Re: [secdir] draft-ietf-tcpm-tcpsecure

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

Hi Nico,

There was a big thread that went in TCPM some time back on this.
Initially the mitigations were tagged as "if you implement TCP secure
then all these are a MUST", such a statement gave a leeway for
implementers to chose whether or not they want to implement tcp-secure.
But some folks felt that since TCP secure has an IPR on it should
probably not have MUST in them at all, another argument was since TCP
secure is mostly useful only for long lived connections (like BGP), then
it may not be applicable to hosts and only applicable to routers. I
didn't (so as many others) didn't buy this argument, but since it was
not going anywhere Lars stepped up with the suggestion of applicability
statement to be added to this draft (I haven't seen any other TCP
related RFC which has an AS in it, FWIW) and the rest is history. I
seriously doubt whether the chairs/Lars/WG would like to fallback to
MUST/MUST/SHOULD.

In practice I have been given to understand that some vendors have
implemented these mitigations. Andre wanted to put these mitigations in
BSD as well, not sure about the current status. So, I am guessing if
folks are interested in adding robustness to their stacks in general and
TCP in particular, they would probably be interested in implementing
these mitigations.

Let me know if you need some text that needs to be added in the current
draft like for example add the reasoning why these mitigations are
chosen like this i.e, expand section 6 a little bit.

As far as the SYN corner case workaround we chose not to talk about the
fix for the same in the draft since the corner case exists in RFC 793
and nothing to do with the current SYN mitigation.

-Anantha

> -----Original Message-----
> From: Nicolas Williams [mailto:[e-mail]] 
> Sent: Friday, August 14, 2009 3:12 PM
> To: Sandra Murphy
> Cc: Anantha Ramaiah (ananth); Mitesh Dalal (mdalal); 
> [e-mail]; [e-mail]
> Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
> 
> The mitigations in this I-D are made SHOULD, SHOULD, and MAY 
> (see section 6, page 15).  But that means that a TCP 
> implementation could claim conformance while not implementing 
> any of these mitigations.
> Therefore they should be, IMO, MUST, MUST and MAY (or SHOULD).
> 
> Also, ISTM that the corner case described in section 4.2 can 
> be avoided by noting the retransmitted SYN and then sending a 
> SYN+ACK to that, and if an acknowledgement comes back then 
> reset the old connection (and if there's no listener to 
> accept the new one, then reset it too).
> 
> Nico
> -- 
>