idnits 2.17.1 draft-hujun-idr-bgp-ipsec-01.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 (September 4, 2019) is 1695 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-13 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 September 4, 2019 5 Expires: March 7, 2020 7 BGP Provisioned IPsec Tunnel Configuration 8 draft-hujun-idr-bgp-ipsec-01 10 Abstract 12 This document defines a method of using BGP to provide 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 March 7, 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 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 5 56 2.3. IPsec Configuration Tag sub-TLV . . . . . . . . . . . . . 5 57 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Semantics and Usage of IPsec Tunnel Encapsulation attribute . 10 59 4.1. Nested Tunnel . . . . . . . . . . . . . . . . . . . . . . 10 60 4.2. Other Operation Specifics . . . . . . . . . . . . . . . . 11 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 66 8.2. Informative References . . . . . . . . . . . . . . . . . 14 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 69 1. Introduction 71 IPsec is the standard for IP layer traffic protection, however in a 72 big network where mesh connections are needed, configuring large 73 number of IPsec tunnels is error prone and not scalable. So instead 74 of pre-provision IPsec tunnels on each router, this document defines 75 a method to allow router to advertise the IPsec tunnel configurations 76 it requires to reach a given NLRI via BGP. This document does not 77 intend to be one solution for all cases, the main use case is to 78 simplify IPsec tunnel provision in networks under single 79 administrative domain; it uses standard based components (IPsec/ 80 IKEv2[RFC7296] and BGP) with limited changes. There is no change to 81 IPsec/IKEv2, and only limited changes to BGP. 83 IPsec tunnel in this document means IPsec tunnel mode as defined in 84 [RFC4301]. 86 IPsec tunnel configurations typically include following parts: 88 o tunnel endpoint address (local and remote) 90 o public routing instance, routing instance where IPsec packet is 91 forwarded in 93 o private routing instance, routing instance where payload packet is 94 forwarded in 96 o tunnel authentication method and credentials 97 o IKE SA and CHILD SA transform (a.k.a crypto algorithms) 99 o CHILD SA traffic selector 101 o other: like lifetime, DPD timer, use of PFS ..etc 103 In order to minimize amount configurations signal via BGP, only 104 following configurations are explicit advertised: 106 o local tunnel endpoint address: BGP tunnel encapsulation attribute 108 o public routing instance: sub-TLV in tunnel encapsulation attribute 110 o CHILD SA traffic selector address range: NLRI and/or sub-TLV in 111 tunnel encapsulation attribute 113 Other configurations are either derived or via tag mapping: 115 o remote tunnel endpoint address: dynamic learned when received 116 IKEv2 IKE_SA_INIT request 118 o private routing instance: via route-target in same BGP UPDATE 120 o tunnel authentication/credentials, traffic selector protocol/port 121 range, IKE SA and CHILD SA transform, lifetime, DPD timer, PFS 122 ..etc: all these configurations are implicitly signaled via IPsec 123 configuration tag sub-TLV in tunnel encapsulation attribute 125 [I-D.ietf-idr-tunnel-encaps] defines a generic tunnel encapsulation 126 attribute for BGP, however it needs to be extended to support IPsec 127 tunnel. 129 1.1. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 2. Tunnel Encapsulation Attribute for IPsec 139 This document extends tunnel encapsulation attribute specified in 140 [I-D.ietf-idr-tunnel-encaps] by introducing following changes: 142 o A tunnel type for IPsec tunnel: ESP tunnel mode (AH tunnel mode is 143 not included in this document). Existing type 4 (IPsec in Tunnel- 144 mode) in IANA "BGP Tunnel Encapsulation Attribute Tunnel Types" 145 registry could be reused 147 o A new sub-TLV for public routing instance 149 o A new sub-TLV for remote address prefix 151 o A new sub-TLV for local address prefix 153 o A new sub-TLV for IPsec configuration tag 155 Following existing sub-TLVs apply to IPsec tunnel encapsulation 156 attribute: 158 o Remote Endpoint: IPsec tunnel endpoint address 160 o Embedded Label Handling: see Section 4 for detail 162 2.1. Local and Remote Prefix sub-TLV 164 Local prefix sub-TLV is an optional sub-TLV used to specify a list of 165 address prefix that used as local traffic selector address ranges; if 166 local prefix sub-TLV is not included, then prefixes in NLRI will be 167 used; Remote prefix sub-TLV is a mandatory sub-TLV used to specify a 168 list of address prefix that used as remote traffic selector address 169 ranges; The IP version of local/remote prefix MUST be as same as IP 170 version of prefix in NLRI. A single all zero prefix means any prefix 171 is allowed. Local and remote prefix sub-TLV has same encoding as 172 following: 174 +---------------------------------------+ 175 | list of prefixes (variable) | 176 +---------------------------------------+ 178 Figure 1: Source Prefix sub-TLV 180 Each prefix is encoded as following: 182 +---------------------------+ 183 | prefix Length (1 octet) | 184 +---------------------------+ 185 | Prefix (4 or 16 octets) | 186 +---------------------------+ 188 Figure 2: prefix 190 For a given IPsec tunnel TLV, local prefix sub-TLV MUST appear either 191 zero or one time; remote prefix sub-TLV MUST appear only one time. 193 2.2. Public Routing Instance sub-TLV 195 Public routing instance sub-TLV is an optional sub-TLV used to 196 specify the routing instance to which the remote point address 197 belongs, if tunnel encapsulation attribute doesn't include this TLV, 198 then the routing instance is the same to which BGP session belongs. 199 the value field of the sub-TLV consist a route target community as 200 defined in [RFC4360]. 202 For a given IPsec tunnel TLV, public routing instance sub-TLV MUST 203 appear either zero or one time. 205 2.3. IPsec Configuration Tag sub-TLV 207 This sub-TLV represents the IPsec configurations (like IPsec 208 transform) that are not explicit advertised by other sub-TLVs 209 specified in this documentation; the meaning of this sub-TLV is local 210 to the administrative domain. Follow are some examples: 212 o tag value T1 map to following configurations: 214 * Certificate trust-anchor: CA-1 216 * IKE_SA/CHILD_SA transform: AES-GCM-128 218 * Diffie-Hellman Group: 15 220 * Perfect Forward Secrecy: No 222 * local/remote Traffic selector protocol: any 224 * local/remote Traffic selector port range: any 226 * IKE_SA lifetime: 24 hours 228 * CHILD_SA lifetime: 1 hour 230 * DPD interval: 30 seconds 232 * ESP extended sequence number: no 234 o tag value T2 map to following configurations: 236 * Certificate trust-anchor: CA-2 238 * IKE_SA/CHILD_SA transform: AES-GCM-256 240 * Diffie-Hellman Group: 20 241 * Perfect Forward Secrecy: Yes with group 20 243 * local/remote Traffic selector protocol: UDP 245 * local/remote Traffic selector port range: any 247 * IKE_SA lifetime: 48 hours 249 * CHILD_SA lifetime: 2 hours 251 * DPD interval: 10 seconds 253 * ESP extended sequence number: yes 255 The value field of this sub-TLV is 4 octets long. each IPsec tunnel 256 TLV SHOULD only contain one IPsec configuration tag sub-TLV; 258 +--------------------------------------+ 259 | IPsec Configuration tag (4 octets) | 260 +--------------------------------------+ 262 Figure 3: IPsec Configuration Tag 264 For a given IPsec tunnel TLV, IPsec configuration tag sub-TLV MUST 265 appear only one time. 267 3. Operation 269 Following are the rules of operation: 271 1. All routers are in same administrative domain 273 2. All routers are pre-provisioned with Mapping between IPsec 274 configuration tag value and IPsec configurations include 275 authentication method/credentials 277 3. If a given NLRI need IPsec protection, then advertising router 278 need to include an IPsec tunnel encapsulation attribute, along 279 with the NLRI in BGP UPDATE U; 281 4. When a router need to forward a packet along a path is determined 282 by a BGP UPDATE which has a tunnel encapsulation attribute that 283 contains one or more IPsec tunnel TLV, and router decides use 284 IPsec based on local policy, then the router use first feasible 285 CHILD_SA, a CHILD SA is considered as feasible when it meets all 286 following conditions: 288 * its private routing instance is same as routing instance to 289 which the packet to be forwarded belongs 291 * its public routing instance is same as indicated by the Public 292 Routing Instance sub-TLV; if the sub-TLV doesn't exist, then 293 it is same as routing instance to which BGP session belongs 295 * its peer tunnel address is same as indicated by Remote 296 Endpoint sub-TLV 298 * the source and destination address of the packet to be 299 forwarded falls in the range of CHILD SA's traffic selector 301 * its transform and other configuration maps to the tag 302 indicated in the IPsec configuration tag sub-TLV 304 5. If router can't find such CHILD SA, then it will use IKEv2 to 305 create one; if there are multiple IPsec tunnel TLVs in U, then it 306 need to select one from feasible TLVs, a IPsec tunnel TLV is 307 considered as feasible when it meets all following requirements: 309 * the source address of the packet must fall in one of Remote 310 Prefixes 312 * the destination address of the packet must fall one of Source 313 Prefixes 315 * the Remote Endpoint, along with Public Routing Instance sub- 316 TLV identifies an IP address that is reachable 318 6. If there are multiple feasible IPsec tunnel TLV exists, then 319 select the TLV using following rules in order: 321 1. TLV with smallest local address range as indicated by Remote 322 Prefix sub-TLV 324 2. TLV with smallest remote address range as indicated by Local 325 Prefix sub-TLV (NLRI prefix if local prefix sub-TLV is not 326 included in TLV) 328 7. After an IPsec TLV is selected, router uses IKEv2 to create the 329 CHILD_SA: 331 * public/private routing instance, peer's tunnel address are 332 chosen based on above rules 334 * Traffic Selector: 336 * For each TS in TSi: 338 + address range: the prefix specified in Remote Prefix sub- 339 TLV 341 + protocol: tag mapped configuration 343 + port range: tag mapped configuration 345 * for each TS in TSr: 347 + address range: prefixes specified by Local Prefix sub-TLV 348 if it exists; otherwise use the prefix specified by the 349 NLRI 351 + protocol: tag mapped configuration 353 + port range: tag mapped configuration 355 The operation of BGP provisioned IPsec configuration is illustrated 356 with following example: 358 +--------+ 359 +--------+ BGP RR +---------+ 360 | +--------+ | 361 | | 362 | CHILDSA1: Tag-1 | 363 +--+---+ <----------------> +--+---+ 364 subetA -------+ R1 | IKEv2 | R2 +----- subnetB/subnetC 365 +------+ <----------------> +------+ 366 CHILDSA2: Tag-2 368 Figure 4: Operation Example 370 There are following traffic protection requirements: 372 o subnetA - subnetB: ESP tunnel, CHACHA20_POLY1305 , mapping to tag 373 Tag-1 375 o subnetA - subnetC: ESP tunnel, NULL-AES-GMAC-256 , mapping to tag 376 Tag-2 378 o note: other IPsec configurations, like IKE_SA lifetime ..etc, are 379 the same for both Tag-1 and Tag-2; not listed here for sake of 381 Both R1 and R2 are provisioned with IPsec authentication credentials 382 and configurations corresponding to Tag-1 and Tag-2; both Tag-1 and 383 Tag-2 map to traffic selector protocol any and port range any. 385 o R1 advertise subnetA in BGP UPDATE, which has a tunnel 386 encapsulation attribute that contains two IPsec tunnel TLVs: 388 * TLV-1: endpoint R1TunnelAddr, tag sub-TLV Tag-1 and subnetB in 389 Remote Prefix sub-TLV. 391 * TLV-2: endpoint R1TunnelAddr, tag sub-TLV Tag-2 and subnetC in 392 Remote Prefix sub-TLV. 394 o R2 advertise subnetB in BGP UPDATE, which has a tunnel 395 encapsulation attribute that contains one IPsec tunnel TLV: 396 R2TunnelAddr, tag sub-TLV Tag-1 and subnetA in Remote Prefix sub- 397 TLV. 399 o R2 advertise subnetC in BGP UPDATE, which has a tunnel 400 encapsulation attribute that contains one IPsec tunnel TLV: 401 R2TunnelAddr, tag sub-TLV Tag-2 and subnetA in Remote Prefix sub- 402 TLV. 404 o R1 received a packet from subnetA destined to subnetB, since BGP 405 UPDATE contain subnetB also contains an IPsec tunnel encapsulation 406 attribute, there is no existing CHILD SA could be used, based on 407 the rules described in this section, R1 select TLV-1 and uses 408 IKEv2 to establish an IPsec tunnel to R2TunnelAddr, using 409 certificate authentication, create 1st CHILD SA CHILDSA1: 411 * ESP transform: CHACHA20_POLY1305 413 * Traffic Selector: 415 + TSi: address subnetA, protocol any, port any 417 + TSr: address subnetB, protocol any, port any 419 o after tunnel is created, R1 and R2 could forward traffic between 420 subnetA and subnetB over CHILDSA1 422 o R1 received a packet from subnetA destined to subnetC, CHILDSA1 423 can't be used for this packet, R1 select TLV-2 to create 2nd CHILD 424 SA, and given there is already an IKE SA between R1 and R2, R1 425 uses existing IKESA to create CHILDSA2: 427 * ESP transform: NULL-AES-GMAC-256 428 * Traffic Selector: 430 + TSi: address subnetA, protocol any, port any 432 + TSr: address subnetC, protocol any, port any 434 o R1 and R2 could forward traffic between subnetA and subnetC over 435 CHILDSA2 437 4. Semantics and Usage of IPsec Tunnel Encapsulation attribute 439 IPsec tunnel encapsulation TLV has same usage and semantics as 440 defined in [I-D.ietf-idr-tunnel-encaps] with following specific to 441 IPsec tunnel: 443 o Due to nature of IPsec, the payload packet could only be IPv4 or 444 IPv6 packet, so it MAY be carried in any BGP UPDATE message whose 445 AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 Unicast). 447 o For 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled 448 Unicast), these NLRI has embedded label, which cause the payload 449 packet can't be encapsulated in ESP packet, however with IPsec 450 tunnel encapsulation, the label could be ignored during 451 encapsulation since CHILD SA itself could be used to identify the 452 private routing instance; so an UPDATE that include IPsec tunnel 453 encapsulation attribute, which contains value 2 of Embedded Label 454 Handling Sub-TLV, could be used to signal this type of setup. 456 o For other types of AFI/SAFI, a nested tunnel setup could be used 457 to get IPsec protection, for example, an 25/70 (EVPN) payload 458 packet could be encapsulated in VXLAN over IPsec tunnel. See 459 Section 4.1 for further detail. 461 4.1. Nested Tunnel 463 A nested tunnel could be used for payload packet type that can't be 464 encapsulated in IPsec tunnel directly, e.g. an Ethernet packet of 465 EVPN service. Following is an example of using VXLAN over IPsec 466 tunnel for EVPN service: 468 o R1 need to forward an Ethernet packet P 470 o the path along which P is to be forwarded is determined by BGP 471 UPDATE U1, which has a VXLAN tunnel encapsulation attribute and 472 the next-hop is router R2 474 o the best path to R2 is a BGP route that was advertised in BGP 475 UPDATE U2, which has an IPsec tunnel encapsulation TLV. 477 o R1 will encapsulate P in a VXLAN tunnel as indicated in U1, then 478 encapsulate VXLAN packet into IPsec tunnel as indicated in U2 480 o if tag sub-TLV is used, then both U1 and U2 MUST have matching tag 481 sub-TLV, otherwise the VXLAN packet will not be sent through IPsec 482 tunnels identified in U2 484 4.2. Other Operation Specifics 486 Following are some operation specific rules: 488 1. An IPsec dead peer detection mechanism, like IKEv2 DPD or BFD 489 over IPsec, SHOULD be used to monitor liveness of IPsec tunnel; 491 2. If IPsec peer goes down, as described in section 5 of 492 [I-D.ietf-idr-tunnel-encaps], packet forwarding router chooses 493 another functional tunnel, specified by another tunnel TLV of 494 same BGP route if there is any, to forward the packet; if there 495 is no such tunnel, then router MAY drop the packet or MAY forward 496 packet as it would had the Tunnel Encapsulation attribute not 497 been present. this is matter of local policy. 499 3. After IPsec peer goes down, packet forwarding router SHOULD try 500 to re-establish IPsec tunnel with certain hold-down timer and 501 back-off mechanism. the detail is up to implementation. also 502 IKEv2 session resumption [RFC5723] MAY be used to efficiently re- 503 create tunnel; 505 4. When router receives a packet destined to a BGP route it 506 advertised but does not have any of tunnel encapsulation in the 507 BGP route, it MAY drop it or MAY accept it; this is matter of 508 local policy. by default, the packet should be accepted. 510 5. As with all types of tunnel technology, IPsec tunnel adds 511 overhead (crypto & encapsulation) to the packet, which often 512 causes MTU issues, deployment SHOULD take tunnel overhead into 513 MTU consideration. 515 5. IANA Considerations 517 This document reuses "IPsec in Tunnel-mode"(4) as BGP Tunnel 518 Encapsulation Attribute Tunnel Types. 520 This document will request new values in IANA "BGP Tunnel 521 Encapsulation Attribute Sub-TLVs" registry for following sub-TLV: 523 o public routing instance 525 o remote address prefix 527 o local address prefix 529 o IPsec configuration tag 531 6. Security Considerations 533 IKEv2 is used to create IPsec tunnel, which ensures following: 535 o Traffic protection keys are generated dynamically during IKEv2 536 negotiation, only known by participating peer of the IPsec tunnel; 537 there is no central node to manage and distribute all keys. 539 o IKEv2 rekey mechanism refresh keys regularly; PFS(Perfect Forward 540 Secrecy) provides additional protection; 542 o Secure authentication mechanism that only allow authenticated peer 543 to create tunnel 545 o Traffic Selector guarantee that only agreed traffic is allowed to 546 be forwarded within the IPsec tunnel; 548 o Using a separate, dedicate protocol(IKEv2) for key management/ 549 authentication ensure they are not tied to BGP, all existing and 550 future IKEv2 features could be used without changing BGP; 552 There is concern that malicious party might manipulate IPsec tunnel 553 encapsulation attribute to divert traffic, however this risk could be 554 mitigated by IKEv2 mutual authentication. 556 BGP route filter include outbound route filter [RFC5291], Origin 557 Validation [RFC6811] and BGPSec [RFC8205] could be used to further 558 secure BGP UPDATE message. 560 IKEv2 cookie [RFC7296] and varies mechanisms defined including client 561 puzzle defined in [RFC8019] could be used to protect IKEv2 from 562 Distributed Denial-of-Service Attacks. 564 Follow latest IETF ESP/IKEv2 implementation requirement and guidance 565 ([RFC8221] and [RFC8247] at time of writing) to make sure always 566 using secure and up-to-date cryptographic algorithms; 568 7. Change Log 570 o v00 March 04, 2019: initial draft 572 o v01 Sep 04, 2019: 574 * replaces color sub-TLV with a new IPsec configuration tag sub- 575 TLV 577 * add rule on selecting TLV when there multiple feasible TLVs in 578 section Section 3 580 * change crypto used in example of section Section 3 582 * change title from "BGP Signaled IPsec Tunnel Configuration" to 583 "BGP Provisioned IPsec Tunnel Configuration" 585 * Add a section Section 4.2 on some operation specifics 587 * add more content in Section 6 589 * add specification of number of time each new sub-TLV allowed in 590 a given tunnel TLV 592 * add clarification in section Section 1 to clarify IPsec tunnel 593 means IPsec tunnel mode 595 * traffic selector protocol and port range now come from tag 596 mapped configuration 598 8. References 600 8.1. Normative References 602 [I-D.ietf-idr-tunnel-encaps] 603 Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The 604 BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 605 tunnel-encaps-13 (work in progress), July 2019. 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, 609 DOI 10.17487/RFC2119, March 1997, 610 . 612 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 613 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 614 December 2005, . 616 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 617 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 618 February 2006, . 620 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 621 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 622 May 2017, . 624 8.2. Informative References 626 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 627 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 628 August 2008, . 630 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 631 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 632 DOI 10.17487/RFC5723, January 2010, 633 . 635 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 636 Austein, "BGP Prefix Origin Validation", RFC 6811, 637 DOI 10.17487/RFC6811, January 2013, 638 . 640 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 641 Kivinen, "Internet Key Exchange Protocol Version 2 642 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 643 2014, . 645 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 646 Protocol Version 2 (IKEv2) Implementations from 647 Distributed Denial-of-Service Attacks", RFC 8019, 648 DOI 10.17487/RFC8019, November 2016, 649 . 651 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 652 Specification", RFC 8205, DOI 10.17487/RFC8205, September 653 2017, . 655 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 656 Kivinen, "Cryptographic Algorithm Implementation 657 Requirements and Usage Guidance for Encapsulating Security 658 Payload (ESP) and Authentication Header (AH)", RFC 8221, 659 DOI 10.17487/RFC8221, October 2017, 660 . 662 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 663 "Algorithm Implementation Requirements and Usage Guidance 664 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 665 RFC 8247, DOI 10.17487/RFC8247, September 2017, 666 . 668 Author's Address 670 Hu Jun 671 Nokia 672 777 East Middlefield Road 673 Mountain View CA 95148 674 United States 676 Email: jun.hu@nokia.com