Subject: [sidr] comments on recent as migration drafts

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 27 Sep 2012 13:40:49 +0000

Speaking as regular ol' member.

Some comments about these drafts.

It appears to me that the ga-idr-as-migration talks about a merger of AS 200 and AS 300, with AS 200 being the eventually retained ASN but george-sidr-as-migration talks about a merger of AS 200 and AS 300 with AS 300 being the eventually retained ASN.  If that is true, then those  reading both drafts should keep that in mind when looking at the examples.

In the idr-as-migration draft, from the discussion it appears that the implementation of the local-as feature on the PE router in AS supports the local-as as something like an ebgp session inside the router.  (like it adds the old 300 ASN on AS_PATHs sent over ibgp sessions to AS 200 neighbors).  Am I understanding the examples correctly?

The goal is for the AS_PATH length to be the same length in the migration interval as it was before migration.  Does it matter if that effect is accomplished some other way than the knobs currently implemented?  IE the local-as knob has a side effect of getting the 300 ASN into the AS_PATH to ibgp neighbors so the second knob no-prepend makes that go away.  Do you need both behaviors -- local-as AND local-as + no-prepend?  Would it be OK if the side effect did not happen and you got to the no-increase-in-path-length goal without needing the no-prepend knob?

wrt the replace-as technique.  The text says that "only the historical (or, legacy) AS will be prepended in the outbound BGP UPDATE toward the customer's network".  But the example says "After ISP A' changes PE-1 to include the "Replace AS" feature, CE-1 would receive an AS_PATH of: 200 400. " That is indeed "the same AS_PATH length pre-AS migration" as the text says, which accomplishes that goal, but it would require configuration of the CE router to accept a first-as that was different from the one used in the OPEN.  I suspect that's a typo, that is after using replace-as the AS_PATH toward the CE would be "300 400".  But it is an important point so I'd like to make sure. 

About sidr-as-migration

The discussion of origin validation seems to assume that multiple ROAs for the same prefix space is unusual and requires a limited overlap period.  That is not the case.  From time immemorial, multiple ROAs for the same prefix have been anticipated and deliberately supported.  There can be *any number* of ROAs for a prefix at any time.  One ROA does not replace another for the same prefix.

The use of pcount=0 is rejected as requiring configuration on the CE router so that it authorizes and accepts the use of pcount=0 from the PE router.  Suppose that the use of pcount=0 was in an internal hop in the PE router, so the AS accepting and authorizing the use of pcount=0 was one of AS 200 or AS 300, so all configuration happened on the PE router, and no configuration happened on the CE router.  If that worked, would that be acceptable?

--Sandy, speaking as regular ol' member

---

From: "George, Wes" <[email-masked]>
Date: Thu, 27 Sep 2012 14:13:31 -0400

Thanks for the quick review. Responses below inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murphy, Sandra
>
> It appears to me that the ga-idr-as-migration talks about a merger of AS
> 200 and AS 300, with AS 200 being the eventually retained ASN but
> george-sidr-as-migration talks about a merger of AS 200 and AS 300 with
> AS 300 being the eventually retained ASN.  If that is true, then those
> reading both drafts should keep that in mind when looking at the
> examples.
[WEG] oops. Sigh. I'll get that corrected in subsequent versions of george-sidr so that the two agree.
>
> In the idr-as-migration draft, from the discussion it appears that the
> implementation of the local-as feature on the PE router in AS supports
> the local-as as something like an ebgp session inside the router.  (like
> it adds the old 300 ASN on AS_PATHs sent over ibgp sessions to AS 200
> neighbors).  Am I understanding the examples correctly?
[WEG] Not exactly no. There's no additional internal eBGP session between the two ASNs on the PE, and remember that the PE has been reconfigured to be in the retained AS, not the legacy one, so this local-as and its related switches are used on the PE-CE sessions and their associated updates, not PE-PE. All it's doing is overriding the values from the global config that would normally be used to populate "MY ASN" and "AS_PATH" when generating BGP messages to a specific neighbor.

>
> The goal is for the AS_PATH length to be the same length in the
> migration interval as it was before migration.  Does it matter if that
> effect is accomplished some other way than the knobs currently
> implemented?
[WEG] the implementation details probably don't matter if the result is the same, other than the fact that this one exists and is in lots of code, while a different approach may not be widely implemented. You could make the argument that since we're talking about trying to make this work on BGPSec-capable routers, you could also assume that a BGPSec-friendly AS-migration method would also be supported in the same code I guess, but that's only if it's a required feature as a part of the BGPSec implementation. If it's a standalone, it might require code upgrades that may not be possible for a number of different reasons.

 IE the local-as knob has a side effect of getting the 300
