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

["Anantha Ramaiah \(ananth\)" <[e-mail]>]

Inline comments....

> > Anyways, I don't want to side-track this discussion from 
> it's original 
> > intent viz., "strength of mitigations"
> 
> OK, so let's get back to that. If you believe that it's 
> appropriate to let people decide what mitigations they want 
> to deploy, then why isn't tcpsecure a MAY?


Here is why I think it is SHOULD ( I have already pointed out the
reasons, but will try to more explicit this time.)

- I believe by making it a SHOULD it already lets people chose. Many
implementations have ignored the recommendations tagged as SHOULD and
some of them "knobbed" it for the "good reasons" of their own.

- 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?

- to me these recommendations are good to have, so it falls under SHOULD
since the internet has changed a lot from being what it was 20 years ago
and I believe protocol robustness and quality are good to have and esp.
for a pervasive protocol like TCP. To me "good to have" is a SHOULD. I
agree it is not "MUST have".

> 
> I.e., you MAY deploy it if you want the mitigations.
> 
> 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" ?

> 
> I think we're all agreeing that "let the user decide" is appropriate.
> What we disagree upon appears to be what that implies. 

Yes I think we are all focussed on the RFC language to be used here.

-Anantha

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