Re: [tcpm] tcpsecure recommendations

I think it would be help if folks can also narrate the reason for
chosing a particular permutation.

My few cents,

-Anantha 

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> Behalf Of David Borman
> Sent: Wednesday, February 06, 2008 10:42 AM
> To: mallman@icir.org
> Cc: tcpm@ietf.org
> Subject: 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
> 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
http://www.ietf.org/mailman/listinfo/tcpm