Re: [sidr] pCNT & (AS_PATH) prepending: Is it in scope?

[Shane Amante <[e-mail]>]

On Jul 28, 2011, at 1:43 PM, Montgomery, Douglas wrote:

> The discussion so far has not been protecting/validating if prepending *should have* occurred.    BGPSEC protects the AS_PATH.  Prepending occurs in the AS_PATH.  Today's strawman presented one approach to protect the fact that prepending *did* occur (without comment as if it should have occurred).

Right.  But, if BGPSEC is not "commenting" whether AS_PATH prepending should, or should not, have occurred, then wouldn't it be more straightforward to avoid representing AS_PATH prepending in BGPSEC's AS_PATH Attr?  IOW, isn't the intent of the BGPSEC AS_PATH signature to "simply" represent the ASN's over which the BGP UPDATE has travelled?  Why does AS_PATH prepending *need* representation in the BGPSEC AS_PATH Attr, (or, what does it help with wrt BGPSEC)?

The SIDR WG instigated the deprecation of AS_SET's for reasons of simplification.  If WG really believes in simplification, then why does that not apply here wrt AS_PATH prepending?


> With that interpretation, I don't think today's proposal violates the requirement about presuming intent.
> 
> This too is good discussion as to what the requirement is.    
> 
> If we want to protect the common encoding of prepending in the AS_PATH today's strawman provides a simple approach.   
> 
> I don't know if your example is primarily pointing out another situation where prepending occurs on ingress .... or if we you are proposing that we discuss protecting the intent to prepend.
> 
> If it is the latter - that is a significant expansion of requirements - and there are no obvious simple enhancements of bgpsec-00 mechanisms that would get us there.

So, I grudgingly agree with the requirement, as written, that a BGPSEC AS_PATH signature should not describe/express intent.  (I'd feel better if the requirement were changed to say "does not" describe/express intent, but I'm not sure there is consensus to do so ...).

Ultimately, my concern is the more "faithfully" the AS_PATH appears to be represented in the BGPSEC AS_PATH Attr (i.e.: it does include AS_PATH prepending), then:
a)  The more potential confusion there might be with operators who aren't well versed in SIDR incorrectly /assuming/ that it does describe intent[1]; and/or,
b)  The more potential/temptation there may be for vendors to use the BGPSEC AS_PATH Attr in BGP path selection (i.e.: as the AS_PATH length tie-breaker) in place of the legacy AS_PATH Attribute.  This has implications wrt control plane scaling w/out any appreciable benefit.

-shane

[1] Yeah, yeah, they should RTFM ...


> 
> dougm
> 
> 
> 
> 
> Doug Montgomery - Manager Internet and Scalable Systems Research Group / Information Technology Laboratory / NIST
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Shane Amante [[e-mail]]
> Sent: Thursday, July 28, 2011 3:00 PM
> To: [e-mail]
> Subject: [sidr] pCNT & (AS_PATH) prepending: Is it in scope?
> 
> Hi,
> 
> I have a question for the WG.  In a series of e-mail exchanges earlier this year, I had thought it was concluded that BGPSEC was merely being used as a means to express that a BGP UPDATE had passed through a series of ASN's, i.e.: it's an expression of a "breadcrumbs", if you will, that can [later] be validated by receiver that are further downstream.  IOW, it's not a validation of the TE policies (e.g.: AS_PATH prepending) applied by ASN's.
> 
> I went back to the BGPSEC requirements:
> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-00
> ... and, if I look at Req #3.19:
>   3.19  A BGPsec design SHOULD NOT presume to know the intent of the
>         originator of a NLRI, nor that of any AS on the AS Path.
> 
> What was the intended meaning of the word "intent"?  I thought that word was meant to say that BGPsec was not intended to validate TE policies that may, or may not, be applied to the NLRI.  If that is correct, then why is the WG looking at signing an BGP attribute that expresses the the number of times an ASN may be prepended?  Or, has the WG had a change of direction and I haven't kept up to speed?
> 
> I would note that the reason I'm asking the above is that it may not be the originator that is performing AS_PATH prepending.  Specifically, a customer may use a provider's BGP TE communities to ask the provider to perform AS_PATH prepending (selectively) on their behalf.  But, since these BGP TE communities are not signed, then how would a receiver of the NLRI know that an AS_PATH should or should not have been prepended by an intermediate/transit ASN?
> 
> Thanks,
> 
> -shane
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr