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

> Anantha Ramaiah (ananth) wrote:
> > Inline comments....
> ...
> > - Like someone pointed out MAY is a weak statement, it could also 
> > imply "MAY not". Why should it be a MAY when we know that 
> the pros of 
> > the soultion outweigh the cons?
> 
> They do not in all cases. If TCP is deployed either where no 
> well-known connections exist, or where such connections are 
> protected by other authentication, this solution adds
> 	a) complexity

"complexity" and the strength of mitigation cannot be tied together,
IMO.

Almost every solution that tries to add/modify/delete some TCP behaviour
does add complexity to TCP processing.

That said, we have already debated in the past, about the so called
"complexity" of these solutions.

> 	b) chatter during valid RSTs

You mean an extra RTO? Ok, fair enough. But, benefits outweigh
drawbacks, I would think.

> 	c) IPR encumberance

AFAIK, this is not an issue as this was beaten to death before.

> 
> > - to me these recommendations are good to have,
> 
> You're now making decisions for others, i.e., these 
> recommendations are "good for everyone to have unless they 
> have a reason not to". That's not what you said before in 
> terms of "let the user/implementer decide".

"Good to have" since it improves TCP robustness and quality, this is my
viewpoint. This is different from "making decisions for others".

> 
> ...
> >> There's no MUST in that logic, any more than 'you MUST deploy 
> >> IPsec/BTNS/TCP-MD5++'.
> > 
> > I am assuming it is a conditional MUST like "if you need 
> security then 
> > use TCP MD5", correct? Is "conditional MUST = SHOULD" ?
> 
> It is a conditional SHOULD, i.e., a SHOULD with a caveat. 
> From the RFC2119-level, IMO that's a MAY with explanation.

Curious : Are you ok tagging the TCP secure mitigations with a
"conditional SHOULD" or "SHOULD with caveat" or "an applicability
statement with a SHOULD"? I am assuming that these are equivalent to MAY
with explanation? 

-Anantha

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