Re: [sidr] AS Migration and aliasing

["Sriram, Kotikalapudi" <[e-mail]>]

Wes,
Shane,

Thanks for your time and efforts in doing this very useful write-up.
Some comments/questions inline below, with preamble “KS:”.

Sriram
 
-- snip ---
> 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).
>

KS: In #1 ('local-as <old_ASN>'), the more precise BGPSEC announcement 
seen at AS 100 would be:
NLRI  400<pCount=1>, 200<pCount=1>, 300<pCount=1>
(most recent AS is right most)

In #2 ('local-as <old_ASN> no-prepend':), the more precise BGPSEC 
announcement seen at AS 100 would be:
NLRI  400<pCount=1>, 200<pCount=0>, 300<pCount=1>
(most recent AS is right most)

The difference is that for AS 200, the pCount=1 in #1 and the pCount=0 in #2.

Q1: Are these two solution approaches in BGPSEC acceptable 
for the two cases (#1 and #2) in your view? 

Other questions:

Q2:  Do the two ASes involved in the migration know of
each other? So that AS 300 can accept pCount=0 from AS 200
and vice versa (for updates going in the other directions). 

Q3: Is there any thought here that there could be iBGP/IGP
between AS 200 and AS 300 instead of eBGP?
This question came up during the June 29 interim meeting.

>
> 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 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).
>

KS: Yes, ISP would still need to publish public-keys for AS 200 
(until AS 200 is subsumed by AS 300, and all updates that had AS 200 in the path
have been re-originated and/or re-propagated at AS 300 or attached CEs).

>
> 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?

KS: 
Q4: Perhaps AS 300 resets BGPSEC with all peers who peered with AS 200,
and informs them of its new (replace) ID AS 300? 
The re-originations/re-propagations will follow naturally 
(with AS 300 instead of AS 200 in the path).
But OTOH, is requiring session reset not a desirable way
to induce re-originations/re-propagations in this case?

>
> 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.
>

KS: I think your observations (with the example above) are basically correct.
However, in theory, *without* replace-as enabled, CE-1 would see (in BGPSEC)
more precisely an AS_PATH of: 
NLRI 200<pCount=1>, 300<pCount=0>, 100<pCount=01>. 
So once again, the same question (as Q2 above) arises here:
Do the two ASes involved in the migration know of
each other? So that AS 300 can accept pCount=0 from AS 200
and vice versa (for updates going in the other directions).

>
> 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.
>

KS: Once the migration is “complete” (i.e., all peers know only AS 300 and not AS 200), 
then legacy AS (AS 200) is forgotten about. No?

> 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?
>

KS: I think this security question is addressed if Q2 above is addressed.
(However, I think there will always some remaining abuse vulnerability
associated with pCount=0, in general in BGPSEC.) 

Sriram