Shane, Just to be clear if you look at my second slide from today ... BGPSEC uses a PATH_SIGs attribute to protect the existing BGP4 AS_PATH attribute. That is, there is no distinct BGPSEC_AS_PATH.
Clearly, that could be ... and has been discussed ... done differently. But in the protocol-00 spec, that is the semantic/encoding. So the situation is that prepended AS's already appear today in the attribute we are trying to protect. The protocol-00 spec would have you add a distinct signature for each element (i.e., including prepends) in the AS_PATH. The design-choices document notes that this was flagged as an issue we would clearly want to revisit and optimize in one way or the other. But the position we start from is that prepends are already in the AS_PATH and protected by individual Sigs. If you look at the straw man requirements slide, there are two issues to consider. 1. Avoid duplicating Sigs for prepended AS's in the AS_PATH. 2. Protect prepended AS's with the BGPSEC PATH_Sig. Those really are two distinct options ... If we want: 1, but not 2 - we can just rewrite the sig generation / verification rules to "skip" consecutive repeated AS's. No need to carry or sign over pCNT. If we want: 2, but not 1 - do nothing, that is what the protocol-00 spec does now. 1 sig per AS_PATH element, including prepends. If we want 1 and 2 - you get the strawman proposed today - Anyway, just wanted to be clear that currently we protect the existing AS_PATH, which already has prepends. dougm Doug Montgomery - Manager Internet and Scalable Systems Research Group / Information Technology Laboratory / NIST ________________________________________ From: Shane Amante [[email protected]] Sent: Thursday, July 28, 2011 5:18 PM To: Montgomery, Douglas Cc: [email protected] Subject: Re: [sidr] pCNT & (AS_PATH) prepending: Is it in scope? 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
