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

[<[e-mail]>]

Two things that seem clear from this quite long email thread:

1) many of the people expressing opinions on this are the same ones that
expressed opinions at the meeting in Chicago

2) there is definite lack of agreement on the meaning of SHOULD and MAY
(MUST seems pretty clear).

It almost seems that there is a need for a new level of recommendation
somewhere between SHOULD (which many people seem to take to mean "MUST
unless you have a good reason not to") and MAY (which some people take
to mean "may do if you choose to"). What is lacking (as I think Tim was
driving at) is a word to mean "we advise you to do this but don't want
to obligate you".

Obviously some of this confusion can be reduced if proper applicability
statements are used as described by Lars below.

For what its worth I am torn between options 2) and 3). Option 3) is
correct if the applicability is clearly defined to those TCPs where
there is significant risk of harm from these attacks

Toby
________________________________________________________________________
____
Toby Moncaster, <[e-mail]> Networks Research Centre, BT
Research
B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.  +44 1473
648734 


-----Original Message-----
From: Lars Eggert [mailto:[e-mail]] 
Sent: 25 September 2007 14:54
To: ext Joe Touch
Cc: [e-mail]; [e-mail]
Subject: Re: [tcpm] tcpsecure: how strong to recommend?

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