Subject: [Idr] prepending one's own AS on the AS_PATH

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 13:01:50 -0500 (EST)

On the rpsec list, Russ White has made two interesting observations.

>On searching the document for all occurances of the words: "as_path," or: 
>"as path," I found only a few instances. The one I _believe_ is relevant is 
>here, on page 25:
>
>         b) When a given BGP speaker advertises the route to an external
>         peer, then the advertising speaker updates the AS_PATH attribute
>         as follows:
>
>            1) if the first path segment of the AS_PATH is of type
>            AS_SEQUENCE, the local system prepends its own AS number as the
>            last element of the sequence (put it in the leftmost position
>            with respect to the position of octets in the protocol mes-
>            sage). If the act of prepending will cause an overflow in the
>            AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
>            new segment of type AS_SEQUENCE and prepend its own AS number
>            to this new segment.
>
>When I examine this text, I find two interesting things:

>...

>-- Second, when describing the operation of a BGP speaker, the draft 
>doesn't say the speaker MUST prepend its own AS number as the last element 
>of the sequence, it says it "will." In my experience, when a draft means 
>"MUST," it uses "MUST," rather than "will." This implies the writers of 
>this specification (if you refer to page 7, you'll find I'm listed as a 
>contributor) believed there were valid situations when a BGP speaker would 
>not follow the operational procedure described here.

Good catch, Russ!!!

This has been discussed many times in idr meetings.

I actually softenend the language in the vulnerabilities draft when
talking about prepending your AS to the AS_PATH, because (I was told)
the newest draft said that prepending your own AS on the AS_PATH was
required.  I missed the absence of the "MUST" language.

So - was the MUST removed because there are circumstances in which one
would not prepend one's own AS?  (Route reflectors I remember as being
mentioned in this regard at times.)  Or was this an oversight and the
MUST language was intended?

Note: if legitimate incoming AS_PATHs might not have the peer's AS
appended, then the implementations can't check for this, and bogus
AS_PATHs will be acceptable.  The vulnerabilities draft already speaks
of what happens if implementations don't do the checking, so I think
there's no additional vulnerability.  It's just that the vulnerability
would be due to design, not implementation weakness.

--Sandy

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Jan 2005 13:00:34 -0800

An interesting observation is that the latest draft does not prohibit 
one from also prepending someone else's AS# to the AS_PATH. In fact on 
one of the past RIPE meetings I saw a very interesting presentation from 
William Norton where he showed what kind of tricks folks do with AS_PATH 
to get a better peering agreements ;).

http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing-art-peering/

Cheers,
R.

 > Sandy Murphy wrote:

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Jan 2005 17:26:56 -0500

> would be due to design, not implementation weakness.

Sandy,

I don't think that was the intent at all.  The "prepends" rather than
a "MUST prepend" is an oversight.  If what Russ stated was intended
the word "SHOULD" would appear there, not "prepends".  The word "will"
is used in the phrase "If the act of prepending will cause an
overflow".  That sentence contains a "SHOULD".

In practice, removing duplicates might be an alternative here (where
som other AS has done AS padding to affect AS path length).  Dropping
the advertisement would be another alternative.  If the "SHOULD" is
violated, as in all cases where SHOULD is specified, it may be at some
peril.  Care is advised.

Curtis