idnits 2.17.1 draft-vandevelde-idr-remote-next-hop-08.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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 8, 2014) is 3487 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 205, but not defined == Missing Reference: 'VXLAN' is mentioned on line 270, but not defined == Missing Reference: 'NVGRE' is mentioned on line 311, but not defined == Missing Reference: 'IPVPN-overlay' is mentioned on line 238, but not defined == Missing Reference: 'EVPN-overlay' is mentioned on line 238, but not defined == Missing Reference: 'RFC2890' is mentioned on line 364, but not defined == Unused Reference: 'I-D.ietf-mpls-in-udp' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 640, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-error-handling' is defined on line 669, 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 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-in-udp-05 ** 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-05 == 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: 6 errors (**), 0 flaws (~~), 22 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 K. Patel 4 Intended status: Standards Track D. Rao 5 Expires: April 11, 2015 Cisco Systems 6 R. Raszuk 7 NTT MCL Inc. 8 R. Bush 9 Internet Initiative Japan 10 October 8, 2014 12 BGP Remote-Next-Hop 13 draft-vandevelde-idr-remote-next-hop-08 15 Abstract 17 The BGP Remote-Next-Hop attribute is an optional transitive attribute 18 intended to facilitate automatic tunnelling across an AS for an NLRI 19 in a given address family. The attribute carries one or more tunnel 20 end-points and associated tunnel encapsulation information for a 21 NLRI. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 11, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Remote-Next-Hop Attribute . . . . . . . . . . . . . . . . . . 3 60 3.1. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop 61 attribute . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. BGP Remote-Next-Hop attribute TLV Format . . . . . . . . . . 4 63 5. Encapsulation sub-TLVs for virtual network overlays . . . . . 5 64 5.1. Encapsulation sub-TLV for VXLAN . . . . . . . . . . . . . 6 65 5.2. Encapsulation sub-TLV for NVGRE . . . . . . . . . . . . . 7 66 5.3. Encapsulation sub-TLV for GTP . . . . . . . . . . . . . . 8 67 5.4. Encapsulation for MPLS-in-GRE . . . . . . . . . . . . . . 8 68 6. Remote-Next-Hop Bestpath Considerations . . . . . . . . . . . 9 69 7. Securing Remote-Next-Hop . . . . . . . . . . . . . . . . . . 9 70 7.1. Restrictions on Announcing of Remote-Next-Hop Attribute . 10 71 7.2. Restrictions on Originating of Remote-Next-Hop Attribute 10 72 8. Multiple tunnel endpoint addresses . . . . . . . . . . . . . 11 73 9. Attribute error handling . . . . . . . . . . . . . . . . . . 11 74 10. BGP speakers that do not support BGP Remote-Next-Hop 75 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 11. Use Case scenarios . . . . . . . . . . . . . . . . . . . . . 11 77 11.1. Stateless user-plane architecture for virtualized EPC 78 (vEPC) . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 11.2. Stateless User-plane Architecture for virtual Packet 80 Edge . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 11.3. Dynamic Network Overlay Infrastructure . . . . . . . . . 12 82 11.4. Simple VPN solution using Multi-point Security 83 Association . . . . . . . . . . . . . . . . . . . . . . 12 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 87 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 88 16. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 17.1. Normative References . . . . . . . . . . . . . . . . . . 14 91 17.2. Informative References . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 [RFC5512] defines an attribute attached to an NLRI to signal tunnel 97 end-point encapsulation information between two BGP speakers for a 98 single tunnel. [RFC5512] requires that a new address-family needs to 99 be enabled between the two BGP speakers. It also assumes that the 100 exchanged tunnel endpoint is the NLRI. 102 This document defines a new BGP transitive attribute known as a 103 Remote-Next-Hop BGP attribute for Intra-AS and Inter-AS usage, and 104 simplifies the exchange and operations involved with tunnel end-point 105 information propagation between two BGP speakers. 107 The tunnel endpoint information and the tunnel encapsulation 108 information is carried within a Remote-Next-Hop BGP attribute. This 109 attribute can be added to any BGP NLRI. This way the Address Family 110 (AF) of the NLRI exchanged is decoupled from the tunnel SAFI address- 111 family defined in [RFC5512]. Multiple Remote-Next-Hop attribute TLVs 112 can be added to a single NLRI. 114 Security measures SHOULD be taken to protect against accidental or 115 malicious tampering of the Remote-Next-Hop attribute. 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 121 be interpreted as described in [RFC2119] only when they appear in all 122 upper case. They may also appear in lower or mixed case as English 123 words, without any normative meaning. 125 3. Remote-Next-Hop Attribute 127 There are an increasing number of use cases where the exchange of 128 multiple unique tunnel endpoints and associated tunnel data is 129 desired for a prefix using segments of an existing infrastructure, 130 where requiring a new address-family to be enabled would add 131 operational complexity. 133 The BGP Remote-Next-Hop attribute is defined to be attached to each 134 originated BGP NLRI in any applicable address-family. Multiple 135 Remote-Next-Hop attribute TLVs can be applied to a single originated 136 BGP NLRI. Each TLV can contain one or more sub-TLVs that carry 137 encapsulation information. Thus, it enables a simple mechanism to 138 signal multiple, unique tunnel endpoints for a given prefix; as well 139 as multiple encapsulation parameters for prefixes with the same 140 remote tunnel end-point. 142 BGP Remote-Next-Hop attribute is a Transitive Optional BGP attribute, 143 allowing to signal next-hop encapsulation parameters in a transitive 144 manner without the requirement to enable a new address-family. 146 This document specifies the tunnel types that can be used with this 147 attribute. The sub-TLVs from [RFC5512] and BGP IPsec tunnel 148 encapsulation [RFC5566] are reused for the BGP Next-Hop-Attribute. 150 3.1. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop 151 attribute 153 The use of Tunnel Encapsulation attribute [RFC5512] is based on the 154 principle that the tunnel end-point is carried as part of BGP NLRI in 155 an Encapsulation SAFI. 157 This requires enabling of the Encapsulation SAFI within a BGP enabled 158 network. It also sets up an interdependency between BGP routes in 159 different SAFIs and the BGP Tunnel SAFI for resolving tunnel next- 160 hops. 162 The Encapsulation SAFI [RFC5512] assumes that the tunnel endpoint is 163 the NLRI exchanged in the Encaps SAFI, while Remote-Next-Hop 164 decouples the exchanged NLRI from the tunnel end-point information, 165 thereby requiring mutual exclusive usage of the two mechanisms. 167 While [RFC5512] allows multiple tunnel endpoints and multiple tunnel 168 types to be carried within a BGP Encaps SAFI, the correlation of 169 Tunnel information with other SAFIs is done using the color extended 170 community which is also non-trivial. 172 4. BGP Remote-Next-Hop attribute TLV Format 174 This attribute is an optional transitive attribute [RFC1771]. 176 The BGP Remote-Next-Hop attribute is composed of a set of Type- 177 Length-Value (TLV) encodings. The type code of the attribute is 178 (IANA to assign). Each TLV contains information corresponding to a 179 particular tunnel end-point address. 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Tunnel Type (2 Octets) | Length | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Addr len | Tunnel Address (IPv4 or IPv6) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | AS Number | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Tunnel Parameters | 191 ~ ~ 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Tunnel Type (2 octets): identifies the type of tunneling technology 195 being signaled. This document specifies the following types: 197 - L2TPv3 over IP [RFC3931]: Tunnel Type = 1 198 - GRE [RFC2784]: Tunnel Type = 2 199 - Transmit tunnel endpoint [RFC5566]: Tunnel Type = 3 200 - IPsec in Tunnel-mode [RFC5566]: Tunnel Type = 4 201 - IP in IP tunnel 202 with IPsec Transport Mode [RFC5566]: Tunnel Type = 5 203 - MPLS-in-IP tunnel 204 with IPsec Transport Mode [RFC5566]: Tunnel Type = 6 205 - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7 207 This document defines the following types: 208 - VXLAN: Tunnel Type = 8 209 - NVGRE: Tunnel Type = 9 210 - MPLS-in-GRE: Tunnel Type = 11 211 - MPLS-in-UDP: Tunnel Type = 13 212 - MPLS-in-UDP-with-DTLS: Tunnel Type = 14 213 - GTP: Tunnel Type = 15 215 Unknown types MUST be ignored and skipped upon receipt. 217 Length (2 octets): the total number of octets of the value field. 219 Tunnel Address Length - Addr len (1 octet): Length of Tunnel 220 Address. Set to 4 bytes for an IPv4 address and 16 bytes for an 221 IPv6 address. 223 AS Number - The AS number originating the BGP Remote-Next-Hop 224 attribute and is either a 2-byte AS or 4-Byte AS number 226 Tunnel Parameter - (variable): comprised of multiple sub-TLVs. 227 Each sub-TLV consists of three fields: a 1-octet type, 1-octet 228 length, and zero or more octets of value. 230 5. Encapsulation sub-TLVs for virtual network overlays 232 A VN-ID may need to be signaled along with the encapsulation types 233 for DC overlay encapsulations such as [VXLAN] and [NVGRE]. The VN-ID 234 when present in the encapsulation sub-TLV for an overlay 235 encapsulation, MUST be processed by a receiving device if it is 236 capable of understanding it. The details regarding how such a 237 signaled VN-ID is processed and used is defined in specifications 238 such as [IPVPN-overlay] and [EVPN-overlay]. 240 5.1. Encapsulation sub-TLV for VXLAN 242 This document defines a new encapsulation sub-TLV format, defined in 243 [RFC5512], for VXLAN tunnels. When the tunnel type is VXLAN, the 244 following is the structure of the value field in the encapsulation 245 sub-TLV: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | MAC Address (4 Octets) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | MAC Address (2 Octets) | Reserved | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 V: When set to 1, it indicates that a valid VN-ID is present in the 258 encapsulation sub-TLV. 259 M: When set to 1, it indicates that a valid MAC Address is present 260 in the encapsulation sub-TLV. 261 R: The remaining bits in the 8-bit flags field are reserved for 262 further use. They MUST be set to 0 on transmit and MUST be ignored 263 on receipt. 265 VN-ID: Contains a 24-bit VN-ID value, if the 'V' flag bit is set. 266 If the 'V' flag is not set, it SHOULD be set to zero and MUST be 267 ignored on receipt. 269 The VN-ID value is filled in the VNI field in the VXLAN packet 270 header as defined in [VXLAN]. 272 MAC Address: Contains an Ethernet MAC address if the 'M' flag bit 273 is set. If the 'M' flag is not set, it SHOULD set to all zeroes and 274 MUST be ignored on receipt. 276 The MAC address is local to the device advertising the route, and 277 should be included as the destination MAC address in the inner 278 Ethernet header immediately following the outer VXLAN header, in 279 the packets destined to the advertiser. 281 5.2. Encapsulation sub-TLV for NVGRE 283 This document defines a new encapsulation sub-TLV format, defined in 284 [RFC5512], for NVGRE tunnels. When the tunnel type is NVGRE, the 285 following is the structure of the value field in the encapsulation 286 sub-TLV: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | MAC Address (4 Octets) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | MAC Address (2 Octets) | Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 V: When set to 1, it indicates that a valid VN-ID is present in the 299 encapsulation sub-TLV. 300 M: When set to 1, it indicates that a valid MAC Address is present 301 in the encapsulation sub-TLV. 302 R: The remaining bits in the 8-bit flags field are reserved for 303 further use. They MUST be set to 0 on transmit and MUST be ignored 304 on receipt. 306 VN-ID: Contains a 24-bit VN-ID value, if the 'V' flag bit is set. 307 If the 'V' flag is not set, it SHOULD be set to zero and MUST be 308 ignored on receipt. 310 The VN-ID value is filled in the VSID field in the NVGRE packet 311 header as defined in [NVGRE]. 313 MAC Address: Contains an Ethernet MAC address if the 'M' flag bit is 314 set. If the 'M' flag is not set, it SHOULD set to all zeroes and 315 MUST be ignored on receipt. 317 The MAC address is local to the device advertising the route, and 318 should be included as the destination MAC address in the inner 319 Ethernet header immediately following the outer NVGRE header, in 320 the packets destined to 321 the advertiser. 323 5.3. Encapsulation sub-TLV for GTP 325 This document defines a new encapsulation sub-TLV format, defined in 326 [RFC5512], for GTP tunnels. When the tunnel type is GTP, the 327 following is the structure of the value field in the encapsulation 328 sub-TLV: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Local TEID (4 Octets) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Local Endpoint Address (4/16 Octets (IPv4/IPv6)) | 336 . . 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a 340 GTP tunnel assigned by EPC that is used to distinguish different 341 connections in received packets within the tunnel. 343 Local Endpoint Address: Indicates a 4-octets IPv4 address or 344 16-octets IPv6 address as a local endpoint address of GTP tunnel. 346 Local Endpoint Address element makes a tunnel endpoint router 347 allow to have multiple Local TEID spaces. Received GTP packets 348 are identified which tunnel connection by combination of Local 349 Endpoint Address and Local TEID. 351 5.4. Encapsulation for MPLS-in-GRE 353 This document defines a new encapsulation sub-TLV format, defined in 354 [RFC5512], for MPLS-in-GRE tunnels. When the tunnel type is MPLS-in- 355 GRE, the following is the structure of the value field in an optional 356 encapsulation sub-TLV: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | GRE-Key (4 Octets) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 GRE-Key: 4-octet field [RFC2890] that is generated by the 365 advertising router. The actual method by which the key is obtained 366 is beyond the scope of this document. The key is inserted into the 367 GRE encapsulation header of the payload packets sent by ingress 368 routers to the advertising router. It is intended to be used for 369 identifying extra context information about the received payload. 370 Note that the key is optional. Unless a key value is being 371 advertised, the MPLS-in-GRE encapsulation sub-TLV MUST NOT be 372 present. 374 Note that signaling a GRE tunnel-type with routes in a labeled SAFI 375 may be sufficient to indicate to the receiver that it needs to send 376 MPLS packets with that GRE encapsulation. However, a specific 377 tunnel-type for MPLS-in-GRE is being defined in order to make 378 this indication explicit to a receiver. 380 6. Remote-Next-Hop Bestpath Considerations 382 Traditionally a BGP speaker uses the IGP cost towards the BGP Next- 383 Hop as a BGP path selection criteria. However, when a BGP speaker is 384 configured to use the BGP Remote-Next-Hop value, then it SHOULD use 385 the IGP cost towards the IP address selected from the Remote-Next-Hop 386 attribute. When there are multiple such IP addresses that may be 387 installed, it SHOULD use the worst IGP cost among them. 389 Similarly, the speaker SHOULD also check that the IP address is 390 reachable before considering that path eligible for bestpath. 392 7. Securing Remote-Next-Hop 394 The Remote-Next-Hop attribute provides a set of tunnel parameters. 395 While the Remote-Next-Hop attribute has as goal to inform an intended 396 recipient with these tunnel parameters, it is important to make sure 397 that the attributes have not been tampered with and that they are 398 restricted to the intended scope of distribution for secure 399 operation. 401 7.1. Restrictions on Announcing of Remote-Next-Hop Attribute 403 The Remote-Next-Hop attribute is used to carry an additional 404 information (tunnel end-point, encapsulation type, etc). It has a 405 security value to contain the distribution of the Remote-Next-Hop 406 attribute within its planned scope of distribution. This scope could 407 be, but is not limited to, a particular department, site, 408 organization, across ASes within a same administration control or a 409 global scope. 411 To contain distribution of the Remote-Next-Hop attribute beyond its 412 intended scope of applicability, attribute filtering MAY be deployed. 413 The BGP speaker communicating to a speaker beyond the intended scope 414 of the Remote-Next-Hop attribute SHOULD filter the attribute during 415 the route announcements. 417 To facilitate attribute filtering, an implementation that supports 418 the BGP Remote-Next-Hop attribute MUST support a policy to (1) ignore 419 the received attribute and (2) filter the attribute. 421 7.2. Restrictions on Originating of Remote-Next-Hop Attribute 423 A BGP Remote-Next-Hop attribute may be added to routes that belong to 424 same Autonomous system as the tunnel endpoint address. 425 Implementations should validate the following to ensure the validity 426 of Remote-Next-Hop Attribute: 428 (1) BGP Remote-Next-Hops Tunnel Endpoint and AS number association 429 using BGP Origin Validation. 431 (2) BGP Remote-Next-Hop Tunnel Endpoints underlay routes origin AS 432 SHOULD be same as the AS number carried within BGP Remote-Next-Hop 433 attribute. 435 (3) The origin AS of BGP Routes that carry BGP Remote-Next-Hop 436 attribute MUST be same as the AS number carried within BGP Remote- 437 Next-Hop attribute. 439 (4) A BGP speaker that advertises its received routes to peers with 440 its local address as the BGP next-hop may add the Remote-Next-Hop 441 attribute to the routes if it desires to signal a tunnel 442 encapsulation for its peers to use while sending traffic to the 443 speaker for those routes. 445 8. Multiple tunnel endpoint addresses 447 In some cases, a device may need to accept incoming traffic for a 448 prefix via multiple different encapsulations, to support interactions 449 with remote devices with disjoint capabilities. Certain device 450 implementations cannot support the use of the same IP address as 451 local tunnel endpoint for multiple encapsulations. 453 In certain cases, a device may need to signal an additional, 454 alternate tunnel endpoint address, to be used by other devices only 455 as a backup in certain failure conditions. 457 9. Attribute error handling 459 When receiving a BGP Update message containing a malformed Remote- 460 Next-Hop attribute, the attribute MUST be quietly ignored and not 461 passed along to other BGP peers. (see [draft-ietf-idr-error- 462 handling], Section 7). This is equivalent to the -attribute discard- 463 action specified in [draft-ietf-idr-error-handling]. 465 Note that a BGP Remote-Next-Hop attribute MUST NOT be considered to 466 be malformed because it contains more than one TLV of a given type or 467 because it contains TLVs of unknown types. 469 If a BGP path attribute is received that has the Remote-Next-Hop 470 attribute codepoint but does not have the transitive bit set, the 471 attribute MUST be considered to be a malformed Remote-Next-Hop 472 attribute and MUST be discarded as specified in this section. 474 10. BGP speakers that do not support BGP Remote-Next-Hop attribute 476 If a device does not support this attribute, and receives this 477 attribute, then it follows the normal NLRI processing and BGP best 478 path selection, and the resulting forwarding decision is used, as the 479 attribute is optional. 481 11. Use Case scenarios 483 This section provides a brief overview of some use-cases for the BGP 484 Remote-Next-Hop attribute. Use of the BGP Remote-Next-Hop is not 485 limited to the examples in this section. Details regarding how the 486 attribute is used are described in the respective solution drafts 487 that are referenced where necessary. 489 11.1. Stateless user-plane architecture for virtualized EPC (vEPC) 491 The full usage case of BGP Remote-Next-Hop regarding vEPC can be 492 found in [vEPC], while [RFC6459] documents IPv6 in 3GPP EPS. 494 3GPP introduces Evolved Packet Core (EPC) that is fully IP based 495 mobile system for LTE and -advanced in their Release-8 specification 496 and beyond. Operators are now deploying EPC for LTE services and 497 encounter rapid LTE traffic growth. There are various activities to 498 offload mobile traffic in 3GPP and IETF such as LIPA, SIPTO and DMM. 499 The concept is similar that traffic of OTT (Over The Top) application 500 is offloaded at entity that is closer to the mobile node (ex. eNodeB 501 or closer anchor). 503 11.2. Stateless User-plane Architecture for virtual Packet Edge 505 With the emergence of the NfV technologies, different architectures 506 are proposed for virtualized services. These functions will normally 507 run in the datacenter. BGP remote-next-hop can be used to inject 508 traffic into the virtualized services running in the datacenter using 509 tunnels. These tunnels can be signalled using BGP remote-next-hop. 510 This facilitates a dynamic, simple and clean routing architecture. 511 BGP Remote Next Hop can simplify the orchestration or provisioning 512 layer by signalling the tunnel endpoint (virtual provider edge 513 router) in combination with the encapsulation protocol. 515 If this is used together with orchestrated traffic steering 516 mechanisms (i.e. BGP Flowspec) , it is possible to differentiate at 517 application level, and forward each different traffic types towards 518 the desired destination. 520 11.3. Dynamic Network Overlay Infrastructure 522 The BGP Remote-Next-Hop extension allows consistent signalling of 523 tunnel encapsulations as needed by virtual network overlay solutions 524 such as [I-D.drao-bgp-l3vpn-virtual-network-overlays] and 525 [I-D.sd-l2vpn-evpn-overlay] 527 11.4. Simple VPN solution using Multi-point Security Association 529 [draft-yamaya-ipsecme-mpsa] describes the overlay network solution by 530 utilizing dynamically established IPsec multi-point Security 531 Association (SA) without individual connection. 533 Multi-point SA technology provides the simplified mechanism of the 534 Auto Discovery and Configuration function. This is applicable for 535 any IPsec tunnels such as IPv4 over IPv4, IPv4 over IPv6, IPv6 over 536 IPv4 and IPv6 over IPv6. 538 MPSA does not provide peer discovery function by itself. However, 539 other mechanism, such as BGP, can be employed with MPSA for automatic 540 peer discovery. BGP Remote-Next-Hop can be used to learn peer 541 information as next-hops. 543 12. IANA Considerations 545 This document defines a new BGP attribute known as a BGP Remote-Next- 546 Hop attribute. We request IANA to allocate a new attribute code from 547 the -BGP Path Attributes- registry with a symbolic name -Remote-Next- 548 Hop- attribute. 550 We also request IANA to allocate four new BGP Tunnel Types from the 551 -BGP Tunnel Encapsulation Attribute Tunnel Types- registry with the 552 following symbolic names: -VXLAN- with Tunnel type 8, -NVGRE- with 553 Tunnel type 9, -GTP- with Tunnel type 10, -MPLS-in-GRE with Tunnel 554 type 11, -MPLS-in-UDP- with Tunnel type 12 and -MPLS-in-UDP-with-DTLS 555 with Tunnel type 13. 557 13. Security Considerations 559 This technology could be used as technology as man in the middle 560 attack, however with existing RPKI validation for BGP that risk is 561 reduced. 563 The distribution of Tunnel end-point address information can result 564 in potential DoS attacks. Therefore is it strongly recommended to 565 install traffic filters, IDSs and IPSs at the perimeter of the 566 tunneled network infrastructure. 568 measures SHOULD be taken to protect the validity of the BGP Remote- 569 Next-Hop attribute. It is possible to inject a rogue BGP Remote- 570 Next-Hop attribute to an NLRI resulting in Monkey-In-The-Middle 571 attack (MITM). To avoid this type of MITM attack, it is strongly 572 recommended to use a technology mechanism to verify that for NLRI it 573 is the expected BGP Remote-Next-Hop. We anticipate that this can be 574 done with an expansion of RPKI-Based origin validation, see 575 [I-D.ietf-sidr-pfx-validate]. 577 This does not avoid the fact that rogue AS numbers may be inserted or 578 injected into the AS-Path. To achieve protection against that threat 579 BGP Path Validation should be used, see 580 [I-D.ietf-sidr-bgpsec-overview]. 582 14. Privacy Considerations 584 This proposal may introduce privacy issues, however with BGP security 585 mechanisms in place they should be prevented. 587 15. Acknowledgements 589 The authors would like to thanks Satoru Matsushima, Ryuji Wakikawa 590 and Miya Kohno for their usefull vEPC discussions. Istvan Kakonyi 591 provided insight in the vPE use case scenario. 593 Satoshi Usui provided datapoints around Simple VPN solution using 594 Multi-point Security Association. 596 Thomas Morin, Ali Sajassi, Eric Rosen, Bruno Decraene, Jeffrey Haas 597 and Yakov Rehkter are thanked for their excellent draft review and 598 feedback. 600 16. Change Log 602 Initial Version: 16 May 2012 604 Hacked for -01: 17 July 2012 606 Hacked for -05: 07 January 2014 608 Hacked for -07: 15 September 2014 610 Hacked for -08: 7 October 2014 612 17. References 614 17.1. Normative References 616 [I-D.ietf-mpls-in-udp] 617 Xu, X., Sheth, N., Yong, L., Pignataro, C., and F. 618 Yongbing, "Encapsulating MPLS in UDP", draft-ietf-mpls-in- 619 udp-05 (work in progress), January 2014. 621 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 622 4)", RFC 1771, March 1995. 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, March 1997. 627 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 628 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 629 March 2000. 631 [RFC3484] Draves, R., "Default Address Selection for Internet 632 Protocol version 6 (IPv6)", RFC 3484, February 2003. 634 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 635 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 637 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 638 for IPv6 Hosts and Routers", RFC 4213, October 2005. 640 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 641 Protocol 4 (BGP-4)", RFC 4271, January 2006. 643 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 644 Subsequent Address Family Identifier (SAFI) and the BGP 645 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 647 [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel 648 Encapsulation Attribute", RFC 5566, June 2009. 650 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 651 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 652 Partnership Project (3GPP) Evolved Packet System (EPS)", 653 RFC 6459, January 2012. 655 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 656 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 657 eXtensible Local Area Network (VXLAN): A Framework for 658 Overlaying Virtualized Layer 2 Networks over Layer 3 659 Networks", RFC 7348, August 2014. 661 17.2. Informative References 663 [I-D.drao-bgp-l3vpn-virtual-network-overlays] 664 Rao, D., Mullooly, J., and R. Fernando, "Layer-3 virtual 665 network overlays based on BGP Layer-3 VPNs", draft-drao- 666 bgp-l3vpn-virtual-network-overlays-03 (work in progress), 667 July 2014. 669 [I-D.ietf-idr-error-handling] 670 Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 671 "Revised Error Handling for BGP UPDATE Messages", draft- 672 ietf-idr-error-handling-13 (work in progress), June 2014. 674 [I-D.ietf-sidr-bgpsec-overview] 675 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 676 draft-ietf-sidr-bgpsec-overview-05 (work in progress), 677 July 2014. 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 713 Cisco Systems 714 De Kleetlaan 6a 715 Diegem 1831 716 Belgium 718 Phone: +32 2704 5473 719 Email: gvandeve@cisco.com 720 Keyur Patel 721 Cisco Systems 722 170 W. Tasman Drive 723 San Jose, CA 95124 95134 724 USA 726 Email: keyupate@cisco.com 728 Dhananjaya Rao 729 Cisco Systems 730 170 W. Tasman Drive 731 San Jose, CA 95124 95134 732 USA 734 Email: dhrao@cisco.com 736 Robert Raszuk 737 NTT MCL Inc. 738 101 S Ellsworth Avenue Suite 350 739 San Mateo, CA 94401 740 US 742 Email: robert@raszuk.net 744 Randy Bush 745 Internet Initiative Japan 746 5147 Crystal Springs 747 Bainbridge Island, Washington 98110 748 US 750 Email: randy@psg.com