idnits 2.17.1 draft-vandevelde-idr-remote-next-hop-09.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 9, 2015) is 3329 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) == Missing Reference: 'RFC2003' is mentioned on line 206, but not defined == Missing Reference: 'VXLAN' is mentioned on line 271, but not defined == Missing Reference: 'NVGRE' is mentioned on line 312, but not defined == Missing Reference: 'IPVPN-overlay' is mentioned on line 239, but not defined == Missing Reference: 'EVPN-overlay' is mentioned on line 239, but not defined == Missing Reference: 'RFC2890' is mentioned on line 365, but not defined == Unused Reference: 'I-D.ietf-mpls-in-udp' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-error-handling' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'I-D.matsushima-stateless-uplane-vepc' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'I-D.sridharan-virtualization-nvgre' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'I-D.yamaya-ipsecme-mpsa' is defined on line 704, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) ** Obsolete normative reference: RFC 5566 (Obsoleted by RFC 9012) ** Downref: Normative reference to an Informational RFC: RFC 6459 ** Downref: Normative reference to an Informational RFC: RFC 7348 == Outdated reference: A later version (-19) exists of draft-ietf-idr-error-handling-13 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-06 == Outdated reference: A later version (-06) exists of draft-matsushima-stateless-uplane-vepc-01 == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-05 == Outdated reference: A later version (-06) exists of draft-yamaya-ipsecme-mpsa-04 Summary: 7 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR G. Van de Velde 3 Internet-Draft 4 Intended status: Standards Track K. Patel 5 Expires: September 10, 2015 D. Rao 6 Cisco Systems 7 R. Raszuk 8 NTT MCL Inc. 9 R. Bush 10 Internet Initiative Japan 11 March 9, 2015 13 BGP Remote-Next-Hop 14 draft-vandevelde-idr-remote-next-hop-09 16 Abstract 18 The BGP Remote-Next-Hop attribute is an optional transitive attribute 19 intended to facilitate automatic tunnelling across an AS for an NLRI 20 in a given address family. The attribute carries one or more tunnel 21 end-points and associated tunnel encapsulation information for a 22 NLRI. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. Remote-Next-Hop Attribute . . . . . . . . . . . . . . . . . . 3 61 3.1. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop 62 attribute . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. BGP Remote-Next-Hop attribute TLV Format . . . . . . . . . . 4 64 5. Encapsulation sub-TLVs for virtual network overlays . . . . . 5 65 5.1. Encapsulation sub-TLV for VXLAN . . . . . . . . . . . . . 6 66 5.2. Encapsulation sub-TLV for NVGRE . . . . . . . . . . . . . 7 67 5.3. Encapsulation sub-TLV for GTP . . . . . . . . . . . . . . 8 68 5.4. Encapsulation for MPLS-in-GRE . . . . . . . . . . . . . . 8 69 6. Remote-Next-Hop Bestpath Considerations . . . . . . . . . . . 9 70 7. Securing Remote-Next-Hop . . . . . . . . . . . . . . . . . . 9 71 7.1. Restrictions on Announcing of Remote-Next-Hop Attribute . 10 72 7.2. Restrictions on Originating of Remote-Next-Hop Attribute 10 73 8. Multiple tunnel endpoint addresses . . . . . . . . . . . . . 11 74 9. Attribute error handling . . . . . . . . . . . . . . . . . . 11 75 10. BGP speakers that do not support BGP Remote-Next-Hop 76 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 11. Use Case scenarios . . . . . . . . . . . . . . . . . . . . . 11 78 11.1. Stateless user-plane architecture for virtualized EPC 79 (vEPC) . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 11.2. Stateless User-plane Architecture for virtual Packet 81 Edge . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 11.3. Dynamic Network Overlay Infrastructure . . . . . . . . . 12 83 11.4. Simple VPN solution using Multi-point Security 84 Association . . . . . . . . . . . . . . . . . . . . . . 12 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 88 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 89 16. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 17.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 17.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 [RFC5512] defines an attribute attached to an NLRI to signal tunnel 98 end-point encapsulation information between two BGP speakers for a 99 single tunnel. [RFC5512] requires that a new address-family needs to 100 be enabled between the two BGP speakers. It also assumes that the 101 exchanged tunnel endpoint is the NLRI. 103 This document defines a new BGP transitive attribute known as a 104 Remote-Next-Hop BGP attribute for Intra-AS and Inter-AS usage, and 105 simplifies the exchange and operations involved with tunnel end-point 106 information propagation between two BGP speakers. 108 The tunnel endpoint information and the tunnel encapsulation 109 information is carried within a Remote-Next-Hop BGP attribute. This 110 attribute can be added to any BGP NLRI. This way the Address Family 111 (AF) of the NLRI exchanged is decoupled from the tunnel SAFI address- 112 family defined in [RFC5512]. Multiple Remote-Next-Hop attribute TLVs 113 can be added to a single NLRI. 115 Security measures SHOULD be taken to protect against accidental or 116 malicious tampering of the Remote-Next-Hop attribute. 118 2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 122 be interpreted as described in [RFC2119] only when they appear in all 123 upper case. They may also appear in lower or mixed case as English 124 words, without any normative meaning. 126 3. Remote-Next-Hop Attribute 128 There are an increasing number of use cases where the exchange of 129 multiple unique tunnel endpoints and associated tunnel data is 130 desired for a prefix using segments of an existing infrastructure, 131 where requiring a new address-family to be enabled would add 132 operational complexity. 134 The BGP Remote-Next-Hop attribute is defined to be attached to each 135 originated BGP NLRI in any applicable address-family. Multiple 136 Remote-Next-Hop attribute TLVs can be applied to a single originated 137 BGP NLRI. Each TLV can contain one or more sub-TLVs that carry 138 encapsulation information. Thus, it enables a simple mechanism to 139 signal multiple, unique tunnel endpoints for a given prefix; as well 140 as multiple encapsulation parameters for prefixes with the same 141 remote tunnel end-point. 143 BGP Remote-Next-Hop attribute is a Transitive Optional BGP attribute, 144 allowing to signal next-hop encapsulation parameters in a transitive 145 manner without the requirement to enable a new address-family. 147 This document specifies the tunnel types that can be used with this 148 attribute. The sub-TLVs from [RFC5512] and BGP IPsec tunnel 149 encapsulation [RFC5566] are reused for the BGP Next-Hop-Attribute. 151 3.1. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop 152 attribute 154 The use of Tunnel Encapsulation attribute [RFC5512] is based on the 155 principle that the tunnel end-point is carried as part of BGP NLRI in 156 an Encapsulation SAFI. 158 This requires enabling of the Encapsulation SAFI within a BGP enabled 159 network. It also sets up an interdependency between BGP routes in 160 different SAFIs and the BGP Tunnel SAFI for resolving tunnel next- 161 hops. 163 The Encapsulation SAFI [RFC5512] assumes that the tunnel endpoint is 164 the NLRI exchanged in the Encaps SAFI, while Remote-Next-Hop 165 decouples the exchanged NLRI from the tunnel end-point information, 166 thereby requiring mutual exclusive usage of the two mechanisms. 168 While [RFC5512] allows multiple tunnel endpoints and multiple tunnel 169 types to be carried within a BGP Encaps SAFI, the correlation of 170 Tunnel information with other SAFIs is done using the color extended 171 community which is also non-trivial. 173 4. BGP Remote-Next-Hop attribute TLV Format 175 This attribute is an optional transitive attribute [RFC1771]. 177 The BGP Remote-Next-Hop attribute is composed of a set of Type- 178 Length-Value (TLV) encodings. The type code of the attribute is 179 (IANA to assign). Each TLV contains information corresponding to a 180 particular tunnel end-point address. 182 0 1 2 3 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Tunnel Type (2 Octets) | Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Addr len | Tunnel Address (IPv4 or IPv6) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | AS Number | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Tunnel Parameters | 192 ~ ~ 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Tunnel Type (2 octets): identifies the type of tunneling technology 196 being signaled. This document specifies the following types: 198 - L2TPv3 over IP [RFC3931]: Tunnel Type = 1 199 - GRE [RFC2784]: Tunnel Type = 2 200 - Transmit tunnel endpoint [RFC5566]: Tunnel Type = 3 201 - IPsec in Tunnel-mode [RFC5566]: Tunnel Type = 4 202 - IP in IP tunnel 203 with IPsec Transport Mode [RFC5566]: Tunnel Type = 5 204 - MPLS-in-IP tunnel 205 with IPsec Transport Mode [RFC5566]: Tunnel Type = 6 206 - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7 208 This document defines the following types: 209 - VXLAN: Tunnel Type = 8 210 - NVGRE: Tunnel Type = 9 211 - GTP: Tunnel Type = 10 212 - MPLS-in-GRE: Tunnel Type = 11 213 - MPLS-in-UDP: Tunnel Type = 12 214 - MPLS-in-UDP-with-DTLS: Tunnel Type = 13 216 Unknown types MUST be ignored and skipped upon receipt. 218 Length (2 octets): the total number of octets of the value field. 220 Tunnel Address Length (1 octet): Length of Tunnel 221 Address. Set to 4 bytes for an IPv4 address and 16 bytes for an 222 IPv6 address. 224 AS Number (4 octets): The AS number originating the BGP Remote-Next-Hop 225 attribute and is either a 2-byte AS or 4-Byte AS number 227 Tunnel Parameter (variable): comprised of multiple sub-TLVs. 228 Each sub-TLV consists of three fields: a 1-octet type, 1-octet 229 length, and zero or more octets of value. 231 5. Encapsulation sub-TLVs for virtual network overlays 233 A VN-ID may need to be signaled along with the encapsulation types 234 for DC overlay encapsulations such as [VXLAN] and [NVGRE]. The VN-ID 235 when present in the encapsulation sub-TLV for an overlay 236 encapsulation, MUST be processed by a receiving device if it is 237 capable of understanding it. The details regarding how such a 238 signaled VN-ID is processed and used is defined in specifications 239 such as [IPVPN-overlay] and [EVPN-overlay]. 241 5.1. Encapsulation sub-TLV for VXLAN 243 This document defines a new encapsulation sub-TLV format, defined in 244 [RFC5512], for VXLAN tunnels. When the tunnel type is VXLAN, the 245 following is the structure of the value field in the encapsulation 246 sub-TLV: 248 0 1 2 3 249 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | MAC Address (4 Octets) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | MAC Address (2 Octets) | Reserved | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 V: When set to 1, it indicates that a valid VN-ID is present in the 259 encapsulation sub-TLV. 260 M: When set to 1, it indicates that a valid MAC Address is present 261 in the encapsulation sub-TLV. 262 R: The remaining bits in the 8-bit flags field are reserved for 263 further use. They MUST be set to 0 on transmit and MUST be ignored 264 on receipt. 266 VN-ID: Contains a 3 octets VN-ID value, if the 'V' flag bit is set. 267 If the 'V' flag is not set, it SHOULD be set to zero and MUST be 268 ignored on receipt. 270 The VN-ID value is filled in the VNI field in the VXLAN packet 271 header as defined in [VXLAN]. 273 MAC Address: Contains a 6 octets of an Ethernet MAC address if the 'M' flag bit 274 is set. If the 'M' flag is not set, it SHOULD set to all zeroes and 275 MUST be ignored on receipt. 277 The MAC address is local to the device advertising the route, and 278 should be included as the destination MAC address in the inner 279 Ethernet header immediately following the outer VXLAN header, in 280 the packets destined to the advertiser. 282 5.2. Encapsulation sub-TLV for NVGRE 284 This document defines a new encapsulation sub-TLV format, defined in 285 [RFC5512], for NVGRE tunnels. When the tunnel type is NVGRE, the 286 following is the structure of the value field in the encapsulation 287 sub-TLV: 289 0 1 2 3 290 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | MAC Address (4 Octets) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | MAC Address (2 Octets) | Reserved | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 V: When set to 1, it indicates that a valid VN-ID is present in the 300 encapsulation sub-TLV. 301 M: When set to 1, it indicates that a valid MAC Address is present 302 in the encapsulation sub-TLV. 303 R: The remaining bits in the 8-bit flags field are reserved for 304 further use. They MUST be set to 0 on transmit and MUST be ignored 305 on receipt. 307 VN-ID: Contains a 3 octets VN-ID value, if the 'V' flag bit is set. 308 If the 'V' flag is not set, it SHOULD be set to zero and MUST be 309 ignored on receipt. 311 The VN-ID value is filled in the VSID field in the NVGRE packet 312 header as defined in [NVGRE]. 314 MAC Address: Contains a 6 octets of an Ethernet MAC address if the 'M' flag bit is 315 set. If the 'M' flag is not set, it SHOULD set to all zeroes and 316 MUST be ignored on receipt. 318 The MAC address is local to the device advertising the route, and 319 should be included as the destination MAC address in the inner 320 Ethernet header immediately following the outer NVGRE header, in 321 the packets destined to 322 the advertiser. 324 5.3. Encapsulation sub-TLV for GTP 326 This document defines a new encapsulation sub-TLV format, defined in 327 [RFC5512], for GTP tunnels. When the tunnel type is GTP, the 328 following is the structure of the value field in the encapsulation 329 sub-TLV: 331 0 1 2 3 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Local TEID (4 Octets) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Local Endpoint Address (4/16 Octets (IPv4/IPv6)) | 337 . . 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a 341 GTP tunnel assigned by EPC that is used to distinguish different 342 connections in received packets within the tunnel. 344 Local Endpoint Address: Indicates a 4-octets IPv4 address or 345 16-octets IPv6 address as a local endpoint address of GTP tunnel. 347 Local Endpoint Address element makes a tunnel endpoint router 348 allow to have multiple Local TEID spaces. Received GTP packets 349 are identified which tunnel connection by combination of Local 350 Endpoint Address and Local TEID. 352 5.4. Encapsulation for MPLS-in-GRE 354 This document defines a new encapsulation sub-TLV format, defined in 355 [RFC5512], for MPLS-in-GRE tunnels. When the tunnel type is MPLS-in- 356 GRE, the following is the structure of the value field in an optional 357 encapsulation sub-TLV: 359 0 1 2 3 360 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | GRE-Key (4 Octets) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 GRE-Key: 4-octet field [RFC2890] that is generated by the 366 advertising router. The actual method by which the key is obtained 367 is beyond the scope of this document. The key is inserted into the 368 GRE encapsulation header of the payload packets sent by ingress 369 routers to the advertising router. It is intended to be used for 370 identifying extra context information about the received payload. 371 Note that the key is optional. Unless a key value is being 372 advertised, the MPLS-in-GRE encapsulation sub-TLV MUST NOT be 373 present. 375 Note that signaling a GRE tunnel-type with routes in a labeled SAFI 376 may be sufficient to indicate to the receiver that it needs to send 377 MPLS packets with that GRE encapsulation. However, a specific 378 tunnel-type for MPLS-in-GRE is being defined in order to make 379 this indication explicit to a receiver. 381 6. Remote-Next-Hop Bestpath Considerations 383 A BGP speaker SHOULD support a policy to enable the support for using 384 BGP Remote Nexthop attribute. An implementation that supports the 385 BGP Remote-Next-Hop MUST use BGP Nexthop attribute information 386 whenever BGP Remote-Next-Hop is not enabled. 388 Traditionally a BGP speaker uses the IGP cost towards the BGP Next- 389 Hop as a BGP path selection criteria. However, when a BGP speaker is 390 configured to use the BGP Remote-Next-Hop value, then it SHOULD use 391 the IGP cost towards the IP address selected from the Remote-Next-Hop 392 attribute. When there are multiple such IP addresses that may be 393 installed, it SHOULD use the worst IGP cost among them. 395 Similarly, the speaker SHOULD also check that the IP address is 396 reachable before considering that path eligible for bestpath. 398 7. Securing Remote-Next-Hop 400 The Remote-Next-Hop attribute provides a set of tunnel parameters. 401 While the Remote-Next-Hop attribute has as goal to inform an intended 402 recipient with these tunnel parameters, it is important to make sure 403 that the attributes have not been tampered with and that they are 404 restricted to the intended scope of distribution for secure 405 operation. 407 7.1. Restrictions on Announcing of Remote-Next-Hop Attribute 409 The Remote-Next-Hop attribute is used to carry an additional 410 information (tunnel end-point, encapsulation type, etc). It has a 411 security value to contain the distribution of the Remote-Next-Hop 412 attribute within its planned scope of distribution. This scope could 413 be, but is not limited to, a particular department, site, 414 organization, across ASes within a same administration control or a 415 global scope. 417 To contain distribution of the Remote-Next-Hop attribute beyond its 418 intended scope of applicability, attribute filtering MAY be deployed. 419 The BGP speaker communicating to a speaker beyond the intended scope 420 of the Remote-Next-Hop attribute SHOULD filter the attribute during 421 the route announcements. 423 To facilitate attribute filtering, an implementation that supports 424 the BGP Remote-Next-Hop attribute MUST support a policy to (1) ignore 425 the received attribute and (2) filter the attribute. 427 7.2. Restrictions on Originating of Remote-Next-Hop Attribute 429 A BGP Remote-Next-Hop attribute may be added to routes that belong to 430 same Autonomous system as the tunnel endpoint address. 431 Implementations SHOULD validate the following to ensure the validity 432 of Remote-Next-Hop Attribute: 434 (1) BGP Remote-Next-Hops Tunnel Endpoint and AS number association 435 SHOULD be validated using BGP Origin Validation. 437 (2) BGP Remote-Next-Hop Tunnel Endpoints underlay routes origin AS 438 SHOULD be validated using BGP Origin Validation. This AS number MUST 439 be the same as the AS number carried within BGP Remote-Next-Hop 440 attribute. 442 (3) The origin AS of BGP Routes that carry BGP Remote-Next-Hop 443 attribute SHOULD be validated using BGP Origin Validation. This AS 444 number MUST be same as the AS number carried within BGP Remote-Next- 445 Hop attribute. 447 If the above validation fails, the tunnel type SHOULD be considered 448 as invalid. This does not affect the validity of the others tunnels 449 types carried within the Remote-Next-Hop Attribute. 451 8. Multiple tunnel endpoint addresses 453 In some cases, a device may need to accept incoming traffic for a 454 prefix via multiple different encapsulations, to support interactions 455 with remote devices with disjoint capabilities. Certain device 456 implementations cannot support the use of the same IP address as 457 local tunnel endpoint for multiple encapsulations. 459 In certain cases, a device may need to signal an additional, 460 alternate tunnel endpoint address, to be used by other devices only 461 as a backup in certain failure conditions. 463 9. Attribute error handling 465 When receiving a BGP Update message containing a malformed Remote- 466 Next-Hop attribute, the attribute MUST be quietly ignored and not 467 passed along to other BGP peers. (see [draft-ietf-idr-error- 468 handling], Section 7). This is equivalent to the -attribute discard- 469 action specified in [draft-ietf-idr-error-handling]. An 470 implementation MAY log an error for further analysis. 472 Note that a BGP Remote-Next-Hop attribute MUST NOT be considered to 473 be malformed because it contains more than one TLV of a given type or 474 because it contains TLVs of unknown types. 476 If a BGP path attribute is received that has the Remote-Next-Hop 477 attribute codepoint but does not have the transitive bit set, the 478 attribute MUST be considered to be a malformed Remote-Next-Hop 479 attribute and MUST be discarded as specified in this section. 481 10. BGP speakers that do not support BGP Remote-Next-Hop attribute 483 If a BGP Speaker does not support this attribute, and receives this 484 attribute, then it follows the normal NLRI processing and BGP best 485 path selection, and the resulting forwarding decision is used, as the 486 attribute is optional. 488 11. Use Case scenarios 490 This section provides a brief overview of some use-cases for the BGP 491 Remote-Next-Hop attribute. Use of the BGP Remote-Next-Hop is not 492 limited to the examples in this section. Details regarding how the 493 attribute is used are described in the respective solution drafts 494 that are referenced where necessary. 496 11.1. Stateless user-plane architecture for virtualized EPC (vEPC) 498 The full usage case of BGP Remote-Next-Hop regarding vEPC can be 499 found in [vEPC], while [RFC6459] documents IPv6 in 3GPP EPS. 501 3GPP introduces Evolved Packet Core (EPC) that is fully IP based 502 mobile system for LTE and -advanced in their Release-8 specification 503 and beyond. Operators are now deploying EPC for LTE services and 504 encounter rapid LTE traffic growth. There are various activities to 505 offload mobile traffic in 3GPP and IETF such as LIPA, SIPTO and DMM. 506 The concept is similar that traffic of OTT (Over The Top) application 507 is offloaded at entity that is closer to the mobile node (ex. eNodeB 508 or closer anchor). 510 11.2. Stateless User-plane Architecture for virtual Packet Edge 512 With the emergence of the NfV technologies, different architectures 513 are proposed for virtualized services. These functions will normally 514 run in the datacenter. BGP remote-next-hop can be used to inject 515 traffic into the virtualized services running in the datacenter using 516 tunnels. These tunnels can be signalled using BGP remote-next-hop. 517 This facilitates a dynamic, simple and clean routing architecture. 518 BGP Remote Next Hop can simplify the orchestration or provisioning 519 layer by signalling the tunnel endpoint (virtual provider edge 520 router) in combination with the encapsulation protocol. 522 If this is used together with orchestrated traffic steering 523 mechanisms (i.e. BGP Flowspec) , it is possible to differentiate at 524 application level, and forward each different traffic types towards 525 the desired destination. 527 11.3. Dynamic Network Overlay Infrastructure 529 The BGP Remote-Next-Hop extension allows consistent signalling of 530 tunnel encapsulations as needed by virtual network overlay solutions 531 such as [I-D.drao-bgp-l3vpn-virtual-network-overlays] and 532 [I-D.sd-l2vpn-evpn-overlay] 534 11.4. Simple VPN solution using Multi-point Security Association 536 [draft-yamaya-ipsecme-mpsa] describes the overlay network solution by 537 utilizing dynamically established IPsec multi-point Security 538 Association (SA) without individual connection. 540 Multi-point SA technology provides the simplified mechanism of the 541 Auto Discovery and Configuration function. This is applicable for 542 any IPsec tunnels such as IPv4 over IPv4, IPv4 over IPv6, IPv6 over 543 IPv4 and IPv6 over IPv6. 545 MPSA does not provide peer discovery function by itself. However, 546 other mechanism, such as BGP, can be employed with MPSA for automatic 547 peer discovery. BGP Remote-Next-Hop can be used to learn peer 548 information as next-hops. 550 12. IANA Considerations 552 This document defines a new BGP attribute known as a BGP Remote-Next- 553 Hop attribute. We request IANA to allocate a new attribute code from 554 the -BGP Path Attributes- registry with a symbolic name -Remote-Next- 555 Hop- attribute. 557 We also request IANA to allocate four new BGP Tunnel Types from the 558 -BGP Tunnel Encapsulation Attribute Tunnel Types- registry with the 559 following symbolic names: -VXLAN- with Tunnel type 8, -NVGRE- with 560 Tunnel type 9, -GTP- with Tunnel type 10, -MPLS-in-GRE with Tunnel 561 type 11, -MPLS-in-UDP- with Tunnel type 12 and -MPLS-in-UDP-with-DTLS 562 with Tunnel type 13. 564 13. Security Considerations 566 This technology could be used as technology as man in the middle 567 attack, however with existing RPKI validation for BGP that risk is 568 reduced. 570 The distribution of Tunnel end-point address information can result 571 in potential DoS attacks. Therefore is it strongly recommended to 572 install traffic filters, IDSs and IPSs at the perimeter of the 573 tunneled network infrastructure. 575 measures SHOULD be taken to protect the validity of the BGP Remote- 576 Next-Hop attribute. It is possible to inject a rogue BGP Remote- 577 Next-Hop attribute to an NLRI resulting in Monkey-In-The-Middle 578 attack (MITM). To avoid this type of MITM attack, it is strongly 579 recommended to use a technology mechanism to verify that for NLRI it 580 is the expected BGP Remote-Next-Hop. We anticipate that this can be 581 done with an expansion of RPKI-Based origin validation, see 582 [I-D.ietf-sidr-pfx-validate]. 584 This does not avoid the fact that rogue AS numbers may be inserted or 585 injected into the AS-Path. To achieve protection against that threat 586 BGP Path Validation should be used, see 587 [I-D.ietf-sidr-bgpsec-overview]. 589 14. Privacy Considerations 591 This proposal may introduce privacy issues, however with BGP security 592 mechanisms in place they should be prevented. 594 15. Acknowledgements 596 The authors would like to thanks Satoru Matsushima, Bruno Decraene, 597 Ryuji Wakikawa and Miya Kohno for their usefull vEPC discussions. 598 Istvan Kakonyi provided insight in the vPE use case scenario. 600 Satoshi Usui provided datapoints around Simple VPN solution using 601 Multi-point Security Association. 603 16. Change Log 605 Initial Version: 16 May 2012 607 Hacked for -01: 17 July 2012 609 Hacked for -05: 07 January 2014 611 Hacked for -07: 15 September 2014 613 17. References 615 17.1. Normative References 617 [I-D.ietf-mpls-in-udp] 618 Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 619 "Encapsulating MPLS in UDP", draft-ietf-mpls-in-udp-11 620 (work in progress), January 2015. 622 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 623 4)", RFC 1771, March 1995. 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 629 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 630 March 2000. 632 [RFC3484] Draves, R., "Default Address Selection for Internet 633 Protocol version 6 (IPv6)", RFC 3484, February 2003. 635 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 636 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 638 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 639 for IPv6 Hosts and Routers", RFC 4213, October 2005. 641 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 642 Protocol 4 (BGP-4)", RFC 4271, January 2006. 644 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 645 Subsequent Address Family Identifier (SAFI) and the BGP 646 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 648 [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel 649 Encapsulation Attribute", RFC 5566, June 2009. 651 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 652 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 653 Partnership Project (3GPP) Evolved Packet System (EPS)", 654 RFC 6459, January 2012. 656 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 657 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 658 eXtensible Local Area Network (VXLAN): A Framework for 659 Overlaying Virtualized Layer 2 Networks over Layer 3 660 Networks", RFC 7348, August 2014. 662 17.2. Informative References 664 [I-D.drao-bgp-l3vpn-virtual-network-overlays] 665 Rao, D., Mullooly, J., and R. Fernando, "Layer-3 virtual 666 network overlays based on BGP Layer-3 VPNs", draft-drao- 667 bgp-l3vpn-virtual-network-overlays-03 (work in progress), 668 July 2014. 670 [I-D.ietf-idr-error-handling] 671 Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 672 "Revised Error Handling for BGP UPDATE Messages", draft- 673 ietf-idr-error-handling-13 (work in progress), June 2014. 675 [I-D.ietf-sidr-bgpsec-overview] 676 Lepinski, M., "An Overview of BGPsec", draft-ietf-sidr- 677 bgpsec-overview-06 (work in progress), January 2015. 679 [I-D.ietf-sidr-pfx-validate] 680 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 681 Austein, "BGP Prefix Origin Validation", draft-ietf-sidr- 682 pfx-validate-10 (work in progress), October 2012. 684 [I-D.matsushima-stateless-uplane-vepc] 685 Matsushima, S. and R. Wakikawa, "Stateless user-plane 686 architecture for virtualized EPC (vEPC)", draft- 687 matsushima-stateless-uplane-vepc-01 (work in progress), 688 July 2013. 690 [I-D.sd-l2vpn-evpn-overlay] 691 Sajassi, A., Drake, J., Bitar, N., Isaac, A., Uttaro, J., 692 and W. Henderickx, "A Network Virtualization Overlay 693 Solution using EVPN", draft-sd-l2vpn-evpn-overlay-03 (work 694 in progress), June 2014. 696 [I-D.sridharan-virtualization-nvgre] 697 Sridharan, M., Greenberg, A., Wang, Y., Garg, P., 698 Venkataramiah, N., Duda, K., Ganga, I., Lin, G., Pearson, 699 M., Thaler, P., and C. Tumuluri, "NVGRE: Network 700 Virtualization using Generic Routing Encapsulation", 701 draft-sridharan-virtualization-nvgre-05 (work in 702 progress), July 2014. 704 [I-D.yamaya-ipsecme-mpsa] 705 Yamaya, A., Ohya, T., Yamagata, T., and S. Matsushima, 706 "Simple VPN solution using Multi-point Security 707 Association", draft-yamaya-ipsecme-mpsa-04 (work in 708 progress), July 2014. 710 Authors' Addresses 712 Gunter Van de Velde 714 Email: gunter@vandevelde.cc 716 Keyur Patel 717 Cisco Systems 718 170 W. Tasman Drive 719 San Jose, CA 95124 95134 720 USA 722 Email: keyupate@cisco.com 723 Dhananjaya Rao 724 Cisco Systems 725 170 W. Tasman Drive 726 San Jose, CA 95124 95134 727 USA 729 Email: dhrao@cisco.com 731 Robert Raszuk 732 NTT MCL Inc. 733 101 S Ellsworth Avenue Suite 350 734 San Mateo, CA 94401 735 US 737 Email: robert@raszuk.net 739 Randy Bush 740 Internet Initiative Japan 741 5147 Crystal Springs 742 Bainbridge Island, Washington 98110 743 US 745 Email: randy@psg.com