Subject: [RPSEC] one more comment on MUST/SHOULD/MAY

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Jul 2007 11:14:42 -0400

Folks,

Michael Behringer and I spoke this morning at breakfast, and he 
suggested that I clarify my arguments re the choice of requirements 
wording in the BGP security requirements draft. I will not be at this 
evening's RPSEC meeting, otherwise I would present the arguments in 
person.

I have two arguments against the use of MUST in Section 4.2:

"A BGP security mechanism MUST provide backward compatibility in
the message formatting, transmission, and processing of routing
information carried through a mixed security environment.  Message 
formatting in a fully secured environment MAY be handled in a 
non-backward compatible fashion though care must be taken to ensure 
UPDATES can traverse intermediate routers which don't support the new 
format."

The first argument is that we have discussed plausible deployment 
scenarios in which participating ASes are all contiguous. For 
example, larger ISPs deploy might deploy a solution first, then their 
ISP clients, etc. In such contexts there is no need for the 
requirement imposed above, and imposing this requirement on solutions 
might added needless complexity in such deployment scenarios.

The second argument is that even if non-contiguous deployment does 
take place, it is not clear that security is improved by providing 
ASes with the ability to make decisions about the relative security 
of paths for which there is a mix of verified and unverified path 
elements. An example ma help here.

Assume that A, B, C, and D are ASes that have deployed a BGP security 
technology, and X, Y, and Z have not.  AS A might receive two paths 
for a prefix originated by AS C: C->X->Y->A  and C->B->Z->A. Both 
paths are the same length, but the second contains an AS that has 
verified path info, where the former has none. Does that make the 
second path more trustworthy than the first?  Not necessarily. If AS 
A tries to create policy that takes into account parameters such as 
the number of verified ASes in a path, rather than just making 
individual value judgments about the ASes in question, it may be in 
for a rude awakening. Experience in the security arena has show that 
individuals do a bad job of making such judgments. Experience on the 
routing arena would seem to confirm the applicability of this notion 
in this context, as indicated by the BG Wedgies RFC.

Thus my preference would be for us to reword this text in 4.2 to be a 
MAY. Such wording would say that a proposed solution can include 
provisions for passing security info through ASes that are not aware 
of new message formats, or it may not. The presence or absence of 
such a capability would not affect the evaluation of the solution 
relative to this criteria.

If we stick with a MUST here, then we are saying that we anticipate 
deployment scenarios that will involve a non-trivial number of 
non-contiguous ASes that adopt a solution, AND we are convinced that 
the operators of these ASes are better off having an ability to use 
some (locally defined?) algorithm to select between two or more paths 
when all of the paths contain some amount of unverified data. Based 
on our discussions, I don't see these two premises being satisfied 
with high probability.

Using SHOULD as a compromise is an odd choice here. SHOULD is 
intended to be used in standards when they talk about implementations 
of the standard; we are talking not about criteria for judging a 
standard, not an implementation.

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