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

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

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.

dougm

Doug Montgomery - Manager Internet and Scalable Systems Research Group / Information Technology Laboratory / NIST
________________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Shane Amante [shane@castlepoint.net]
Sent: Thursday, July 28, 2011 3:00 PM
To: sidr@ietf.org
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
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr