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: [email protected] [[email protected]] On Behalf Of Shane Amante > [[email protected]] > Sent: Thursday, July 28, 2011 3:00 PM > To: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
