Subject: Re: [tcpm] Start of WGLC for draft-ietf-tcpm-rfc1948bis

From: Wesley Eddy <[email-masked]>
Date: Wed, 08 Jun 2011 01:17:39 -0400

On 5/26/2011 12:34 PM, Borman, David wrote:
> The author of draft-ietf-tcpm-rfc1948bis believes that the document is ready for Working Group Last Call.  It has been a month since there was anything new on the mailing list with regards to draft-ietf-tcpm-rfc1948bis.
>
> We are starting the WGLC for this document, to end on Friday, June 10.  Please send any comments on the document to the mailing list and the author before that time.
>
> 			-David Borman&  Michael Scharf, TCPM WG co-chairs
>

This is a combined AD review / WGLC response from me.  I think it
would be a good idea to treat it as any other WGLC response.

Overall, I think another revision is probably required to be ready
to move forward, but the needed changes should be fairly simple.

Technical and Content:

- The first sentence of the Introduction mentions "During the last
   25 years", rather than whatever start-date it's trying to imply; it
   can probably be less specific, and just be "Since its inception,"?

- The last sentence of the first paragraph in the Introduction should
   probably refer to the sides of the TCP connection between two known
   ports, rather than the vague wording

- Section 2, 3rd to last paragraph, suggest rewording:
   "Simple randomization of the TCP ..." to:
   "Simple random selection of TCP ..."
   (randomization can mean something completely different)

- Section 2, last paragraph, "The obvious" is really "An obvious", and
   the downside should refer to memory rather than storage space, maybe?
   I'm also not sure it's fair to say this is inelegant; that may be in
   the eye of the beholder.  The end of this paragraph should hint at
   what the benefit of the advocated approach is compared to altering the
   state diagram.

- Section 3 should be specific about the four arguments shown to the PRF
   can really just be one binary string that represents the connection ID
   tuple, and not necessarily 4 distinct arguments with an order that
   matters semantically?

- "and the boot time of the machine, *for instance*" (other things would
   also work, and this document doesn't need to get into then specifying
   how to represent the boot time in binary, etc.)  The next sentence
   then should just stress that it's useful for the secret to change on
   occasion, and that the boot time potentially meets this property.
   However, it would really be best to indicate more clear guidance on
   how frequently this needs to change, how many bits of strength it
   needs, etc.  Some machines rarely reboot, for instance, so do they
   need to use something else?

- is the 2nd to last paragraph of section 3 something that requires
   MUST or SHOULD wording?  I think so.

- some rationale is missing from the last paragraph of section 3 for
   MD5.  I believe you have to indicate why it might be preferable to
   someone (e.g. it's faster than stronger alternatives, or it's what
   the running code is already using, etc.).  I believe if there's
   more rationale people will still have a problem with it, but without
   rationale it's guaranteed to be completely held up over this.

Editorial:

- Need to be consistent throughout about using "ISN" abbreviated after
   it's already been spelled out.  I noticed this in section 3, first
   paragraph, which uses the full form even though the abbreviation was
   formerly in-use, and the title of section 3 also defines it, which
   doesn't seem needed

- in Abstract: "attacker of guessing" -> "attacker guessing" ?

- same as previous comment, but for Introduction, 2nd paragraph also

- abstract should mention not just that this is a revision of 1948, but
   that it Obsoletes it.

- same as previous comment, but for Introduction also

- can "Bad Guy" be "attacker" or something more consistent in Section 1?

- can section 1, paragraph 2 elaborate in 1 sentence or so about the
   "devastating attacks" that would have to be possible?

- in section 2, paragraph 3, "systems establishes" ->
   "system establishes"

-- 
Wes Eddy
MTI Systems

---

From: Fernando Gont <[email-masked]>
Date: Sat, 25 Jun 2011 10:55:55 -0300

Hi, Wes,

Thanks so much for your detailed feedback. Please find my comments
inline....

>   can probably be less specific, and just be "Since its inception,"?

I have changed the text to "For a long time..."

>   ports, rather than the vague wording

Changed to "...will use for new connections between two known end-points."

>   what the benefit of the advocated approach is compared to altering the

I've changed the text to:
---- cut here ----
An obvious way to prevent sequence number guessing attacks while not
breaking the 4.4BSD heuristics would be to maintain state for dead
connections, and the easiest way to do that would be to change the TCP
state transition diagram so that both end-points of all connections go
to TIME-WAIT state. That would work, but would consume system memory to
store the additional state. Instead, we propose an improvement to the
TCP ISN generation algorithm, that does not require TCP to keep state
for all recently-terminated connections.
---- cut here ----

>   tuple, and not necessarily 4 distinct arguments with an order that

Yes. For instance, it is very likely that an implementation may want to
concatenate the {src IP, src port, dst ip, dst port}. Should we change
something here?

>   need to use something else?

I've changed the discussion of the secret key to:

---- cut here ----
   The result of F() is no more secure than the the secret key.  If an
   attacker is aware of which cryptographic hash function is being used
   by the victim (which we should expect), and the attacker can obtain
   enough material (i.e., ISNs selected by the victim), the attacker may
   simply search the entire secret-key space to find matches.  To
   protect against this, the secret key should be of a reasonable
   length.  Key lengths of 128 bits should be adequate.  The secret key
   can either be a true random number [RFC4086], or some per-host
   secret.  A possible mechanism for protecting the secret key would be
   to change it on occasion.  For example, the secret key could be
   changed whenever one of the following events occur:

   o  The system is being bootstrapped (e.g., the secret key could be a
      combination of some secret and the boot time of the machine).

   o  Some predefined/random time has expired.

   o  The secret key has been used sufficiently often that it should be
      regarded as insecure now.

   Note that changing the secret would change the ISN space used for
   reincarnated connections, and thus could lead to the 4.4BSD
   heuristics to fail; to maintain safety, either dead connection state
   could be kept or a quiet time observed for two maximum segment
   lifetimes before such a change.

   It should be noted that while there have been concerns about the
   security properties of MD5 [RFC6151], the algorithm specified in this
   document simply aims at reducing the chances of an off-path attacker
   of guessing the ISN of a new connection, and thus in our threat model
   it is not worth the effort for an attacker to try to learn the secret
   key.  Since MD5 is faster than other "stronger" alternatives, and is
   used in virtually all existing implementations of this algorithm, we
   consider that use of MD5 in the specified algorithm is acceptable.
---- cut here ----

>   MUST or SHOULD wording?  I think so.

See the change above. I'd personally not incorporate RFC2119 for this
(if we were really concerned about this type of attack, we wouldn't be
using MD5 in the first place). But please yell if you feel strongly
about this.

>   rationale it's guaranteed to be completely held up over this.

Please see above.

>   formerly in-use, and the title of section 3 also defines it, which

I've changed the text such that "ISN" (instead of its expanded form) is
used throughout the document (except for the titles, where the expanded
form is used instead).

> - same as previous comment, but for Introduction, 2nd paragraph also

Fixed!

> - same as previous comment, but for Introduction also

Both instances now read "This document revises (and formally obsoletes)
RFC 1948, and takes the ISN generation algorithm originally proposed in
that document to Standards Track.".

> - can "Bad Guy" be "attacker" or something more consistent in Section 1?

Changed. :-)

>   "devastating attacks" that would have to be possible?

I've changed the text to: "...such attacks would remain possible if and
only if the attacker already had the ability to perform a "man in the
middle" attacks."

Thanks!

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

---

From: Wesley Eddy <[email-masked]>
Date: Sat, 25 Jun 2011 15:46:59 -0400

Hi Fernando, everything looks good to me, except for one possible
further tweak, and an answer to a question you asked:

> concatenate the {src IP, src port, dst ip, dst port}. Should we change

It's not a big deal to me, and fine to leave as-is if nobody else has an
opinion on it.

>     consider that use of MD5 in the specified algorithm is acceptable.

I would perhaps append to the end something like:
"However, implementations should consider the trade-offs involved in
using functions with stronger security properties, and employ them
if it is deemed reasonable."

-- 
Wes Eddy
MTI Systems

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Jun 2011 07:48:00 -0300

Hi, Wes,

On 06/25/2011 04:46 PM, Wesley Eddy wrote:
[....]
>> I've changed the discussion of the secret key to:
[....]
> if it is deemed reasonable."

Should I s/reasonable/appropriate/?

BTW, I have just seen your response (my fault -- I was migrating e-mail
from one computer to another), and thus published a rev a couple of
hours ago.

I have incorporated this note in my working copy of the document, though.

I will wait for a couple of days to see if anybody has anything else to
add/comment, and will publish a rev of the doc on, say, next Wednesday
(so that we can ship it).

Thanks!

Best regards,

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 27 Jun 2011 12:13:43 -0400

> Should I s/reasonable/appropriate/?

That would be fine with me.

-- 
Wes Eddy
MTI Systems