Subject: Re: [RPSEC] proposed message to the IESG

From: Sandy Murphy <[email-masked]>
Date: Fri, 21 Jan 2005 18:38:18 -0500 (EST)

>> I disagree strongly that the statement is "meaningful" unless and until 
>> you have decided on the *meaning* of "verify the path".
>
>That's actually correct.

You are agreeing with me that we need to define "verify the path"?

>What I mean by "meaningful" is that the path
>actually exists, that there is a way from my peer, who has advertised that 
>path, to the destination stated in the route.

(a) If you agree that we need to define "verify the path", why are you
defining "meaningful"?
(b) Your definition sounds to me like a definition of "verify the path", not
a definition of "meaningful", anyway.
(c) I know you'll hate me for bringing up definitions again, but -- by
"exist", you mean "two AS's adjacent in the AS_PATH have a peering
relationship?"

--Sandy

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

---

From: Russ White <[email-masked]>
Date: Fri, 21 Jan 2005 23:30:55 -0500 (Eastern Standard Time)

> You are agreeing with me that we need to define "verify the path"?

Yes, but I think I've said that before. In fact, I believe I insisted we 
insert text explaining what, exactly, about the AS Path must and should be 
verified.

> (b) Your definition sounds to me like a definition of "verify the path", 
> not a definition of "meaningful", anyway.

I don't understand these two??

> "exist", you mean "two AS's adjacent in the AS_PATH have a peering 

I mean every pairwise set of AS' listed in the AS Path have a peering 
relationship. I do _not_ mean the "update" (really route) has passed 
through each of those pairwise peerings.

Going back to my other email:

--

Suppose you state: "A speaker should be able to prove the update has passed 
through the AS' listed in the as path," as a requirement. Now, my question 
is going to be: "Why? What do you want to prove by verifying this in this 
way?" Your answer is going to be: "Because proving this proves the path 
actually exists, and can prove non-repudiation, and...."

--

I believe you stated your answer would be: "Because the specification says 
that's what's supposed to happen." Thus, you are stating the questions I've 
asked above are invalid questions. Asking why is always met with: "It's 
what the spec says," and no other anwers or questions, based on operational 
and implementation experience, are allowed.

Given this, I go back to my original statement. We won't reach concensus on 
this point. I believe asking "why" is valid, based on my experience with 
BGP in the real world. I also believe asking "why" is valid, even within 
the pure security space. You would never, as a security expert, place four 
locks on a door, without considering the other methods of entry into the 
space, simply because: "the specification states you must enter through the 
door."

Essentially, what I'm saying is that you're trying to secure the wrong 
thing. You're trying to secure the routing update, the process. I'm trying 
to secure routing.

>From another tack: If someone asks you why the security requirements 
include a section on deployability, what would your answer be? According to 
these rules, that entire section needs to go, correct? Or can you justify 
it from the BGP specification?

Further, why aren't you insisting the other attributes be treated in the 
same way? For instance, why shouldn't a BGP speaker be required to prove 
the next hop listed in a received update is actually the next hop it should 
send the traffic to? Why aren't we requiring speakers to prove the point at 
which transitive communities are added to a route, and the authorization of 
an AS to add those transitive communities? Or the MED, for instance, why 
aren't we requiring BGP speakers to verify that attribute?

Is it because operational experience shows us that those questions aren't 
the right sorts of questions to ask about those attributes? My contention 
is very simple: Operational and implementation experience shows that the 
right question to ask about the AS Path is not: "has the update traversed 
this set of AS'?" I believe the correct questions, based on both the BGP 
specification and operational experience with BGP as a protocol, have 
already been defined in the draft.

--

If the only answer allowed to the question above is: "It's what the 
specification states," I don't see how we can come to concensus without 
either:

-- Building the requirements loose enough to support both interpretations, 
letting the designers make their best case, and the community decide 
through whatever process it uses (the market, a technical design team, or 
other methods) which is correct, securing the process, or securing routing, 
based on the tradeoffs and other issues involved.

-- Simply disbanding the entire draft.

-- One or more people dropping completely out of the conversation, and 
simply no longer contributing in any way shape or form.

I believe the best path to take is the first path, since it is a way 
forward as a community. It seems I may be alone in that belief, since I've 
offered this option on several occasions, and no-one has supported the 
concept in any previous instance.

IMHO, the third option is quickly approaching, which is a shame. I hate to 
see the community lose technical expertise, and perspective, but it's what 
most often happens if only a minority will accept the middle road.

:-)

Russ

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