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

Hopefully it is not too late..

The document is good to be shipped but I have some minor comments.
[Text is quotes is cut&pasted from original document which is followed
by comments.]

1  Introduction

"if and only if the Bad Guy already"  can sound better if re-worded to :
"if and only if the attacker"

2  Generation of Initial Sequence Numbers

   "This is
   accomplished by the TIME-WAIT state, and TCP's "quiet time" concept
   (see Appendix B of [RFC1323])."

Actually it is PAWS that is helping discard old segments.

   "We can prevent sequence number guessing attacks by giving each
   connection -- that is, each 4-tuple of (localip, localport, remoteip,
   remoteport) -- a separate sequence number space.  Within each space,
   the initial sequence number is incremented according to [RFC0793];
   however, there is no obvious relationship between the numbering in
   different spaces."

Doing above would increase the attack probability since as the number of
connections (4tuples or 5tuples) increases the vulnerability to attack
increases. It sounds like you are recommending such a scheme esp if
storage isn't an issue, but that is just one aspect.

3.  Proposed Initial Sequence Number (ISN) generation algorithm

"It is vital that F not be computable from the outside,"

Can we chose a better word than " the outside"?  You could say simply
that without a seed, it is useless since if the connection 4 tuple can
be guessed, also port randomization (RFC xxx) helps a bit here since
guessing src port would become difficult. Maybe you can mention that and
refer that as well? 

   "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 hence we consider that
   use of MD5 in the specified algorithm is acceptable."

I am surprised at the above. Are we saying "MD5 is ok" or just saying
"we don't really care". It is an implementation to chose the desired
algorithm. I think we should make this reference a bit generic. Was this
reviewed by the security working groups?

4.  Security Consideration

   "Depending on the ISN generators implemented by each of
   the systems behind the NAT, an attacker might be able to count the
   number of systems behind a NAT by establishing a number of TCP
   connections (using the public address of the NAT) and indentifying
   the number of different sequence number "spaces".
   [I-D.gont-behave-nat-security] discusses how this and other
   information leakages at NATs could be mitigated."

I don't think this is true, it depends on the PRF chosen and the
smartness can be put in there. Also there is going to collisions here
and hence not sure how reliably an attacker can identify the end
systems. With port randomization, this may become difficult as well
(although I haven't really verified that is the case...)

Appendix B
"This document aims at Standards Track (rather than Informaitonal)."

Fix the typo :-)

General question :-  

Middleboxes (TCP proxies) terminate the TCP connection and originate new
ones in the middle, wondering whether the scope of this document should
extend to such devices as well, w.r.t choosing ISN's.? Or you don't
care.?

Thanks,
-Anantha

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf
Of
> SCHARF, Michael
> Sent: Saturday, June 25, 2011 12:28 AM
> To: TCP Maintenance and Minor Extensions WG
> Cc: Fernando Gont
> Subject: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
> 
> Dear all,
> 
> there has only been one response during the WGLC. As a result, we will
> need a small revision of the draft, but no fundamental change.
> 
> If you should have any further comment but somehow missed the
deadline,
> please speak up now. We should move forward this small draft.
> 
> Thanks
> 
> Michael
> 
> 
> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf
Of
> Borman, David
> Sent: Thursday, May 26, 2011 6:35 PM
> To: TCP Maintenance and Minor Extensions WG
> Cc: tsv-ads@tools.ietf.org; Fernando Gont
> Subject: [tcpm] Start of WGLC for draft-ietf-tcpm-rfc1948bis
> 
> 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
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm