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

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

>Stating: "A BGP speaker should 
>be able to verify the path described in the as path of a received route," 
>is meaningful.

I disagree strongly that the statement is "meaningful" unless and until
you have decided on the *meaning* of "verify the path".

That's a point that is unclear in the current requirements draft and
has been noted as unclear and admitted to be unclear.

And I think that's part of the disagreement between you and Steve.
You not only disagree about the meaning, you can't agree how to
decide what the meaning could be.  So you have no way of "proving" (:-))
to each other which meaning is correct.

--Sandy

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

---

From: Russ White <[email-masked]>
Date: Fri, 21 Jan 2005 13:57:10 -0500 (Eastern Standard Time)

>> Stating: "A BGP speaker should be able to verify the path described in 
>> the as path of a received route," is meaningful.
>

That's actually correct. 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.

What others apparently want it to mean is that the update has passed 
through the route described in the update. 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...."

Well, then, you shouldn't have an objection to asking those questions, 
discussing them, and listing the outcome as the requirements themselves. 
That I can ask this question, and the answer is going to be a set of things 
you are trying to verify/prove, shows me the stated requirement is actually 
a solution, not a true requirement.

I think the actual main sticking point is that many people think requiring 
"verify/prove the update has passed through path x" actually proves 
transitive authorization, but then we fall into the entire trap of 
"transitive authorization for what??" The update (updates aren't 
transitive), the prefix (it's been proven you can't do transitive 
authorization for prefixes), or.... what, exactly?

Rather than stating this question separately, and discussing it, we're at a 
point where some folks would like to just include a solution as the 
requirement, claiming it's the "right thing to do, because it matches the 
'sense of the BGP specifications,'" and leave it at that, burying the 
entire discussion.

I think, if you go back far enough in the thread, I've said this before. I 
specifically stated that every currently proposed system can meet the 
requirements as they are written today (S-BGP, IRV, SPV, soBGP, and several 
others, including off-line databases built IRR databases, etc). Systems 
may, if they want to, claim _more_ security than the requirements document 
state (remember, this is informational, and meant to guide, not a 
standard), and, at that point, the community would be able to set that 
question out on its own, discuss the assumptions, tradeoffs, and 
feasibility of answering it.

In other words, admit, honestly, that we can't reach a concensus on this 
one question, and write the document in such a way that the question is 
left to the protocol designers, implementors, and deployers, to decide.

I believe that suggestion was rejected, outright, by Steve. Instead, he 
states that we are "missing essential security we could claim." My argument 
is that we can't claim that security, the type of security you're talking 
about doesn't, and can't, exist in routing systems today.

IMHO, the best way to move forward is exactly what I said above. State the 
requirements we can agree on, state we can't reach concensus on this one 
point, and move forward. The requirements are reasonable, as written, and 
clear in what they mean. We need more justifications, introductions, etc, 
etc, but the doc itself asks the correct questions, and in the correct way 
(well, the wording may not be formal enough for some people).

This business about the requirements "not being based on the BGP 
specification" is a red herring, IMHO, meant to push requirements into the 
draft without actually discussing those requirements, or without actually 
considering the tradeoffs, etc, as they really exist.

:-)

Russ

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

---

From: Blaine Christian <[email-masked]>
Date: Fri, 21 Jan 2005 14:21:27 -0500

> feasibility of answering it.

Only one point I want to make in the above statement.  If the requirements
document allows every proposed standard then it is not yet complete.  It
"should" be written such that it helps to identify the most feasible
solution.  The trick, IMHO, is to get specific enough in the requirements
that either one of the existing solutions fits or a better solution gets
designed.  If the solutions are close enough together that they all solve
the document then we should just toss a coin <grin>.

---

From: Russ White <[email-masked]>
Date: Fri, 21 Jan 2005 14:25:44 -0500 (Eastern Standard Time)

> the document then we should just toss a coin <grin>.

IMHO, I don't agree.... I think all of the proposed solutions meet all of 
the MUSTs listed in the current requirements, and all miss at least one 
SHOULD. I've spent some time thinking about this, so I'm not just 
guessing.... :-)

That seems about right, to me. Each of the proposals put forward, thus far, 
have been put forward by people with serious interest in the topic, and 
have each taken a long time to develop, so this situation doesn't surprise 
me at all.

:-)

Russ

---

From: Blaine Christian <[email-masked]>
Date: Fri, 21 Jan 2005 15:55:07 -0500

> SHOULD. I've spent some time thinking about this, so I'm not just

I just want to parse the sentence a bit...  It sounds like you are saying
the draft will not be used to aid in the selection process of the security
mechanism.  I thought that is what we were shooting for?  I DO agree that it
is possible the draft covers all of the existing solutions.

> have each taken a long time to develop, so this situation doesn't surprise

My understanding of the proposals as described matches yours.  I know
everyone devoted significant effort in development to get us this far.
Perhaps, when we get to the protocol specification phase, the best thing to
do is evaluate the proposed mechanisms against the requirements draft and
see if some form of an almagam is possible?

---

From: Russ White <[email-masked]>
Date: Fri, 21 Jan 2005 16:03:28 -0500 (Eastern Standard Time)

>> IMHO, I don't agree.... I think all of the proposed solutions meet all 
>> of the MUSTs listed in the current requirements, and all miss at least 
>> one SHOULD. I've spent some time thinking about this, so I'm not just 
>> guessing.... :-)
>
> the draft will not be used to aid in the selection process of the 
> security mechanism.  I thought that is what we were shooting for?  I DO 
> agree that it is possible the draft covers all of the existing solutions.

