idnits 2.17.1 draft-vandevelde-idr-remote-next-hop-07.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 == Line 188 has weird spacing: '...tribute and i...' == 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 (June 30, 2014) is 3581 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 171, but not defined == Missing Reference: 'VXLAN' is mentioned on line 235, but not defined == Missing Reference: 'NVGRE' is mentioned on line 276, but not defined == Missing Reference: 'IPVPN-overlay' is mentioned on line 203, but not defined == Missing Reference: 'EVPN-overlay' is mentioned on line 203, but not defined == Unused Reference: 'RFC6459' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'I-D.mahalingam-dutt-dcops-vxlan' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'I-D.matsushima-stateless-uplane-vepc' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'I-D.sridharan-virtualization-nvgre' is defined on line 529, 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) ** Downref: Normative reference to an Informational RFC: RFC 6459 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-04 == Outdated reference: A later version (-09) exists of draft-mahalingam-dutt-dcops-vxlan-02 == 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-02 Summary: 4 errors (**), 0 flaws (~~), 16 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: January 1, 2015 Cisco Systems 6 R. Raszuk 7 NTT MCL Inc. 8 R. Bush 9 Internet Initiative Japan 10 June 30, 2014 12 BGP Remote-Next-Hop 13 draft-vandevelde-idr-remote-next-hop-07 15 Abstract 17 The BGP Remote-Next-Hop is an optional transitive attribute intended 18 to facilitate automatic tunneling across an AS on a per address 19 family basis. The attribute carries one or more tunnel end-points 20 for a NLRI. Additionally, tunnel encapsulation information is 21 communicated to successfully setup these tunnels. 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 January 1, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop 60 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. BGP Remote-Next-Hop attribute TLV Format . . . . . . . . . . 4 62 4.1. Encapsulation sub-TLVs for virtual network overlays . . . 5 63 4.1.1. Encapsulation sub-TLV for VXLAN . . . . . . . . . . . 6 64 4.1.2. Encapsulation sub-TLV for NVGRE . . . . . . . . . . . 7 65 4.1.3. Encapsulation sub-TLV for GTP . . . . . . . . . . . . 8 66 5. Use Case scenarios . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. Stateless user-plane architecture for virtualized EPC 68 (vEPC) . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. Stateless User-plane Architecture for virtual Packet Edge 9 70 5.3. Multi-homing for IPv6 . . . . . . . . . . . . . . . . . . 9 71 5.4. Dynamic Network Overlay Infrastructure . . . . . . . . . 10 72 5.5. The Tunnel end-point is NOT the originating BGP speaker . 10 73 5.6. Networks that do not support BGP Remote-Next-Hop 74 attribute . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.7. Networks that do support BGP Remote-Next-Hop attribute . 10 76 6. BGP Remote-Next-Hop Community . . . . . . . . . . . . . . . . 10 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 8.1. Protecting the validity of the BGP Remote-Next-Hop 80 attribute . . . . . . . . . . . . . . . . . . . . . . . . 11 81 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 83 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 12.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 [RFC5512] defines an attribute attached to an NLRI to signal tunnel 92 end-point encapsulation information between two BGP speakers for a 93 single tunnel. It assumes that the exchanged tunnel endpoint is the 94 NLRI. 96 This document defines a new BGP transitive attribute known as a 97 Remote-Next-Hop BGP attribute for Intra-AS and Inter-AS usage which 98 removes the assumption of both a single tunel and that the exchanged 99 NLRI is the tunnel endpoint. 101 The tunnel endpoint information and the tunnel encapsulation 102 information is carried within a Remote-Next-Hop BGP attribute. This 103 attribute can be added to any BGP NLRI. This way the Address Family 104 (AF) of the NLRI exchanged is decoupled from the tunnel SAFI address- 105 family defined in [RFC5512]. 107 2. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 111 be interpreted as described in [RFC2119] only when they appear in all 112 upper case. They may also appear in lower or mixed case as English 113 words, without any normative meaning. 115 3. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop attribute 117 The Tunnel Encapsulation attribute [RFC5512] is based on the 118 principle that the tunnel end-point is the BGP speaker originating 119 the update and is inserted as the NLRI in the exchange, with the 120 consequence that it is impossible to set the endpoint to an arbitrary 121 address. It is also assumed that there is only a single tunnel 122 between endpoints. 124 There are use cases where it is desired that the tunnel end-point 125 address should be a different address, or set of addresses, than the 126 originating BGP speaker. It is also useful to be able to signal 127 different encapsulation parameters for different prefixes with the 128 same remote tunnel end-point. The BGP Remote-Next-Hop attribute 129 provides the ability to have one or more different tunnel end-point 130 addresses from IPv4, IPv6 and/or other address-families, and be able 131 to signal next-hop encapsulation parameters along with any prefix. 133 The sub-TLVs from the Tunnel Encapsulation Attribute [RFC5512] are 134 reused for the BGP Next-Hop-Attribute. 136 Due to the intrinsic nature of both attributes, the tunnel 137 encapsulation end-point assumes that the tunnel end-point is both the 138 NLRI exchanged and the originating router, while the BGP Remote-Next- 139 Hop attribute is inserted for an exchanged NLRI by adding a set of 140 tunnel end-points and hence these two attributes are mutually 141 exclusive. 143 4. BGP Remote-Next-Hop attribute TLV Format 145 This attribute is an optional transitive attribute [RFC1771]. 147 The BGP Remote-Next-Hop attribute is is composed of a set of Type- 148 Length-Value (TLV) encodings. The type code of the attribute is 149 (IANA to assign). Each TLV contains information corresponding to a 150 particular tunnel technology and tunnel end-point address. The TLV 151 is structured as follows: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Tunnel Type (2 Octets) | Length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Addr len | Tunnel Address (IPv4, IPv6, or L2 Address) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | AS Number | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Tunnel Parameters | 163 ~ ~ 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Tunnel Type (2 octets): identifies the type of tunneling technology 167 being signaled. This document specifies the following types: 169 - L2TPv3 over IP [RFC3931]: Tunnel Type = 1 170 - GRE [RFC2784]: Tunnel Type = 2 171 - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7 173 This document also defines the following types: 174 - VXLAN: Tunnel Type = 8 175 - NVGRE: Tunnel Type = 9 176 - GTP: Tunnel Type = 10 177 - MPLS-in-GRE: Tunnel Type = 11 179 Unknown types MUST be ignored and skipped upon receipt. 181 Length (2 octets): the total number of octets of the value field. 183 Tunnel Address Length - Addr len (1 octet): Length of Tunnel 184 Address. Set to 4 bytes for an IPv4 address, 16 bytes for an 185 IPv6 address or 8 bytes for a MAC address. 187 AS Number - The AS number originating the BGP Remote-Next-Hop 188 attribute and is either a 2-byte AS or 4-Byte AS number 190 Tunnel Parameter - (variable): comprised of multiple sub-TLVs. 191 Each sub-TLV consists of three fields: a 1-octet type, 1-octet 192 length, and zero or more octets of value. The sub-TLV definitions 193 and the sub-TLV data are described in depth in [RFC5512]. 195 4.1. Encapsulation sub-TLVs for virtual network overlays 197 A VN-ID may need to be signaled along with the encapsulation types 198 for DC overlay encapsulations such as [VXLAN] and [NVGRE]. The VN-ID 199 when present in the encapsulation sub-TLV for an overlay 200 encapsulation, MUST be processed by a receiving device if it is 201 capable of understanding it. The details regarding how such a 202 signaled VN-ID is processed and used is defined in specifications 203 such as [IPVPN-overlay] and [EVPN-overlay]. 205 4.1.1. Encapsulation sub-TLV for VXLAN 207 This document defines a new encapsulation sub-TLV format, defined in 208 [RFC5512], for VXLAN tunnels. When the tunnel type is VXLAN, the 209 following is the structure of the value field in the encapsulation 210 sub-TLV: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | MAC Address (4 Octets) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | MAC Address (2 Octets) | Reserved | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 V: When set to 1, it indicates that a valid VN-ID is present in the 223 encapsulation sub-TLV. 224 M: When set to 1, it indicates that a valid MAC Address is present 225 in the encapsulation sub-TLV. 226 R: The remaining bits in the 8-bit flags field are reserved for 227 further use. They MUST be set to 0 on transmit and MUST be ignored 228 on receipt. 230 VN-ID: Contains a 24-bit VN-ID value, if the 'V' flag bit is set. 231 If the 'V' flag is not set, it SHOULD be set to zero and MUST be 232 ignored on receipt. 234 The VN-ID value is filled in the VNI field in the VXLAN packet 235 header as defined in [VXLAN]. 237 MAC Address: Contains an Ethernet MAC address if the 'M' flag bit 238 is set. If the 'M' flag is not set, it SHOULD set to all zeroes and 239 MUST be ignored on receipt. 241 The MAC address is local to the device advertising the route, and 242 should be included as the destination MAC address in the inner 243 Ethernet header immediately following the outer VXLAN header, in 244 the packets destined to the advertiser. 246 4.1.2. Encapsulation sub-TLV for NVGRE 248 This document defines a new encapsulation sub-TLV format, defined in 249 [RFC5512], for NVGRE tunnels. When the tunnel type is NVGRE, the 250 following is the structure of the value field in the encapsulation 251 sub-TLV: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | MAC Address (4 Octets) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | MAC Address (2 Octets) | Reserved | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 V: When set to 1, it indicates that a valid VN-ID is present in the 264 encapsulation sub-TLV. 265 M: When set to 1, it indicates that a valid MAC Address is present 266 in the encapsulation sub-TLV. 267 R: The remaining bits in the 8-bit flags field are reserved for 268 further use. They MUST be set to 0 on transmit and MUST be ignored 269 on receipt. 271 VN-ID: Contains a 24-bit VN-ID value, if the 'V' flag bit is set. 272 If the 'V' flag is not set, it SHOULD be set to zero and MUST be 273 ignored on receipt. 275 The VN-ID value is filled in the VSID field in the NVGRE packet 276 header as defined in [NVGRE]. 278 MAC Address: Contains an Ethernet MAC address if the 'M' flag bit is 279 set. If the 'M' flag is not set, it SHOULD set to all zeroes and 280 MUST be ignored on receipt. 282 The MAC address is local to the device advertising the route, and 283 should be included as the destination MAC address in the inner 284 Ethernet header immediately following the outer NVGRE header, in 285 the packets destined to 286 the advertiser. 288 4.1.3. Encapsulation sub-TLV for GTP 290 This document defines a new encapsulation sub-TLV format, defined in 291 [RFC5512], for GTP tunnels. When the tunnel type is GTP, the 292 following is the structure of the value field in the encapsulation 293 sub-TLV: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Local TEID (4 Octets) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Local Endpoint Address (4/16 Octets (IPv4/IPv6)) | 301 . . 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a 305 GTP tunnel assigned by EPC that is used to distinguish different 306 connections in received packets within the tunnel. 308 Local Endpoint Address: Indicates a 4-octets IPv4 address or 309 16-octets IPv6 address as a local endpoint address of GTP tunnel. 311 Local Endpoint Address element makes a tunnel endpoint router 312 allow to have multiple Local TEID spaces. Received GTP packets 313 are identified which tunnel connection by combination of Local 314 Endpoint Address and Local TEID. 316 5. Use Case scenarios 318 This section provides a short overview of some use-cases for the BGP 319 Remote-Next-Hop attribute. Use of the BGP Remote-Next-Hop is not 320 limited to the examples in this section. 322 5.1. Stateless user-plane architecture for virtualized EPC (vEPC) 324 The full usage case of BGP remote-next-hop regarding vEPC can be 325 found in [vEPC], while [RFC6459]documents IPv6 in 3GPP EPS. 327 3GPP introduces Evolved Packet Core (EPC) that is fully IP based 328 mobile system for LTE and -advanced in their Release-8 specification 329 and beyond. Operators are now deploying EPC for LTE services and 330 encounter rapid LTE traffic growth. There are various activities to 331 offload mobile traffic in 3GPP and IETF such as LIPA, SIPTO and DMM. 332 The concept is similar that traffic of OTT (Over The Top) application 333 is offloaded at entity that is closer to the mobile node (ex. eNodeB 334 or closer anchor). 336 5.2. Stateless User-plane Architecture for virtual Packet Edge 338 With the emergence of the NfV technologies, different architectures 339 are proposed for virtualised Services. These functions will normally 340 run in the datacenter. BGP remote-next-hop can be used to inject 341 traffic into the virtualised services running in the datacenter for a 342 optimized, simple and clean routing architecture. BGP Remote Next 343 Hop can simplify the orchestration or provisioning layer by 344 signalling the tunnel endpoint (virtual provider edge router) and the 345 encapsulation protocol. 347 If this is used together with orchestrated traffic steering mechnisms 348 (i.e. BGP Flowspec) , it is possible to differentiate at application 349 level, and forward each different traffic types towards the desired 350 destination. 352 5.3. Multi-homing for IPv6 354 When an end-user IPv6 network is multi-homed to the Internet, it may 355 be assigned more than a single prefix originated by various upstream 356 ASs. Each AS prefers to only announce a supernet of all its assigned 357 IPv6 prefixes, unlike IPv4 where the AS announced the end-users 358 assigned prefix. The goal of this BGP policy behaviour is to keep 359 the number of entries in the IPv6 global BGP table to a minimum, it 360 also it also results in well known resiliency improvements. 362 For example, if an end-user IPv6 is peering with 2 different Service 363 providers AS1 and AS2. In this case the IPv6 end-user will have at 364 least one prefix assigned from each of these service providers. The 365 devices at the IPv6 end-user will each receive an address from these 366 prefixes. The devices will in most cases, when building IPv6 367 sessions (TCP, etc...), do so with only a single IPv6 address. The 368 decision which IPv6 address the device will use is documented in 369 [RFC3484]. 371 If one of the links between the end-user and one the neighboring AS's 372 fails, a consequence will be that a set of sessions need to be reset, 373 or that a section of the end-user network becomes unreachable. 375 With usage of the BGP-remote-Next-Hop attribute the service provider 376 can tunnel that packet towards an alternate BGP Remote-Next-Hop at 377 the end-users alternate provider and restore the network connectivity 378 even though the local link towards the end-user is broken. 380 5.4. Dynamic Network Overlay Infrastructure 382 The BGP Remote-Next-Hop extension allows signaling tunnel 383 encapsulations needed to build and dynamically create an overlay 384 tunneled network with traffic isolation and virtual private networks. 386 5.5. The Tunnel end-point is NOT the originating BGP speaker 388 Note that, in each network environment, the originating router is the 389 preferred tunnel end-point server. It may be that the network 390 administrator has deployed an independent set of tunnel end-point 391 servers across their network, which may or may not speak BGP. The 392 BGP Remote-Next-Hop attribute provides the ability to signal this via 393 BGP. 395 5.6. Networks that do not support BGP Remote-Next-Hop attribute 397 If a device does not support this attribute, and receives this 398 attribute, then normal NLRI BGP forwarding is used as the attribute 399 is optional and transitive. 401 5.7. Networks that do support BGP Remote-Next-Hop attribute 403 If a BGP speaker does understand this attribute, and receives this 404 attribute, then the BGP speaker MAY, by configuration, skip use or 405 not use the information within this attribute. 407 6. BGP Remote-Next-Hop Community 409 place-holder for an BGP extension to signal valid prefixes allowed to 410 be considered as tunnel end-points. To be completed. 412 7. IANA Considerations 414 This document defines a new BGP attribute known as a BGP Remote-Next- 415 Hop attribute. We request IANA to allocate a new attribute code from 416 the "BGP Path Attributes" registry with a symbolic name "Remote-Next- 417 Hop" attribute. 419 We also request IANA to allocate four new BGP Tunnel Types from the 420 "BGP Tunnel Encapsulation Attribute Tunnel Types" registry with the 421 following symbolic names: "VXLAN" with Tunnel type 8, "NVGRE" with 422 Tunnel type 9, "GTP" with Tunnel type 10, and "MPLS-in-GRE" with 423 Tunnel type 11. 425 8. Security Considerations 427 This technology could be used as technology as man in the middle 428 attack, however with existing RPKI validation for BGP that risk is 429 reduced. 431 The distribution of Tunnel end-point address information can result 432 in potential DoS attacks if the information is sent by malicious 433 organisations. Therefore is it strongly recommended to install 434 traffic filters, IDSs and IPSs at the perimeter of the tunneled 435 network infrastructure. 437 8.1. Protecting the validity of the BGP Remote-Next-Hop attribute 439 It is possible to inject a rogue BGP Remote-Next-Hop attribute to an 440 NLRI resulting in Monkey-In-The-Middle attack (MITM). To avoid this 441 type of MITM attack, it is strongly recommended to use a technology a 442 mechanism to verify that for NLRI it is the expected BGP Remote-Next- 443 Hop. We anticipate that this can be done with an expansion of RPKI- 444 Based origin validation, see [I-D.ietf-sidr-pfx-validate]. 446 This does not avoid the fact that rogue AS numbers may be inserted or 447 injected into the AS-Path. To achieve protection against that threat 448 BGP Path Validation should be used, see 449 [I-D.ietf-sidr-bgpsec-overview]. 451 9. Privacy Considerations 453 This proposal may introduce privacy issues, however with BGP security 454 mechanisms in place they should be prevented. 456 10. Acknowledgements 458 The authors would like to thanks Satoru Matsushima, Ryuji Wakikawa 459 and Miya Kohno for their usefull vEPC discussions. Istvan Kakonyi 460 provided insight in the vPE use case scenario. 462 11. Change Log 464 Initial Version: 16 May 2012 466 Hacked for -01: 17 July 2012 468 Hacked for -05: 07 January 2014 470 Hacked for -07: 30 June 2014 472 12. References 474 12.1. Normative References 476 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 477 4)", RFC 1771, March 1995. 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, March 1997. 482 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 483 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 484 March 2000. 486 [RFC3484] Draves, R., "Default Address Selection for Internet 487 Protocol version 6 (IPv6)", RFC 3484, February 2003. 489 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 490 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 492 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 493 for IPv6 Hosts and Routers", RFC 4213, October 2005. 495 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 496 Subsequent Address Family Identifier (SAFI) and the BGP 497 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 499 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 500 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 501 Partnership Project (3GPP) Evolved Packet System (EPS)", 502 RFC 6459, January 2012. 504 12.2. Informative References 506 [I-D.ietf-sidr-bgpsec-overview] 507 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 508 draft-ietf-sidr-bgpsec-overview-04 (work in progress), 509 December 2013. 511 [I-D.ietf-sidr-pfx-validate] 512 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 513 Austein, "BGP Prefix Origin Validation", draft-ietf-sidr- 514 pfx-validate-10 (work in progress), October 2012. 516 [I-D.mahalingam-dutt-dcops-vxlan] 517 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 518 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 519 Framework for Overlaying Virtualized Layer 2 Networks over 520 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-02 521 (work in progress), August 2012. 523 [I-D.matsushima-stateless-uplane-vepc] 524 Matsushima, S. and R. Wakikawa, "Stateless user-plane 525 architecture for virtualized EPC (vEPC)", draft- 526 matsushima-stateless-uplane-vepc-01 (work in progress), 527 July 2013. 529 [I-D.sridharan-virtualization-nvgre] 530 Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang, 531 Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., 532 and C. Tumuluri, "NVGRE: Network Virtualization using 533 Generic Routing Encapsulation", draft-sridharan- 534 virtualization-nvgre-02 (work in progress), February 2013. 536 Authors' Addresses 538 Gunter Van de Velde 539 Cisco Systems 540 De Kleetlaan 6a 541 Diegem 1831 542 Belgium 544 Phone: +32 2704 5473 545 Email: gvandeve@cisco.com 547 Keyur Patel 548 Cisco Systems 549 170 W. Tasman Drive 550 San Jose, CA 95124 95134 551 USA 553 Email: keyupate@cisco.com 555 Dhananjaya Rao 556 Cisco Systems 557 170 W. Tasman Drive 558 San Jose, CA 95124 95134 559 USA 561 Email: dhrao@cisco.com 562 Robert Raszuk 563 NTT MCL Inc. 564 101 S Ellsworth Avenue Suite 350 565 San Mateo, CA 94401 566 US 568 Email: robert@raszuk.net 570 Randy Bush 571 Internet Initiative Japan 572 5147 Crystal Springs 573 Bainbridge Island, Washington 98110 574 US 576 Email: randy@psg.com