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

From: "t.petch" <[email-masked]>
Date: Mon, 1 Aug 2011 17:42:01 +0200

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Aug 2011 02:17:34 +0900

not your fault, but very hard to find your text amid the top posting,
lack of line wraps, quoting disasters, ...

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

we knew as-sets were rare.  but before moving to deprecate we decided to
actually measure how rare.

note that as-sets affect both origin validation and path validation.

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

we could measure.  but given that we can see that it is quite common,
and we have reasonable ways to deal with it, why should we spend the
time?  what might we learn?

randy

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 1 Aug 2011 13:31:55 -0400

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

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 1 Aug 2011 15:01:49 -0400

>time?  what might we learn?

Randy's answer was better.  Given that it is easy to do, what is the down
side to enabling one to tell if someone else added/subtracted from your
prepend list?

Maybe to help that discussion, I will note by "tell" above, what the
current proposal suggests is that such adding/trimming would cause BGPSEC
path validation to FAIL.

Dougm

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 1 Aug 2011 15:16:18 -0400

It is easy enough to tell, but should we?
It is also easy to protect other bgp attributes that affect path selection.

However, the real question is:
Do we want to invalidate an update if someone changes such an attribute?

Remember, if we send a route to an AS, even if it is less preferred
than another route, then that route will be used if the preferred route
becomes infeasible. Therefore, there is not as much value in
protecting attributes as there is in protecting the path.

I thought there was a statement some time ago that we only protect
the path, not the attributes.

A prepend is not a change in path. It is more like an attribute.

--
Jakob Heitz.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Montgomery, Douglas
> Sent: Monday, August 01, 2011 12:02 PM
> To: Randy Bush; t.petch
> Cc: [email-masked]
> Subject: Re: [sidr] pCNT & (AS_PATH) prepending: Is it in scope?
> 
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 1 Aug 2011 17:18:51 -0400

>It is also easy to protect other bgp attributes that affect path selection.

maybe, or maybe not. The AS path info can be protected using the RPKI,
because each ISP gets a cert that enumerates all AS#'s associated 
with that ISP.
So, when a router signs an AS path entry, the authorization of the 
router to represent can be verified using the RPKI data.  Other 
attributes may not
correspond to data that we can verify, based on the RPKI.

>Do we want to invalidate an update if someone changes such an attribute?

in the case of As path, sinec we know that ISPs make use of AS path to
distinguish between different routes for the same prefix, it makes sense to
reject (or at least penalize locally) a route if the path sig data is invalid.

>becomes infeasible.

More precisely, the route MAY become the preferred route if the previous
preferred route becomes ...

>Therefore, there is not as much value in

I don't agree.  because the AS path length if a very important attribute
in pat selection, it merits protection.

>the path, not the attributes.

that have been a lot of statements on this list over time :-).

>A prepend is not a change in path. It is more like an attribute.

Prepedning is a way that ISP use BGP to effect traffic engineering,
at a distance.  A route, technically, is a set of prefixes (NLRI) plus
an AS path.  I believe we are trying to protect routes. Biut I agree that
we ought to be more precise in the way we say this.

Steve