I unfortunately won't be attending much of today's interim if at all - $day_job calls...
Thanks, Wes > -----Original Message----- > From: Murphy, Sandra [mailto:sandra.mur...@sparta.com] > Sent: Thursday, June 28, 2012 6:20 PM > To: George, Wes; sidr wg list (sidr@ietf.org) > Subject: RE: AS Migration and aliasing > > Lots of stuff to consider here! > > Last minute, but would you like to fit this into the interim meeting > tomorrow? > > --Sandy, speaking as co-chair > ________________________________________ > From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of George, > Wes [wesley.geo...@twcable.com] > Sent: Thursday, June 28, 2012 4:27 PM > To: sidr wg list (sidr@ietf.org) > Subject: [sidr] AS Migration and aliasing > > During the last SIDR Interim, we talked about BGP Aliasing as a means to > migrate from one ASN to another. I proxied some concerns from Shane > Amante and others who weren't present, but I ended up being the stuckee > to write up the requirements/use case so that we can make sure that it's > being appropriately addressed. Shane and I have worked to put together > the below. If it's helpful to put this in draft form, we're happy to do > so, or the relevant bits of text can be incorporated into existing > drafts, or whatever. I figured the main thing was that I needed to get > this out of my edit buffer and in front of the right people without any > additional delay so that we can discuss it further as necessary, so I'm > sending it to the list as raw text for now. > > > > > General scenario - merging two or more ASNs, where eventually one > subsumes the other(s). Confederations are NOT being implemented between > the ASNs. In this example, AS200 is being subsumed by AS300. The reason > that this may drive a slightly different solution in BGPSec than a > standard confederation is that unlike in a confed, eBGP peers may not be > peering with the "correct" external ASN, and the forward-signed updates > are for a public ASN, rather than a private one, so there is no > expectation that we should strip them. > > There are two types/directions of migration to consider, each of which > uses some set of implementation-specific knobs to tweak the AS-Path. > It's important to emphasize that a fundamental goal of these > "proprietary knobs" is to (absolutely) ensure that you are NOT changing > the AS_PATH length during the ASN migration. Note, this is critical in > *both* the inbound (CE -> PE) and outbound (PE -> CE) directions. This > is important because for large carriers who bill customers based on bits > (usage), any lengthening of the AS_PATH in either direction will cause > traffic to shift away from their network, which is bad (less usage == > less revenue). > > Local-AS: You have an end customer/eBGP peer that is peering with AS200. > You wish to reconfigure that router to be in AS300, and need to be able > to do so without disrupting/coordinating the change with all of the eBGP > peers simultaneously. So you reconfigure the peers with Local AS 200 so > that the router still appears to be in the same ASN. However, if the > peer is doing BGPSec, you have some additional wrinkles. For outbound > announcements, this would require the router to have the right keys for > AS200 so that it can continue signing with the right ASN towards peers > configured this way. > Inbound is more complicated - the peer doesn't know that you've changed > ASNs, so it is forward-signing all of its routes with AS200, not AS300. > How do you fix? > > Reference: > http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ft11bhla > .html > > In the direction of CE -> PE (inbound), and speaking about IOS > specifically, (although equivalent knobs do exist in JUNOS and possibly > others): > 1) 'local-as <old_ASN>': appends the <old_ASN> value to the AS_PATH of > routes received from the CE > 2) 'local-as <old_ASN> no-prepend': DOES NOT prepend <old_ASN> value to > the AS_PATH of routes received from the CE. > > For the reason stated above, one prefers configuration #2. This ensures > that routes received by a PE through eBGP sessions with this 'local-as > <old_ASN> no-prepend' knob configured get transmitted out to SFI peers > and/or customers with normal/natural <new_ASN> neighbor sessions so that > they do not see a longer AS_PATH. IOW, if you had the following: > > NOTE: Direction of BGP Update as per the arrows. > PE-1 is a PE whose "global configuration AS" has been changed from AS > 200 to AS 300 to make it part of the "go forward/keep" ASN. > PE-1 needs the configuration: > > router bgp 300 > neighbor <CE-1_IP> remote-as 400 > neighbor <CE-1_IP> local-as 300 no-prepend > > CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2 > 400 Old_ASN: 200 New_ASN: 300 100 > New_ASN: 300 > > CE-2 should see an AS_PATH that looks like: 400 300, (without seeing AS > 200 *anywhere* in the AS_PATH due to the 'local-as no-prepend' knob). > (NOTE: if you *just* had the "local-as 300" knob configured on PE-1, > then CE-2 would see an AS_PATH that looked like: 400 200 300). > > So, to answer the questions above: yes, in a BGPSec world, CE-1 in AS > 400 would (by default) be forward-signing toward <Old_ASN>, (a.k.a: AS > 200). I'm guessing the ISP would still need to publish public-keys for > AS 200 if it is to appear in the BGPSec_Path_Signature in order that > receivers can validate the BGPSEC_Path_Signature arrived intact/whole. > And, you need to roll the keys for AS 200 indefinitely (or, as long as > you keep AS 200 around in your network). > > > Replace-AS: You are trying to remove AS200 from the AS-path to ensure > that routes learned from AS200 don't have a longer AS-path and/or you > want to make them look like they only transited AS300, not AS200->AS300. > So you configure routers to do replace-AS. How do you manage the routes > that have been forward-signed into AS200? What about routes originated > by AS200? Do you re-originate with AS300? Is there actually provision in > the Origin validation spec to allow you to re-originate routes, or do > you have to do this with more standard methods (filter the original > announcement/origination and generate a completely new announcement via > null routes, network statements, etc). And from an RIR perspective, how > do you manage this? Do they allow an overlap period on RPKI for > transitions like this? > > This is the opposite direction, from PE -> CE: > http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas > .html > > The reference above is specifically looking at the 'replace-as' knob in > Cisco-land, (similar knobs also exist in JUNOS). To re-use the above > diagram, but in the opposite direction we have: > > CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2 > 400 Old_ASN: 200 New_ASN: 300 100 > New_ASN: 300 > > By default, *without* replace-as enabled, CE-1 would see an AS_PATH of: > 200 300 100, which is bad. Now, if we change PE-1 to have the following > config: > > router bgp 300 > neighbor <CE-1_IP> remote-as 400 > neighbor <CE-1_IP> local-as 300 no-prepend replace-as > > In this case, CE-1 would see an AS_PATH of: 300 100. > > In this direction, I don't believe CE-1 will care in a BGPSec-world, > because PE-1 could begin forward-signing from <New_ASN> to AS 400 at any > time and, as long as CE-1 has the certs for <New_ASN>, then the path > should validate OK. But we need someone to confirm this, so we document > it for completeness. > > > A couple of additional wrinkles to mention here: > 1) Companies rarely stop with one M&A, and end up accumulating several > legacy ASN's over time, which don't go away very quickly, if at all. In > a BGPSEC world, does this mean that every router in your network needs > to maintain a unique public/private key-pair per "legacy ASN"? I'm > really not sure what is the answer, but would want to make sure this is > considered, and answered, as solutions are being proposed to solve this. > 2) That second Cisco URL above also mentions the "dual-as" knob. My > understanding of that knob is it allows a eBGP peer, specifically a CE, > to establish a BGP neighbor session with /either/ <old_ASN> or <new_ASN> > ... it's really up to the CE's discretion to choose one or the other. > Of course, this allows the customer to decide, at a time of their > choosing, when to migrate from the ISP's <old_ASN> to <new_ASN> in their > CE device's config. > The reason for "dual-as" is that it's an enhancement above and > beyond "local-as". With just 'local-as' enabled, the PE is (in my > understanding) only expecting the CE to establish a neighbor > relationship with <old_ASN>, not (ever) with <new_ASN>. Anyway, point > of mentioning this is to ensure that, again, this is captured in the > reqmt's since the eBGP neighbor ASN can migrate pretty rapidly. > 3) In many ways, we're talking about a use case where there are valid > reasons to do exactly what BGPSec Path validation is trying to prevent - > changing the AS-Path so that it differs from the path the update > actually traveled to make one path seem preferred over the other. How do > we do this without opening up an attack vector to allow malicious users > to circumvent BGPSec? > > Thanks, > > Wes George, with a lot of assitance from Shane Amante > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is addressed. > If you are not the intended recipient of this E-mail, you are hereby > notified that any dissemination, distribution, copying, or action taken > in relation to the contents of and attachments to this E-mail is > strictly prohibited and may be unlawful. If you have received this E- > mail in error, please notify the sender immediately and permanently > delete the original and any copy of this E-mail and any printout. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
