Subject: [RPSEC] Back to Basics--The AS Path

From: Russ White <[email-masked]>
Date: Sat, 22 Jan 2005 08:23:36 -0500 (Eastern Standard Time)

Sandy:

My last message last night actually drove me back into the BGP 
specification, to discover what the specification really says. Note that 
throughout this email, I've used your preferred wording, using the term 
"update" as if updates were transitive objects being sent through a BGP 
network, and I've attempted to be as precise as possible in all definitions 
and wordings.

Now, if we are going to claim something close to this as a requirement:

"On receiving an update, any proposed solution MUST verify the update has 
passed through the pairwise peerings represented by the AS Path attribute 
contained in the update."

With this as our basis:

"Because the specification says so."

Then I think we should really go look at the specification, and see what it 
actually says, no? I used the most current version of the specification, 
currently in line for draft-standard state, which I found here:

http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-26.txt

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:

-- First, there is no mention of any conditions under which information may 
be removed from the AS Path, or the AS Path is reordered. I believe, based 
on reading of the specification (without outside reference to operational 
or implementation experience), this means the AS Path may be reordered, or 
information may be removed from the AS Path. Let me at least say neither of 
these are strictly prohibited.

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

Would you say this is all correct? I believe, then, that you cannot get the 
proposed requirement listed above from the BGP specification itself. At 
least I can't find any justification for it. If you believe the 
specification should say "MUST" at this point, I would say that's an 
argument for the IDR WG, not for RPsec. :-)

--

Now, let's expand this further, and say we'd like to state this:

"On receiving an update, any proposed solution MUST verify the update has
passed through the pairwise peerings represnted by the AS Path attribute
contained in the update."

And base it on this reasoning:

"The sense of the BGP specification is that the protocol will not operate 
correctly is this rule is not followed."

This is a slightly less strong justification, but let's deal with it, 
anyway, just for argument's sake.

I would point out numerous instances have been cited where operational 
requirements, in running, live networks, have caused operators to:

-- Add additional information to an AS Path, causing it to _not_ represent 
the list of peerwise AS peerings the update has passed through. A common 
example of this is AS Path prepend.

-- Remove information from the AS Path, causing it to _not_ represent the 
list of peerwise AS peerings the update has passed through. A common 
example of this is stripping private AS numbers out of the AS Path at an 
autonomous system boundary.

-- Advertise a set of reachable addresses which contains address space 
reachable through a different AS Path than that listed in the update. A 
common instance of this is the re-origination of routing information at an 
autonomous system border.

With these thoughts in mind, we must choose between one of three 
alternatives:

-- These examples are a figment of my imagination. If you want to choose 
this option, you'll need to consult my psychologist.

-- Operators shouldn't be doing these things, and therefore the 
justification above stands. In fact, the security requirements document 
should be defined so such modifications are not allowed, and the BGP 
specification should be modified in accordance with this.

-- The requirement, as listed, in some way, doesn't truly define what 
"valid" means as applied to an AS Path, based on operational and 
implementation experience.

I would suggest the third option as the logical choice.

Now, if we can't base the definition of "valid" in reference to the AS Path 
on the BGP specification, because the required MUST isn't there, and we 
operational experience shows we can't base it on what we think the "sense 
of the BGP draft is or should be," then how can we define "valid" in 
reference to an AS Path?

I would suggest the definition contained in the current BGP security 
requirements draft, as published, are a good start. The wording may be 
formalized, etc., but the sense of the definition in that draft is based on 
the sense of the BGP specification combined with operational and 
implementation experience, IMHO.

I hope it helps to clarify things by starting from the beginning, and 
summarize the overall picture.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Jan 2005 11:38:50 -0500

I'll just pick one example of a significant error in this message, 
because finding and correcting all of them is too much work.

>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:
>
>-- First, there is no mention of any conditions under which 
>information may be removed from the AS Path, or the AS Path is 
>reordered. I believe, based on reading of the specification (without 
>outside reference to operational or implementation experience), this 
>means the AS Path may be reordered, or information may be removed 
>from the AS Path. Let me at least say neither of these are strictly 
>prohibited.

Perhaps you forgot the following quote from the BGP spec that 
appeared in my message a few weeks ago:

The path segment type is a 1-octet long field with the following 
values defined:

      Value      Segment Type

        1         AS_SET: unordered set of ASs a route in the
                     UPDATE message has traversed

        2         AS_SEQUENCE: ordered set of ASs a route in
                     the UPDATE message has traversed

This makes a pretty clear statement about the ordering of the AS 
numbers in an AS_SEQUENCE, and what they represent.

Steve