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

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 12:36:49 -0500 (EST)

>I've used your preferred wording, using the term 
>"update" as if updates were transitive objects being sent through a BGP 
>network,

I'd like to go on record right now to say that I do not believe that
updates are transitive objects.

I hope that I've never said that updates were transitive, since
"transitive" is a term that applies to relations, not objects.  If I
ever said updates were transitive, I apologize for being so inprecise
in terminology.  And inaccurate, even if you were trying to stretch
the definition of transitive to include objects or operations on
objects, since we all know that any update is created anew by each AS
on the basis of received and configured info.

So.  Update are not transitive.

--Sandy

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

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 12:37:19 -0500 (EST)

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

An interesting interpretation of the spec.  (Tongue in cheek.)

I do not believe that you can read a spec to say that any operation
not "strictly prohibited" is allowed.  The specs say what operations
should be performed, they could not hope to cover all possible
operations that are not to be performed.  So I reject this line of
reasoning.  But I'm also going to post this section of your email to
the idr list to see if other implementers interpret specs in this way
and this specific part of this spec in this specific way.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 12:38:31 -0500 (EST)

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

I've been in a number of idr meetings where exactly this point was
discussed.  The idr security vulnerabilities draft I wrote initally
mentioned the vulnerabilities that result if the AS_PATH did not start
with the peer's AS.  I was told that the new version of the spec said
that it was necessary for the peer to add it's own AS.  So I softened
the language to say only that if implementations did not check for the
peer's AS as the first AS, bogus AS_PATHs could still be produced.

I'm passing this one to the idr list to find out if the MUST was
removed because of special conditions or whether this was an oversight.
It's an important oversight, I would say, that should be corrected
if possible.

--Sandy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 24 Jan 2005 17:16:07 -0500

I have been watching this debate, and trying to understand what is driving 
such strong disagreement.

I thinking about it, I am reminded of a comment made by a colleague of my 
in a protocol discussion.  "Of course that's lying.  That's what routers 
do.  We lie, cheat, and steal."  His point was that in achieving the 
objectives of making things work, we (the router and operational 
communities) have always bent the spec, lied when necessary, and made it 
work.  The basic rule is that if it is not completely prohibited by the 
spec, someone probably does it.  And even if it is prohibited, it probably 
still happens.  (Deployed routers have been known to be configured for 
example, to forward packets in ways that do not agree with their BGP 
advertisements, even though that flat violates the spec.)

Unless we recognize and address this basic mismatch, it becomes impossible 
to agree on what it means to secure the routing system.  This applies 
independent of which protocol we are talking about.  (I have seen some 
interesting topological lies in OSPF.  I have committed some of them myself.)

Hence, arguing about what the spec does or does not say is never going to 
resolve this debate.  The new BGP spec is as accurate as folks could make 
it.  It still does not, and can not, capture all of the 
realities.  Particularly since some of those realities violate the spec.  I 
do not know that Russ' text is any better at allowing us to have a set of 
requirements we can understand and apply to the real world.  I do 
understand that paying attention to the stated semantics of the spec is 
also very helpful in getting a useful security result.   (After all, it is 
pretty hard to "secure" an undefined semantic.)

This may not help the primary discussants come to agreement.  But maybe 
this perspective will help someone else on this list come up with a useful 
way forward.

Yours,
Joel M. Halpern

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 18:03:09 -0500 (EST)

>realities.

The really tough questions become:  what operational uses are
so common, so useful, (AND so lacking in ways to exploit harmfully)
that we want to maintain them.  And how can we do that.

>I do 
>also very helpful in getting a useful security result.

Yes.  But that won't cover the accepted (mis)uses, lies, etc.
Particularly when those uses violate the semantics.

>(After all, it is 

Yes, we agree.

So getting the "undefined semantics" down will be important.

--Sandy