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

> The whole discussion becomes relevant only if we are really updating
> rfc793, so as long as you see these changes as standalone, the question
> of SHOULD/MUST/MAY  become self explanatory in the right context. 
> 
> So, in that sense I propose the changes as MUST. If an implementation
> claims
> compliance with these changes, than this (MUST) is the way it has to be
> implemented.

I think we've lost something important with MAY/SHOULD/MUST stuff.

Recall Lars Eggert's pointing out the need for an applicability
statement (in general and in particular).

It seems the mitigations described in this draft should be implemented
in any TCP which is going to be used for things which use TCP in such
a way that they will be vulnerable (where the IP addresses of both
ends and the port number of one end are knowable by an attacker) *or*
something else could be done to reduce vulnerability to such an
attack.

But its not completely clear to me that here we are trying to define a
protocol, the sort of thing which needs things like MAY/SHOULD/MUST to
ensure that interoperability goals will be met.

A somewhat serious security problem was discovered some time ago.
This draft documents one vendor's approach to solving this problem.
There are other ways of solving this problem.  It's not clear that a
standard is needed here to ensure interoperability of systems.

What is our goal here with this document?

Can the English word "should" be used in an RFC (without making it uppercase)?

I'd be happy publishing this document as informational and not
sweating the MAY/SHOULD/MUST stuff.  Just make them lowercase and make
the text make sense.

How's BTNS coming along?   Will we be seeing BGP over BTNS anytime soon?
(I've not been following BTNS too closely recently).

			-Tim Shepard
			 shep@alum.mit.edu

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm