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

----- Original Message -----
From: "Shane Amante" <shane@castlepoint.net>
To: "Montgomery, Douglas" <dougm@nist.gov>
Cc: <sidr@ietf.org>
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: 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
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr