Subject: Re: [tcpm] RE: TCP secure

From: Alfred Hönes <[email-masked]>
Date: Fri, 11 Jan 2008 03:08:10 +0100 (MEZ)

Hello all,
I generally agree with the recent changes performed for
   draft-ietf-tcpm-tcpsecure-09,

yet in the newly added AS (Section 1.1),
the language should be improved based on the rationale below.

a) "The mitigations presented in" and "talks about" almost mean
   the same, but even worse, combined in the first line, the
   sentence does not parse.  Because "The mitigations" re-occurs
   in the next line, I suggest to drop the first occurrence.

b) "Solutions to .. [attacks]" does not seem to be very meaningful.
   I therefore also suggest to replace "the solutions to the same"
   by "suitable defenses against these".  Hopefully, this will
   increase the clarity, and add to the readability of the text.

c) "... devices where the TCP connections are most vulnerable ..."
   pretends to not admit the co-existence with less vulnerable
   TCP connections and the temporal variation over all the story.
   I suggest to talk about "... devices that regularly have to
   maintain TCP connections of the kind most vulnerable ...".

d) I also suggest to delete the subsequent "Some", because the
   following explanation only details *one* specific kind of TCP
   connections particularly vulnerable.

e) In the middle of the original paragraph, I suggest adding an "and"
   to make the syntax and semantics of the sentence unambiguous.

Taking that into account, I recommend changing:

OLD:

|  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 be implemented in devices where the
                  vvvvv                                    ^^^^^^^^^^
   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 [RFC2385] can be deployed.  These mitigations
   MAY be implemented in other cases.

NEW:

|  This document talks about some known in-window attacks and suitable
|  defenses against these.  The mitigations suggested in this draft
|  SHOULD be implemented in devices that regularly need to maintain TCP
|  connections of the kind most vulnerable to the attacks described in
|  this document.  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.  These mitigations
   MAY be implemented in other cases.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 10 Jan 2008 19:29:31 -0800

The references continue to be out of date.

1. antispoof has been an RFC (4953) since July.

2. TCP-MD5 has a replacement (TCP-AO) that was discussed in Nov in 
Vancouver; that I-D should be noted, esp. where TCP-MD5 is discussed as 
an alternate solution.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 10 Jan 2008 22:54:51 -0800

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Thursday, January 10, 2008 7:30 PM
> To: Alfred ?
> Cc: Anantha Ramaiah (ananth); Randall Stewart (rrs); Mitesh 
> Dalal (mdalal); [email-masked]
> Subject: Re: [tcpm] RE: TCP secure
> 

Point taken, this can be done during the next revision whenever that is.

> 
> 2. TCP-MD5 has a replacement (TCP-AO) that was discussed in 
> Nov in Vancouver; that I-D should be noted, esp. where 
> TCP-MD5 is discussed as an alternate solution.

TCP secure just mentions TCP MD5 as an example of an already deployed
existing security mechanism. There may be many ways available to protect
TCP connections and it is NOT the purpose or motivation of TCP secure to
list all of them. If the "antispoof" draft was still in the works I
would have suggested to list AO in it.

But if the workgroup strongly feels that TCP secure should make a note
of AO, I am willing to add it, but at the moment I stand unconvinced.

-Anantha