Re: [tcpm] tcpsecure: how strong to recommend?

[Lars Eggert <[e-mail]>]

Hi,

On 2007-9-25, at 1:34, ext Joe Touch wrote:
> I'd encourage others to weigh in on this. I'm uncomfortable with our
> making recommendations to change TCP's fundamental behavior as a  
> SHOULD
> on the basis of a handful of representatives.

this brings up an important point we need to clarify. The tcpsecure  
document contains a technical specification for multiple TCP  
mechanisms to protect against certain attacks.

However, RFC 2026 recommends that technical specifications should  
also come with a statement of applicability, i.e., something that  
says when the technical specification should or should not be used.  
Many documents don't have this, and often that isn't an issue. The  
tcpsecure document is missing this piece, too, but in this case I  
believe this is causing some confusion.

For some folks, this lack of a clear applicability statement means  
that the tcpsecure mechanisms become part of the "must-implement" set  
of TCP. To other folks, the MUST/SHOULD/MAY in the current document  
*are* a kind of applicability statement.

I think it would be helpful if we would tease apart applicability  
statement and technical specification. What were missing is consensus  
on the applicability of the proposed set of mechanisms. During the  
discussion around this document, I've heard basically two choices  
being expressed:

(1) all TCP stacks should implement tcpsecure

(2) only TCP stacks that expect to support a significant number of  
connections for which the described attacks are possible should  
implement tcpsecure

This is important to scope the discussion we're currently having on  
SHOULD vs. MAY.

If the applicability is (1), a SHOULD with its should-have-a-really- 
good-reason-to-ignore semantics is a pretty strong statement that  
affects all stacks.

Whereas if the applicability is (2) or something else that is more  
restricted than (1), a SHOULD is essentially without effect for  
stacks that don't consider themselves to fall under the conditions  
stated.

Lars

PS: Here is the relevant section from RFC2026:

3.1  Technical Specification (TS)

    A Technical Specification is any description of a protocol, service,
    procedure, convention, or format.  It may completely describe all of
    the relevant aspects of its subject, or it may leave one or more
    parameters or options unspecified.  A TS may be completely self-
    contained, or it may incorporate material from other specifications
    by reference to other documents (which might or might not be  
Internet
    Standards).

    A TS shall include a statement of its scope and the general intent
    for its use (domain of applicability).  Thus, a TS that is  
inherently
    specific to a particular context shall contain a statement to that
    effect.  However, a TS does not specify requirements for its use
    within the Internet;  these requirements, which depend on the
    particular context in which the TS is incorporated by different
    system configurations, are defined by an Applicability Statement.

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm