idnits 2.17.1 draft-vandevelde-idr-remote-next-hop-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 165 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 (October 2012) is 4182 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 154, but not defined == Unused Reference: 'I-D.ietf-sidr-bgpsec-overview' is defined on line 308, 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) == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-02 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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 Cisco Systems 5 Expires: April 02, 2013 R. Raszuk 6 NTT MCL Inc. 7 R. Bush 8 Internet Initiative Japan 9 October 2012 11 BGP Remote-Next-Hop 12 draft-vandevelde-idr-remote-next-hop-02 14 Abstract 16 The BGP Remote-Next-Hop is a new optional transitive attribute 17 intended to facilitate automatic tunneling across an AS on a per 18 address family basis. The attribute carries one or more tunnel end- 19 points for a NLRI. Additionally, tunnel encapsulation information is 20 communicated to successfully setup these tunnels. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 02, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 This document may not be modified, and derivative works of it may not 54 be created, and it may not be published except as an Internet-Draft. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 60 3. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop 61 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. BGP Remote-Next-Hop attribute TLV Format . . . . . . . . . . 3 63 5. Use Case scenarios . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1. Multi-homing for IPv6 . . . . . . . . . . . . . . . . . . 4 65 5.2. Dynamic Network Overlay Infrastructure . . . . . . . . . . 5 66 5.3. The Tunnel end-point is NOT the originating BGP speaker . 5 67 5.4. Networks that do not support BGP Remote-Next-Hop attribute 5 68 5.5. Networks that do NOT support BGP Remote-Next-Hop attribute 5 69 6. BGP Remote-Next-Hop Community . . . . . . . . . . . . . . . . 5 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 8.1. Protecting the validity of the BGP Remote-Next-Hop attribut 6 73 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 6 74 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 11.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 [RFC5512] defines an attribute attached to an NLRI to signal tunnel 83 end-point encapsulation information between two BGP speakers. It 84 assumes that the exchanged tunnel endpoint is the NLRI. 86 This document defines a new BGP transitive attribute known as a 87 Remote-Next-Hop BGP attribute for Intra-AS and Inter-AS usage which 88 removes that assumption. 90 The tunnel endpoint information and the tunnel encapsulation 91 information is carried within a Remote-Next-Hop BGP attribute. This 92 attribute is tagged on an any BGP NLRI. This way the Address Family 93 (AF) of the NLRI exchanged is decoupled from the tunnel SAFI address- 94 family defined in [RFC5512]. 96 2. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 99 be interpreted as described in [RFC2119] only when they appear in all 100 upper case. They may also appear in lower or mixed case as English 101 words, without any normative meaning. 103 3. Tunnel Encapsulation attribute versus BGP Remote-Next-Hop attribute 105 The Tunnel Encapsulation attribute [RFC5512] is based on the 106 principle that the tunnel end-point is the BGP speaker originating 107 the update and is inserted as the NLRI in the exchange, with the 108 consequence that it is impossible to set the endpoint it to an 109 arbitrary IP address. 111 There are use cases where it is desired that the tunnel end-point 112 address should be a different address, or set of addresses, than the 113 originating BGP speaker. The BGP Remote-Next-Hop attribute provides 114 the ability to have one or more different tunnel end-point addresses 115 from either the IPv4 and/or the IPv6 address-families. 117 The sub-TLVs from the Tunnel Encapsulation Attribute [RFC5512] are 118 reused for the BGP Next-Hop-Attribute. 120 Due to the intrinsic nature of both attributes, the tunnel 121 encapsulation end-point assumes that the tunnel end-point is both the 122 NLRI exchanged and the originating router, while the BGP Remote-Next- 123 Hop attribute is inserted for an exchanged NLRI by adding a set of 124 tunnel end-points, these two attributes are mutually exclusive. 126 4. BGP Remote-Next-Hop attribute TLV Format 128 This attribute is an optional transitive attribute [RFC1771]. 130 The BGP Remote-Next-Hop attribute is is composed of a set of Type- 131 Length-Value (TLV) encodings. The type code of the attribute is 132 (IANA to assign). Each TLV contains information corresponding to a 133 particular tunnel technology and tunnel end-point Address. The TLV 134 is structured as follows: 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Tunnel Type (2 Octets) | Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Addr len | Tunnel Address (IPv4 or IPv6) | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | AS Number | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Tunnel Parameters | 146 ~ ~ 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Tunnel Type (2 octets): identifies the type of tunneling technology 150 being signaled. This document defines the following types: 152 - L2TPv3 over IP [RFC3931]: Tunnel Type = 1 153 - GRE [RFC2784]: Tunnel Type = 2 154 - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7 156 Unknown types MUST be ignored and skipped upon receipt. 158 Length (2 octets): the total number of octets of the value field. 160 Tunnel Address Length - Addr len (1 octet): Length of Tunnel 161 Address. Set to 4 bytes for an IPv4 address and 16 bytes for an 162 IPv6 address. 164 AS Number - The AS number originating the BGP Remote-Next-Hop 165 attribute and is either a 2-byte AS or 4-Byte AS number 167 Value (variable): comprised of multiple sub-TLVs. Each sub-TLV 168 consists of three fields: a 1-octet type, 1-octet length, and zero 169 or more octets of value. The sub-TLV definitions and the sub-TLV 170 data are described in depth in [RFC5512]. 172 5. Use Case scenarios 174 This section provides a short overview of some use-cases for the BGP 175 Remote-Next-Hop attribute. Use of the BGP Remote-Next-Hop is not 176 limited to the examples in this section. 178 5.1. Multi-homing for IPv6 180 When an end-user IPv6 network is multi-homed to the Internet, it may 181 be assigned more than a single prefix originated by various upstream 182 ASs. Each AS prefers to only announce a supernet of all its assigned 183 IPv6 prefixes, unlike IPv4 where the AS announced the end-users 184 assigned prefix. The goal of this BGP policy behaviour is to keep 185 the number of entries in the IPv6 global BGP table to a minimum, it 186 also it also results in well known resiliency improvements. 188 For example, if an end-user IPv6 is peering with 2 different Service 189 providers AS1 and AS2. In this case the IPv6 end-user will have at 190 least one prefix assigned from each of these service providers. The 191 devices at the IPv6 end-user will each receive an address from these 192 prefixes. The devices will in most cases, when building IPv6 193 sessions (TCP, etc...), do so with only a single IPv6 address. The 194 decision which IPv6 address the device will use is documented in 195 [RFC3484]. 197 If one if the links between the end-user and one of the neighboring 198 AS's breaks, a consequence will be that a set of sessions need to be 199 reset, or that a section of the end-user network becomes unreachable. 201 With usage of the BGP-remote-Next-Hop attribute the service provider 202 can tunnel that packet towards an alternate BGP Remote-Next-Hop at 203 the end-users alternate provider and restore the network connectivity 204 even though the local link towards the end-user is broken. 206 5.2. Dynamic Network Overlay Infrastructure 208 With the BGP Remote-Next-Hop feature it is possible to build and 209 dynamically create an overlay tunneled network with privacy, traffic 210 isolation, and virtual private networks. 212 5.3. The Tunnel end-point is NOT the originating BGP speaker 214 Note that, in each network environment, the originating router is the 215 preferred tunnel end-point server. It may be that the network 216 administrator has deployed an independent set of tunnel end-point 217 servers across their network, which may or may not speak BGP. The BGP 218 Remote-Next-Hop attribute provides the ability to signal this via 219 BGP. 221 5.4. Networks that do not support BGP Remote-Next-Hop attribute 223 If a device does not support this attribute, and receives this 224 attribute, then normal NLRI BGP forwarding is used as the attribute 225 is optional and transitive. 227 5.5. Networks that do NOT support BGP Remote-Next-Hop attribute 229 If a BGP speaker does understand this attribute, and receives this 230 attribute, then the BGP speaker MAY, by configuration, skip use or 231 not use the information within this attribute. 233 6. BGP Remote-Next-Hop Community 235 place-holder for an BGP extension to signal valid prefixes allowed to 236 be considered as tunnel end-points. To be completed. 238 7. IANA Considerations 240 This memo asks the IANA for a new BGP attribute assignment. 242 8. Security Considerations 244 This technology could be used as technology as man in the middle 245 attack, however with existing RPKI validation for BGP that risk is 246 reduced. 248 The distribution of Tunnel end-point address information can result 249 in potential DoS attacks if the information is sent by malicious 250 organisations. Therefore is it strongly recommended to install 251 traffic filters, IDSs and IPSs at the perimeter of the tunneled 252 network infrastructure. 254 8.1. Protecting the validity of the BGP Remote-Next-Hop attribute 256 It is possible to inject a rogue BGP Remote-Next-Hop attribute to an 257 NLRI resulting in Monkey-In-The-Middle attack (MITM). To avoid this 258 type of MITM attack, it is strongly recommended to use a technology a 259 mechanism to verify that for NLRI it is the expected BGP Remote-Next- 260 Hop. We anticipate that this can be done with an expansion of RPKI- 261 Based origin validation, see [I-D.ietf-sidr-pfx-validate]. 263 This does not avoid the fact that rogue AS numbers may be inserted or 264 injected into the AS-Path. To achieve protection against that threat 265 BGP Path Validation should be used, see [I-D.ietf-sidr-bgpsec- 266 overview]. 268 9. Privacy Considerations 270 This proposal may introduce privacy issues, however with BGP security 271 mechanisms in place they should be prevented. 273 10. Change Log 275 Initial Version: 16 May 2012 277 Hacked for -01: 17 July 2012 279 11. References 281 11.1. Normative References 283 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 284 (BGP-4)", RFC 1771, March 1995. 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, 290 "Generic Routing Encapsulation (GRE)", RFC 2784, March 291 2000. 293 [RFC3484] Draves, R., "Default Address Selection for Internet 294 Protocol version 6 (IPv6)", RFC 3484, February 2003. 296 [RFC3931] Lau, J., Townsley, M. and I. Goyret, "Layer Two Tunneling 297 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 299 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 300 for IPv6 Hosts and Routers", RFC 4213, October 2005. 302 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 303 Subsequent Address Family Identifier (SAFI) and the BGP 304 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 306 11.2. Informative References 308 [I-D.ietf-sidr-bgpsec-overview] 309 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 310 Internet-Draft draft-ietf-sidr-bgpsec-overview-02, May 311 2012. 313 [I-D.ietf-sidr-pfx-validate] 314 Mohapatra, P., Scudder, J., Ward, D., Bush, R. and R. 315 Austein, "BGP Prefix Origin Validation", Internet-Draft 316 draft-ietf-sidr-pfx-validate-10, October 2012. 318 Authors' Addresses 320 Gunter Van de Velde 321 Cisco Systems 322 De Kleetlaan 6a 323 Diegem 1831 324 Belgium 326 Phone: +32 2704 5473 327 Email: gvandeve@cisco.com 329 Keyur Patel 330 Cisco Systems 331 170 W. Tasman Drive 332 San Jose, CA 95124 95134 333 USA 335 Email: keyupate@cisco.com 337 Robert Raszuk 338 NTT MCL Inc. 339 101 S Ellsworth Avenue Suite 350 340 San Mateo, CA 94401 341 US 343 Email: robert@raszuk.net 344 Randy Bush 345 Internet Initiative Japan 346 5147 Crystal Springs 347 Bainbridge Island, Washington 98110 348 US 350 Email: randy@psg.com