doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc5566.txt b/doc/rfc/rfc5566.txt
new file mode 100644
index 0000000..c7eb5eb
--- /dev/null
+++ b/doc/rfc/rfc5566.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          L. Berger
+Request for Comments: 5566                                          LabN
+Category: Standards Track                                       R. White
+                                                                E. Rosen
+                                                           Cisco Systems
+                                                               June 2009
+
+
+                BGP IPsec Tunnel Encapsulation Attribute
+
+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 BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 1]
+
+RFC 5566             BGP IPsec Tunnel Encapsulation            June 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................2
+   2. Tunnel Encapsulation Types ......................................3
+   3. Use of IPsec Tunnel Types .......................................3
+   4. IPsec Tunnel Authenticator sub-TLV ..............................4
+      4.1. Use of the IPsec Tunnel Authenticator sub-TLV ..............5
+   5. Security Considerations .........................................5
+   6. IANA Considerations .............................................6
+   7. References ......................................................7
+      7.1. Normative References .......................................7
+      7.2. Informative References .....................................7
+   8. Acknowledgments .................................................8
+
+1.  Introduction
+
+   The BGP [RFC4271] 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 [RFC4798], and IPv4 prefixes to IPv6 next hops and
+   tunnels using [RFC5549].  The Encapsulation SAFI can also be used to
+   support the mapping of VPN prefixes to tunnels when VPN prefixes are
+   advertised per [RFC4364] or [RFC4659].  [RFC5565] provides useful
+   context for the use of the Encapsulation SAFI.
+
+   The Encapsulation SAFI is defined in [RFC5512].  [RFC5512] also
+   defines support for the GRE [RFC2784], L2TPv3 [RFC3931], and IP in IP
+   [RFC2003] tunnel types.  This document builds on [RFC5512] and
+   defines support for IPsec tunnels.  Support is defined for IP
+   Authentication Header (AH) in tunnel mode [RFC4302] and for IP
+   Encapsulating Security Payload (ESP) in tunnel mode [RFC4303].  The
+   IPsec architecture is defined in [RFC4301].  Support for IP in IP
+   [RFC2003] and MPLS-in-IP [RFC4023] protected by IPsec Transport Mode
+   is also defined.
+
+   The Encapsulation Network Layer Reachability Information (NLRI)
+   Format is not modified by this document.
+
+1.1.  Conventions Used in This Document
+
+   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 [RFC2119].
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 2]
+
+RFC 5566             BGP IPsec Tunnel Encapsulation            June 2009
+
+
+2.  Tunnel Encapsulation Types
+
+   Per [RFC5512], 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 [RFC4302], [RFC4303]
+
+     - IP in IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
+       [RFC2003], [RFC4303]
+
+     - MPLS-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 6
+       [RFC4023]
+
+       Note, see Section 4.3 of [RFC5512] for a discussion on the
+       advertisement and use of multiple tunnel types.
+
+       Note, the specification in [RFC4023] 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 [RFC5512] with these tunnel types.  See below for the definition
+   of a specific sub-TLV for use with the defined tunnel types.
+
+3.  Use of IPsec Tunnel Types
+
+   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
+
+
+
+Berger, et al.              Standards Track                     [Page 3]
+
+RFC 5566             BGP IPsec Tunnel Encapsulation            June 2009
+
+
+   IKEv2 (Internet Key Exchange) [RFC4306], 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 [RFC4301], [RFC4302], and [RFC4303]
+   (and includes keys, Security Parameter Index (SPI) numbers, IPsec
+   protocol, integrity/encryption algorithms, and sequence number mode).
+
+4.  IPsec Tunnel Authenticator sub-TLV
+
+   This document defines a new sub-TLV for use with the Tunnel
+   Encapsulation attribute defined in [RFC5512].  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
+   [RFC5512] 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 Section 3.7 of RFC 4306.
+
+     - 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
+   [RFC2385].
+
+
+
+
+Berger, et al.              Standards Track                     [Page 4]
+
+RFC 5566             BGP IPsec Tunnel Encapsulation            June 2009
+
+
+4.1.  Use of the IPsec Tunnel Authenticator sub-TLV
+
+   If an IPsec Tunnel Authenticator sub-TLV with authenticator type 1 is
+   present in the Encapsulation SAFI update, then R1 (as defined above
+   in Section 3) MUST use IKEv2 [RFC4306] to obtain a certificate from
+   R2 (as defined above in Section 3), 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
+   [RFC4306] 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.
+
+5.  Security Considerations
+
+   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
+   [RFC4302] and ESP [RFC4303].  The security considerations from those
+   documents as well as [RFC4301] apply to the data plane aspects of
+   this document.
+
+   As with [RFC5512], 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 Section 4 may be used.
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 5]
+
+RFC 5566             BGP IPsec Tunnel Encapsulation            June 2009
+
+
+   More broadly, the security considerations for the transport of IP
+   reachability information using BGP are discussed in [RFC4271] and
+   [RFC4272], 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.
+
+6.  IANA Considerations
+
+   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                    [RFC5566]
+
+     4    IPsec in Tunnel-mode                        [RFC5566]
+
+     5    IP in IP tunnel
+             with IPsec Transport Mode                [RFC5566]
+
+     6    MPLS-in-IP tunnel
+             with IPsec Transport Mode                [RFC5566]
+
+   IANA has made the following assignment in the "BGP Tunnel
+   Encapsulation Attribute Sub-TLVs" registry.
+
+   Value  Name                                        Reference
+   -----  ----                                        ---------
+     3    IPsec Tunnel Authenticator                  [RFC5566]
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 6]
+
+RFC 5566             BGP IPsec Tunnel Encapsulation            June 2009
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4271]   Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+               Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
+               2006.
+
+   [RFC4301]   Kent, S. and K. Seo, "Security Architecture for the
+               Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4302]   Kent, S., "IP Authentication Header", RFC 4302, December
+               2005.
+
+   [RFC4303]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+               4303, December 2005.
+
+   [RFC4306]   Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+               Protocol", RFC 4306, December 2005.
+
+   [RFC5512]   Mohapatra, P. and E. Rosen, "The BGP Encapsulation
+               Subsequent Address Family Identifier (SAFI) and the BGP
+               Tunnel Encapsulation Attribute", RFC 5512, April 2009.
+
+7.2.  Informative References
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2385]   Heffernan, A., "Protection of BGP Sessions via the TCP
+               MD5 Signature Option", RFC 2385, August 1998.
+
+   [RFC2784]   Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+               Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+               March 2000.
+
+   [RFC3931]   Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
+               "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC
+               3931, March 2005.
+
+   [RFC4023]   Worster, T., Rekhter, Y., and E. Rosen, Ed.,
+               "Encapsulating MPLS in IP or Generic Routing
+               Encapsulation (GRE)", RFC 4023, March 2005.
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 7]
+
+RFC 5566             BGP IPsec Tunnel Encapsulation            June 2009
+
+
+   [RFC4272]   Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
+               4272, January 2006.
+
+   [RFC4364]   Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+               Networks (VPNs)", RFC 4364, February 2006.
+
+   [RFC4659]   De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
+               "BGP-MPLS IP Virtual Private Network (VPN) Extension for
+               IPv6 VPN", RFC 4659, September 2006.
+
+   [RFC4798]   De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
+               "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
+               Provider Edge Routers (6PE)", RFC 4798, February 2007.
+
+   [RFC5549]   Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
+               Layer Reachability Information with an IPv6 Next Hop",
+               RFC 5549, May 2009.
+
+   [RFC5565]   Wu, J., Cui, Y., Metz, C. and E. Rosen, "Softwire Mesh
+               Framework", RFC 5565, June 2009.
+
+8.  Acknowledgments
+
+   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: lberger@labn.net
+
+   Russ White
+   Cisco Systems
+   EMail: riw@cisco.com
+
+   Eric C. Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA, 01719
+   EMail: erosen@cisco.com
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 8]
+