Re: [tcpm] tcpsecure recommendations

I think the applicability statement is a great addition.  I'm in favor  
of (3), SHOULD/SHOULD/MAY.
			-David Borman

On Feb 6, 2008, at 11:40 AM, Mark Allman wrote:

>
> Folks-
>
> It'd be good to get some opinions on the new tcpsecure version and get
> it finished.  The sticking point on this document is how strongly to
> recommend TCP stacks implement / use the three mitigations in the  
> draft
> (to spoofed RSTs, SYNs and data segments).  We had a discussion about
> this in Chicago and also on the list.  Since it seemed that we were  
> not
> converging because there was not WG-wide agreement on the scope of the
> document we asked the authors to generate an applicability statement.
> They did that, per a previous email from Anantha.  The AS reads:
>
>    The mitigations presented in this document talks about some known
>    in-window attacks and the solutions to the same. The mitigations
>    suggested in this draft SHOULD (RECOMMENDED) be implemented in
>    devices where the TCP connections are most vulnerable to the  
> attacks
>    described in this document.  Some examples of such TCP connections
>    are the ones that tend to be long-lived where the connection end
>    points can be determined, in cases where no auxiliary anti-spoofing
>    protection mechanisms like TCP MD5 can be deployed. TCP secure MAY
>    (OPTIONAL) be implemented in other cases.
>
> We can recommend each of mitigations with a MAY, SHOULD or MUST.  In
> Chicago we winnowed the proposals to three three:
>
>    (1) RST spoofing mitigation: MAY
>        SYN spoofing mitigation: MAY
>        data injection mitigation: MAY
>
>    (2) RST spoofing mitigation: SHOULD
>        SYN spoofing mitigation: SHOULD
>        data injection mitigation: SHOULD
>
>    (3) RST spoofing mitigation: SHOULD
>        SYN spoofing mitigation: SHOULD
>        data injection mitigation: MAY
>
> Nobody has advocated for other permutations of recommendations
> (although, clearly if people like some different combination they  
> should
> advocate away!).
>
> Can folks please weigh in on their feeling about how strongly we  
> should
> recommend these mitigations given the AS above?  It'd be great to get
> this document moving and we're sort of stuck here.
>
> Thanks,
> allman
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> http://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
http://www.ietf.org/mailman/listinfo/tcpm