idnits 2.17.1 draft-ietf-softwire-encaps-ipsec-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 6, 2009) is 5496 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Category: Standards Track Russ White (Cisco Systems) 3 Expiration Date: October 6, 2009 Eric Rosen (Cisco Systems) 5 April 6, 2009 7 BGP IPsec Tunnel Encapsulation Attribute 9 draft-ietf-softwire-encaps-ipsec-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on October 6, 2009. 39 Copyright and License Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 The BGP Encapsulation Subsequence Address Family Identifiers (SAFI) 53 provides a method for the dynamic exchange of encapsulation 54 information, and the indication of encapsulation protocol types to be 55 used for different next hops. Currently support for GRE, L2TPv3 and 56 IP in IP tunnel types are defined. This document defines support for 57 IPsec tunnel types. 59 Table of Contents 61 1 Introduction ........................................... 3 62 1.1 Conventions used in this document ...................... 3 63 2 Tunnel Encapsulation Types ............................. 3 64 3 Use of IPsec Tunnel Types .............................. 4 65 4 IPsec Tunnel Authenticator sub-TLV ..................... 4 66 4.1 Use of the IPsec Tunnel Authenticator sub-TLV .......... 5 67 5 Security Considerations ................................ 6 68 6 IANA Considerations .................................... 7 69 7 References ............................................. 7 70 7.1 Normative References ................................... 7 71 7.2 Informative References ................................. 8 72 8 Acknowledgments ........................................ 9 73 9 Authors' Addresses ..................................... 9 75 1. Introduction 77 The BGP [RFC4271] Encapsulation Subsequence Address Family 78 Identifiers (SAFI) allows for the communication of tunnel information 79 and the association of this information to a BGP next hop. The 80 Encapsulation SAFI can be used to support the mapping of prefixes to 81 next hops and tunnels of the same address family, IPv6 prefixes to 82 IPv4 next hops and tunnels using [RFC4798], and IPv4 prefixes to IPv6 83 next hops and tunnels using [V4NLRI-V6NH]. The Encapsulation SAFI 84 can also be used to support the mapping of VPN prefixes to tunnels 85 when VPN prefixes are advertised per [RFC4364] or [RFC4659]. 86 [SOFTWIRES] provides useful context for the use of the Encapsulation 87 SAFI. 89 The Encapsulation SAFI is defined in [ENCAPS-SAFI]. [ENCAPS-SAFI] 90 also defines support for the GRE [RFC2784], L2TPv3 [RFC3931] and IP 91 in IP [RFC2003] tunnel types. This document builds on [ENCAPS-SAFI] 92 and defines support for IPsec tunnels. Support is defined for IP 93 Authentication Header in Tunnel-mode (AH), [RFC4302], and for IP 94 Encapsulating Security Payload in Tunnel-mode (ESP), [RFC4303]. The 95 IPsec architecture is defined in [RFC4301]. Support for IP in IP, 96 [RFC2003], and MPLS-in-IP, [RFC4023] protected by IPsec Transport 97 Mode is also defined. 99 The Encapsulation NLRI Format is not modified by this document. 101 1.1. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. Tunnel Encapsulation Types 109 Per [ENCAPS-SAFI], tunnel type is indicated in the Tunnel 110 Encapsulation attribute. This document defines the following tunnel 111 type values: 113 - Transmit tunnel endpoint: Tunnel Type = 3 115 - IPsec in Tunnel-mode: Tunnel Type = 4 [RFC4302], [RFC4303] 117 - IP in IP Tunnel with IPsec Transport Mode: Tunnel Type = 5 118 [RFC2003], [RFC4303] 120 - MPLS-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 6 121 [RFC4023] 123 Note, see Section 4.3 of [ENCAPS-SAFI] for a discussion on the 124 advertisement and use of multiple tunnel types. 126 Note, the specification in [RFC4023] for MPLS-in-IP tunnels with 127 IPsec Transport mode applies as well to IP in IP tunnels. 129 This document does not specify the use of the sub-TLV types defined 130 in [ENCAPS-SAFI] with these tunnel types. See below for the 131 definition of a specific sub-TLV for use with the defined tunnel 132 types. 134 3. Use of IPsec Tunnel Types 136 The IPsec Tunnel types are defined above with the values 4, 5 and 6. 137 If a R1 is a BGP speaker that receives an Encapsulation SAFI update 138 from another BGP speaker, R2, then if R1 has any data packets for 139 which R2 is the BGP next hop, R1 MUST initiate an IPsec SA of the 140 specified "tunnel type", and all such data packets MUST be sent 141 through that SA. 143 Let R1 and R2 be two BGP speakers that may send data packets through 144 R3, such that the data packets from R1 and from R2 may be received by 145 R3 over the same interface. In this case, when R3 sends an 146 Encapsulation SAFI which indicates an IPsec tunnel type to R2, then 147 R3 SHOULD also send an update specifying an Encapsulation SAFI with 148 an IPsec tunnel type to R1. That is, on a given interface, if IPsec 149 is required for any data packets, it SHOULD be required for all. 150 This eliminates dependence on the IPsec selector mechanisms to 151 correctly distinguish traffic which needs to be protected from 152 traffic which does not. 154 Security policy has the granularity of BGP speaker to BGP speaker. 155 The required security policies must be configured into the BGP 156 speakers. Policies for each SA will typically be established using 157 IKEv2, [RFC4306], with either public-key or pre-shared key 158 authentication. The SA MAY also be configured via manual techniques. 159 Manual configuration specification and considerations are defined in 160 [RFC4301], [RFC4302] and [RFC4303] (and includes keys, SPI numbers, 161 IPsec protocol, integrity/encryption algorithms, and sequence number 162 mode). 164 4. IPsec Tunnel Authenticator sub-TLV 166 This document defines a new sub-TLV for use with the Tunnel 167 Encapsulation Attribute defined in [ENCAPS-SAFI]. The new sub-TLV is 168 referred to as the "IPsec Tunnel Authenticator sub-TLV", and one or 169 more of the sub-TLVs MAY be included in any Encapsulation SAFI NLRI 170 ([ENCAPS-SAFI]) indicating a Tunnel Type defined in this document. 171 Support for the IPsec Tunnel Authenticator sub-TLV MUST be 172 implemented whenever the tunnel types defined in this document are 173 implemented. However, its use is OPTIONAL, and is a matter of 174 policy. 176 The sub-TLV type of the IPsec Tunnel Authenticator sub-TLV is 3. The 177 sub-TLV length is variable. The structure of the sub-TLV is as 178 follows: 180 - Authenticator Type: two octets 182 This document defines authenticator type 1, "SHA-1 hash of public 183 key", as defined in section 3.7 of RFC 4306. 185 - Value: (variable) 187 A value used to authenticate the BGP speaker that generated this 188 NLRI. The length of this field is is not encoded explicitly, but 189 can be calculated as (sub-TLV length - 2). 191 In the case of authenticator type 1, this field contains the 192 20-octet value of the hash. 194 A BGP speaker which sends the IPsec Tunnel Authenticator sub-TLV with 195 authenticator type 1 MUST be configured with a private key, public 196 key pair, the public key being the key whose hash is sent in the 197 value field of the sub-TLV. The BGP speaker MUST either (a) be able 198 to generate a self-signed certificate for the public key, or else (b) 199 be configured with a certificate for the public key. 201 When the IPsec Tunnel Authenticator sub-TLV is used, it is highly 202 RECOMMENDED that the integrity of the BGP session itself be 203 protected. This is usually done by using the TCP MD5 option 204 [RFC2385]. 206 4.1. Use of the IPsec Tunnel Authenticator sub-TLV 208 If a IPsec Tunnel Authenticator sub-TLV with authenticator type 1 is 209 present in the Encapsulation SAFI update, then R1 (as defined above 210 in Section 3) MUST use IKEv2 [RFC4306] to obtain a certificate from 211 R2 (as defined above in Section 3), and R2 MUST send a certificate 212 for the public key whose hash occurred in the value field of the 213 IPsec Tunnel Authenticator sub-TLV. R1 MUST NOT attempt to establish 214 an SA to R2 UNLESS the public key in the certificate hashes to the 215 same value that occurs in one of the IPsec Tunnel Authenticator sub- 216 TLVs. 218 R2 MUST also perform the reciprocal processing. Specifically, when 219 establishing an SA from R1 and R1 has advertised the IPsec Tunnel 220 Authenticator sub-TLV with authenticator type 1, R2 MUST use IKEv2 221 [RFC4306] to obtain a certificate from R1, and R1 MUST send a 222 certificate for the public key whose hash occurred in the value field 223 of the IPsec Tunnel Authenticator sub-TLV. R2 MUST NOT attempt 224 establish an SA to R1 UNLESS the public key in the certificate hashes 225 to the same value that occurs in one of the IPsec Tunnel 226 Authenticator sub-TLVs. 228 Note that the "Transmit tunnel endpoint" tunnel type (value = 3) may 229 be used by BGP speaker that does not want to be the receiving 230 endpoint of an IPsec tunnel, but only the transmitting endpoint. 232 5. Security Considerations 234 This document uses IP based tunnel technologies to support data plane 235 transport. Consequently, the security considerations of those tunnel 236 technologies apply. This document defines support for IPsec AH 237 [RFC4302] and ESP [RFC4303]. The security considerations from those 238 documents as well as [RFC4301] apply to the data plane aspects of 239 this document. 241 As with [ENCAPS-SAFI], any modification of the information that is 242 used to form encapsulation headers, or to choose a tunnel type, or to 243 choose a particular tunnel for a particular payload type, user data 244 packets may end up getting misrouted, misdelivered, and/or dropped. 245 Misdelivery is less of an issue when IPsec is used as such 246 misdelivery is likely to result in a failure of authentication or 247 decryption at the receiver. Furthermore, in environments where 248 authentication of BGP speakers is desired, the IPsec Tunnel 249 Authenticator sub-TLV defined in Section 4 may be used. 251 More broadly, the security considerations for the transport of IP 252 reachability information using BGP are discussed in [RFC4271] and 253 [RFC4272], and are equally applicable for the extensions described in 254 this document. 256 If the integrity of the BGP session is not itself protected, then an 257 imposter could mount a denial of service attack by establishing 258 numerous BGP sessions and forcing an IPsec SAs to be created for each 259 one. However, as such an imposter could wreak havoc on the entire 260 routing system, this particular sort of attack is probably not of any 261 special importance. 263 It should be noted that a BGP session may itself be transported over 264 an IPsec tunnel. Such IPsec tunnels can provide additional security 265 to a BGP session. The managment of such IPsec tunnels is outside the 266 scope of this document. 268 6. IANA Considerations 270 IANA is requested to administer assignment of new namespaces and new 271 values for namespaces defined in this document and reviewed in this 272 section. 274 Upon approval of this document, the IANA will make the assignment in 275 the "BGP Tunnel Encapsulation Attribute Tunnel Types" and the "BGP 276 Tunnel Encapsulation Attribute Sub-TLVs" registries. 278 Tunnel Type Reference 279 ----------- --------- 280 Reserved: Type = 3 [This document] 281 IPsec in Tunnel-mode: Type = 4 [This document] 282 IP in IP tunnel 283 with IPsec Transport Mode: Type = 5 [This document] 284 MPLS-in-IP tunnel 285 with IPsec Transport Mode: Type = 6 [This document] 287 Tunnel Type Sub-TLV Type Reference 288 ----------- ------------ --------- 289 3,4,5,6 IPsec Tunnel Authenticator: Type = 3 [This document] 291 7. References 293 7.1. Normative References 295 [ENCAPS-SAFI] Mohapatra, P., Rosen, E., "BGP Information SAFI 296 and BGP Tunnel Encapsulation Attribute", Work in 297 Progress, draft-ietf-softwire-encaps-safi-05.txt, 298 February 2009. 300 [RFC4271] Rekhter, Y., Ed. et al, "A Border Gateway Protocol 4 301 (BGP-4)", RFC 4271, January 2006. 303 [RFC4301] Kent, S., Seo, K., "Security Architecture for the 304 Internet Protocol", RFC 4301, December 2005. 306 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 307 December 2005. 309 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 310 RFC 4303, December 2005. 312 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 313 Protocol", RFC 4306, December 2005. 315 7.2. Informative References 317 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 318 October 1996. 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels," RFC 2119. 323 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP 324 MD5 Signature Option", RFC 2385, August 1998. 326 [RFC2784] Farinacci, D., et al, "Generic Routing Encapsulation 327 (GRE)", RFC 2784, March 2000. 329 [RFC3931] Lau, J., Ed., et al, "Layer Two Tunneling Protocol - 330 Version 3 (L2TPv3)", RFC 3931, March 2005. 332 [RFC4023] Worster, T., Rekhter, Y., Rosen, E., Ed., 333 "Encapsulating MPLS in IP or Generic Routing 334 Encapsulation (GRE)", RFC 4023, March 2005. 336 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 337 RFC 4272, January 2006. 339 [RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private 340 Networks (VPNs)", RFC 4364, February 2006. 342 [RFC4659] De Clercq, J., et al, "BGP-MPLS IP Virtual Private 343 Network (VPN) Extension for IPv6 VPN", RFC 4659, 344 September 2006. 346 [RFC4798] J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur, 347 "Connecting IPv6 Islands over IPv4 MPLS using IPv6 348 Provider Edge Routers (6PE)", RFC 4798, February 2007. 350 [SOFTWIRES] Wu, J. et al, "Softwire Mesh Framework", Work in 351 Progress, draft-ietf-softwire-mesh-framework-06.txt, 352 February, 2009. 354 [V4NLRI-V6NH] F. Le Faucheur, E. Rosen, "Advertising an IPv4 NLRI 355 with an IPv6 Next Hop", Work in Progress, 356 draft-ietf-idr-v4nlri-v6nh-01.txt, October 2007. 358 8. Acknowledgments 360 The authors wish to thank Sam Hartman and Tero Kivinen for their help 361 with the security-related issues. 363 9. Authors' Addresses 365 Lou Berger 366 LabN Consulting, L.L.C. 367 Phone: +1-301-468-9228 368 Email: lberger@labn.net 370 Russ White 371 Cisco Systems 372 Email: riw@cisco.com 374 Eric C. Rosen 375 Cisco Systems, Inc. 376 1414 Massachusetts Avenue 377 Boxborough, MA, 01719 378 Email: erosen@cisco.com 380 Generated on: Mon Apr 6 13:42:02 EDT 2009