No, there are two differentiators:

-- Which shoulds are matched, and which aren't? What are the tradeoffs in 
this space?

-- Is there "extra" security claimed by any of the solutions? How do you 
evaluate those claims, and what are their tradeoffs, if they are provable?

Finally, I think the draft serves another _very_ important purpose, to open 
the door for other people to think about the problems, and dream up new 
solutions to the problems. It's always harder to dream up new solutions in 
a space without something to work with.

I think all of these are very good reasons to go forth and require (!).

> Perhaps, when we get to the protocol specification phase, the best thing 
> to do is evaluate the proposed mechanisms against the requirements draft 
> and see if some form of an almagam is possible?

I don't see that happening, really.... I don't know that we'll ever have a 
technical design team to design a solution, but I think that question is up 
in the air. I'm not certain it's pertinent, though, at this point, we need 
more community feedback to decide.

:-)

Russ

---

From: Blaine Christian <[email-masked]>
Date: Fri, 21 Jan 2005 17:15:22 -0500

> -- Which shoulds are matched, and which aren't? What are the tradeoffs in

Very good point.  I think this leads us towards doing some work further
refining, somehow, the relative priorities of the shoulds.

> evaluate those claims, and what are their tradeoffs, if they are provable?

Is that something that should be documented?  I doubt discussion will
resolve those questions (as we have historic proof that it does not seem to
work).  This could be something where we can develop a weighting system and
select the aspects that are perceived as important and rate them.  After we
agree on the items to be weighted we can assign a numeric rating to each
proposed solution (on the specific aspect under review).  Once each aspect
has a rating we let the scoring system decide.  I was heavily involved with
this process for an employer before.  It seems to work well with large
groups of decision makers.

Items that are "MUST" would be in a class all their own (where a failure to
meet a MUST is criteria for immediate abandonment until revision).

> I think all of these are very good reasons to go forth and require (!).

I agree with that.  Without getting the needs documented designing (or
deciding) on something is pretty futile.

> more community feedback to decide.

Well, I suspect that we will get the almagam even if it happens without
being overtly stated.  I recall several hallway conversations where folks
identified bits that they could incorporate within their specifications
(from other specifications).

On a completely different topic that is in no way directed towards anyone in
particular...  I would love it if we could all try to forget about the
proposed systems and focus on the requirements first.  If we can get the
proposed systems out of our heads we can focus on how to optimize the
requirements such that we can achieve optimal deployment of a new system.
If we can get the requirements optimized such that deployment is broad we
can improve overall security of the inter-domain routing system.  While we
may not be able to perfectly secure the system and please all the developers
on this thread, we can, perhaps, make things safer and pave the way for
future improvements to the security of distributed prefixes.

BTW, I am just as guilty about thinking about the solutions (as evidenced by
the paragraph before the one above).

---

From: Russ White <[email-masked]>
Date: Fri, 21 Jan 2005 17:41:26 -0500 (Eastern Standard Time)

> resolve those questions (as we have historic proof that it does not seem 
> to work).  This could be something where we can develop a weighting 
> system and select the aspects that are perceived as important and rate 
> them.  After we agree on the items to be weighted we can assign a numeric 
> rating to each proposed solution (on the specific aspect under review). 
> Once each aspect has a rating we let the scoring system decide.  I was 
> heavily involved with this process for an employer before.  It seems to 
> work well with large groups of decision makers.

No, I don't think so.... I would leave this out, or we'll rat hole on each 
item, and never actually have a draft. Part of the point here is that we 
can push things we never reach concensus into this category, and actually 
get a draft out the door at some point, IMHO. :-)

> Items that are "MUST" would be in a class all their own (where a failure 
> to meet a MUST is criteria for immediate abandonment until revision).

Yes, and I think the draft, as it sits, accurately represents the correct 
set of shoulds and musts. I would rather see serious discussion on that 
topic than the rathole about what we should base the draft on, myself.

> On a completely different topic that is in no way directed towards anyone 
> in particular...  I would love it if we could all try to forget about the 
> can improve overall security of the inter-domain routing system.  While 
> we may not be able to perfectly secure the system and please all the 
> developers on this thread, we can, perhaps, make things safer and pave 
> the way for future improvements to the security of distributed prefixes.

Sure, but we have to get past this question:

Should we toss the draft as it sits today, and rewrite it based strictly on 
the processes/algorithms described in the BGP specifications? Specifically, 
as it concerns the contents of an "update" (not a transitive object in 
BGP), should we:

-- Describe how the update should be secured (any proposed solution must be 
able to verify the path taken by the update is the same as the as path in 
the update).

--OR--

-- Describe what things must and/should be asserted as true or false based 
on the routing data contained within an update (any proposed system must 
verify the as path is correct, with correct meaning x, y, and z, and the 
appropriate should and must in each case).

That seems to be the critical question at this moment.

IMHO:

-- The current draft does the second.

-- The second is the correct way to approach the problem.

-- The first is a solution, not a requirement, for the reasons I've listed 
elsewhere.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jan 2005 17:45:46 -0500

Russ,

>specification" is a red herring, IMHO, meant to push requirements 
>into the draft without actually discussing those requirements, or 
>without actually considering the tradeoffs, etc, as they really 
>exist.

This is obnoxious and calls into question whether you can serve 
(impartially) as WG co-chair.

Steve