Re: [sidr] AS Migration and aliasing

["Murphy, Sandra" <[e-mail]>]

Thanks, and understood.

No one on the call had had the time to read your message thoroughly so we could not discuss it well.

Discussion can (and should) proceed on the list, of course.

I hope you will be in Vancouver (interim and/or regular IETF slot) and we can discuss the topic there.  Providing we don't finish the discussion on the list before hand, of course.

--Sandy
________________________________________
From: George, Wes [[e-mail]]
Sent: Friday, June 29, 2012 10:20 AM
To: Murphy, Sandra; sidr wg list ([e-mail])
Subject: RE: AS Migration and aliasing

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.