5566
PROPOSED STANDARD
BGP IPsec Tunnel Encapsulation Attribute (Obsoleted)
Authors: L. Berger, R. White, E. Rosen
Date: June 2009
Area: int
Working Group: softwire
Stream: IETF
Obsoleted by:
RFC 9012
Abstract
The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), and IP in IP tunnel types are defined. This document defines support for IPsec tunnel types. [STANDARDS-TRACK]
RFC 5566
Obsoleted by: 9012 PROPOSED STANDARD
Network Working Group L. Berger
Request for Comments: 5566 LabN
Category: Standards Track R. White
E. Rosen
Cisco Systems
June 2009
<span class="h1">BGP IPsec Tunnel Encapsulation Attribute</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The BGP Encapsulation Subsequent Address Family Identifier (SAFI)
provides a method for the dynamic exchange of encapsulation
information and for the indication of encapsulation protocol types to
be used for different next hops. Currently, support for Generic
Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), and
IP in IP tunnel types are defined. This document defines support for
IPsec tunnel types.
<span class="grey">Berger, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc5566">RFC 5566</a> BGP IPsec Tunnel Encapsulation June 2009</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document ..........................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Tunnel Encapsulation Types ......................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Use of IPsec Tunnel Types .......................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. IPsec Tunnel Authenticator sub-TLV ..............................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Use of the IPsec Tunnel Authenticator sub-TLV ..............<a href="#page-5">5</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-5">5</a>
<a href="#section-6">6</a>. IANA Considerations .............................................<a href="#page-6">6</a>
<a href="#section-7">7</a>. References ......................................................<a href="#page-7">7</a>
<a href="#section-7.1">7.1</a>. Normative References .......................................<a href="#page-7">7</a>
<a href="#section-7.2">7.2</a>. Informative References .....................................<a href="#page-7">7</a>
<a href="#section-8">8</a>. Acknowledgments .................................................<a href="#page-8">8</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The BGP [<a href="./rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>] Encapsulation Subsequent Address Family Identifier
(SAFI) allows for the communication of tunnel information and for the
association of this information to a BGP next hop. The Encapsulation
SAFI can be used to support the mapping of prefixes to next hops and
tunnels of the same address family, IPv6 prefixes to IPv4 next hops
and tunnels using [<a href="./rfc4798" title=""Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)"">RFC4798</a>], and IPv4 prefixes to IPv6 next hops and
tunnels using [<a href="./rfc5549" title=""Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop"">RFC5549</a>]. The Encapsulation SAFI can also be used to
support the mapping of VPN prefixes to tunnels when VPN prefixes are
advertised per [<a href="./rfc4364" title=""BGP/MPLS IP Virtual Private Networks (VPNs)"">RFC4364</a>] or [<a href="./rfc4659" title=""BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN"">RFC4659</a>]. [<a href="./rfc5565" title=""Softwire Mesh Framework"">RFC5565</a>] provides useful
context for the use of the Encapsulation SAFI.
The Encapsulation SAFI is defined in [<a href="./rfc5512" title=""The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute"">RFC5512</a>]. [<a href="./rfc5512" title=""The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute"">RFC5512</a>] also
defines support for the GRE [<a href="./rfc2784" title=""Generic Routing Encapsulation (GRE)"">RFC2784</a>], L2TPv3 [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>], and IP in IP
[<a href="./rfc2003" title=""IP Encapsulation within IP"">RFC2003</a>] tunnel types. This document builds on [<a href="./rfc5512" title=""The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute"">RFC5512</a>] and
defines support for IPsec tunnels. Support is defined for IP
Authentication Header (AH) in tunnel mode [<a href="./rfc4302" title=""IP Authentication Header"">RFC4302</a>] and for IP
Encapsulating Security Payload (ESP) in tunnel mode [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>]. The
IPsec architecture is defined in [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>]. Support for IP in IP
[<a href="./rfc2003" title=""IP Encapsulation within IP"">RFC2003</a>] and MPLS-in-IP [<a href="./rfc4023" title=""Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)"">RFC4023</a>] protected by IPsec Transport Mode
is also defined.
The Encapsulation Network Layer Reachability Information (NLRI)
Format is not modified by this document.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Berger, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc5566">RFC 5566</a> BGP IPsec Tunnel Encapsulation June 2009</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Tunnel Encapsulation Types</span>
Per [<a href="./rfc5512" title=""The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute"">RFC5512</a>], tunnel type is indicated in the Tunnel Encapsulation
attribute. This document defines the following tunnel type values:
- Transmit tunnel endpoint: Tunnel Type = 3
- IPsec in Tunnel-mode: Tunnel Type = 4 [<a href="./rfc4302" title=""IP Authentication Header"">RFC4302</a>], [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>]
- IP in IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
[<a href="./rfc2003" title=""IP Encapsulation within IP"">RFC2003</a>], [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>]
- MPLS-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 6
[<a href="./rfc4023" title=""Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)"">RFC4023</a>]
Note, see <a href="./rfc5512#section-4.3">Section 4.3 of [RFC5512]</a> for a discussion on the
advertisement and use of multiple tunnel types.
Note, the specification in [<a href="./rfc4023" title=""Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)"">RFC4023</a>] for MPLS-in-IP tunnels with
IPsec Transport mode applies as well to IP in IP tunnels.
This document does not specify the use of the sub-TLV types defined
in [<a href="./rfc5512" title=""The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute"">RFC5512</a>] with these tunnel types. See below for the definition
of a specific sub-TLV for use with the defined tunnel types.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Use of IPsec Tunnel Types</span>
The IPsec tunnel types are defined above with the values 4, 5, and 6.
If R1 is a BGP speaker that receives an Encapsulation SAFI update
from another BGP speaker, R2, then if R1 has any data packets for
which R2 is the BGP next hop, R1 MUST initiate an IPsec SA (security
association) of the specified "tunnel type", and all such data
packets MUST be sent through that SA.
Let R1 and R2 be two BGP speakers that may send data packets through
R3, such that the data packets from R1 and from R2 may be received by
R3 over the same interface. In this case, when R3 sends an
Encapsulation SAFI that indicates an IPsec tunnel type to R2, then R3
SHOULD also send an update specifying an Encapsulation SAFI with an
IPsec tunnel type to R1. That is, on a given interface, if IPsec is
required for any data packets, it SHOULD be required for all. This
eliminates dependence on the IPsec selector mechanisms to correctly
distinguish traffic that needs to be protected from traffic that does
not.
Security policy has the granularity of BGP speaker to BGP speaker.
The required security policies must be configured into the BGP
speakers. Policies for each SA will typically be established using
<span class="grey">Berger, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc5566">RFC 5566</a> BGP IPsec Tunnel Encapsulation June 2009</span>
IKEv2 (Internet Key Exchange) [<a href="./rfc4306" title=""Internet Key Exchange (IKEv2) Protocol"">RFC4306</a>], with either public-key or
pre-shared key authentication. The SA MAY also be configured via
manual techniques. Manual configuration specification and
considerations are defined in [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>], [<a href="./rfc4302" title=""IP Authentication Header"">RFC4302</a>], and [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>]
(and includes keys, Security Parameter Index (SPI) numbers, IPsec
protocol, integrity/encryption algorithms, and sequence number mode).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IPsec Tunnel Authenticator sub-TLV</span>
This document defines a new sub-TLV for use with the Tunnel
Encapsulation attribute defined in [<a href="./rfc5512" title=""The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute"">RFC5512</a>]. The new sub-TLV is
referred to as the "IPsec Tunnel Authenticator sub-TLV", and one or
more of the sub-TLVs MAY be included in any Encapsulation SAFI NLRI
[<a href="./rfc5512" title=""The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute"">RFC5512</a>] indicating a tunnel type defined in this document. Support
for the IPsec Tunnel Authenticator sub-TLV MUST be implemented
whenever the tunnel types defined in this document are implemented.
However, its use is OPTIONAL, and is a matter of policy.
The sub-TLV type of the IPsec Tunnel Authenticator sub-TLV is 3. The
sub-TLV length is variable. The structure of the sub-TLV is as
follows:
- Authenticator Type: two octets
This document defines authenticator type 1, "SHA-1 hash of public
key", as defined in <a href="./rfc4306#section-3.7">Section 3.7 of RFC 4306</a>.
- Value: (variable)
A value used to authenticate the BGP speaker that generated this
NLRI. The length of this field is not encoded explicitly, but
can be calculated as (sub-TLV length - 2).
In the case of authenticator type 1, this field contains the
20-octet value of the hash.
A BGP speaker that sends the IPsec Tunnel Authenticator sub-TLV with
authenticator type 1 MUST be configured with a private key / public
key pair, the public key being the key whose hash is sent in the
value field of the sub-TLV. The BGP speaker MUST either (a) be able
to generate a self-signed certificate for the public key, or else (b)
be configured with a certificate for the public key.
When the IPsec Tunnel Authenticator sub-TLV is used, it is highly
RECOMMENDED that the integrity of the BGP session itself be
protected. This is usually done by using the TCP MD5 option
[<a href="./rfc2385" title=""Protection of BGP Sessions via the TCP MD5 Signature Option"">RFC2385</a>].
<span class="grey">Berger, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc5566">RFC 5566</a> BGP IPsec Tunnel Encapsulation June 2009</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Use of the IPsec Tunnel Authenticator sub-TLV</span>
If an IPsec Tunnel Authenticator sub-TLV with authenticator type 1 is
present in the Encapsulation SAFI update, then R1 (as defined above
in <a href="#section-3">Section 3</a>) MUST use IKEv2 [<a href="./rfc4306" title=""Internet Key Exchange (IKEv2) Protocol"">RFC4306</a>] to obtain a certificate from
R2 (as defined above in <a href="#section-3">Section 3</a>), and R2 MUST send a certificate
for the public key whose hash occurred in the value field of the
IPsec Tunnel Authenticator sub-TLV. R1 MUST NOT attempt to establish
an SA to R2 UNLESS the public key in the certificate hashes to the
same value that occurs in one of the IPsec Tunnel Authenticator sub-
TLVs.
R2 MUST also perform the reciprocal processing. Specifically, when
establishing an SA from R1 and R1 has advertised the IPsec Tunnel
Authenticator sub-TLV with authenticator type 1, R2 MUST use IKEv2
[<a href="./rfc4306" title=""Internet Key Exchange (IKEv2) Protocol"">RFC4306</a>] to obtain a certificate from R1, and R1 MUST send a
certificate for the public key whose hash occurred in the value field
of the IPsec Tunnel Authenticator sub-TLV. R2 MUST NOT attempt to
establish an SA to R1 UNLESS the public key in the certificate hashes
to the same value that occurs in one of the IPsec Tunnel
Authenticator sub-TLVs.
Note that the "Transmit tunnel endpoint" tunnel type (value = 3) may
be used by a BGP speaker that does not want to be the receiving
endpoint of an IPsec tunnel but only the transmitting endpoint.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This document uses IP-based tunnel technologies to support data plane
transport. Consequently, the security considerations of those tunnel
technologies apply. This document defines support for IPsec AH
[<a href="./rfc4302" title=""IP Authentication Header"">RFC4302</a>] and ESP [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>]. The security considerations from those
documents as well as [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>] apply to the data plane aspects of
this document.
As with [<a href="./rfc5512" title=""The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute"">RFC5512</a>], any modification of the information that is used
to form encapsulation headers, to choose a tunnel type, or to choose
a particular tunnel for a particular payload type may lead to user
data packets getting misrouted, misdelivered, and/or dropped.
Misdelivery is less of an issue when IPsec is used, as such
misdelivery is likely to result in a failure of authentication or
decryption at the receiver. Furthermore, in environments where
authentication of BGP speakers is desired, the IPsec Tunnel
Authenticator sub-TLV defined in <a href="#section-4">Section 4</a> may be used.
<span class="grey">Berger, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc5566">RFC 5566</a> BGP IPsec Tunnel Encapsulation June 2009</span>
More broadly, the security considerations for the transport of IP
reachability information using BGP are discussed in [<a href="./rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>] and
[<a href="./rfc4272" title=""BGP Security Vulnerabilities Analysis"">RFC4272</a>], and are equally applicable for the extensions described in
this document.
If the integrity of the BGP session is not itself protected, then an
imposter could mount a denial-of-service attack by establishing
numerous BGP sessions and forcing an IPsec SA to be created for each
one. However, as such an imposter could wreak havoc on the entire
routing system, this particular sort of attack is probably not of any
special importance.
It should be noted that a BGP session may itself be transported over
an IPsec tunnel. Such IPsec tunnels can provide additional security
to a BGP session. The management of such IPsec tunnels is outside
the scope of this document.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
IANA administers the assignment of new namespaces and new values for
namespaces defined in this document and reviewed in this section.
IANA has made the following assignments in the "BGP Tunnel
Encapsulation Attribute Tunnel Types" registry.
Value Name Reference
----- ---- ---------
3 Transmit tunnel endpoint [<a href="./rfc5566">RFC5566</a>]
4 IPsec in Tunnel-mode [<a href="./rfc5566">RFC5566</a>]
5 IP in IP tunnel
with IPsec Transport Mode [<a href="./rfc5566">RFC5566</a>]
6 MPLS-in-IP tunnel
with IPsec Transport Mode [<a href="./rfc5566">RFC5566</a>]
IANA has made the following assignment in the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry.
Value Name Reference
----- ---- ---------
3 IPsec Tunnel Authenticator [<a href="./rfc5566">RFC5566</a>]
<span class="grey">Berger, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc5566">RFC 5566</a> BGP IPsec Tunnel Encapsulation June 2009</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC4271">RFC4271</a>] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", <a href="./rfc4271">RFC 4271</a>, January
2006.
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
[<a id="ref-RFC4302">RFC4302</a>] Kent, S., "IP Authentication Header", <a href="./rfc4302">RFC 4302</a>, December
2005.
[<a id="ref-RFC4303">RFC4303</a>] Kent, S., "IP Encapsulating Security Payload (ESP)", <a href="./rfc4303">RFC</a>
<a href="./rfc4303">4303</a>, December 2005.
[<a id="ref-RFC4306">RFC4306</a>] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", <a href="./rfc4306">RFC 4306</a>, December 2005.
[<a id="ref-RFC5512">RFC5512</a>] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", <a href="./rfc5512">RFC 5512</a>, April 2009.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC2003">RFC2003</a>] Perkins, C., "IP Encapsulation within IP", <a href="./rfc2003">RFC 2003</a>,
October 1996.
[<a id="ref-RFC2385">RFC2385</a>] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", <a href="./rfc2385">RFC 2385</a>, August 1998.
[<a id="ref-RFC2784">RFC2784</a>] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", <a href="./rfc2784">RFC 2784</a>,
March 2000.
[<a id="ref-RFC3931">RFC3931</a>] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)", <a href="./rfc3931">RFC</a>
<a href="./rfc3931">3931</a>, March 2005.
[<a id="ref-RFC4023">RFC4023</a>] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", <a href="./rfc4023">RFC 4023</a>, March 2005.
<span class="grey">Berger, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc5566">RFC 5566</a> BGP IPsec Tunnel Encapsulation June 2009</span>
[<a id="ref-RFC4272">RFC4272</a>] Murphy, S., "BGP Security Vulnerabilities Analysis", <a href="./rfc4272">RFC</a>
<a href="./rfc4272">4272</a>, January 2006.
[<a id="ref-RFC4364">RFC4364</a>] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", <a href="./rfc4364">RFC 4364</a>, February 2006.
[<a id="ref-RFC4659">RFC4659</a>] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", <a href="./rfc4659">RFC 4659</a>, September 2006.
[<a id="ref-RFC4798">RFC4798</a>] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", <a href="./rfc4798">RFC 4798</a>, February 2007.
[<a id="ref-RFC5549">RFC5549</a>] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
Layer Reachability Information with an IPv6 Next Hop",
<a href="./rfc5549">RFC 5549</a>, May 2009.
[<a id="ref-RFC5565">RFC5565</a>] Wu, J., Cui, Y., Metz, C. and E. Rosen, "Softwire Mesh
Framework", <a href="./rfc5565">RFC 5565</a>, June 2009.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
The authors wish to thank Sam Hartman and Tero Kivinen for their help
with the security-related issues.
Authors' Addresses
Lou Berger
LabN Consulting, L.L.C.
Phone: +1-301-468-9228
EMail: [email protected]
Russ White
Cisco Systems
EMail: [email protected]
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
EMail: [email protected]
Berger, et al. Standards Track [Page 8]
Annotations
Select text to annotate