Subject: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt

From: David Borman <[email-masked]>
Date: Thu, 21 Aug 2008 12:40:43 -0500

Wes and I would like to start the WG Last Call for:

  Title           : Improving TCP's Robustness to Blind In-Window  
Attacks'
  Author(s)       : A. Ramaiah, R. Stewart & M. Dalal
  Filename        : draft-ietf-tcpm-tcpsecure-10.txt
  Pages           : 27
  Date            : July 9, 2008
  Intended Status : Proposed Standard

http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt

It is our understanding that all the feedback has been incorporated  
into this latest version and that there are no known outstanding  
issues with this document.

Please send feedback to the list, even if it is just a "yes, go ahead  
and publish".

The WGLC will end on Friday, September 5, 2009.

		David Borman & Wes Eddy, TCPM WG co-chairs

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Aug 2008 14:03:26 -0700

Hi, all,

Some final suggestions:

- --- I believe this document should include an informational reference to
IPsec and TCP-AO in the applicability statement:

   ...Examples of such TCP connections are the ones that
   tend to be long-lived and where the connection end points can be
   determined, in cases where no auxiliary anti-spoofing protection
   mechanisms like TCP MD5 [RFC2385] can be deployed.
                                    ^TCP-AO [I-D...], or IPsec [RFC4301]

- --- concerns with changing TCP behavior should be noted in the
applicability statement, in particular:

   These mitigations
   MAY be implemented in other cases.

, with consideration for the potential implications noted in Section 10.

- --- RFC4953 should be cited as a detailed explanation

"The feasibility of
 this methodology (without mitigations) was first shown in [SITW]."
, and is explained in detail in [RFC4953].

(retain the subsequent reference to 4953's discussion of probabilities)

- ---- section 1.3 can be omitted, as 4953 covers this issue in detail
already, as explained already in section 1.2

If retained, then add TCP-AO and IPsec to TCP MD5 as providing
protection in:

   For applications that can use the TCP MD5 option [RFC2385], such as
   BGP, that option makes the attacks described in this specification
   effectively impossible.

If retained, please omit "draft" from the following:

   For further details regarding the attacks and
   the existing techniques, please refer to draft [RFC4953]

- -- section 10 should similarly refer to TCP-MD5 and TCP-AO where it
refers to IPsec as providing complete protection,

   The only way to fully protect a TCP connection from both on and off
   path attacks is by using either IPSEC-AH [RFC4302] or IPSEC-ESP
   [RFC4303].

IMO, it would be useful to be consistent here, and thus say:
	IPsec [RFC4301], TCP MD5 [RFC...], or TCP-AO [I-D...]

- --- Section 6 should include the context of the recommendation level of
the whole document, e.g.:

   As described in the above sections, recommendation levels for RST,
   SYN and Data are tagged as SHOULD, SHOULD and MAY respectively.

All of the mitigations are subject to the overall recommendations as
indicated in the applicability statement in section Z, notably SHOULD
use where TCP is vulnerable to off-path attacks and is not otherwise
protected, and MAY elsewhere.

Joe

David Borman wrote:
>  Title           : Improving TCP's Robustness to Blind In-Window Attacks'
> It is our understanding that all the feedback has been incorporated into
> this latest version and that there are no known outstanding issues with
> this document.
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Aug 2008 18:54:59 -0300

>Please send feedback to the list, even if it is just a "yes, go ahead

It had been raised by Joe already that the draft should include a 
reference to the port randomization draft: 
http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-randomization-01.txt 
. Considering the type of attacks the tcpsecure draft aims to 
mitigate, it is clear that port randomization should be taken into 
account. And given that this is a TSVWG WG item, I think tcpsecure 
should mention port randomization, and include a reference to the 
port randomization draft.

Thanks!

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Aug 2008 15:28:23 -0700

Yes - thanks for catching that Fernando!

Joe

Fernando Gont wrote:
> . Considering the type of attacks the tcpsecure draft aims to mitigate,
> it is clear that port randomization should be taken into account. And
> given that this is a TSVWG WG item, I think tcpsecure should mention
> port randomization, and include a reference to the port randomization
> draft.
> 
> Thanks!
> 
> Kind regards,
> 
> -- 
> Fernando Gont

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 28 Aug 2008 16:55:12 -0700

Fernando,
   It was mentioned earlier that a reference in the security
consideration section to ICMP attacks draft is needed. This was done in
the latest version (ver 10). I am not sure about the port randomization
though, but I can add it if the WG feels so.

   IMO, all the recent TCP connection robustness related drafts (port
randomization, ICMP attacks etc.,) should have a reference to TCP secure
since most of these drafts were inspired by TCP secure!

-Anantha 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Fernando Gont
> Sent: Thursday, August 28, 2008 2:55 PM
> To: David Borman; [email-masked]
> Cc: [email-masked]; Mitesh Dalal (mdalal); Anantha Ramaiah 
> (ananth); Joe Touch
> Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt
> 
> >into this latest version and that there are no known 
> outstanding issues 
> >with this document.
> >
> It had been raised by Joe already that the draft should 
> include a reference to the port randomization draft: 
> mitigate, it is clear that port randomization should be taken 
> into account. And given that this is a TSVWG WG item, I think 
> tcpsecure should mention port randomization, and include a 
> reference to the port randomization draft.
> 
> Thanks!
> 
> Kind regards,
> 
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked] PGP 
> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 Aug 2008 16:44:21 -0300

