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

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

> As a way forward, the following captures the 
> SHOULD/SHOULD/MAY which was
>  most supported in Chicago:
> 
> --------------------------------------------------------------
> -------------
> 
> tcpsecure SHOULD be implemented in TCP stacks supporting router.
> Notable exceptions include deployments where routers are known to use
> other antispoofing protection, e.g., IPsec, TCP/MD5 and its 
> successors.
> 
> tcpsecure MAY be implemented in other TCP stacks.
> 
> ----


> within tcpsecure:
> 
> RST protection MUST be supported
> 
> SYN protection MUST be supported
> 
> data segment (i.e., non-RST, non-SYN) protection MAY be supported
> 
> -------------------------------------------

I think you got it wrong. 

Most supported in Chicago was about [SHOULD/SHOULD/MAY] WITHOUT the
applicability statement in place. It was "STANDALONE" question raised by
the chairs for which the consensus seemed to be in favour of S/S/M.  Now
WITH the applicability statement in place, it completely changes the
entire equation. To quote Mark's email :

BEGIN QUOTE
> It seems to me that this discussion is really divergent because there
> is no applicability statement in the document, per Lars' comment.  I
> wonder if you guys could go off and generate such a statement and 
> then we could re-visit this question.  I think that would factor
things
> into a question of "where" this is applicable and then how strongly we
> want to advocate these mitigations within that context.  Is that
> reasonable?
END QUOTE

So, the game plan moving forward is, to generate the AS and revisit the
mitigation strengths. Also, just in case you missed, some of responses
in this list have indicated no issues with "MUST'ing" all the
mitigations provided there is a proper applicability statement in place.

-Anantha


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