idnits 2.17.1 draft-hujun-idr-bgp-ipsec-transport-mode-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.hujun-idr-bgp-ipsec], [I-D.ietf-idr-tunnel-encaps]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 10, 2019) is 1657 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) == Outdated reference: A later version (-02) exists of draft-hujun-idr-bgp-ipsec-01 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-14 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 idr J. Hu 3 Internet-Draft Nokia 4 Intended status: Standards Track October 10, 2019 5 Expires: April 12, 2020 7 BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration 8 draft-hujun-idr-bgp-ipsec-transport-mode-00 10 Abstract 12 This document defines a method of using BGP to advertise IPsec 13 transport mode protected tunnel (like GRE tunnel with IPsec transport 14 mode protection) configuration along with NLRI, based on 15 [I-D.ietf-idr-tunnel-encaps] and [I-D.hujun-idr-bgp-ipsec]. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 12, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.2. IPsec Transport Protected sub-TLV . . . . . . . . . . . . 3 54 2. Semantics and Operation . . . . . . . . . . . . . . . . . . . 3 55 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 60 6.2. Informative References . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 [I-D.hujun-idr-bgp-ipsec] defines a method of using BGP to advertise 66 configuration for IPsec tunnel with ESP tunnel mode, however there 67 are other use cases require of using IPsec/ESP transport mode with 68 other types of IP tunnel, like GRE tunnel, as defined in [RFC4301] 69 and [RFC4303]. Figure 2 shows an example of IPv4 GRE tunnel packet 70 with ESP transport mode protection. This document defines a method 71 of using BGP to advertise configuration for these use cases. 73 ---------------------------------------------------- 74 |IPv4 header | ESP | GRE | Payload | ESP | ESP| 75 |(any options)| Hdr | Hdr | Packet | Trailer | ICV| 76 ---------------------------------------------------- 77 |<-- encryption --->| 78 |<-------- integrity ---->| 80 Figure 1: IPv4 GRE tunnel packet with ESP transport protection 82 The method follows same principle as [I-D.hujun-idr-bgp-ipsec], keep 83 changes to BGP minimal and not changing IKEv2/IPsec; however the 84 IPsec transport mode protected IP tunnel is not a tunnel stack or 85 nested tunnels, IPsec transport mode protection doesn't add extra IP 86 header. 88 The requirement of using IPsec transport mode is signaled by 89 including a sub-TLV: IPsec transport protected, in a BGP tunnel 90 encapsulation TLV. 92 1.1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 1.2. IPsec Transport Protected sub-TLV 102 This sub-TLV represents using IPsec transport mode protection for the 103 tunnel specified by parent tunnel encapsulation TLV, its value is a 104 IPsec configuration tag as defined in [I-D.hujun-idr-bgp-ipsec]. 106 +--------------------------------------+ 107 | IPsec Configuration tag (4 octets) | 108 +--------------------------------------+ 110 Figure 2: IPsec Configuration Tag 112 For a given tunnel encapsulation TLV, IPsec configuration tag sub-TLV 113 MUST appear only one time. 115 2. Semantics and Operation 117 Except for what this document explicitly specifies, the semantics and 118 operation of tunnel encapsulation TLV with IPsec Transport Protected 119 sub-TLV are same as defined in [I-D.ietf-idr-tunnel-encaps] and 120 [I-D.hujun-idr-bgp-ipsec]. 122 IPsec Transport Protected sub-TLV MAY be included in any type of IP 123 tunnel TLV specified in [I-D.ietf-idr-tunnel-encaps]; it MUST be 124 ignored when included in a IPsec tunnel TLV. 126 The inclusion of IPsec Transport Protected TLV and its value is 127 determined by local policy. 129 Following are the rules of operations: 131 1. All routers are pre-provisioned with Mapping between IPsec 132 configuration tag value and IPsec configurations include 133 authentication method/credentials 135 2. If a given NLRI needs a specific tunnel encapsulation with IPsec 136 transport mode protection, then advertising router need to 137 include an IPsec Transport Protected sub-TLV with required 138 configuration tag, in the corresponding tunnel encapsulation TLV/ 139 attribute, along with the NLRI in BGP UPDATE U; 141 3. When a router need to forward a packet along a path is determined 142 by a BGP UPDATE which has a tunnel encapsulation attribute that 143 contains one or more tunnel TLV, router selects a tunnel TLV 144 based on Semantics defined in [I-D.ietf-idr-tunnel-encaps], if 145 the selected tunnel TLV contains IPsec Transport Protected sub- 146 TLV, then the router use first feasible CHILD_SA for IP tunnel 147 packet encryption, a CHILD SA is considered as feasible when it 148 meets all following conditions: 150 * it is ESP transport mode 152 * its private and public routing instance is same as routing 153 instance in which the packet to be forwarded 155 * its peer tunnel address is same as indicated by Remote 156 Endpoint sub-TLV 158 * the source and destination address of the packet to be 159 forwarded falls in the range of CHILD SA's traffic selector 161 * its transform and other configuration maps to the tag 162 indicated in the IPsec configuration tag sub-TLV 164 4. If router can't find such CHILD SA, then it will use IKEv2 to 165 create one with following IPsec configuration: 167 * ESP transport mode 169 * private and public routing instance is the routing instance in 170 which the packet to be forwarded 172 * peer tunnel address is specified by Remote Endpoint sub-TLV 174 * local traffic selector: 176 + address range: local tunnel endpoint address 178 + protocol: tag mapped configuration 180 + port range: tag mapped configuration 182 * remote traffic selector: 184 + address range: address in Remote Endpoint sub-TLV of 185 selected tunnel encapsulation TLV 187 + protocol: tag mapped configuration 189 + port range: tag mapped configuration 191 * other configurations come from mapping of the configuration 192 tag in IPsec Transport Protected sub-TLV of selected tunnel 193 encapsulation TLV 195 3. IANA Considerations 197 This document will request new values in IANA "BGP Tunnel 198 Encapsulation Attribute Sub-TLVs" registry for IPsec Transport 199 Protected sub-TLV. 201 4. Security Considerations 203 IKEv2 is used to create IPsec tunnel, which ensures following: 205 o Traffic protection keys are generated dynamically during IKEv2 206 negotiation, only known by participating peer of the IPsec tunnel; 207 there is no central node to manage and distribute all keys. 209 o IKEv2 rekey mechanism refresh keys regularly; PFS(Perfect Forward 210 Secrecy) provides additional protection; 212 o Secure authentication mechanism that only allow authenticated peer 213 to create tunnel 215 o Traffic Selector guarantee that only agreed traffic is allowed to 216 be forwarded within the IPsec tunnel; 218 o Using a separate, dedicate protocol(IKEv2) for key management/ 219 authentication ensure they are not tied to BGP, all existing and 220 future IKEv2 features could be used without changing BGP; 222 There is concern that malicious party might manipulate IPsec tunnel 223 encapsulation attribute to divert traffic, however this risk could be 224 mitigated by IKEv2 mutual authentication. 226 BGP route filter include outbound route filter [RFC5291], Origin 227 Validation [RFC6811] and BGPSec [RFC8205] could be used to further 228 secure BGP UPDATE message. 230 IKEv2 cookie [RFC7296] and varies mechanisms defined including client 231 puzzle defined in [RFC8019] could be used to protect IKEv2 from 232 Distributed Denial-of-Service Attacks. 234 Follow latest IETF ESP/IKEv2 implementation requirement and guidance 235 ([RFC8221] and [RFC8247] at time of writing) to make sure always 236 using secure and up-to-date cryptographic algorithms; 238 5. Change Log 240 o v00 Sep 29, 2019: initial draft 242 6. References 244 6.1. Normative References 246 [I-D.hujun-idr-bgp-ipsec] 247 Hu, J., "BGP Provisioned IPsec Tunnel Configuration", 248 draft-hujun-idr-bgp-ipsec-01 (work in progress), September 249 2019. 251 [I-D.ietf-idr-tunnel-encaps] 252 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 253 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-14 254 (work in progress), September 2019. 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, 258 DOI 10.17487/RFC2119, March 1997, 259 . 261 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 262 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 263 December 2005, . 265 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 266 RFC 4303, DOI 10.17487/RFC4303, December 2005, 267 . 269 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 270 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 271 May 2017, . 273 6.2. Informative References 275 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 276 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 277 August 2008, . 279 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 280 Austein, "BGP Prefix Origin Validation", RFC 6811, 281 DOI 10.17487/RFC6811, January 2013, 282 . 284 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 285 Kivinen, "Internet Key Exchange Protocol Version 2 286 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 287 2014, . 289 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 290 Protocol Version 2 (IKEv2) Implementations from 291 Distributed Denial-of-Service Attacks", RFC 8019, 292 DOI 10.17487/RFC8019, November 2016, 293 . 295 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 296 Specification", RFC 8205, DOI 10.17487/RFC8205, September 297 2017, . 299 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 300 Kivinen, "Cryptographic Algorithm Implementation 301 Requirements and Usage Guidance for Encapsulating Security 302 Payload (ESP) and Authentication Header (AH)", RFC 8221, 303 DOI 10.17487/RFC8221, October 2017, 304 . 306 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 307 "Algorithm Implementation Requirements and Usage Guidance 308 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 309 RFC 8247, DOI 10.17487/RFC8247, September 2017, 310 . 312 Author's Address 314 Hu Jun 315 Nokia 316 777 East Middlefield Road 317 Mountain View CA 95148 318 United States 320 Email: jun.hu@nokia.com