I find the discussion of the "intent" of prepending a bit confusing. The previous notes and presentation in SIDR tried to make clear that ...
1. As currently spec'ed bgpsec-00 signs each prepend with a unique sig. I.e., prepend lists are protected in -00 spec. 2. We could either (a) continue to protect prepends, but optimize down to 1 sig per unique AS, or (b) completely ignore (I.e, skip over and not protect) prepends in the sig gen/validation logic, or (c) leave it as currently specified. In all cases, we are just discussing protecting the field, as put on the wire, nothing more. The requirement about not making assumptions about the intent of an update, derives from a similar logic. That is BGPSEC does not assure that a router intended to send an announcement to a peer (I.e., that the announce is actually consistent with local policy), it only allows us to verify that the router *did* send the update. Thus if the definition of "intent" is that it is consistent with local policy etc, neither the basic BGPSEC AS_PATH protection mechanisms, nor the proposed enhancements for prepending give any assurances of intent. Actually, to turn the question around a bit ... What would it mean to protect/verify intent. If we stick with a mechanistic view of this, we can either: 1. Provide ways to detect that a prepend list was manipulated after original transmission (AS's added or subtracted). 2. Or Not, making is possible to have downstream AS's manipulate the length of a prepend list without BGPSEC detecting it. I would think the discussion should be on the use/business case for allowing/disallowing downstream modification. WRT use in path_length computations ... So far the -00 spec and the proposed enhancements from the SIDR meeting have taken the view that is best to leave the semantics and encoding of the existing AS_PATH attribute unmodified. There were some opinions expressed that a lot of existing mechanisms/configuration is based upon the AS_PATH attribute as it currently exists. Thus BGPSEC's PATH_SIG attribute does not replicate or change the AS_PATH attribute, it just provides the data that allows a receiver to validate the AS_PATH. So as it stands, there is no BGPSEC_AS_PATH ... Now I guess one could count the number of unique SIGs to come up with an AS_PATH_Length that ignores prepends, but that is already trivial to do with the existing AS_PATH attribute. In fact some commercial implementations provide such a feature. So I don't think optimizing the number of SIGs will give away anything that you couldn't already easily figure out ... Dougm On 8/1/11 11:42 AM, "t.petch" <[email protected]> wrote: >----- Original Message ----- >From: "Shane Amante" <[email protected]> >To: "Montgomery, Douglas" <[email protected]> >Cc: <[email protected]> >Sent: Thursday, July 28, 2011 11:18 PM >> >> 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? > >I do not think that it was simplification that led to the deprecation of >AS-SET, >rather the difficulty or impossibility of securing it to the same extent >as a >single >AS; which led to the discovery that AS_SET were rare and that their loss >would not affect almost all of the Internet. > >Question is; how common is prepending? I thought that it was widespread >and >'normal' but there would have to be hard data first, before deprecation >could >be contemplated. > >Tom Petch > >> > 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 > >_______________________________________________ >sidr mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
