idnits 2.17.1 draft-berger-idr-encaps-ipsec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 349. 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 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 (February 25, 2008) is 5905 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) -- Possible downref: Normative reference to a draft: ref. 'ENCAPS-SAFI' == Outdated reference: A later version (-06) exists of draft-ietf-softwire-mesh-framework-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 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: August 25, 2008 Eric Rosen (Cisco Systems) 5 February 25, 2008 7 BGP IPSec Tunnel Encapsulation Attribute 9 draft-berger-idr-encaps-ipsec-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on August 25, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The BGP Encapsulation Subsequence Address Family Identifiers (SAFI) 43 provides a method for the dynamic exchange of encapsulation 44 information, and the indication of encapsulation protocol types to be 45 used for different next hops. Currently support for GRE and L2TPv3 46 tunnel types are defined. This document defines support for IPsec 47 tunnel types. 49 Contents 51 1 Introduction .............................................. 3 52 1.1 Conventions used in this document ......................... 3 53 2 IPsec Tunnel Encapsulation Types .......................... 3 54 3 Use of IPsec .............................................. 4 55 4 IPsec Tunnel Authenticator sub-TLV ........................ 4 56 4.1 Use of the IPsec Tunnel Authenticator sub-TLV ............. 5 57 5 Security Considerations ................................... 5 58 6 IANA Considerations ....................................... 6 59 7 References ................................................ 6 60 7.1 Normative References ...................................... 6 61 7.2 Informative References .................................... 7 62 8 Acknowledgments ........................................... 8 63 9 Authors' Addresses ........................................ 8 64 10 Full Copyright Statement .................................. 8 65 11 Intellectual Property ..................................... 9 66 1. Introduction 68 The BGP [RFC4271] Encapsulation Subsequence Address Family 69 Identifiers (SAFI) allows for the communication of tunnel information 70 and the association of this information to a BGP next hop. The 71 Encapsulation SAFI can be used to support the mapping of prefixes to 72 next hops and tunnels of the same address family, IPv6 prefixes to 73 IPv4 next hops and tunnels using [RFC4798], and IPv4 prefixes to IPv6 74 next hops and tunnels using [V4NLRI-V6NH]. The Encapsulation SAFI 75 can also be used to support the mapping of VPN prefixes to tunnels 76 when VPN prefixes are advertised per [RFC4364] or [RFC4659]. 77 [SOFTWIRES] provides useful context for the use of the Encapsulation 78 SAFI. 80 The Encapsulation SAFI is defined in [ENCAPS-SAFI]. [ENCAPS-SAFI] 81 also defines support for the GRE [RFC2784] and L2TPv3 [RFC3931] 82 tunnel types. This document builds on [ENCAPS-SAFI] and defines 83 support for IPsec tunnels. Support is defined for IP Authentication 84 Header in Tunnel-mode (AH), [RFC4302], and for IP Encapsulating 85 Security Payload in Tunnel-mode (ESP), [RFC4303]. Support for IP-in- 86 IP, [RFC2003], and MPLS-in-IP, [RFC4023] protected by IPsec Transport 87 Mode is also defined. 89 The Encapsulation NLRI Format is not modified by this document. 91 1.1. Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. IPsec Tunnel Encapsulation Types 99 Per [ENCAPS-SAFI], tunnel type is indicated in the Tunnel 100 Encapsulation attribute. This document defines the following tunnel 101 type values: 103 - AH in Tunnel-mode: Tunnel Type = 3 105 - ESP in Tunnel-mode: Tunnel Type = 4 107 - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5 108 - MPLS-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 6 110 Note, see Section 4.3 of [ENCAPS-SAFI] for a discussion on the 111 advertisement and use of multiple tunnel types. 113 This document does not specify the use of the sub-TLV types defined 114 in [ENCAPS-SAFI] with these tunnel types. See below for the 115 definition of an IPsec tunnel type specific sub-TLV. 117 3. Use of IPsec 119 If a R1 is a BGP speaker that receives an Encapsulation SAFI update 120 from another BGP speaker, R2, then if R1 has any data packets for 121 which R2 is the BGP next hop, R1 MUST initiate an IPsec SA of the 122 specified "tunnel type", and all such data packets MUST be sent 123 through that SA. 125 Let R1 and R2 be two BGP speakers that may send data packets through 126 R3, such that the data packets from R1 and from R2 may be received by 127 R3 over the same interface. Then if R3 has sent an update containing 128 an Encapsulation SAFI, and if this update specifies an IPsec tunnel 129 type, and if this update is received by R2, and an Encapsulation-SAFI 130 with an IPsec tunnel type, MUST also be received by R1. That is, on 131 a given interface, if IPsec is required for any data packets, it MUST 132 be required for all. It does not necessarily need to be required for 133 control packets that are directly addressed to R3. 135 Security policy has the granularity of BGP speaker to BGP speaker. 136 The required security policies must be configured into the BGP 137 speakers, and the policy for each SA is negotiated via IKE. 139 4. IPsec Tunnel Authenticator sub-TLV 141 This document defines a new sub-TLV for use with the Tunnel 142 Encapsulation Attribute defined in [ENCAPS-SAFI]. The new sub-TLV is 143 referred to as the "IPsec Tunnel Authenticator sub-TLV" and MAY be 144 included in any Encapsulation SAFI NLRI ([ENCAPS-SAFI]) indicating a 145 Tunnel Type defined in this document. Support for the IPsec Tunnel 146 Authenticator sub-TLV" MUST be implemented whenever the tunnel types 147 defined in this document are implemented. However, its use is 148 OPTIONAL, and is a matter of policy. 150 The sub-TLV type of the IPsec Tunnel Authenticator sub-TLV is 3. The 151 sub-TLV length is variable. The structure of the sub-TLV is as 152 follows: 154 - Authenticator Type: two octets 156 This document defines authenticator type 1, "SHA-1 hash of public 157 key", as defined in section 3.7 of RFC 4306. 159 - Value: (variable) 161 A value used to authenticate the BGP speaker that generated this 162 NLRI. The length of this field is is not encoded explicitly, but 163 can be calculated as (sub-TLV length - 2). 165 In the case of authenticator type 1, this field contains the 166 20-octet value of the hash. 168 A BGP speaker which sends the IPsec Tunnel Authenticator sub-TLV with 169 authenticator type 1 MUST be configured with a certificate containing 170 the public key whose hash is sent in the value field of the sub-TLV. 171 This certificate MAY be self-signed. 173 4.1. Use of the IPsec Tunnel Authenticator sub-TLV 175 If a IPsec Tunnel Authenticator sub-TLV with authenticator type 1 is 176 present in the Encapsulation SAFI update, then R1 (as defined above 177 in Section 3) must use IKE to obtain a certificate from R2 (as 178 defined above in Section 3), and R2 must send a certificate 179 containing the public key whose hash occurred in the value field of 180 the IPsec Tunnel Authenticator sub-TLV. R1 MUST NOT attempt to 181 establish an SA to R2 UNLESS the public key in the certificate hashes 182 to the same value that occurs in the IPsec Tunnel Authenticator sub- 183 TLV. 185 5. Security Considerations 187 This document uses IP based tunnel technologies to support data plane 188 transport. Consequently, the security considerations of those tunnel 189 technologies apply. This document defines support for IPsec AH 190 [RFC4302] and ESP [RFC4303]. The security considerations from those 191 documents apply to the data plane aspects of this document. 193 As with [ENCAPS-SAFI], any modification of the information that is 194 used to form encapsulation headers, or to choose a tunnel type, or to 195 choose a particular tunnel for a particular payload type, user data 196 packets may end up getting misrouted, misdelivered, and/or dropped. 197 Misdelivery is less of an issue when IPsec is used as such 198 misdelivery is likely to result in a failure of authentication or 199 decryption at the receiver. Furthermore, in environments where 200 authentication of BGP speakers is desired, the IPsec Tunnel 201 Authenticator sub-TLV defined in Section 4 may be used. 203 More broadly, the security considerations for the transport of IP 204 reachability information using BGP are discussed in [RFC4271] and 205 [RFC4272], and are equally applicable for the extensions described in 206 this document. 208 6. IANA Considerations 210 IANA is requested to administer assignment of new namespaces and new 211 values for namespaces defined in this document and reviewed in this 212 section. 214 Upon approval of this document, the IANA will make the assignment in 215 the Tunnel TLVs and sub-TLVs section of the registry. 217 Tunnel Type Reference 218 ----------- --------- 219 AH: Type = 3 [This document] 220 ESP: Type = 4 [This document] 221 IP-in-IP tunnel 222 with IPsec Transport Mode: Type = 5 [This document] 223 MPLS-in-IP tunnel 224 with IPsec Transport Mode: Type = 6 [This document] 226 Tunnel Type Sub-TLV Type Reference 227 ----------- ------------ --------- 228 3,4,5,6 IPsec Tunnel Authenticator: Type = 3 [This document] 230 7. References 232 7.1. Normative References 234 [ENCAPS-SAFI] Mohapatra, P., Rosen, E., "BGP Information SAFI 235 and BGP Tunnel Encapsulation Attribute", Work in 236 Progress, draft-ietf-idr-encaps-safi-00.txt, 237 August 2007. 239 [RFC4271] Rekhter, Y., Ed. et al, "A Border Gateway Protocol 4 240 (BGP-4)", RFC 4271, January 2006. 242 7.2. Informative References 244 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 245 October 1996. 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels," RFC 2119. 250 [RFC2784] Farinacci, D., et al, "Generic Routing Encapsulation 251 (GRE)", RFC 2784, March 2000. 253 [RFC3931] Lau, J., Ed., et al, "Layer Two Tunneling Protocol - 254 Version 3 (L2TPv3)", RFC 3931, March 2005. 256 [RFC4023] Worster, T., Rekhter, Y., Rosen, E., Ed., 257 "Encapsulating MPLS in IP or Generic Routing 258 Encapsulation (GRE)", RFC 4023, March 2005. 260 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 261 RFC 4272, January 2006. 263 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 264 December 2005. 266 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)" 267 RFC 4303, December 2005. 269 [RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private 270 Networks (VPNs)", RFC 4364, February 2006. 272 [RFC4659] De Clercq, J., et al, "BGP-MPLS IP Virtual Private 273 Network (VPN) Extension for IPv6 VPN", RFC 4659, 274 September 2006. 276 [RFC4798] J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur, 277 "Connecting IPv6 Islands over IPv4 MPLS using IPv6 278 Provider Edge Routers (6PE)", RFC 4798, February 2007. 280 [SOFTWIRES] Wu, J. et al, "Softwire Mesh Framework", Work in 281 Progress, draft-ietf-softwire-mesh-framework-03.txt, 282 January 2008. 284 [V4NLRI-V6NH] F. Le Faucheur, E. Rosen, "Advertising an IPv4 NLRI 285 with an IPv6 Next Hop", Work in Progress, 286 draft-ietf-idr-v4nlri-v6nh-01.txt, October 2007. 288 8. Acknowledgments 290 The authors wish to thank Sam Hartman and Tero Kivinen for their help 291 with the security-related issues. However, it should be noted that 292 they have not reviewed this revision of the draft. 294 9. Authors' Addresses 296 Lou Berger 297 LabN Consulting, L.L.C. 298 Phone: +1-301-468-9228 299 Email: lberger@labn.net 301 Russ White 302 Cisco Systems 303 Email: riw@cisco.com 305 Eric C. Rosen 306 Cisco Systems, Inc. 307 1414 Massachusetts Avenue 308 Boxborough, MA, 01719 309 Email: erosen@cisco.com 311 10. Full Copyright Statement 313 Copyright (C) The IETF Trust (2008). 315 This document is subject to the rights, licenses and restrictions 316 contained in BCP 78, and except as set forth therein, the authors 317 retain all their rights. 319 This document and the information contained herein are provided on an 320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 322 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 323 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 324 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 327 11. Intellectual Property 329 The IETF takes no position regarding the validity or scope of any 330 Intellectual Property Rights or other rights that might be claimed 331 to pertain to the implementation or use of the technology 332 described in this document or the extent to which any license 333 under such rights might or might not be available; nor does it 334 represent that it has made any independent effort to identify any 335 such rights. Information on the procedures with respect to rights 336 in RFC documents can be found in BCP 78 and BCP 79. 338 Copies of IPR disclosures made to the IETF Secretariat and any 339 assurances of licenses to be made available, or the result of an 340 attempt made to obtain a general license or permission for the use 341 of such proprietary rights by implementers or users of this 342 specification can be obtained from the IETF on-line IPR repository 343 at http://www.ietf.org/ipr. 345 The IETF invites any interested party to bring to its attention 346 any copyrights, patents or patent applications, or other 347 proprietary rights that may cover technology that may be required 348 to implement this standard. Please address the information to the 349 IETF at ietf-ipr@ietf.org. 351 Acknowledgement 353 Funding for the RFC Editor function is provided by the IETF 354 Administrative Support Activity (IASA). 356 Generated on: Thu Feb 21 12:11:30 EST 2008