Re: [sidr] AS Migration and aliasing

["George, Wes" <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, June 28, 2012 6:20 PM
> To: George, Wes; sidr wg list ([e-mail])
> 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: [e-mail] [[e-mail]] on behalf of George,
> Wes [[e-mail]]
> Sent: Thursday, June 28, 2012 4:27 PM
> To: sidr wg list ([e-mail])
> 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
> [e-mail]
> 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.