Subject: [Idr] BGPSEC proposal to drop AS_PATH [was: Fwd: [sidr] request for agenda items for interim meeting 6 Jun]

From: "John G. Scudder" <[email-masked]>
Date: Tue, 29 May 2012 14:24:50 -0400

IDR folks,

BGPSEC (in the SIDR WG) includes a path attribute, BGPSEC_Path_Signatures, that substantially overlaps the semantics of AS_PATH. For reasons discussed in the forwarded note below, it proposes that updates carrying BGPSEC_Path_Signatures should NOT carry AS_PATH. 

Since this would represent a fairly major change to the protocol, I wanted to make sure those not following SIDR were aware of it. Please cross-post any comments to [email-masked].

(See http://tools.ietf.org/html/ietf-sidr-bgpsec-protocol-03 Section 3.)

--John

Begin forwarded message:

> From: "John G. Scudder" <[email-masked]>
> Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun
> Date: May 29, 2012 2:21:33 PM EDT
> To: Matt Lepinski <[email-masked]>
> Cc: "[email-masked] list" <[email-masked]>
> 
> On May 22, 2012, at 5:46 PM, Matt Lepinski wrote:
> 
>> Other than confeds are there any other potentially open issues related to the removal of AS_Path?
> 
> (I think this just recapitulates what I said at the interim, but maybe it's worth saying again for the list.)
> 
> Philosophically, the thing that makes me worry the most is that we're cutting out one of BGP's fundamental elements and replacing it with one which provides only a subset of its semantics. Specific things missing include:
> 
> - Confederations. But we are discussing ways to fix this.
> - Extensibility to include new segment types. In principle this is a fairly serious omission, but one can argue that new segment types can't be introduced in practice, since existing implementations will treat them as fatal errors.
> 
> And actually, that's it for my list of specifics. I think we can check off the "done, in principle" box for confeds. So the remaining issue is extensibility. One may or may not find the "extensibility doesn't work anyway" argument compelling, I'm not entirely sure *I* do. In any case, I think this deserves a good airing before we commit.
> 
> The other issue is one Shane already brought up on this thread -- the fact that some of the more egregious AS_PATH editing hacks that exist in the wild may not be supportable in the AS_PATH-less new world order. (Many of the less egregious ones seem to be OK with appropriate pcount gyrations.) The pros and cons are a bit slippery here since even if we continue to carry AS_PATH, if the BGPSEC_Path_Signatures attribute can't represent the semantics of what's in that AS_PATH, then validation will fail. But at least there's scope for a network operator on the receiving end to tolerate the validation failure and use the route anyway, if desired. In the case where there's no AS_PATH, the data are just gone with no chance for appeal. 
> 
> It's also worth noting that leaving AS_PATH in would not be without cost. In the cases where the content of AS_PATH is isomorphic to that of BGPSEC_Path_Signatures, there's no problem -- but in those cases AS_PATH clearly could have been left out. In the remaining cases, what is the implementation supposed to do? It would be necessary to carefully specify. The easiest cop-out would be to say that in all such cases, the route fails validation. But I have a feeling that it's not that easy. Leaving AS_PATH out reduces that particular maze of twisty passages, although it replaces it with another: making sure it was really OK to axe AS_PATH to begin with (i.e., the discussion above).
> 
> I'm going to forward this to IDR to ensure that those who aren't following SIDR are aware there's a proposal to phase out AS_PATH in favor of a simplified replacement in BGPSEC. 
> 
> --John
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 29 May 2012 17:23:00 -0400

[Once more from proper account, sigh.]

> It's also worth noting that leaving AS_PATH in would not be without cost. In the cases where the content of AS_PATH is isomorphic to that of BGPSEC_Path_Signatures, there's no problem -- but in tho…

In an offline follow-up with Robert Raszuk, he pointed out that when one applies a knob that results in an AS_PATH that can't be represented as a BGPSEC_Path_Signatures [*] there is a third option, that of downgrading from BGPSEC to unsigned BGP. That is to say, you convert the BGPSEC_Path_Signatures to an AS_PATH, apply the knob to the AS_PATH, and propagate the route with the AS_PATH and not the BGPSEC_Path_Signatures. This is functionally equivalent to "in all such cases, the route fails validation" but is more straightforward and seems to make a lot of sense: everything that can be represented signed, should be. If you insist on doing something that can't be signed, you can fall back to unsigned BGP and hope for the best.

This leaves me feeling a little more sanguine about the drop-the-AS_PATH idea, although I still think some more attention to enumerating what knobs will fall by the wayside is advisable. 

--John

[*] The name of this attribute makes for awkward prose since it has no natural singular. How about calling it BGPSEC_Path_Signature instead? Or Signed_Path or Signed_AS_Path sans brand name?

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 May 2012 08:45:39 +0900

> This leaves me feeling a little more sanguine about the
> drop-the-AS_PATH idea, although I still think some more attention to
> enumerating what knobs will fall by the wayside is advisable.

as folk keep inventing new knobs, one question would seem to be whether
the knob inventors will understand and accept the trust/threat model
implications of knobs which force downgrade to non-sec.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 29 May 2012 20:01:42 -0400

AS_PATH is used to specify the path that the payload takes.
Signed_AS_PATH is to verify the path that the update message takes.

There is no reason they can not be different. Let the verifying
function take both as input and let it decide based on policy.

An AS could forward an update with a third party nexthop of a third
party AS. The update message does not need to traverse the third
party AS at all, but the payload will. The third party ASN might just
be another ASN that the first party is using: it might be renumbering.
The first party might like to include the third party ASN for
loop detection.

I don't have a specific feature in mind. Just "what if".

On Tuesday, May 29, 2012 2:22 PM, John G. Scudder <> wrote:

>> It's also worth noting that leaving AS_PATH in would not be without
>> cost. In the cases where the content of AS_PATH is isomorphic to
>> that of BGPSEC_Path_Signatures, there's no problem -- but in those
>> cases AS_PATH clearly could have been left out. In the remaining
>> cases, what is the implementation supposed to do? It would be
>> necessary to carefully specify. The easiest cop-out would be to say
>> that in all such cases, the route fails validation. But I have a
>> feeling that it's not that easy. Leaving AS_PATH out reduces that
>> particular maze of twisty passages, although it replaces it with
>> another: making sure it was really OK to axe AS_PATH to begin with
>> (i.e., the discussion above).          
> 
> In an offline follow-up with Robert Raszuk, he pointed out that when
> one applies a knob that results in an AS_PATH that can't be
> represented as a BGPSEC_Path_Signatures [*] there is a third option,
> that of downgrading from BGPSEC to unsigned BGP. That is to say, you
> convert the BGPSEC_Path_Signatures to an AS_PATH, apply the knob to
> the AS_PATH, and propagate the route with the AS_PATH and not the
> BGPSEC_Path_Signatures. This is functionally equivalent to "in all
> such cases, the route fails validation" but is more straightforward
> and seems to make a lot of sense: everything that can be represented
> signed, should be. If you insist on doing something that can't be
> signed, you can fall back to unsigned BGP and hope for the best.     
> 
> [*] The name of this attribute makes for awkward prose since it has
> no natural singular. How about calling it BGPSEC_Path_Signature
> instead? Or Signed_Path or Signed_AS_Path sans brand name

-- 
Jakob Heitz.

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 May 2012 09:29:23 +0900

> AS_PATH is used to specify the path that the payload takes.

really?  i thought it was a routing loop detection mechanism.
it's been a while since folk wrote research papers describing
schemes for routing by AS.

i would phrase it as

AS_PATH specifies the ASs through which the routing announcement has
passed.

> Signed_AS_PATH is to verify the path that the update message takes.

and then this works really nicely.

> There is no reason they can not be different.

and here i thought that detecting that they differ, as an attack, is the
core goal of as-path validation.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 29 May 2012 20:47:36 -0400

On Tuesday, May 29, 2012 5:29 PM, Randy Bush <mailto:[email-masked]> wrote:

> and here i thought that detecting that they differ, as an attack, is
> the core goal of as-path validation.

I thought it was to prevent an AS from
announcing an update that it was not authorised  to.

An entirely different thing.

-- 
Jakob Heitz.

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 May 2012 09:52:05 +0900

> I thought it was to prevent an AS from announcing an update that it
> was not authorised to.

nope.  that is rpki-based origin validation.  we are now talking about
as-path validation.

from a note to some gov folk:

To be clear, as people keep calling BGP security 'RPKI'

In the current taxonomy, there are three pieces, the RPKI, RPKI-based
origin validation, and then path validation.

RPKI is the X.509 based hierarchy with is congruent with the internet IP
address allocation administration, the IANA, RIRS, ISPs, ...  It is the
substrate on which the next two are based.  It is currently deployed in
four of the five administrative regions, ARIN in North America being the
sad and embarrassing exception.

RPKI-based origin validation uses some of the RPKI data to allow a
router to verify that the autonomous system announcing an IP address
prefix is in fact authorized to do so.  This is not crypto checked so
can be violated.  But it prevents the vast majority of accidental
'hijackings' on the internet today, e.g. the famous Pakastani accidental
announcement of YouTube's address space.  RPKI-based origin validation
is in shipping code from Cisco, and will be shipping by Juniper soon.

Path validation uses the full crypto information of the RPKI to make up
for the embarrassing mistake that, like much of the internet BGP was
designed with no thought to securing the BGP protocol itself from being
gamed/violated.  It allows a receiver of a BGP announcement to formally
cryptographically validate that the originating autonomous system was
truely authorized to announce the IP address prefix, and that the
systems through which the announcement passed were indeed those which
the sender/forwarder at each hop intended.

Sorry to drone on, but these three really need to be differentiated.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 29 May 2012 21:05:59 -0400

On Tuesday, May 29, 2012 5:52 PM, Randy Bush <mailto:[email-masked]> wrote:

> RPKI is the X.509 based hierarchy with is congruent with the internet
> IP address allocation administration, the IANA, RIRS, ISPs, ...  It
> is the substrate on which the next two are based.  It is currently
> deployed in four of the five administrative regions, ARIN in North
> America being the sad and embarrassing exception.
> 
> 'hijackings' on the internet today, e.g. the famous Pakastani
> accidental announcement of YouTube's address space.  RPKI-based
> origin validation 
> Path validation uses the full crypto information of the RPKI to make
> up for the embarrassing mistake that, like much of the internet BGP
> was designed with no thought to securing the BGP protocol itself from
> being gamed/violated.  It allows a receiver of a BGP announcement to
> formally cryptographically validate that the originating autonomous
> system was truely authorized to announce the IP address prefix, and
> that the 

Apology accepted.
Note, I said "announcing", not "originating".

Here is my view of the difference:

Origin validation does not stop anyone from announcing an update.
It only requires the first AS in that update to be the
owner of the prefix.

Path validation prevents anyone from announcing an update unless
it was sent to them by an authorised AS. And they are authorised,
because it was sent to them by an authorised AS and so on, back
to the authorised originator.

-- 
Jakob Heitz.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 May 2012 14:01:37 +0200

Let's observe that mangling with AS_PATH is usually done for a reason .. 
to achieve reachability to some set of prefixes which otherwise would be 
dropped.

So with this in mind a better question to think about from customer 
perspective is to choose either:

- unsecure but reachable Internet destinations
- secure Internet routing but unreachable destinations

Rgs,
R.

PS. I believe I have a solution to address both sides. Let me write it 
up and share in a week or two.

> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 May 2012 10:06:57 -0400

Randy,

Thanks for the nicely articulated description of these elements of routing
security work in  SIDR.

Steve

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 30 May 2012 16:52:19 -0400

[added IDR to cc]

On May 30, 2012, at 12:10 PM, Murphy, Sandra wrote:

...
> About extensibility - as you say, any new segment type not built into implementations would result in fatal errors.  So any new segment type would need to be built into implementations before use.  The question then becomes - can the signature attributes also be augmented at the same time to deal with the new segment types?
...
> So the AS_PATH extensibility could be maintained in the security protections - as long as the new extension is "protectable".

OK, as long as it's practical to extend the BGPSEC_Path_Signatures attribute. I confess to not having given this much thought but it doesn't appear to be as easily extensible as AS_PATH, because the latter has a TLV structure and the former doesn't. I guess your answer is that since AS_PATH extensions are in practice a big deal, you'll just introduce a new, incompatible format of BGPSEC_Path_Signatures to match? If this is the plan, BGPSEC_Path_Signatures should include a version number, since it would be a little rude to consume another code point from the one-byte BGP path attribute code point space for this purpose. Also, for generality you'll need to think about whether you want to be able to support different subsets of extensions -- this is easy in a TLV-encoded attribute but hard if all you've got is a version number. (Another answer might be that Additional_info will serve as the extensibility placeholder, but if so its length field is too small.)

...
> I am quite sure I don't know the complete list of AS_PATH knobs!

Nor do I, from memory. But we probably should plan to enumerate a list of them so that we can categorize them as "we can do this", "this is formally an attack and therefore will never be supported", or "other", and then iterate on "other".

> But some of those I do know are hacks that would allow attacks as well.  The fact that the security protections prohibit the attacks is a good thing.  If there's a way to identify good, not evil, uses, then we can design for that.  But in cases where there's no real way to distinguish the good from the evil, we're in a hard place.  Shoot a hole in the protection to allow the hack or prohibit the hack.

Right, and agreed (see "formally an attack" above). But to repeat my further point, if the AS_PATH is present (even if not secured): "at least there's scope for a network operator on the receiving end to tolerate the validation failure and use the route anyway, if desired. In the case where there's no AS_PATH, the data are just gone with no chance for appeal."

--John

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 30 May 2012 20:02:44 -0400

>
>Right, and agreed (see "formally an attack" above). But to repeat my further
>point, if the AS_PATH is present (even if not secured): "at least there's scope for a
>network operator on the receiving end to tolerate the validation failure and use
>the route anyway, if desired. In the case where there's no AS_PATH, the data are
>just gone with no chance for appeal."
>

John,

I do not agree that in the event of "validation failure" the route becomes unusable
in BGPSEC as currently specified.
The operator has a choice to consider and select a route as best path (or as add-path)
even if the update failed validation or validation was deferred.
(Note: Validation may not be deferred sometimes due to 
processor overload, or known RPKI staleness, etc.)

You seem to be suggesting that when there is "validation failure",
then "BGPSEC_Path_Signatures" as whole is unusable. 
That is not the case.

"BGPSEC_Path_Signatures" is just a name given to the outer shell of
the BGPSEC update. (BGPSEC need not give the outer shell any name at all.) 
Within it, we have these segments: Secure_Path, Sig_Block, and Additional_Info.
Each of these segments has its own proper semantics.
Even if the Sig_Block were to have an invalid signature, 
the Secure_Path segment is still usable as it provides the AS path info.
If the operator chose an _Invalid_ update for lack of a better choice, 
then it is still the Secure_Path that provides the AS path info,
and also the update SHOULD be signed and propagated to other BGPSEC peers.
Also, if a specific eBGP neighbor is a non-bgpsec speaker, then the selected
BGPSEC update (valid or invalid) is converted to a regular BGP-4 update wherein 
the AS_PATH attribute is constructed from the Secure_Path. 
So validation failure in BGPSEC does not mean that "the data are just gone."

In fact, for clarity sake I would like to suggest that in the spec we consider
Secure_Path, Sig_Block, and Additional_Info as distinct BGPSEC attributes.
(That is to say we should not lump them together as one attribute.)

Sriram

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 31 May 2012 13:31:29 -0400

> So validation failure in BGPSEC does not mean that "the data are just gone."

My point is not that validation failure causes this. It's that absent AS_PATH, a semantically non-representable AS_PATH will be lost if forced through BGPSEC_Path_Signatures.

To reiterate, the options to address the case where a feature wants to produce output that can't be represented in BGPSEC_Path_Signatures are:

- Don't solve it. Effectively forbid any such feature.
- Carry both AS_PATH and BGPSEC_Path_Signatures in every update. Rules for reconciliation would be required.
- Downgrade BGPSEC update to BGP update. 
- Extend BGPSEC_Path_Signatures format to be able to represent the needed feature. (As Sandy noted, this only makes sense insofar as the feature isn't formally an attack, so this option is incomplete.)

The validation failure I spoke of is a potential *consequence* of the middle two options above, and as you say, the operator can then decide what to do.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 31 May 2012 13:37:57 -0400

[Sigh. Again with the right source email address.]

Missed one:

>> - Extensibility to include new segment types. In principle this is a fairly serious omission, but one can argue that new segment types can't be introduced in practice, since existing implementatio…

- AS_SETs. SIDR has decided not to support these, and IDR has published RFC 6472 / BCP 172 "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP". Nonetheless, they remain part of the protocol and have not (yet) been formally deprecated, so I mention them for completeness.

--John