>though, but I can add it if the WG feels so.

The whole debate of RST attacks had to do with Paul Watson coming to 
the conclusion that these attacks were much more feasible than 
previously assumed (e.g., by some presentation that had been made at NANOG).

Paul's presentation assumed a global and linear ephemeral-port 
selection function. IMO, the most obvious and trivial way to mitigate 
these blind attacks is to randomize the ephemeral port numbers.

And this is even more so when there's a BCP-candidate document that 
has been adopted by a related WG.

>since most of these drafts were inspired by TCP secure!

I don't quite understand this comment. My motivation for suggesting 
references to these documents are:

* It does not make sense to address the most difficult attack vector 
for reset attacks if you leave a much more trivial one open (that's 
the reason for the reference to the ICMP attacks draft).
* tcpsecure aims at mitigating blind in-window attacks. With an 
incremental ephemeral-port selection function, these attacks are not 
as "blind" as they "should" be. If you randomize ephemeral-ports, 
then the attack will require many more packets. (this is the reason 
for the reference to the port randomization draft).

That said, the ICMP attack draft does reference tcpsecure. However, 
it was inspired by the discussions we had while writing the "Security 
Considerations" section of the soft errors draft. The non-wg -00 
version of the port randomization I-D was written by M. Larsen... so 
I have no idea what inspired him to write that document. Maybe 
tcpsecure, maybe Paul Watson's presentation.... maybe he had already 
been working on that.

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Aug 2008 14:38:44 -0700

>> randomization, ICMP attacks etc.,) should have a reference to TCP
>> secure since most of these drafts were inspired by TCP secure!

Above Ananth is claiming that the recent burst of activity in this space
is due to his draft, though Watson (CanSec West, March 2004) is the
origin of the RST issue in public forums (tcpsecure-00 wasn't out until
April 2004).

Other solutions in this space were Larsen's port-randomisation-00 in
June 2004 (later Larsen and Gont), and Poon's timestamp-00 also in June
2004, though port-randomisation closely parallels Bellovin's ISN
randomization in RFC1948 from 1996. (and port randomization may have
been deployed before 2004 - does anyone recall?)

However, I would be glad to credit Ananth with the large number of
'attacks' on Postel's RFC793 design principle, "be liberal in what you
accept from others" from 1981. ;-)

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 Aug 2008 18:46:04 -0300

>origin of the RST issue in public forums (tcpsecure-00 wasn't out until

Exactly.

>randomization in RFC1948 from 1996.

Yes. And Larsen's port-randomisation-00 acknowledges this (and our 
tsvwg-port-randomization draft keeps the ack to Bellovin).

>(and port randomization may have

Yes. It has. At least OpenBSD has shipped with port randomization way 
before 2004.

Kind regards,