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 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
