idnits 2.17.1 draft-hujun-idr-bgp-ipsec-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.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 (March 4, 2019) is 1879 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 (-22) exists of draft-ietf-idr-tunnel-encaps-11 Summary: 1 error (**), 0 flaws (~~), 2 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 March 4, 2019 5 Expires: September 5, 2019 7 BGP Signaled IPsec Tunnel Configuration 8 draft-hujun-idr-bgp-ipsec-00 10 Abstract 12 This document defines a method of using BGP to signal IPsec tunnel 13 configuration along with NLRI, it uses and extends tunnel 14 encapsulation attribute as specified in [I-D.ietf-idr-tunnel-encaps] 15 for IPsec tunnel. 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 September 5, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Tunnel Encapsulation Attribute for IPsec . . . . . . . . . . 3 54 2.1. Local and Remote Prefix sub-TLV . . . . . . . . . . . . . 4 55 2.2. Public Routing Instance sub-TLV . . . . . . . . . . . . . 4 56 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Semantics and Usage of IPsec Tunnel Encapsulation attribute . 8 58 4.1. Nested Tunnel . . . . . . . . . . . . . . . . . . . . . . 9 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 63 7.2. Informative References . . . . . . . . . . . . . . . . . 10 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 66 1. Introduction 68 IPsec is the standard for IP layer traffic protection, however in a 69 big network where mesh connections are needed, configuring large 70 number of IPsec tunnels is error prone and not scalable. So instead 71 of pre-provision IPsec tunnels on each router, this document defines 72 a method to allow router to advertise the IPsec tunnel configurations 73 it requires to reach a given NLRI via BGP. This document does not 74 intend to be one solution for all cases, the main use case is to 75 simplify IPsec tunnel provision in networks under single 76 administrative domain; it uses standard based components (IPsec/ 77 IKEv2[RFC7296] and BGP) with limited changes. There is no change to 78 IPsec/IKEv2, and only limited changes to BGP. 80 IPsec tunnel configurations typically include following parts: 82 o tunnel endpoint address (local and remote) 84 o public routing instance, routing instance where IPsec packet is 85 forwarded in 87 o private routing instance, routing instance where payload packet is 88 forwarded in 90 o tunnel authentication method and credentials 92 o IKE SA and CHILD SA transform (a.k.a crypto algorithms) 94 o CHILD SA traffic selector 96 o other: like lifetime, DPD timer, use of PFS ..etc 97 In order to minimize amount configurations signal via BGP, only 98 following configurations are explicit advertised: 100 o local tunnel endpoint address: BGP tunnel encapsulation attribute 102 o public routing instance: sub-TLV in tunnel encapsulation attribute 104 o CHILD SA traffic selector: NLRI and/or sub-TLV in tunnel 105 encapsulation attribute 107 Other configurations are either derived or via color mapping: 109 o remote tunnel endpoint address: dynamic learned when received 110 IKEv2 IKE_SA_INIT request 112 o private routing instance: via route-target in same BGP UPDATE 114 o tunnel authentication and credentials: out of scope, could be PKI 115 based authentication 117 o IKE SA and CHILD SA transform, lifetime, DPD timer, PFS ..etc: all 118 these configurations are implicitly signaled via color sub-TLV in 119 tunnel encapsulation attribute 121 [I-D.ietf-idr-tunnel-encaps] defines a generic tunnel encapsulation 122 attribute for BGP, however it needs to be extended to support IPsec 123 tunnel. 125 1.1. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 2. Tunnel Encapsulation Attribute for IPsec 135 This document extends tunnel encapsulation attribute specified in 136 [I-D.ietf-idr-tunnel-encaps] by introducing following changes: 138 o A tunnel type for IPsec tunnel: ESP tunnel mode (AH tunnel mode is 139 not included in this document). Existing type 4 (IPsec in Tunnel- 140 mode) in IANA "BGP Tunnel Encapsulation Attribute Tunnel Types" 141 registry could be reused 143 o A new sub-TLV for public routing instance 144 o A new sub-TLV for remote address prefix 146 o A new sub-TLV for local address prefix 148 Following existing sub-TLVs apply to IPsec tunnel encapsulation 149 attribute: 151 o Remote Endpoint: IPsec tunnel endpoint address 153 o Color: IPsec configuration attributes like ESP transform; the 154 meaning of this sub-TLV is local to the administrative domain 156 o Embedded Label Handling: see Section 4 for detail 158 2.1. Local and Remote Prefix sub-TLV 160 Local prefix sub-TLV is an optional sub-TLV used to specify a list of 161 address prefix that used as local traffic selector address ranges; if 162 local prefix sub-TLV is not included, then prefixes in NLRI will be 163 used; Remote prefix sub-TLV is a mandatory sub-TLV used to specify a 164 list of address prefix that used as remote traffic selector address 165 ranges; The IP version of local/remote prefix MUST be as same as IP 166 version of prefix in NLRI. A single all zero prefix means any prefix 167 is allowed. Local and remote prefix sub-TLV has same encoding as 168 following: 170 +---------------------------------------+ 171 | list of prefixes (variable) | 172 +---------------------------------------+ 174 Figure 1: Source Prefix sub-TLV 176 Each prefix is encoded as following: 178 +---------------------------+ 179 | prefix Length (1 octet) | 180 +---------------------------+ 181 | Prefix (4 or 16 octets) | 182 +---------------------------+ 184 Figure 2: prefix 186 2.2. Public Routing Instance sub-TLV 188 Public routing instance sub-TLV is an optional sub-TLV used to 189 specify the routing instance to which the remote point address 190 belongs, if tunnel encapsulation attribute doesn't include this TLV, 191 then the routing instance is the same to which BGP session belongs. 193 the value field of the sub-TLV consist a route target community as 194 defined in [RFC4360]. 196 3. Operation 198 Following are the rules of operation: 200 1. All routers are in same administrative domain 202 2. All routers are pre-provisioned with following: 204 * Authentication credential like PKI certificates and key 206 * Mapping between color and IPsec configurations 208 3. If a given NLRI need IPsec protection, then advertising router 209 need to include an IPsec tunnel encapsulation attribute, along 210 with the NLRI in BGP UPDATE U; 212 4. When a router need to forward a packet along a path is determined 213 by a BGP UPDATE which has a tunnel encapsulation attribute that 214 contains one or more IPsec TLV, and router decides use IPsec 215 based on local policy, then the router need to check if there is 216 an existing CHILD SA could be used, a CHILD SA could be used when 217 it meets all following conditions: 219 * its private routing instance is same as routing instance to 220 which the packet to be forwarded belongs 222 * its public routing instance is same as indicated by the Public 223 Routing Instance sub-TLV; if the sub-TLV doesn't exist, then 224 it is same as routing instance to which BGP session belongs 226 * its peer tunnel address is same as indicated by Remote 227 Endpoint sub-TLV 229 * the source and destination address of the packet to be 230 forwarded falls in the range of CHILD SA's traffic selector 232 * its transform and other configuration maps to the color 233 indicated in the Color sub-TLV 235 5. If router can't find such CHILD SA, then it will use IKEv2 to 236 create one; if there are multiple IPsec TLVs in U, then it need 237 to select one from feasible TLVs, a IPsec TLV is considered as 238 feasible when it meets all following requirements: 240 * the source address of the packet must fall in one of Remote 241 Prefixes 243 * the destination address of the packet must fall one of Source 244 Prefixes 246 * the Remote Endpoint, along with Public Routing Instance sub- 247 TLV identifies an IP address that is reachable 249 6. After an IPsec TLV is selected, router uses IKEv2 to create the 250 CHILD_SA: 252 * public/private routing instance, peer's tunnel address are 253 chosen based on above rules 255 * Traffic Selector: 257 * For each TS in TSi: 259 + address range: the prefix specified in Remote Prefix sub- 260 TLV 262 + protocol: any 264 + port range: any 266 * for each TS in TSr: 268 + address range: prefixes specified by Local Prefix sub-TLV 269 if it exists; otherwise use the prefix specified by the 270 NLRI 272 + protocol: any 274 + port range: any 276 The operation of BGP signaling IPsec configuration is illustrated 277 with following example: 279 +--------+ 280 +--------+ BGP RR +---------+ 281 | +--------+ | 282 | | 283 | CHILDSA1: Red | 284 +--+---+ <----------------> +--+---+ 285 subetA -------+ R1 | IKEv2 | R2 +----- subnetB/subnetC 286 +------+ <----------------> +------+ 287 CHILDSA2: Yellow 289 Figure 3: Operation Example 291 There are following traffic protection requirements: 293 o subnetA - subnetB: ESP tunnel, AES-CBC-256 with SHA-384, mapping 294 to color red 296 o subnetA - subnetC: ESP tunnel, null encryption with only integrity 297 protection, SHA-256, mapping to color yellow 299 Both R1 and R2 are provisioned with PKI key and certificate from same 300 CA. 302 o R1 advertise subnetA in BGP UPDATE, which has a tunnel 303 encapsulation attribute that contains two IPsec tunnel TLVs: 305 * TLV-1: endpoint R1TunnelAddr, color sub-TLV red and subnetB in 306 Remote Prefix sub-TLV. 308 * TLV-2: endpoint R1TunnelAddr, color sub-TLV yellow and subnetC 309 in Remote Prefix sub-TLV. 311 o R2 advertise subnetB in BGP UPDATE, which has a tunnel 312 encapsulation attribute that contains one IPsec tunnel TLV: 313 R2TunnelAddr, color sub-TLV red and subnetA in Remote Prefix sub- 314 TLV. 316 o R2 advertise subnetC in BGP UPDATE, which has a tunnel 317 encapsulation attribute that contains one IPsec tunnel TLV: 318 R2TunnelAddr, color sub-TLV yellow and subnetA in Remote Prefix 319 sub-TLV. 321 o R1 received a packet from subnetA destined to subnetB, since BGP 322 UPDATE contain subnetB also contains an IPsec tunnel encapsulation 323 attribute, there is no existing CHILD SA could be used, based on 324 the rules described in this section, R1 select TLV-1 and uses 325 IKEv2 to establish an IPsec tunnel to R2TunnelAddr, using 326 certificate authentication, create 1st CHILD SA CHILDSA1: 328 * ESP transform: AES-CBC-256 and SHA-384 330 * Traffic Selector: 332 + TSi: address subnetA, protocol any, port any 334 + TSr: address subnetB, protocol any, port any 336 o after tunnel is created, R1 and R2 could forward traffic between 337 subnetA and subnetB over CHILDSA1 339 o R1 received a packet from subnetA destined to subnetC, CHILDSA1 340 can't be used for this packet, R1 select TLV-2 to create 2nd CHILD 341 SA, and given there is already an IKE SA between R1 and R2, R1 342 uses existing IKESA to create CHILDSA2: 344 * ESP transform: Null encryption with SHA-256 346 * Traffic Selector: 348 + TSi: address subnetA, protocol any, port any 350 + TSr: address subnetC, protocol any, port any 352 o R1 and R2 could forward traffic between subnetA and subnetC over 353 CHILDSA2 355 4. Semantics and Usage of IPsec Tunnel Encapsulation attribute 357 IPsec tunnel encapsulation TLV has same usage and semantics as 358 defined in [I-D.ietf-idr-tunnel-encaps] with following differences: 360 o Due to nature of IPsec, the payload packet could only be IPv4 or 361 IPv6 packet, so it MAY be carried in any BGP UPDATE message whose 362 AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 Unicast). 364 o For 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled 365 Unicast), these NLRI has embedded label, which cause the payload 366 packet can't be encapsulated in ESP packet, however with IPsec 367 tunnel encapsulation, the label could be ignored during 368 encapsulation since CHILD SA itself could be used to identify the 369 private routing instance; so an UPDATE that include IPsec tunnel 370 encapsulation attribute, which contains value 2 of Embedded Label 371 Handling Sub-TLV, could be used to signal this type of setup. 373 o For other types of AFI/SAFI, a nested tunnel setup could be used 374 to get IPsec protection, for example, an 25/70 (EVPN) payload 375 packet could be encapsulated in VXLAN over IPsec tunnel. See 376 Section 4.1 for further detail. 378 4.1. Nested Tunnel 380 A nested tunnel could be used for payload packet type that can't be 381 encapsulated in IPsec tunnel directly, e.g. an Ethernet packet of 382 EVPN service. Following is an example of using VXLAN over IPsec 383 tunnel for EVPN service: 385 o R1 need to forward an Ethernet packet P 387 o the path along which P is to be forwarded is determined by BGP 388 UPDATE U1, which has a VXLAN tunnel encapsulation attribute and 389 the next-hop is router R2 391 o the best path to R2 is a BGP route that was advertised in BGP 392 UPDATE U2, which has an IPsec tunnel encapsulation TLV. 394 o R1 will encapsulate P in a VXLAN tunnel as indicated in U1, then 395 encapsulate VXLAN packet into IPsec tunnel as indicated in U2 397 o if color sub-TLV is used, then both U1 and U2 MUST have matching 398 color sub-TLV, otherwise the VXLAN packet will not be sent through 399 IPsec tunnels identified in U2 401 5. IANA Considerations 403 This document reuses "IPsec in Tunnel-mode"(4) as BGP Tunnel 404 Encapsulation Attribute Tunnel Types. 406 This document will request new values in IANA "BGP Tunnel 407 Encapsulation Attribute Sub-TLVs" registry for following sub-TLV: 409 o public routing instance 411 o remote address prefix 413 o local address prefix 415 6. Security Considerations 417 IKEv2 is used to create IPsec tunnel, which ensures following: 419 o Traffic protection keys are generated dynamically during IKEv2 420 negotiation, only known by participating peer of the IPsec tunnel; 421 there is no central node to manage and distribute all keys. 423 o IKEv2 rekey mechanism refresh keys regularly; PFS(Perfect Forward 424 Secrecy) provides additional protection; 426 o Secure authentication mechanism that only allow authenticated peer 427 to create tunnel 429 o Traffic Selector guarantee that only agreed traffic is allowed to 430 be forwarded within the IPsec tunnel; 432 o Using a separate, dedicate protocol(IKEv2) for key management/ 433 authentication ensure they are not tied to BGP, all existing and 434 future IKEv2 features could be used without changing BGP; 436 There is concern that malicious party might manipulate IPsec tunnel 437 encapsulation attribute to divert traffic, however this risk could be 438 mitigated by IKEv2 mutual authentication. 440 BGP Origin Validation [RFC6811] and BGPSec [RFC8205] could be used to 441 further secure BGP UPDATE message. 443 7. References 445 7.1. Normative References 447 [I-D.ietf-idr-tunnel-encaps] 448 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 449 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11 450 (work in progress), February 2019. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, 454 DOI 10.17487/RFC2119, March 1997, 455 . 457 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 458 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 459 February 2006, . 461 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 462 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 463 May 2017, . 465 7.2. Informative References 467 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 468 Austein, "BGP Prefix Origin Validation", RFC 6811, 469 DOI 10.17487/RFC6811, January 2013, 470 . 472 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 473 Kivinen, "Internet Key Exchange Protocol Version 2 474 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 475 2014, . 477 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 478 Specification", RFC 8205, DOI 10.17487/RFC8205, September 479 2017, . 481 Author's Address 483 Hu Jun 484 Nokia 485 777 East Middlefield Road 486 Mountain View CA 95148 487 United States 489 Email: jun.hu@nokia.com