> ASN into the AS_PATH to ibgp neighbors so the second knob no-prepend
> makes that go away.  Do you need both behaviors -- local-as AND local-as
> + no-prepend?  Would it be OK if the side effect did not happen and you
> got to the no-increase-in-path-length goal without needing the no-
> prepend knob?
[WEG] different use cases require different configurations. Local-AS no-prepend ensures that the AS_PATH length doesn't change, which is critical to this migration technique, so I guess it's safe to say that you don't need the local-as behavior by itself, but that if you don't care about the AS-path length, using only local-as will still enable you to change the global BGP AS of the PE for migrations, and will be less complex/risky since you're not manipulating the AS_PATH in ways that could result in route loops.
>
> wrt the replace-as technique.  The text says that "only the historical
> (or, legacy) AS will be prepended in the outbound BGP UPDATE toward the
> customer's network".  But the example says "After ISP A' changes PE-1 to
> include the "Replace AS" feature, CE-1 would receive an AS_PATH of: 200
> 400. " That is indeed "the same AS_PATH length pre-AS migration" as the
> text says, which accomplishes that goal, but it would require
> configuration of the CE router to accept a first-as that was different
> from the one used in the OPEN.  I suspect that's a typo, that is after
> using replace-as the AS_PATH toward the CE would be "300 400".  But it
> is an important point so I'd like to make sure.
[WEG] I think you're right that it's a typo, I'll doublecheck with my co-author.
>From the referenced cisco doc: "The replace-as keyword is used to prepend only the local autonomous-system number (as configured with the ip-address argument) to the AS_PATH attribute. The autonomous-system number from the local BGP routing process is not prepended."

However...
4271 6.3 lists the requirement you mention for the Open "My ASN" value and AS_Path to match as a MAY:
   "If the UPDATE message is received from an external peer, the local
   system MAY check whether the leftmost (with respect to the position
   of octets in the protocol message) AS in the AS_PATH attribute is
   equal to the autonomous system number of the peer that sent the
   message.  If the check determines this is not the case, the Error
   Subcode MUST be set to Malformed AS_PATH."
I don't know if most common implementations perform this check. In fact, that's why I point out that the question needs to be answered as far as path validation is concerned - does the ASN of the established neighborship have to match the AS_Path or PATH_signatures or does it not matter as long as the signatures are all valid? Does that MAY need to be a MUST in BGPSec land?

>
> About sidr-as-migration
>
> The discussion of origin validation seems to assume that multiple ROAs
> for the same prefix space is unusual and requires a limited overlap
> period.  That is not the case.  From time immemorial, multiple ROAs for
> the same prefix have been anticipated and deliberately supported.  There
> can be *any number* of ROAs for a prefix at any time.  One ROA does not
> replace another for the same prefix.
[WEG] ok. I knew they were possible, but I guess I didn't realize that this wasn't expected to be a temporary situation. I just reread 6480 3.2 and I see what you mean. I'll fix. Any other portions of the spec you recommend that I reference that covers the presence of multiple ROAs for the same prefix/length more explicitly or is that the right thing to reference?
>
> The use of pcount=0 is rejected as requiring configuration on the CE
> router so that it authorizes and accepts the use of pcount=0 from the PE
> router.  Suppose that the use of pcount=0 was in an internal hop in the
> PE router, so the AS accepting and authorizing the use of pcount=0 was
> one of AS 200 or AS 300, so all configuration happened on the PE router,
> and no configuration happened on the CE router.  If that worked, would
> that be acceptable?
[WEG] hmm... that's an interesting way to play it and worth exploring some more I think. However, as far as requirements go: it MUST NOT require the router to actually establish and maintain a second set of eBGP sessions (even internally/behind the scenes) such that it has to do 2x the update generation, 2x the processing, etc. 2x the signatures is likely unavoidable, because if you didn't require the implementer to be in possession of signatures for both ASNs you would have the potential for a path-shortening attack. But generally what I'm saying is that this can't be something that creates a major scale drag for every session that has it enabled, since we're talking about something that might be enabled on hundreds of PE-CE neighbor sessions during an active migration.

Wes George

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.

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 27 Sep 2012 23:56:38 +0000

Thanks for the quick response!

wrt:
>[WEG] oops. 

No problem.  And don't bother with this right now.  I only wanted to be sure people noticed, as they might read both drafts.

wrt:

>[WEG] Not exactly no. There's no additional internal eBGP session between the 
>two ASNs on the PE, and remember that the PE has been reconfigured to be in 
>the retained AS, not the legacy one, so this local-as and its related switches are 
>used on the PE-CE sessions and their associated updates, not PE-PE. All it's 
>doing is overriding the values from the global config that would normally be 
>used to populate "MY ASN" and "AS_PATH" when generating BGP messages 
>to a specific neighbor.

No, I did not mean to suggest that there was an actual ebgp session.  I think maybe I was reading the replace-as example incorrectly.  I am not sure what the AS_PATH is when it is transmitted between PE1 and PE2 and it looked like PE1 might be adding ASNs to the AS_PATH it sent over the ibgp session to PE2.

>[WEG] I think you're right that it's a typo, I'll doublecheck with my co-author.
<skip>
>I don't know if most common implementations perform this check. In fact, 
>that's why I point out that the question needs to be answered as far as path 
>validation is concerned - does the ASN of the established neighborship have 
>to match the AS_Path or PATH_signatures or does it not matter as long as the 
>signatures are all valid? Does that MAY need to be a MUST in BGPSec land?

>From http://www.cisco.com/en/US/docs/ios/12_3t/ip_route/command/reference/ip2_b1gt.html#wp1080615, "bgp enforce-first-as" default is enabled and it means
To configure a router to deny an update received from an external BGP (eBGP) peer that does not list its autonomous system (AS) number at the beginning of the AS_PATH in the incoming update, use the bgp enforce-first-as command in router configuration mode.

I think this is already a MUST in the protocol because the protocol makes sure the AS listed are the ones that the packet came through.  If the update came from the neighbor and the first AS in the path is not the neighbor's AS, then the validation will fail.  (Unless the neighbor has the keys to two ASs and uses an AS other than is used in the OPEN packet.  It's all about the keys.)

>[WEG] hmm... that's an interesting way to play it and worth exploring some 
>more I think. However, as far as requirements go: it MUST NOT require the 
>router to actually establish and maintain a second set of eBGP sessions (even 
>internally/behind the scenes) such that it has to do 2x the update generation, 
>2x the processing, etc. 2x the signatures is likely unavoidable, because if you 
>didn't require the implementer to be in possession of signatures for both ASNs 
>you would have the potential for a path-shortening attack. 

No, I did not mean to indicate that there would be an actual ebgp session.  But as you say two signatures (tho not two updates) are probably unavoidable.

________________________________________
From: George, Wes [[email-masked]]
Sent: Thursday, September 27, 2012 2:13 PM
To: Murphy, Sandra; [email-masked]
Subject: RE: comments on recent as migration drafts

However...

Wes George

---

From: "George, Wes" <[email-masked]>
Date: Fri, 28 Sep 2012 15:14:41 -0400

> From: Murphy, Sandra [mailto:[email-masked]]
>
> No, I did not mean to suggest that there was an actual ebgp session.  I
> think maybe I was reading the replace-as example incorrectly.  I am not
> sure what the AS_PATH is when it is transmitted between PE1 and PE2 and
> it looked like PE1 might be adding ASNs to the AS_PATH it sent over the
> ibgp session to PE2.
[WEG] I think maybe the confusion comes from the fact that these commands have to interact with BGP route updates in both directions (PE-> CE and CE -> PE). In the routes that the PE receives from the CE, it has to make the change in AS in the AS_PATH so that the rest of the routers in its global ASN don't see routes with the configured local ASN in the path, but the way I think of it is that it's doing this when it receives and processes the routes from the CE before it installs them into its RIB, not when it generates the updates towards its neighbors, since this is a neighbor-specific configuration rather than a global one.

>
> I think this is already a MUST in the protocol because the protocol
> makes sure the AS listed are the ones that the packet came through.  If
> the update came from the neighbor and the first AS in the path is not
> the neighbor's AS, then the validation will fail.  (Unless the neighbor
> has the keys to two ASs and uses an AS other than is used in the OPEN
> packet.  It's all about the keys.)
[WEG] Understand that. I was specifically asking about the case where the PE is in possession of keys for both ASNs and therefore can choose which of the two valid ASNs to sign with. Does it fail if the signature is valid but the AS in the OPEN message is different from the one in the signature? If not, should it, or are we expecting similar behavior to the "enforce-first-AS" keyword, where by default it fails, but you can twist a knob to make it acceptable? I think this is one of those things that we have to be clear about which way we want the behavior to be, since it's a MAY in BGP. It is even more important to specify if it has to be a certain way in order to prevent security concerns in BGPSec.

Wes George