idnits 2.17.1 draft-vandevelde-idr-remote-next-hop-06.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 187 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 3589 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 234, but not defined == Missing Reference: 'NVGRE' is mentioned on line 275, but not defined == Missing Reference: 'IPVPN-overlay' is mentioned on line 202, but not defined == Missing Reference: 'EVPN-overlay' is mentioned on line 202, but not defined == Missing Reference: 'RFC-to-Be' is mentioned on line 435, but not defined == Unused Reference: 'RFC6459' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'I-D.mahalingam-dutt-dcops-vxlan' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'I-D.matsushima-stateless-uplane-vepc' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'I-D.sridharan-virtualization-nvgre' is defined on line 541, 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 (~~), 17 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-06 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 . . . . . . . . . . . . . . . . . . . . . . 12 83 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 12.2. Informative References . . . . . . . . . . . . . . . . . 13 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 178 Unknown types MUST be ignored and skipped upon receipt. 180 Length (2 octets): the total number of octets of the value field. 182 Tunnel Address Length - Addr len (1 octet): Length of Tunnel 183 Address. Set to 4 bytes for an IPv4 address, 16 bytes for an 184 IPv6 address or 8 bytes for a MAC address. 186 AS Number - The AS number originating the BGP Remote-Next-Hop 187 attribute and is either a 2-byte AS or 4-Byte AS number 189 Tunnel Parameter - (variable): comprised of multiple sub-TLVs. 190 Each sub-TLV consists of three fields: a 1-octet type, 1-octet 191 length, and zero or more octets of value. The sub-TLV definitions 192 and the sub-TLV data are described in depth in [RFC5512]. 194 4.1. Encapsulation sub-TLVs for virtual network overlays 196 A VN-ID may need to be signaled along with the encapsulation types 197 for DC overlay encapsulations such as [VXLAN] and [NVGRE]. The VN-ID 198 when present in the encapsulation sub-TLV for an overlay 199 encapsulation, MUST be processed by a receiving device if it is 200 capable of understanding it. The details regarding how such a 201 signaled VN-ID is processed and used is defined in specifications 202 such as [IPVPN-overlay] and [EVPN-overlay]. 204 4.1.1. Encapsulation sub-TLV for VXLAN 206 This document defines a new encapsulation sub-TLV format, defined in 207 [RFC5512], for VXLAN tunnels. When the tunnel type is VXLAN, the 208 following is the structure of the value field in the encapsulation 209 sub-TLV: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | MAC Address (4 Octets) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | MAC Address (2 Octets) | Reserved | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 V: When set to 1, it indicates that a valid VN-ID is present in the 222 encapsulation sub-TLV. 223 M: When set to 1, it indicates that a valid MAC Address is present 224 in the encapsulation sub-TLV. 225 R: The remaining bits in the 8-bit flags field are reserved for 226 further use. They MUST be set to 0 on transmit and MUST be ignored 227 on receipt. 229 VN-ID: Contains a 24-bit VN-ID value, if the 'V' flag bit is set. 230 If the 'V' flag is not set, it SHOULD be set to zero and MUST be 231 ignored on receipt. 233 The VN-ID value is filled in the VNI field in the VXLAN packet 234 header as defined in [VXLAN]. 236 MAC Address: Contains an Ethernet MAC address if the 'M' flag bit 237 is set. If the 'M' flag is not set, it SHOULD set to all zeroes and 238 MUST be ignored on receipt. 240 The MAC address is local to the device advertising the route, and 241 should be included as the destination MAC address in the inner 242 Ethernet header immediately following the outer VXLAN header, in 243 the packets destined to the advertiser. 245 4.1.2. Encapsulation sub-TLV for NVGRE 247 This document defines a new encapsulation sub-TLV format, defined in 248 [RFC5512], for NVGRE tunnels. When the tunnel type is NVGRE, the 249 following is the structure of the value field in the encapsulation 250 sub-TLV: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | MAC Address (4 Octets) | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | MAC Address (2 Octets) | Reserved | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 V: When set to 1, it indicates that a valid VN-ID is present in the 263 encapsulation sub-TLV. 264 M: When set to 1, it indicates that a valid MAC Address is present 265 in the encapsulation sub-TLV. 266 R: The remaining bits in the 8-bit flags field are reserved for 267 further use. They MUST be set to 0 on transmit and MUST be ignored 268 on receipt. 270 VN-ID: Contains a 24-bit VN-ID value, if the 'V' flag bit is set. 271 If the 'V' flag is not set, it SHOULD be set to zero and MUST be 272 ignored on receipt. 274 The VN-ID value is filled in the VSID field in the NVGRE packet 275 header as defined in [NVGRE]. 277 MAC Address: Contains an Ethernet MAC address if the 'M' flag bit is 278 set. If the 'M' flag is not set, it SHOULD set to all zeroes and 279 MUST be ignored on receipt. 281 The MAC address is local to the device advertising the route, and 282 should be included as the destination MAC address in the inner 283 Ethernet header immediately following the outer NVGRE header, in 284 the packets destined to 285 the advertiser. 287 4.1.3. Encapsulation sub-TLV for GTP 289 This document defines a new encapsulation sub-TLV format, defined in 290 [RFC5512], for GTP tunnels. When the tunnel type is GTP, the 291 following is the structure of the value field in the encapsulation 292 sub-TLV: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Local TEID (4 Octets) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Local Endpoint Address (4/16 Octets (IPv4/IPv6)) | 300 . . 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a 304 GTP tunnel assigned by EPC that is used to distinguish different 305 connections in received packets within the tunnel. 307 Local Endpoint Address: Indicates a 4-octets IPv4 address or 308 16-octets IPv6 address as a local endpoint address of GTP tunnel. 310 Local Endpoint Address element makes a tunnel endpoint router 311 allow to have multiple Local TEID spaces. Received GTP packets 312 are identified which tunnel connection by combination of Local 313 Endpoint Address and Local TEID. 315 5. Use Case scenarios 317 This section provides a short overview of some use-cases for the BGP 318 Remote-Next-Hop attribute. Use of the BGP Remote-Next-Hop is not 319 limited to the examples in this section. 321 5.1. Stateless user-plane architecture for virtualized EPC (vEPC) 323 The full usage case of BGP remote-next-hop regarding vEPC can be 324 found in [vEPC], while [RFC6459]documents IPv6 in 3GPP EPS. 326 3GPP introduces Evolved Packet Core (EPC) that is fully IP based 327 mobile system for LTE and -advanced in their Release-8 specification 328 and beyond. Operators are now deploying EPC for LTE services and 329 encounter rapid LTE traffic growth. There are various activities to 330 offload mobile traffic in 3GPP and IETF such as LIPA, SIPTO and DMM. 331 The concept is similar that traffic of OTT (Over The Top) application 332 is offloaded at entity that is closer to the mobile node (ex. eNodeB 333 or closer anchor). 335 5.2. Stateless User-plane Architecture for virtual Packet Edge 337 With the emergence of the NfV technologies, different architectures 338 are proposed for virtualised Services. These functions will normally 339 run in the datacenter. BGP remote-next-hop can be used to inject 340 traffic into the virtualised services running in the datacenter for a 341 optimized, simple and clean routing architecture. BGP Remote Next 342 Hop can simplify the orchestration or provisioning layer by 343 signalling the tunnel endpoint (virtual provider edge router) and the 344 encapsulation protocol. 346 If this is used together with orchestrated traffic steering mechnisms 347 (i.e. BGP Flowspec) , it is possible to differentiate at application 348 level, and forward each different traffic types towards the desired 349 destination. 351 5.3. Multi-homing for IPv6 353 When an end-user IPv6 network is multi-homed to the Internet, it may 354 be assigned more than a single prefix originated by various upstream 355 ASs. Each AS prefers to only announce a supernet of all its assigned 356 IPv6 prefixes, unlike IPv4 where the AS announced the end-users 357 assigned prefix. The goal of this BGP policy behaviour is to keep 358 the number of entries in the IPv6 global BGP table to a minimum, it 359 also it also results in well known resiliency improvements. 361 For example, if an end-user IPv6 is peering with 2 different Service 362 providers AS1 and AS2. In this case the IPv6 end-user will have at 363 least one prefix assigned from each of these service providers. The 364 devices at the IPv6 end-user will each receive an address from these 365 prefixes. The devices will in most cases, when building IPv6 366 sessions (TCP, etc...), do so with only a single IPv6 address. The 367 decision which IPv6 address the device will use is documented in 368 [RFC3484]. 370 If one of the links between the end-user and one the neighboring AS's 371 fails, a consequence will be that a set of sessions need to be reset, 372 or that a section of the end-user network becomes unreachable. 374 With usage of the BGP-remote-Next-Hop attribute the service provider 375 can tunnel that packet towards an alternate BGP Remote-Next-Hop at 376 the end-users alternate provider and restore the network connectivity 377 even though the local link towards the end-user is broken. 379 5.4. Dynamic Network Overlay Infrastructure 381 The BGP Remote-Next-Hop extension allows signaling tunnel 382 encapsulations needed to build and dynamically create an overlay 383 tunneled network with traffic isolation and virtual private networks. 385 5.5. The Tunnel end-point is NOT the originating BGP speaker 387 Note that, in each network environment, the originating router is the 388 preferred tunnel end-point server. It may be that the network 389 administrator has deployed an independent set of tunnel end-point 390 servers across their network, which may or may not speak BGP. The 391 BGP Remote-Next-Hop attribute provides the ability to signal this via 392 BGP. 394 5.6. Networks that do not support BGP Remote-Next-Hop attribute 396 If a device does not support this attribute, and receives this 397 attribute, then normal NLRI BGP forwarding is used as the attribute 398 is optional and transitive. 400 5.7. Networks that do support BGP Remote-Next-Hop attribute 402 If a BGP speaker does understand this attribute, and receives this 403 attribute, then the BGP speaker MAY, by configuration, skip use or 404 not use the information within this attribute. 406 6. BGP Remote-Next-Hop Community 408 place-holder for an BGP extension to signal valid prefixes allowed to 409 be considered as tunnel end-points. To be completed. 411 7. IANA Considerations 413 This document defines a new BGP attribute known as a BGP Remote-Next- 414 Hop attribute. We request IANA to allocate a new attribute code from 415 the "BGP Path Attributes" registry with a symbolic name "Remote-Next- 416 Hop" attribute. 418 This document also defines new Tunnel types for BGP Remote-Next-Hop 419 attributes. We request IANA to create a new registry for BGP Remote- 420 Next-Hop Tunnel Types as follows: 422 Under "Border Gateway Protocol (BGP) Parameters": 423 Registry: "BGP Remote-Next-Hop Tunnel Types" 424 Reference: [RFC-to-Be] 425 Registration Procedure(s): Values 0-65535 Standards Action, 426 First Come, First Served 428 Value Code Reference 429 0 Reserved 430 1 L2TPv3 over IP [RFC-to-Be] 431 2 GRE [RFC-to-Be] 432 3 IP in IP [RFC-to-Be] 433 4 VXLAN [RFC-to-Be] 434 5 NVGRE [RFC-to-Be] 435 6 GTP [RFC-to-Be] 436 7-65535 Unassigned 437 65535 Reserved 439 8. Security Considerations 441 This technology could be used as technology as man in the middle 442 attack, however with existing RPKI validation for BGP that risk is 443 reduced. 445 The distribution of Tunnel end-point address information can result 446 in potential DoS attacks if the information is sent by malicious 447 organisations. Therefore is it strongly recommended to install 448 traffic filters, IDSs and IPSs at the perimeter of the tunneled 449 network infrastructure. 451 8.1. Protecting the validity of the BGP Remote-Next-Hop attribute 453 It is possible to inject a rogue BGP Remote-Next-Hop attribute to an 454 NLRI resulting in Monkey-In-The-Middle attack (MITM). To avoid this 455 type of MITM attack, it is strongly recommended to use a technology a 456 mechanism to verify that for NLRI it is the expected BGP Remote-Next- 457 Hop. We anticipate that this can be done with an expansion of RPKI- 458 Based origin validation, see [I-D.ietf-sidr-pfx-validate]. 460 This does not avoid the fact that rogue AS numbers may be inserted or 461 injected into the AS-Path. To achieve protection against that threat 462 BGP Path Validation should be used, see 463 [I-D.ietf-sidr-bgpsec-overview]. 465 9. Privacy Considerations 467 This proposal may introduce privacy issues, however with BGP security 468 mechanisms in place they should be prevented. 470 10. Acknowledgements 472 The authors would like to thanks Satoru Matsushima, Ryuji Wakikawa 473 and Miya Kohno for their usefull vEPC discussions. Istvan Kakonyi 474 provided insight in the vPE use case scenario. 476 11. Change Log 478 Initial Version: 16 May 2012 480 Hacked for -01: 17 July 2012 482 Hacked for -05: 07 January 2014 484 12. References 486 12.1. Normative References 488 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 489 4)", RFC 1771, March 1995. 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 495 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 496 March 2000. 498 [RFC3484] Draves, R., "Default Address Selection for Internet 499 Protocol version 6 (IPv6)", RFC 3484, February 2003. 501 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 502 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 504 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 505 for IPv6 Hosts and Routers", RFC 4213, October 2005. 507 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 508 Subsequent Address Family Identifier (SAFI) and the BGP 509 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 511 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 512 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 513 Partnership Project (3GPP) Evolved Packet System (EPS)", 514 RFC 6459, January 2012. 516 12.2. Informative References 518 [I-D.ietf-sidr-bgpsec-overview] 519 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 520 draft-ietf-sidr-bgpsec-overview-04 (work in progress), 521 December 2013. 523 [I-D.ietf-sidr-pfx-validate] 524 Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 525 Austein, "BGP Prefix Origin Validation", draft-ietf-sidr- 526 pfx-validate-10 (work in progress), October 2012. 528 [I-D.mahalingam-dutt-dcops-vxlan] 529 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 530 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 531 Framework for Overlaying Virtualized Layer 2 Networks over 532 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-02 533 (work in progress), August 2012. 535 [I-D.matsushima-stateless-uplane-vepc] 536 Matsushima, S. and R. Wakikawa, "Stateless user-plane 537 architecture for virtualized EPC (vEPC)", draft- 538 matsushima-stateless-uplane-vepc-01 (work in progress), 539 July 2013. 541 [I-D.sridharan-virtualization-nvgre] 542 Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang, 543 Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., 544 and C. Tumuluri, "NVGRE: Network Virtualization using 545 Generic Routing Encapsulation", draft-sridharan- 546 virtualization-nvgre-02 (work in progress), February 2013. 548 Authors' Addresses 550 Gunter Van de Velde 551 Cisco Systems 552 De Kleetlaan 6a 553 Diegem 1831 554 Belgium 556 Phone: +32 2704 5473 557 Email: gvandeve@cisco.com 558 Keyur Patel 559 Cisco Systems 560 170 W. Tasman Drive 561 San Jose, CA 95124 95134 562 USA 564 Email: keyupate@cisco.com 566 Dhananjaya Rao 567 Cisco Systems 568 170 W. Tasman Drive 569 San Jose, CA 95124 95134 570 USA 572 Email: dhrao@cisco.com 574 Robert Raszuk 575 NTT MCL Inc. 576 101 S Ellsworth Avenue Suite 350 577 San Mateo, CA 94401 578 US 580 Email: robert@raszuk.net 582 Randy Bush 583 Internet Initiative Japan 584 5147 Crystal Springs 585 Bainbridge Island, Washington 98110 586 US 588 Email: randy@psg.com