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

From: "SCHARF, Michael" <[email-masked]>
Date: Sat, 25 Jun 2011 09:27:56 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Borman, David
Sent: Thursday, May 26, 2011 6:35 PM
To: TCP Maintenance and Minor Extensions WG
Cc: [email-masked]; 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

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 26 Jun 2011 03:47:56 -0700

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

> SCHARF, Michael
> Sent: Saturday, June 25, 2011 12:28 AM
> Cc: Fernando Gont
> Subject: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
> 
> Dear all,
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Jun 2011 04:06:58 -0300

Hi, Anantha,

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

> Hopefully it is not too late..

WGLC is over, but this I-D will be IETF LCed, anyway.. so I will try to
address your feedback now (before IETF LC)

> "if and only if the attacker"

This one had already been fixed in response to Wes' feedback.

> Actually it is PAWS that is helping discard old segments.

No. PAWS protects against wrapped SEQs of the same connection. For
instance, there was no requirement that timestamps be monotonically
increasing across connections (RFC 6191 suggests that they should).

> storage isn't an issue, but that is just one aspect.

Not sure what you mean. Could you elaborate a little more?

> that without a seed, 

Not sure what you mean....

> it is useless since if the connection 4 tuple can

I will add a pointer to the port randomization RFC in the security
considerations section.

> "we don't really care". 

We are saying "MD5 is okay for this specific use".

> It is an implementation to chose the desired

MD5 is "suggested", but not required. And no, this I-D was not reviewed
by the security working groups. But the port randomization RFC has,
which was very similar in this respect.

> (although I haven't really verified that is the case...)

It doesn't depend on the PRF. Whatever PRF you use, the result of F()
will be the same for each set of (local socket, remote socket). As a
result, if an implementation increments the global counter/timer by a
fixed value each time a new connection is established/issued (as is the
case of *BSDs), an attacker could potentially learn the number of
connections recently established.

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

Fixed :-)

> extend to such devices as well, w.r.t choosing ISN's.? Or you don't

Two possible pov's for this one:
* Any device that originates or terminates TCP connections must
(implicitly) comply with all TCP requirements.
* We should make this explicit.

-- I personally don't have a strong preference for one over the other...

Thanks!

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

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 27 Jun 2011 00:32:15 -0700

> increasing across connections (RFC 6191 suggests that they should).

Fair enough. You may want to mention this point since it was confusing
at first read. 

> > Doing above would increase the attack probability since as the
number
> of

What I meant is a separate sequence number space for each connection
isn't practical. If there are more number of connections, then the
sequence space shrinks, that makes it more vulnerable.  At first read,
the text appears as though you are acknowledging such a scheme.

> Not sure what you mean....

When you say "outside" I assume you mean an attacker can compute it?
What is the meaning of the word "outside" in this context? 

<snip>

> We are saying "MD5 is okay for this specific use".

Atleast that is not what I understood it to mean. Scope for making an
explicit statement like the above exists to avoid some confusion, IMO.

> MD5 is "suggested", but not required. 

This is unclear in the document. Explicit language would help.

> And no, this I-D was not reviewed

Maybe this would get reviewed by the secdir folks during IESG review.
I'll leave it to them to comment on this aspect..
 
> connections recently established.

Hmm.. the secret sauce is in the PRF, you mention that it is
concatenation of connection ID (which is constant for that particular 4
tuple) but the MD5 key is added which makes it different each time.
Isn't it. The point is that it needs to be greater than the last
sequence number which it would due to the additive property and iff it
doesn't wraparound (which would defeat the acceptance at the other end)

> -- I personally don't have a strong preference for one over the

Well, it wouldn't hurt to make this explicit, but I'll leave it to you
to make that judgement.

-Anantha

<snip>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Jun 2011 04:56:19 -0300

Hi, Anantha,

On 06/27/2011 04:32 AM, Anantha Ramaiah (ananth) wrote:
>>> "This is accomplished by the TIME-WAIT state, and TCP's "quiet
>>> time"
>> concept
>> instance, there was no requirement that timestamps be
>> monotonically increasing across connections (RFC 6191 suggests that
>> they should).
> 
> Fair enough. You may want to mention this point since it was
> confusing at first read.

Ok, I have left this one in the "potential TODO list". -- not sure about
adding text, since a reference *is* provided.

>>> however, there is no obvious relationship between the numbering
[....]
> sequence space shrinks, that makes it more vulnerable.  At first
> read, the text appears as though you are acknowledging such a
> scheme.

No. "Separate sequence number spaces" means that rather than trying to
avoid TCP SEQ reuse on a "global" basis, you only avoid TCP SEQ reuse on
a per-destination-endpoint basis. But the same TCP sequence numbers can
be in use for multiple connections at any given time.

> What is the meaning of the word "outside" in this context?

I mean "any other party that does not know the secret".

>>> "It should be noted that while there have been concerns about
>>> the security properties of MD5 [RFC6151], the algorithm specified
>>> in
>> this
> Atleast that is not what I understood it to mean. Scope for making
> an explicit statement like the above exists to avoid some confusion,
> IMO.

I'm lost. :-) Isn't "...we consider that use of MD5 in the specified
algorithm is acceptable." enough for this purpose?

>>> It is an implementation to chose the desired algorithm. I think
>>> we should make this reference a bit generic. Was
>> this

The only normative text is no the expression, not the hash function.

>>> "Depending on the ISN generators implemented by each of the
>>> systems behind the NAT, an attacker might be able to count
> the
>>> systems. With port randomization, this may become difficult as
>>> well (although I haven't really verified that is the case...)
>> 
>> It doesn't depend on the PRF. Whatever PRF you use, the result of
>> F() will be the same for each set of (local socket, remote socket).
>> As a result, if an implementation increments the global
>> counter/timer by a fixed value each time a new connection is
>> established/issued (as is
> the
> concatenation of connection ID (which is constant for that particular
> 4 tuple) but the MD5 key is added which makes it different each
> time. Isn't it. 

The output of F() is constant for each destination endpoint. See this
example:

Let's say that each time a new connection is issued, the TCP SEQ is
incremented by 64K. And that you establish a new connection, and you see
the ISN "ISN1". If you establish a new connection, and there had not
been any third-party-established connections in-between, for such second
conenction you'd get the ISN "ISN1+64K". However, if *one* connection
has been established in-between, you'd get the ISN "ISN+128K". If two
connections has been established in-between, you'd get the ISN
"ISN1+3*64K", etc... See?

The concept is similar to the "idle scan" that leverages the IPv4
Identification field.

Thanks!

Best regards,

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 27 Jun 2011 08:09:10 -0700

> I mean "any other party that does not know the secret".

I think making such a clarification helps readability. 

> algorithm is acceptable." enough for this purpose?

I read Wes's comment and your response. Since you are going to
incorporate Wes's suggestion, it should cover my queries as well. Same
holds good for the comment on the security considerations section.

> The concept is similar to the "idle scan" that leverages the IPv4

Well, my point was that you don't require a constant multiplier (1,2,3
etc.,) as in the above example. You could chose something different (the
entropy could be in the built in to the hash function). It just need to
be increasing that's all.  Coming to the original point, NAT case
wouldn't be an issue if we chose the sequence number accordingly.

-Anantha