idnits 2.17.1 draft-jhaas-ase-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview and Rational' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 82 has weird spacing: '...unately remov...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 February 2001) is 8465 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 section? '1' on line 380 looks like a reference -- Missing reference section? '2' on line 383 looks like a reference -- Missing reference section? '3' on line 386 looks like a reference -- Missing reference section? '4' on line 389 looks like a reference -- Missing reference section? '5' on line 392 looks like a reference -- Missing reference section? '6' on line 396 looks like a reference -- Missing reference section? '7' on line 399 looks like a reference -- Missing reference section? '8' on line 402 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft draft-jhaas-ase-00.txt Februrary 2001 4 Network Working Group J. Haas 5 Internet Draft NextHop 6 Expiration Date: August 2001 22 February 2001 8 Autonomous System Number Substitution on Egress 9 draft-jhaas-ase-00.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as "work 25 in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Overview and Rational 35 Network Reachability information in the Internet is curretly 36 exchanged through the use of the BGP-4 protocol[1]. BGP Speakers 37 require an Autonomous System (AS) number in order to peer. The AS 38 number is used to identify sets of routes sharing a common 39 administrative policy. 41 Studies of the current allocation patterns of Autonomous System 42 numbers have projected that all available Autonomous System 43 numbers will be exhausted by 2005. As noted by recent 44 presentations at IETF and NANOG, the allocation pattern has been 45 roughly exponential.[2] 47 The CIDR report[3] has shown that a large number of ASs are 48 advertising only a single prefix into the global routing system. 49 Additional data supplied by CAIDA[4] suggest that a large number 50 of leaf AS's advertise a relatively small number of prefixes. 52 This data suggests that the large increase in the usage of AS 53 numbers is due to small networks multihoming themselves. The 54 reasons for the current increase in the rate of multihoming is 55 outside the scope of this document. 57 Most of these ASs that announce a small number of prefixes could 58 be adequately served in their multihoming by having each of their 59 upstream providers originate the route. There are several issues 60 that make this problematic: 62 +o RFC 1930[5], Section 7 states that a prefix should not be 63 originated from more than one AS. However the CAIDA data 64 also notes several ASs that already violate this. 65 Operationally this may not be an issue where the networks 66 originating the prefix are doing this for a stub AS. 68 +o Methods by which the upstream AS could originate the prefix: 70 a. Static configuration. This can result in blackholes if 71 the customer link goes down. 73 b. Running an IGP on the customer link. This addresses 74 the blackhole issue, however due to security concerns 75 many providers do not wish to run an IGP on a customer 76 link. Additionally, a flapping customer link would 77 affect internal routing convergence. 79 c. Running BGP on the link using a private AS number and 80 utilizing the ability of the ISP router to strip the 81 private AS. This solves problems a and b. This 82 unfortunately removes the ability of the customer to 83 bias their incoming traffic by adjusting AS_PATH 84 length. 86 In order to address AS number depletion, a recent Internet Draft 87 (draft-chen-as4bytes-00 [6]) suggests extending the AS Path 88 component size from 2 octets to 4 octets. This would address the 89 issue of AS number depletion, but requires wide deployment 90 throughout the Internet to be most useful. The method suggested 91 by this draft works at the edges of a partcipating network and 92 doesn't require additional functionality to be added to non- 93 participating routers. 95 RFC 1965[7] (recently updated), AS Confederations for BGP, 96 introduced the concept of modifying a route's AS_PATH to remove 97 confederation member AS numbers when that route is advertised 98 outside of the AS confederation. The member AS numbers are 99 replaced with the AS number for the AS confederation, thus 100 representing the group of ASs as a single AS. 102 This draft recommends a simple modification similar to AS 103 Confederations that helps conserve AS numbers. 105 3. Discussion 107 This draft attempts to address the issue of AS number exhaustion 108 issue for a large and growing class of BGP speakers. This class 109 includes entities that are multihoming to more than one network 110 and do not provide transit service between the networks that they 111 multihome to -- in other words, stub ASs. 113 RFC 1930 reserves AS numbers 64512 through 65535 for private use. 114 These AS numbers should never be found in the global Internet 115 routing tables. 117 The following diagram represents the typical customer multi-homing 118 scenario: 120 +---------------+ 121 | Transit ISP 1 | AS-A 122 +---------------+ 123 / 124 +----------+ 125 AS-X | Customer | 126 +----------+ 127 \ 128 +---------------+ 129 | Transit ISP 2 | AS-B 130 +---------------+ 132 Figure 1 134 In the normal multi-homing scenario, the customer would need to 135 request an AS number from its Regional Internet Registry (ARIN, 136 RIPE, APNIC, etc.). This draft proposes that the customer is 137 assigned a private AS number that is mutually agreeable to its 138 transit providers. The customer may then originate its routes 139 normally with BGP-4 using this private AS number. 141 The transit routers, when re-advertising routes originated from 142 the Customer AS will substitute its own AS number for each 143 occurence of the customer's private AS. This is called AS number 144 Substitution on Egress (ASE). 146 It can be noted that this methodology is analogous to two BGP 147 confederations with an overlapping member AS. 149 ASE is intended to be applied only to non-transit AS's. As such 150 it strictly prohibits advertisement of routes containing any AS 151 number that is not the mutually agreed Customer AS number. If a 152 router performing ASE for a peer has received a route that 153 contains non-peer AS numbers in the AS_PATH, the router must 154 terminate the peering session with a notification message of 155 "Malformed AS Path Attribute". 157 In order to provide loop detection for the customer AS by proxy, a 158 new non-transitive attribute will be added to the route when it is 159 re-advertised. 161 4. ASE-ORIGINATOR attribute 163 This document creates the ASE-ORIGINATOR path attribute. This 164 attribute is an optional transitive attribute with a fixed length 165 of 10 octets. The attribute consists of three components: 167 a. The originating AS number (customer AS) which is two octets 168 and is part of the private AS space. 170 b. The AS that is performing the ASE. Should this AS be a 171 member of a BGP confederation, the AS Confederation 172 Identifier should be used. This is inserted to guarantee 173 uniqueness of the ASE-ORIGINATOR across the Internet. 175 c. The ASE client identifier, which is four octets. Unless 176 configured otherwise, the ASE client identifier should 177 default to the BGP Identifier of the peering session. 179 The Customer AS number and the ASE client identifier must be 180 mutually agreed upon by the transit ISPs. 182 A BGP-4 speaker who is configured to perform ASE must not re- 183 advertise a route to an ASE client when that route contains the 184 ASE-ORIGINATOR attribute containing the peer's AS number and ASE 185 client id. 187 The ASE-ORIGINATOR attribute has Type Code 255. (To be assigned by 188 IANA.) 190 5. Implementation Issues 192 When a route is received by a BGP-4 speaker, administrative policy 193 is often used to determine whether or not a route will be placed 194 into the router's AdjRibsIn. Some of this policy is implemented 195 based on filtering on the contents of the AS_PATH of the route. 196 It is important for the router to retain the route in its original 197 form so that filtering can happen normally. Performing the AS 198 number substitution prior to egress can make it difficult to apply 199 proper filtering. 201 Additionally, if policy were to change it is useful to be able to 202 run policy on the originating customer AS number rather than on 203 one's own AS number with additional criteria. 205 6. Operational Considerations 207 a. Receiving an ASE peer AS number from internal BGP peers: 209 AS Numbers in the private AS number space are often used for 210 many things within a given network. For example, they are 211 used as the AS number for a BGP confederation member. 212 Additionally, private ASs are often used for stub BGP peers. 214 Thus, even though a router performing ASE for a peer will 215 never propagate the AS number of the peer undergoing ASE 216 (and thus knowledge of the ASE peering AS is localized to 217 that router), this router may still receive BGP updates 218 containing the AS number that is used for the ASE peering 219 session from other BGP speakers. 221 Care must be taken by operators of routers running ASE when 222 constructing policy for routes received from other BGP 223 speakers. 225 Example of this issue: 227 ....................... 228 AS 64512 : AS A : AS 64512 229 +----------+ : +------+ +------+ : +----------+ 230 | Client-1 |---| ISP |---| ISP |--- | Client-2 | 231 | BR | : | BR-1 | | BR-2 | : | BR | 232 +----------+ : +------+ +------+ : +----------+ 233 ASE Client :.....................: 235 Figure 2 237 This diagram shows an AS with two external peers, both with 238 AS 64512, which is a Private AS number. ISP BR-1 is 239 performing ASE, ISP BR-2 is not. In this configuration, ISP 240 BR-1 will receive routes from Client-1's border router with 241 an AS_PATH containing one or more instances of 64512. When 242 ISP BR-1 re-advertises the route to ISP BR-2, these 243 instances of 64512 will be substituted with the AS number A. 245 ISP BR-1 will receive from ISP BR-2 routes containing AS 246 64512. Since the peering session between ISP BR-1 and ISP 247 BR-2 is IBGP, the AS_PATH will not be modified. It is 248 important for ISP BR-1 to be aware of this and deal with 249 policy appropriately. Additionally, Client-1 will discard 250 any routes propagated by ISP BR-1 that came from Client-2 251 since its own AS number occurs in the AS_PATH. 253 In general, having the same private AS used by peers of your 254 AS that may also be used internally for ASE may cause 255 problems. Care should be taken so this doesn't happen. 256 This could be done, for example, by allocating a range of 257 Private ASs that will only be used for ASE within one's AS. 259 b. Route Looping and Prevention: 261 Since the AS path information is substituted by the transit 262 routers on egress, an ASE Client may receive an announcement 263 of its own NLRI from the upstream routers. Since the 264 AS_PATH has been modified to remove the private AS of the 265 customer, standard AS_PATH loop detection will not work. 267 The ASE-ORIGINATOR attribute is meant to provide loop 268 prevention by a router performing ASE from propagating known 269 loops. Misconfiguration of an ASE speaker, for example by 270 configuring the BGP peering session as a normal external 271 peering session without ASE, may lead to this. 273 This may result in the customer router containing AdjRibsIn 274 entries for its own NLRI. These routes will not usually 275 become active due to the default route selection criteria of 276 BGP-4. However, in the event of misconfiguration, route 277 loops may take place if the externally received route is 278 installed in preference to the internal routes. 280 Example: 282 ...................... 283 : : 284 : 10.0.0.1 : AS A 285 : +--------------+ : +----------+ 286 Dest------| ASE Client 1 |------| ISP-1 BR | 287 : +--------------+ : +----------+ 288 : | : | 289 : AS 64512 : | 290 : | : | 291 : +--------------+ : +----------+ 292 : | ASE Client 2 |------| ISP-2 BR | 293 : +--------------+ : +----------+ 294 : 10.0.0.2 : AS B 295 : : 296 :....................: 298 Figure 3 300 In this example, AS X is an ASE client of AS A and B. ASE 301 Client 1 has a BGP Identifier of 10.0.0.1 and ASE Client 2 302 has a BGP Identifier of 10.0.0.2. To prevent loops, AS A 303 and AS B should both agree on the same BGP Identifier for 304 the ASE Client Identifier. 306 i. AS X, an ASE Client of AS A and AS B, advertises Dest 307 to AS A. AS A thus has a route of Dest with a path of 308 . 310 ii. AS A re-advertises the route to AS B and performs the 311 ASE on it. It appends the ASE-ORIGINATOR attribute of 312 64512:A:10.0.0.1 (where A is the AS number of AS A) to 313 the route. AS B thus has the route Dest with a path 314 of . 316 iii. AS B is either misconfigured to not use ASE on this 317 peering session, or has an incorrectly configured ASE 318 Client Identifier and thus re-advertises the route to 319 ASE Client 2. ASE Client 2 thus has the route Dest 320 with a path of . 322 iv. Normally this would be a loop and the route would be 323 dropped. However, the path information to prevent 324 loops has been lost. AS X must filter on the prefixes 325 it advertises (normally a good thing) to prevent this 326 route from being installed in its AdjRibsIn. More 327 importantly, AS X must ensure that policy does not 328 select this route as being active and thus leading to 329 a routing loop. 331 One case where this behaviour may be useful is in the case 332 of a customer AS partition. This allows the customer AS to 333 reach itself via its transit ASs. 335 c. ASE clients must NEVER re-advertise BGP routes they learn. 337 In the example above, if AS X receives the route Dest 338 and then re-advertises the route to AS A, it will lose its 339 peering session with AS A. This is due to AS A receiving an 340 AS_PATH from the ASE Client that contains an AS that is not 341 the configured AS number of the ASE Client. 343 To reiterate, ASE clients must be configured to avoid 344 propagating externally learned routes to peers. This 345 behaviour, although operationally troublesome, is to prevent 346 a stub AS with a Private AS number from becoming a transit 347 AS. 349 7. Summary 351 ASE provides a simple mechanism to help slow the exhaustion of AS 352 Numbers. ASE is very simple mechanism to implement and needs only 353 be deployed at the edges of the network. Routers that are not 354 participating in ASE do not need to understand ASE. 356 In short, ASE is meant to provide an analog to the benefits of 357 Network Address Translation (NAT) at the AS level. 359 As noted throughout this draft, misconfiguration of routers 360 performing ASE can lead to an ASE client receiving its own NLRI 361 without enough information to perform loop detection and drop the 362 route. However, the ASE mechanism prevents such loops from 363 affecting the wider Internet by preventing re-advertisement of 364 routes that are not locally originated. 366 8. Security Considerations 368 All security considerations of the BGP-4 protocol apply. In 369 addition, ASE "hides" the originating entity and may cause parties 370 who are troubleshooting routing issues to contact the transit ISP 371 when contacting the customer directly may have sufficed. 373 9. Acknowledgements 375 The author wishes to thank Matt Richardson of Nexthop for valuable 376 comments. 378 10. References 380 [1] RFC 1771 - A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, 381 T. Li. 383 [2] NANOG-21 presentation on Global Routing System Scaling Issues. 384 February 2001. http://www.nanog.org/mtg-0102/ppt/cathy/index.html 386 [3] The CIDR report. Author Tony Bates. 387 http://www.employees.org:80/~tbates/cidr-report.html 389 [4] CAIDA study of Stub AS's injecting a few (< 10) routes. 390 http://www.caida.org/~broido/bgp/stubas.html 392 [5] RFC 1930 - Guidelines for creation, selection, and 393 registration of an Autonomous System (AS). J. Hawkinson, T. 394 Bates. 396 [6] draft-ietf-idr-as4bytes-00 - BGP support for four-octet AS 397 number space. Quaizar Vohra, Enke Chen. 399 [7] RFC 1965 - Autonomous System Confederations for BGP. P. 400 Traina. 402 [8] draft-ramachandra-bgp-ext-communities-08 - BGP Extended 403 Communities Attribute. Srihari Ramachandra, Yakhov Rekhter. 405 11. Author's Address 407 Jeffrey Haas 408 NextHop Technologies 409 517 W. William St. 410 Ann Arbor, MI 48103-4943 412 Phone: (734) 973-2200 414 EMail: jhaas@nexthop.com