From rs@netapp.com  Wed Jun  1 04:34:15 2011
Return-Path: <rs@netapp.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F305AE0692 for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 04:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.394
X-Spam-Level: 
X-Spam-Status: No, score=-9.394 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaZ7mQAmcc-I for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 04:34:13 -0700 (PDT)
Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by ietfa.amsl.com (Postfix) with ESMTP id D27A5E0670 for <tcpm@ietf.org>; Wed,  1 Jun 2011 04:34:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,303,1304319600"; d="scan'208";a="251214477"
Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 01 Jun 2011 04:34:11 -0700
Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p51BYAHK028724; Wed, 1 Jun 2011 04:34:10 -0700 (PDT)
Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 1 Jun 2011 12:34:10 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 1 Jun 2011 12:33:27 +0100
Message-ID: <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <4DE57E52.5030501@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] feedback from group to	draft-scheffenegger-tcpm-timestamp-negotiation-02.txt
Thread-Index: Acwf7VUxsmeLzjmjS1y0wqEeJVqvYQAUT94g
References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu>
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "Joe Touch" <touch@isi.edu>
X-OriginalArrivalTime: 01 Jun 2011 11:34:10.0404 (UTC) FILETIME=[D3284A40:01CC204F]
Cc: tcpm@ietf.org, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] feedback from group to	draft-scheffenegger-tcpm-timestamp-negotiation-02.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2011 11:34:15 -0000

Hi Joe,

>=20
> > If the receiver determines that a sender compliant to this draft is
> > negotiating, the<SYN,ACK>  TSecr is set to (<SYN>  TSval) XOR
> (receiver
> > TS capabilities).
>=20
> How do you know whether it's a sender compliant to the draft
> negotiating, vs. a noncompliant RFC1323 host?


There are three aspects to this:

a) The receiver may think a higher version sender is trying to
negotiate.
Assuming a non-compliant RFC1323 sender has the <SYN> TSecr bits set in
a random way, the chances for this are EXO=3D1 (50%) * VER=3D[1..3] =
(75%),
so ~37.5%.=20

The receiver may only run the PAWS check on TSval during the session
(perhaps using a partial TSval, as MASK also contains random bits).

If SACK is negotiated too, the sender may be coaxed into too aggressive
RTTM / RTO calculation. However, the effect of this would be a reduced
throughput (and reduced goodput) for that session, due to the frequence
congestion control reaction after a spurious RTO by the sender.


b) The receiver may coaxed into enabling local algorithms exceeding PAWS
(ie. OWD variance). This is more problematic, as the receiver (or
passive sender) may use TSval as input signal into congestion control or
loss recovery.=20

To reduce the chances of this happening, the RES bits field MUST be set
to zero by a compliant sender.

The likelihood that a misbehaving sender sends these fields to
EXO=3D1, VER=3D00b, RES=3D00000000b, by random chance is about 2^-11...

Bob pointed out, that the behavior of such misbehaving hosts would need
to be investigated. My understanding is, that the misbehavior was due to
not initializing the TS.recent value in tcpcb correctly, so a random
memory content, likely to be word-aligned, used to be visible.

Perhaps Fernando Gont has a pointer to the source of that section in his
tcp security draft, which stacks exhibited the issue... (I believe it
was with rather old stacks).

What I found is this hint
http://kerneltrap.org/mailarchive/linux-netdev/2009/4/10/5446374 - as a
TSval of a previous session is reused, that should come close enough to
random scambled bits...



c) Some older versions of Windows (95?) will not reflect TSval sent to
them in a <SYN> in the TSecr of the <SYN,ACK>. It is unclear however, if
TSecr is also not cleared (and contains some random content). If a
compliant sender sends TS capabilities (and TSval) in the initial <SYN>,
there is also the chance (again 2^-11), that the value of TSecr in the
<SYN,ACK> decodes by chance to a valid VER=3D00b capability. However, if
TSecr from such a receiver is known to be zero (in case of windows
xp..2003), an appropriate TS.offset can be selected by the sender, that
decoding would result in one of the 9 bits (EXO, RES) to be set invalid
for TS capability negotiation.

(I will include that scenario in the next revision of the draft. Just
learned about this from
http://www.itsec.gov.cn/webportal/download/2003-Ambiguity%20Resolution%2
0via%20Passive%20OS%20Fingerprinting.pdf, and
http://www.eggheadcafe.com/microsoft/Windows-Server-Networking/30891786/
windows-tcp-timestamp-not-compliant-to-rfc-1323-.aspx
while searching for the TSecr on <SYN> issue...
=20
=20


>=20
> If the only example you have for using these bits is something you
> discourage, perhaps it's worth omitting it. ;-)

Yes; I only wanted to mention here on-list, that the scheme is still
compatible with RTT sampling during 3WHS, and only very minimal state
has to be kept to decode retransmitted SYNs...

Best regards,
   Richard
=20

From touch@isi.edu  Wed Jun  1 09:21:01 2011
Return-Path: <touch@isi.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1C1E07A9 for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 09:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.765
X-Spam-Level: 
X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWD-oiE55THG for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 09:21:00 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id D7EB5E05D3 for <tcpm@ietf.org>; Wed,  1 Jun 2011 09:21:00 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p51GKhIw018531 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2011 09:20:44 -0700 (PDT)
Message-ID: <4DE666DB.3010109@isi.edu>
Date: Wed, 01 Jun 2011 09:20:43 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: p51GKhIw018531
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] feedback from group to	draft-scheffenegger-tcpm-timestamp-negotiation-02.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2011 16:21:01 -0000

Hi, Richard,

On 6/1/2011 4:33 AM, Scheffenegger, Richard wrote:
>
> Hi Joe,
>
>>
>>> If the receiver determines that a sender compliant to this draft is
>>> negotiating, the<SYN,ACK>   TSecr is set to (<SYN>   TSval) XOR
>> (receiver
>>> TS capabilities).
>>
>> How do you know whether it's a sender compliant to the draft
>> negotiating, vs. a noncompliant RFC1323 host?
>
>
> There are three aspects to this:
>
> a) The receiver may think a higher version sender is trying to
> negotiate.
> Assuming a non-compliant RFC1323 sender has the<SYN>  TSecr bits set in
> a random way, the chances for this are EXO=1 (50%) * VER=[1..3] (75%),
> so ~37.5%.

I find this kind of analysis unconvincing; these aren't bits generated 
by a PRNG. A given host will either set some of these bits with 100% 
probability on a given date (or what it thinks is that date) or not. 
They're definitely *not* independent or random. Sure, the above would 
happen for sure 1/23/2055 at 10:02pm GMT or so for hosts using 
reasonably valid clocks - or before, for those that (correctly or not) 
pick times near this as their timestamp.

IMO, the overall analysis needs to take that into account.

> b) The receiver may coaxed into enabling local algorithms exceeding PAWS
> (ie. OWD variance). This is more problematic, as the receiver (or
> passive sender) may use TSval as input signal into congestion control or
> loss recovery.
>
> To reduce the chances of this happening, the RES bits field MUST be set
> to zero by a compliant sender.
>
> The likelihood that a misbehaving sender sends these fields to
> EXO=1, VER=00b, RES=00000000b, by random chance is about 2^-11...

Again, random chance isn't the problem. This particular problem *will* 
occur on 1/19/2038 at 3:14am GMT, for hosts using reasonably valid clocks.

Sure, these dates are far into the future. But we have NO idea:
	a) how long these changes will be in use
	b) whether someone will decide to 'randomize' the dates
	for some (false) sense of security (no, please - don't!)

I.e., you're playing with a space that has no requirements. There is no 
absolute that "TCP must use date stamps that are reasonably accurate to 
the current date/time". Any such assumption is asking for trouble, IMO.

Joe


From rs@netapp.com  Wed Jun  1 13:03:36 2011
Return-Path: <rs@netapp.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BE3E0833 for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 13:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.395
X-Spam-Level: 
X-Spam-Status: No, score=-9.395 tagged_above=-999 required=5 tests=[AWL=0.004,  BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdYWuVZ70GYO for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 13:03:35 -0700 (PDT)
Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by ietfa.amsl.com (Postfix) with ESMTP id C8DB0E0843 for <tcpm@ietf.org>; Wed,  1 Jun 2011 13:02:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,305,1304319600"; d="scan'208";a="251248247"
Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 01 Jun 2011 13:02:52 -0700
Received: from ldcrsexc2-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p51K2pl7022753; Wed, 1 Jun 2011 13:02:51 -0700 (PDT)
Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 1 Jun 2011 21:02:51 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 1 Jun 2011 21:02:07 +0100
Message-ID: <5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <4DE666DB.3010109@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] feedback from group to	draft-scheffenegger-tcpm-timestamp-negotiation-02.txt
Thread-Index: Acwgd/LNRnZoEqrmTt+VUnbN8+xrMwAF7vwQ
References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com> <4DE666DB.3010109@isi.edu>
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "Joe Touch" <touch@isi.edu>
X-OriginalArrivalTime: 01 Jun 2011 20:02:51.0237 (UTC) FILETIME=[E2FDD150:01CC2096]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] feedback from group to	draft-scheffenegger-tcpm-timestamp-negotiation-02.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2011 20:03:36 -0000

Hi Joe,

I am sorry, but you lost me...

I fully agree, the PRNG assumption may not hold. But I don't quite
follow where you set a fixed date (or was your choice of the signed unix
epoch rollover random?)...

As I mentioned, the (known to me) instance where an active sender would
not set TSecr in a <SYN> to zero was an older, broken stack. IIRC, the
reason was, that TS.recent was not initialized properly, thus whatever
data was there before that section of memory got allocated to the tcpcb
is sent. It may have been a previously used tcpcb, thus some (random,
see below) TSval of a prior session may still reside there... Or zero,
if the host was recently rebooted. Or any other arbitrary number from
calculations completely unrelated to TCP...


Second, it is already known that a random TS.offset per TCP session
should be used, to avoid leaking interesting information such as system
uptime.=20


Third, a passive host with a broken implementation of RFC1323 (such as
Windows XP, 2000, 2003), that set TSecr explicitly to zero in <SYN,ACK>
can be addressed by an appropriate selection of a TSoffset, such that no
valid combination of the mentioned fields can result on the decoding
operation (so 0x00 XOR <SYN> TSval should result in EXO=3D0, or any RES
bit =3D 1).


Fourth, the timestamp clock could be running at any conceivable rate (1
Hz, 60 Hz, 100Hz, 1 kHz, CPU cycles,...) thus a roll-over of the 32-bit
value will probably not occur at the same time the unix (signed) epoch
rolls over. Of course, using 1Hz granularity is just as good as anything
else. Still, I don't quite follow why a rollover (or setting of the MSB
bit) would pose a problem within the protocol described in the draft.

As broken stacks are just that (broken, not malicious), they will cause
only harm to their own sessions (e.g. higher spurious retransmissions),
IF the other end is made believe a valid capability negotiation took
place. Obviously, a protocol like this, which enables new uses, could
also be exploited (and timestamp based time measurements can be
exploited, for example is CUBIC in unpatched 2.6.16..2.6.22 vulnerable
to this). The solution in Linux (don't trust timestamps at all, and keep
per-segment state for time-tracking purposes) appears to be a bit of
overkill to me. Making sure a malicious receiver cannot modify TSval
undetected, when it reflects it, should suffice (and the protocol
provides this capability)...




Regarding the last statement, this is very true for RFC1323. As long as
monotonic increasing values are maintained, a sender is free to choose
any arbitrary clock source, including sources of variable speed (and
even simple packet or window counting is valid).

This draft makes it explicit, that if a pair of hosts want to engage
potentially improved, time-based heuristics (such as CUBIC, LEDBAT,
Chirp,...), a reasonable clock source of known tick interval length
should be chosen. In addition, a few bits may be used to add some kind
of entropy the receiver should not care about may also be present in the
TSval field. If a host does not want to contribute to any time-based
heuristics in TCP, it is free to signal that it's Timestamp clock is not
ticking at a constant interval (DUR=3D0), even if that host wants the
modified timestamp processing semantics (e.g. for improvements in loss
recovery timeliness). If a host doesn't wish to participate at all, it
is free to use (correctly implemented) RFC1323 semantics...


Again, the 3 points I mentioned in the earlier email are all (partial)
mitigations about *broken* RFC1323 implementations. Their prevalence
appears to be low though, but I will try to sift through a larger and
broader volume of internet traffic than I have done so far...

I doubt that there can be a perfect solution to this, with a lightweight
capability signaling as described in the draft.




Richard Scheffenegger



> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Mittwoch, 01. Juni 2011 18:21
> To: Scheffenegger, Richard
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm-
> timestamp-negotiation-02.txt
>=20
> Hi, Richard,
>=20
> On 6/1/2011 4:33 AM, Scheffenegger, Richard wrote:
> >
> > Hi Joe,
> >
> >>
> >>> If the receiver determines that a sender compliant to this draft
is
> >>> negotiating, the<SYN,ACK>   TSecr is set to (<SYN>   TSval) XOR
> >> (receiver
> >>> TS capabilities).
> >>
> >> How do you know whether it's a sender compliant to the draft
> >> negotiating, vs. a noncompliant RFC1323 host?
> >
> >
> > There are three aspects to this:
> >
> > a) The receiver may think a higher version sender is trying to
> > negotiate.
> > Assuming a non-compliant RFC1323 sender has the<SYN>  TSecr bits set
> in
> > a random way, the chances for this are EXO=3D1 (50%) * VER=3D[1..3]
> (75%),
> > so ~37.5%.
>=20
> I find this kind of analysis unconvincing; these aren't bits generated
> by a PRNG. A given host will either set some of these bits with 100%
> probability on a given date (or what it thinks is that date) or not.
> They're definitely *not* independent or random. Sure, the above would
> happen for sure 1/23/2055 at 10:02pm GMT or so for hosts using
> reasonably valid clocks - or before, for those that (correctly or not)
> pick times near this as their timestamp.
>=20
> IMO, the overall analysis needs to take that into account.
>=20
> > b) The receiver may coaxed into enabling local algorithms exceeding
> PAWS
> > (ie. OWD variance). This is more problematic, as the receiver (or
> > passive sender) may use TSval as input signal into congestion
control
> or
> > loss recovery.
> >
> > To reduce the chances of this happening, the RES bits field MUST be
> set
> > to zero by a compliant sender.
> >
> > The likelihood that a misbehaving sender sends these fields to
> > EXO=3D1, VER=3D00b, RES=3D00000000b, by random chance is about =
2^-11...
>=20
> Again, random chance isn't the problem. This particular problem *will*
> occur on 1/19/2038 at 3:14am GMT, for hosts using reasonably valid
> clocks.
>=20
> Sure, these dates are far into the future. But we have NO idea:
> 	a) how long these changes will be in use
> 	b) whether someone will decide to 'randomize' the dates
> 	for some (false) sense of security (no, please - don't!)
>=20
> I.e., you're playing with a space that has no requirements. There is
no
> absolute that "TCP must use date stamps that are reasonably accurate
to
> the current date/time". Any such assumption is asking for trouble,
IMO.
>=20
> Joe


From touch@isi.edu  Wed Jun  1 13:54:03 2011
Return-Path: <touch@isi.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD223E0919 for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 13:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.048
X-Spam-Level: 
X-Spam-Status: No, score=-102.048 tagged_above=-999 required=5 tests=[AWL=-1.249, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZLQ-YQqL4Zx for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 13:54:03 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id 183E1E088C for <tcpm@ietf.org>; Wed,  1 Jun 2011 13:54:03 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p51KriGr016561 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2011 13:53:44 -0700 (PDT)
Message-ID: <4DE6A6D8.20908@isi.edu>
Date: Wed, 01 Jun 2011 13:53:44 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com> <4DE666DB.3010109@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: p51KriGr016561
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] feedback from group to	draft-scheffenegger-tcpm-timestamp-negotiation-02.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2011 20:54:03 -0000

On 6/1/2011 1:02 PM, Scheffenegger, Richard wrote:
>
> Hi Joe,
>
> I am sorry, but you lost me...
>
> I fully agree, the PRNG assumption may not hold. But I don't quite
> follow where you set a fixed date (or was your choice of the signed unix
> epoch rollover random?)...

I picked dates that had the bits set as you indicated ;-)

> As I mentioned, the (known to me) instance where an active sender would
> not set TSecr in a <SYN>  to zero was an older, broken stack. IIRC, the
> reason was, that TS.recent was not initialized properly, thus whatever
> data was there before that section of memory got allocated to the tcpcb
> is sent. It may have been a previously used tcpcb, thus some (random,
> see below) TSval of a prior session may still reside there... Or zero,
> if the host was recently rebooted. Or any other arbitrary number from
> calculations completely unrelated to TCP...

OK, so this issue is limited to what happens in a <SYN>, but it's still 
worth explaining what happens in that case - even if a poor 
implementation dumps the current timestamp value in the <SYN> (even if 
oddly set). AFAICT, RFC1323 doesn't care about that situation - does it??

> Second, it is already known that a random TS.offset per TCP session
> should be used, to avoid leaking interesting information such as system
> uptime.
 >
> Third, a passive host with a broken implementation of RFC1323 (such as
> Windows XP, 2000, 2003), that set TSecr explicitly to zero in<SYN,ACK>
> can be addressed by an appropriate selection of a TSoffset, such that no
> valid combination of the mentioned fields can result on the decoding
> operation (so 0x00 XOR<SYN>  TSval should result in EXO=0, or any RES
> bit = 1).
>
> Fourth, the timestamp clock could be running at any conceivable rate (1
> Hz, 60 Hz, 100Hz, 1 kHz, CPU cycles,...) thus a roll-over of the 32-bit
> value will probably not occur at the same time the unix (signed) epoch
> rolls over. Of course, using 1Hz granularity is just as good as anything
> else. Still, I don't quite follow why a rollover (or setting of the MSB
> bit) would pose a problem within the protocol described in the draft.
>
> As broken stacks are just that (broken, not malicious), they will cause
> only harm to their own sessions (e.g. higher spurious retransmissions),
> IF the other end is made believe a valid capability negotiation took
> place. Obviously, a protocol like this, which enables new uses, could
> also be exploited (and timestamp based time measurements can be
> exploited, for example is CUBIC in unpatched 2.6.16..2.6.22 vulnerable
> to this). The solution in Linux (don't trust timestamps at all, and keep
> per-segment state for time-tracking purposes) appears to be a bit of
> overkill to me. Making sure a malicious receiver cannot modify TSval
> undetected, when it reflects it, should suffice (and the protocol
> provides this capability)...

My overall suggestion is to ensure that if RFC1323 is robust to a badly 
set <SYN>, you should explain whether your new mechanism is similarly 
robust or not

> Regarding the last statement, this is very true for RFC1323. As long as
> monotonic increasing values are maintained, a sender is free to choose
> any arbitrary clock source, including sources of variable speed (and
> even simple packet or window counting is valid).
>
> This draft makes it explicit, that if a pair of hosts want to engage
> potentially improved, time-based heuristics (such as CUBIC, LEDBAT,
> Chirp,...), a reasonable clock source of known tick interval length
> should be chosen.

Are you defining "reasonable" as having the desired bits clear? If so, 
that's useful to state, as is what happens when this is not the case.

(I hope "reasonable" doesn't mean "reasonably close to current time" - I 
want to preserve TS-independence as per RFC1323).

> In addition, a few bits may be used to add some kind
> of entropy the receiver should not care about may also be present in the
> TSval field. If a host does not want to contribute to any time-based
> heuristics in TCP, it is free to signal that it's Timestamp clock is not
> ticking at a constant interval (DUR=0), even if that host wants the
> modified timestamp processing semantics (e.g. for improvements in loss
> recovery timeliness). If a host doesn't wish to participate at all, it
> is free to use (correctly implemented) RFC1323 semantics...
>
>
> Again, the 3 points I mentioned in the earlier email are all (partial)
> mitigations about *broken* RFC1323 implementations. Their prevalence
> appears to be low though, but I will try to sift through a larger and
> broader volume of internet traffic than I have done so far...
>
> I doubt that there can be a perfect solution to this, with a lightweight
> capability signaling as described in the draft.

Agreed; it's useful to be clear to whether your mechanism introduces 
some sort of susceptibility to such errors that isn't there for 
RFC1323-hosts.

Joe

>> -----Original Message-----
>> From: Joe Touch [mailto:touch@isi.edu]
>> Sent: Mittwoch, 01. Juni 2011 18:21
>> To: Scheffenegger, Richard
>> Cc: tcpm@ietf.org
>> Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm-
>> timestamp-negotiation-02.txt
>>
>> Hi, Richard,
>>
>> On 6/1/2011 4:33 AM, Scheffenegger, Richard wrote:
>>>
>>> Hi Joe,
>>>
>>>>
>>>>> If the receiver determines that a sender compliant to this draft
> is
>>>>> negotiating, the<SYN,ACK>    TSecr is set to (<SYN>    TSval) XOR
>>>> (receiver
>>>>> TS capabilities).
>>>>
>>>> How do you know whether it's a sender compliant to the draft
>>>> negotiating, vs. a noncompliant RFC1323 host?
>>>
>>>
>>> There are three aspects to this:
>>>
>>> a) The receiver may think a higher version sender is trying to
>>> negotiate.
>>> Assuming a non-compliant RFC1323 sender has the<SYN>   TSecr bits set
>> in
>>> a random way, the chances for this are EXO=1 (50%) * VER=[1..3]
>> (75%),
>>> so ~37.5%.
>>
>> I find this kind of analysis unconvincing; these aren't bits generated
>> by a PRNG. A given host will either set some of these bits with 100%
>> probability on a given date (or what it thinks is that date) or not.
>> They're definitely *not* independent or random. Sure, the above would
>> happen for sure 1/23/2055 at 10:02pm GMT or so for hosts using
>> reasonably valid clocks - or before, for those that (correctly or not)
>> pick times near this as their timestamp.
>>
>> IMO, the overall analysis needs to take that into account.
>>
>>> b) The receiver may coaxed into enabling local algorithms exceeding
>> PAWS
>>> (ie. OWD variance). This is more problematic, as the receiver (or
>>> passive sender) may use TSval as input signal into congestion
> control
>> or
>>> loss recovery.
>>>
>>> To reduce the chances of this happening, the RES bits field MUST be
>> set
>>> to zero by a compliant sender.
>>>
>>> The likelihood that a misbehaving sender sends these fields to
>>> EXO=1, VER=00b, RES=00000000b, by random chance is about 2^-11...
>>
>> Again, random chance isn't the problem. This particular problem *will*
>> occur on 1/19/2038 at 3:14am GMT, for hosts using reasonably valid
>> clocks.
>>
>> Sure, these dates are far into the future. But we have NO idea:
>> 	a) how long these changes will be in use
>> 	b) whether someone will decide to 'randomize' the dates
>> 	for some (false) sense of security (no, please - don't!)
>>
>> I.e., you're playing with a space that has no requirements. There is
> no
>> absolute that "TCP must use date stamps that are reasonably accurate
> to
>> the current date/time". Any such assumption is asking for trouble,
> IMO.
>>
>> Joe
>

From rs@netapp.com  Wed Jun  1 14:17:44 2011
Return-Path: <rs@netapp.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666ADE083F for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 14:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.095
X-Spam-Level: 
X-Spam-Status: No, score=-9.095 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYKMhJOJ34sA for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 14:17:43 -0700 (PDT)
Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6C02EE08F9 for <tcpm@ietf.org>; Wed,  1 Jun 2011 14:17:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,305,1304319600"; d="scan'208";a="257957972"
Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 01 Jun 2011 14:17:36 -0700
Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p51LHaWK001051; Wed, 1 Jun 2011 14:17:36 -0700 (PDT)
Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 1 Jun 2011 23:17:36 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 1 Jun 2011 22:16:51 +0100
Message-ID: <5FDC413D5FA246468C200652D63E627A0EAA9454@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <4DE6A6D8.20908@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] feedback from group to	draft-scheffenegger-tcpm-timestamp-negotiation-02.txt
Thread-Index: AcwgnguAzAZQQA/bSkST02VxiUcF2AAAEAmw
References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com> <4DE51EC0.7070302@isi.edu> <5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com> <4DE57E52.5030501@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com> <4DE666DB.3010109@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com> <4DE6A6D8.20908@isi.edu>
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "Joe Touch" <touch@isi.edu>
X-OriginalArrivalTime: 01 Jun 2011 21:17:36.0248 (UTC) FILETIME=[54442F80:01CC20A1]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] feedback from group to	draft-scheffenegger-tcpm-timestamp-negotiation-02.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2011 21:17:44 -0000

Hello Joe,=20

thanks for the quick feedback!

The semantics of the Timestamp option during the session will not
change; so the hosts have complete freedom to choose whatever clock
source and offset they like.

The issue we are discussion only happens during the initial <SYN> /
<SYN,ACK> exchange, where this draft changes the semantics what is
encoded in the - so far unused - TSecr field.

RFC1323 states, that=20
"When TSecr is not valid, its value must be zero."=20

As the initial <SYN> cannot have a valid timestamp to reflect, this must
mean that a compliant RFC1323 stack should zero out TSecr in <SYN>. And
all current stacks comply here.

When a stack does not, there really is no telling what kind of data is
contained therein (therefore, there is also no direct dependency on
absolute time in any way).


Those stacks that explicitly clear TSecr on <SYN,ACK> are a little bit
harder to dismiss as misbehaving. However, a <SYN,ACK> is usually the
result of a <SYN>, and the timestamp option must only be sent when the
<SYN> already contained one; therefore, the <SYN,ACK> TSecr should
reflect the <SYN> TSval. But if it doesn't, it's not strictly a
violation of protocol.

Fortunately, this is a special case, and can be handled by the active
sender.


You are correct, RFC1323 doesn't really care about what happens during
the <SYN> and <SYN,ACK>, as RTTM (should) be started only with the first
normal <ACK> segment. [RFC3390] section 6 "Interaction with the
Retransmission Timer" recommends not to sample the RTT during the
three-way handshake... And many versions of linux mistakenly assume a
TSecr value of 0 is always invalid (turning the RFC1323 statement on
it's head).

Regarding robustness: Yes, proper implementations should be; however, I
have a strong suspicion, that whenever TSecr is non-zero, stacks will
use that as a valid RTTM sample (regardless of the SYN flag), possibly
arriving at strange RTO values.

As long as the only purpose of timestamps is to provide RTT measurements
and PAWS, broken implementations in this respect have limited exposure
(a few initial spurious retransmits may be caused). However, if
timestamps should be empowered to provide a higher quality input signal
for more core algorithms than RTO calculation, the exposure is
definitely larger.

Best regards,=20



Richard Scheffenegger


> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Mittwoch, 01. Juni 2011 22:54
> To: Scheffenegger, Richard
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm-
> timestamp-negotiation-02.txt
>=20
>=20
>=20
> On 6/1/2011 1:02 PM, Scheffenegger, Richard wrote:
> >
> > Hi Joe,
> >
> > I am sorry, but you lost me...
> >
> > I fully agree, the PRNG assumption may not hold. But I don't quite
> > follow where you set a fixed date (or was your choice of the signed
> unix
> > epoch rollover random?)...
>=20
> I picked dates that had the bits set as you indicated ;-)
>=20
> > As I mentioned, the (known to me) instance where an active sender
> would
> > not set TSecr in a <SYN>  to zero was an older, broken stack. IIRC,
> the
> > reason was, that TS.recent was not initialized properly, thus
> whatever
> > data was there before that section of memory got allocated to the
> tcpcb
> > is sent. It may have been a previously used tcpcb, thus some
(random,
> > see below) TSval of a prior session may still reside there... Or
> zero,
> > if the host was recently rebooted. Or any other arbitrary number
from
> > calculations completely unrelated to TCP...
>=20
> OK, so this issue is limited to what happens in a <SYN>, but it's
still
> worth explaining what happens in that case - even if a poor
> implementation dumps the current timestamp value in the <SYN> (even if
> oddly set). AFAICT, RFC1323 doesn't care about that situation - does
> it??
>=20
> > Second, it is already known that a random TS.offset per TCP session
> > should be used, to avoid leaking interesting information such as
> system
> > uptime.
>  >
> > Third, a passive host with a broken implementation of RFC1323 (such
> as
> > Windows XP, 2000, 2003), that set TSecr explicitly to zero
> in<SYN,ACK>
> > can be addressed by an appropriate selection of a TSoffset, such
that
> no
> > valid combination of the mentioned fields can result on the decoding
> > operation (so 0x00 XOR<SYN>  TSval should result in EXO=3D0, or any
RES
> > bit =3D 1).
> >
> > Fourth, the timestamp clock could be running at any conceivable rate
> (1
> > Hz, 60 Hz, 100Hz, 1 kHz, CPU cycles,...) thus a roll-over of the 32-
> bit
> > value will probably not occur at the same time the unix (signed)
> epoch
> > rolls over. Of course, using 1Hz granularity is just as good as
> anything
> > else. Still, I don't quite follow why a rollover (or setting of the
> MSB
> > bit) would pose a problem within the protocol described in the
draft.
> >
> > As broken stacks are just that (broken, not malicious), they will
> cause
> > only harm to their own sessions (e.g. higher spurious
> retransmissions),
> > IF the other end is made believe a valid capability negotiation took
> > place. Obviously, a protocol like this, which enables new uses,
could
> > also be exploited (and timestamp based time measurements can be
> > exploited, for example is CUBIC in unpatched 2.6.16..2.6.22
> vulnerable
> > to this). The solution in Linux (don't trust timestamps at all, and
> keep
> > per-segment state for time-tracking purposes) appears to be a bit of
> > overkill to me. Making sure a malicious receiver cannot modify TSval
> > undetected, when it reflects it, should suffice (and the protocol
> > provides this capability)...
>=20
> My overall suggestion is to ensure that if RFC1323 is robust to a
badly
> set <SYN>, you should explain whether your new mechanism is similarly
> robust or not
>=20
> > Regarding the last statement, this is very true for RFC1323. As long
> as
> > monotonic increasing values are maintained, a sender is free to
> choose
> > any arbitrary clock source, including sources of variable speed (and
> > even simple packet or window counting is valid).
> >
> > This draft makes it explicit, that if a pair of hosts want to engage
> > potentially improved, time-based heuristics (such as CUBIC, LEDBAT,
> > Chirp,...), a reasonable clock source of known tick interval length
> > should be chosen.
>=20
> Are you defining "reasonable" as having the desired bits clear? If so,
> that's useful to state, as is what happens when this is not the case.
>=20
> (I hope "reasonable" doesn't mean "reasonably close to current time" -
> I
> want to preserve TS-independence as per RFC1323).
>=20
> > In addition, a few bits may be used to add some kind
> > of entropy the receiver should not care about may also be present in
> the
> > TSval field. If a host does not want to contribute to any time-based
> > heuristics in TCP, it is free to signal that it's Timestamp clock is
> not
> > ticking at a constant interval (DUR=3D0), even if that host wants =
the
> > modified timestamp processing semantics (e.g. for improvements in
> loss
> > recovery timeliness). If a host doesn't wish to participate at all,
> it
> > is free to use (correctly implemented) RFC1323 semantics...
> >
> >
> > Again, the 3 points I mentioned in the earlier email are all
> (partial)
> > mitigations about *broken* RFC1323 implementations. Their prevalence
> > appears to be low though, but I will try to sift through a larger
and
> > broader volume of internet traffic than I have done so far...
> >
> > I doubt that there can be a perfect solution to this, with a
> lightweight
> > capability signaling as described in the draft.
>=20
> Agreed; it's useful to be clear to whether your mechanism introduces
> some sort of susceptibility to such errors that isn't there for
> RFC1323-hosts.
>=20
> Joe
>=20
> >> -----Original Message-----
> >> From: Joe Touch [mailto:touch@isi.edu]
> >> Sent: Mittwoch, 01. Juni 2011 18:21
> >> To: Scheffenegger, Richard
> >> Cc: tcpm@ietf.org
> >> Subject: Re: [tcpm] feedback from group to
draft-scheffenegger-tcpm-
> >> timestamp-negotiation-02.txt
> >>
> >> Hi, Richard,
> >>
> >> On 6/1/2011 4:33 AM, Scheffenegger, Richard wrote:
> >>>
> >>> Hi Joe,
> >>>
> >>>>
> >>>>> If the receiver determines that a sender compliant to this draft
> > is
> >>>>> negotiating, the<SYN,ACK>    TSecr is set to (<SYN>    TSval)
XOR
> >>>> (receiver
> >>>>> TS capabilities).
> >>>>
> >>>> How do you know whether it's a sender compliant to the draft
> >>>> negotiating, vs. a noncompliant RFC1323 host?
> >>>
> >>>
> >>> There are three aspects to this:
> >>>
> >>> a) The receiver may think a higher version sender is trying to
> >>> negotiate.
> >>> Assuming a non-compliant RFC1323 sender has the<SYN>   TSecr bits
> set
> >> in
> >>> a random way, the chances for this are EXO=3D1 (50%) * =
VER=3D[1..3]
> >> (75%),
> >>> so ~37.5%.
> >>
> >> I find this kind of analysis unconvincing; these aren't bits
> generated
> >> by a PRNG. A given host will either set some of these bits with
100%
> >> probability on a given date (or what it thinks is that date) or
not.
> >> They're definitely *not* independent or random. Sure, the above
> would
> >> happen for sure 1/23/2055 at 10:02pm GMT or so for hosts using
> >> reasonably valid clocks - or before, for those that (correctly or
> not)
> >> pick times near this as their timestamp.
> >>
> >> IMO, the overall analysis needs to take that into account.
> >>
> >>> b) The receiver may coaxed into enabling local algorithms
exceeding
> >> PAWS
> >>> (ie. OWD variance). This is more problematic, as the receiver (or
> >>> passive sender) may use TSval as input signal into congestion
> > control
> >> or
> >>> loss recovery.
> >>>
> >>> To reduce the chances of this happening, the RES bits field MUST
be
> >> set
> >>> to zero by a compliant sender.
> >>>
> >>> The likelihood that a misbehaving sender sends these fields to
> >>> EXO=3D1, VER=3D00b, RES=3D00000000b, by random chance is about =
2^-11...
> >>
> >> Again, random chance isn't the problem. This particular problem
> *will*
> >> occur on 1/19/2038 at 3:14am GMT, for hosts using reasonably valid
> >> clocks.
> >>
> >> Sure, these dates are far into the future. But we have NO idea:
> >> 	a) how long these changes will be in use
> >> 	b) whether someone will decide to 'randomize' the dates
> >> 	for some (false) sense of security (no, please - don't!)
> >>
> >> I.e., you're playing with a space that has no requirements. There
is
> > no
> >> absolute that "TCP must use date stamps that are reasonably
accurate
> > to
> >> the current date/time". Any such assumption is asking for trouble,
> > IMO.
> >>
> >> Joe
> >

From touch@isi.edu  Wed Jun  1 14:22:45 2011
Return-Path: <touch@isi.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06D2E083F for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 14:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.689
X-Spam-Level: 
X-Spam-Status: No, score=-101.689 tagged_above=-999 required=5 tests=[AWL=-1.490, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgkuMSjHy0zI for <tcpm@ietfa.amsl.com>; Wed,  1 Jun 2011 14:22:44 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id B3744E08F5 for <tcpm@ietf.org>; Wed,  1 Jun 2011 14:22:24 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p51LLrqF021468 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2011 14:21:53 -0700 (PDT)
Message-ID: <4DE6AD71.4070902@isi.edu>
Date: Wed, 01 Jun 2011 14:21:53 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: <5FDC413D5FA246468C200652D63E627A0E99C04B@LDCMVEXC1-PRD.hq.netapp.com>	<5FDC413D5FA246468C200652D63E627A0E99C04C@LDCMVEXC1-PRD.hq.netapp.com>	<4DE51EC0.7070302@isi.edu>	<5FDC413D5FA246468C200652D63E627A0E99CD4C@LDCMVEXC1-PRD.hq.netapp.com>	<4DE57E52.5030501@isi.edu>	<5FDC413D5FA246468C200652D63E627A0EAA9115@LDCMVEXC1-PRD.hq.netapp.com>	<4DE666DB.3010109@isi.edu>	<5FDC413D5FA246468C200652D63E627A0EAA9444@LDCMVEXC1-PRD.hq.netapp.com>	<4DE6A6D8.20908@isi.edu> <5FDC413D5FA246468C200652D63E627A0EAA9454@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <5FDC413D5FA246468C200652D63E627A0EAA9454@LDCMVEXC1-PRD.hq.netapp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: p51LLrqF021468
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] feedback from group	to	draft-scheffenegger-tcpm-timestamp-negotiation-02.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2011 21:22:45 -0000

Thanks - I'm hoping some of this will be included in the update as 
clarification of "backward compat" (even busted) issues...

Joe

On 6/1/2011 2:16 PM, Scheffenegger, Richard wrote:
>
> Hello Joe,
>
> thanks for the quick feedback!
>
> The semantics of the Timestamp option during the session will not
> change; so the hosts have complete freedom to choose whatever clock
> source and offset they like.
>
> The issue we are discussion only happens during the initial<SYN>  /
> <SYN,ACK>  exchange, where this draft changes the semantics what is
> encoded in the - so far unused - TSecr field.
>
> RFC1323 states, that
> "When TSecr is not valid, its value must be zero."
>
> As the initial<SYN>  cannot have a valid timestamp to reflect, this must
> mean that a compliant RFC1323 stack should zero out TSecr in<SYN>. And
> all current stacks comply here.
>
> When a stack does not, there really is no telling what kind of data is
> contained therein (therefore, there is also no direct dependency on
> absolute time in any way).
>
>
> Those stacks that explicitly clear TSecr on<SYN,ACK>  are a little bit
> harder to dismiss as misbehaving. However, a<SYN,ACK>  is usually the
> result of a<SYN>, and the timestamp option must only be sent when the
> <SYN>  already contained one; therefore, the<SYN,ACK>  TSecr should
> reflect the<SYN>  TSval. But if it doesn't, it's not strictly a
> violation of protocol.
>
> Fortunately, this is a special case, and can be handled by the active
> sender.
>
>
> You are correct, RFC1323 doesn't really care about what happens during
> the<SYN>  and<SYN,ACK>, as RTTM (should) be started only with the first
> normal<ACK>  segment. [RFC3390] section 6 "Interaction with the
> Retransmission Timer" recommends not to sample the RTT during the
> three-way handshake... And many versions of linux mistakenly assume a
> TSecr value of 0 is always invalid (turning the RFC1323 statement on
> it's head).
>
> Regarding robustness: Yes, proper implementations should be; however, I
> have a strong suspicion, that whenever TSecr is non-zero, stacks will
> use that as a valid RTTM sample (regardless of the SYN flag), possibly
> arriving at strange RTO values.
>
> As long as the only purpose of timestamps is to provide RTT measurements
> and PAWS, broken implementations in this respect have limited exposure
> (a few initial spurious retransmits may be caused). However, if
> timestamps should be empowered to provide a higher quality input signal
> for more core algorithms than RTO calculation, the exposure is
> definitely larger.
>
> Best regards,
>
>
>
> Richard Scheffenegger
>
>
>> -----Original Message-----
>> From: Joe Touch [mailto:touch@isi.edu]
>> Sent: Mittwoch, 01. Juni 2011 22:54
>> To: Scheffenegger, Richard
>> Cc: tcpm@ietf.org
>> Subject: Re: [tcpm] feedback from group to draft-scheffenegger-tcpm-
>> timestamp-negotiation-02.txt
>>
>>
>>
>> On 6/1/2011 1:02 PM, Scheffenegger, Richard wrote:
>>>
>>> Hi Joe,
>>>
>>> I am sorry, but you lost me...
>>>
>>> I fully agree, the PRNG assumption may not hold. But I don't quite
>>> follow where you set a fixed date (or was your choice of the signed
>> unix
>>> epoch rollover random?)...
>>
>> I picked dates that had the bits set as you indicated ;-)
>>
>>> As I mentioned, the (known to me) instance where an active sender
>> would
>>> not set TSecr in a<SYN>   to zero was an older, broken stack. IIRC,
>> the
>>> reason was, that TS.recent was not initialized properly, thus
>> whatever
>>> data was there before that section of memory got allocated to the
>> tcpcb
>>> is sent. It may have been a previously used tcpcb, thus some
> (random,
>>> see below) TSval of a prior session may still reside there... Or
>> zero,
>>> if the host was recently rebooted. Or any other arbitrary number
> from
>>> calculations completely unrelated to TCP...
>>
>> OK, so this issue is limited to what happens in a<SYN>, but it's
> still
>> worth explaining what happens in that case - even if a poor
>> implementation dumps the current timestamp value in the<SYN>  (even if
>> oddly set). AFAICT, RFC1323 doesn't care about that situation - does
>> it??
>>
>>> Second, it is already known that a random TS.offset per TCP session
>>> should be used, to avoid leaking interesting information such as
>> system
>>> uptime.
>>   >
>>> Third, a passive host with a broken implementation of RFC1323 (such
>> as
>>> Windows XP, 2000, 2003), that set TSecr explicitly to zero
>> in<SYN,ACK>
>>> can be addressed by an appropriate selection of a TSoffset, such
> that
>> no
>>> valid combination of the mentioned fields can result on the decoding
>>> operation (so 0x00 XOR<SYN>   TSval should result in EXO=0, or any
> RES
>>> bit = 1).
>>>
>>> Fourth, the timestamp clock could be running at any conceivable rate
>> (1
>>> Hz, 60 Hz, 100Hz, 1 kHz, CPU cycles,...) thus a roll-over of the 32-
>> bit
>>> value will probably not occur at the same time the unix (signed)
>> epoch
>>> rolls over. Of course, using 1Hz granularity is just as good as
>> anything
>>> else. Still, I don't quite follow why a rollover (or setting of the
>> MSB
>>> bit) would pose a problem within the protocol described in the
> draft.
>>>
>>> As broken stacks are just that (broken, not malicious), they will
>> cause
>>> only harm to their own sessions (e.g. higher spurious
>> retransmissions),
>>> IF the other end is made believe a valid capability negotiation took
>>> place. Obviously, a protocol like this, which enables new uses,
> could
>>> also be exploited (and timestamp based time measurements can be
>>> exploited, for example is CUBIC in unpatched 2.6.16..2.6.22
>> vulnerable
>>> to this). The solution in Linux (don't trust timestamps at all, and
>> keep
>>> per-segment state for time-tracking purposes) appears to be a bit of
>>> overkill to me. Making sure a malicious receiver cannot modify TSval
>>> undetected, when it reflects it, should suffice (and the protocol
>>> provides this capability)...
>>
>> My overall suggestion is to ensure that if RFC1323 is robust to a
> badly
>> set<SYN>, you should explain whether your new mechanism is similarly
>> robust or not
>>
>>> Regarding the last statement, this is very true for RFC1323. As long
>> as
>>> monotonic increasing values are maintained, a sender is free to
>> choose
>>> any arbitrary clock source, including sources of variable speed (and
>>> even simple packet or window counting is valid).
>>>
>>> This draft makes it explicit, that if a pair of hosts want to engage
>>> potentially improved, time-based heuristics (such as CUBIC, LEDBAT,
>>> Chirp,...), a reasonable clock source of known tick interval length
>>> should be chosen.
>>
>> Are you defining "reasonable" as having the desired bits clear? If so,
>> that's useful to state, as is what happens when this is not the case.
>>
>> (I hope "reasonable" doesn't mean "reasonably close to current time" -
>> I
>> want to preserve TS-independence as per RFC1323).
>>
>>> In addition, a few bits may be used to add some kind
>>> of entropy the receiver should not care about may also be present in
>> the
>>> TSval field. If a host does not want to contribute to any time-based
>>> heuristics in TCP, it is free to signal that it's Timestamp clock is
>> not
>>> ticking at a constant interval (DUR=0), even if that host wants the
>>> modified timestamp processing semantics (e.g. for improvements in
>> loss
>>> recovery timeliness). If a host doesn't wish to participate at all,
>> it
>>> is free to use (correctly implemented) RFC1323 semantics...
>>>
>>>
>>> Again, the 3 points I mentioned in the earlier email are all
>> (partial)
>>> mitigations about *broken* RFC1323 implementations. Their prevalence
>>> appears to be low though, but I will try to sift through a larger
> and
>>> broader volume of internet traffic than I have done so far...
>>>
>>> I doubt that there can be a perfect solution to this, with a
>> lightweight
>>> capability signaling as described in the draft.
>>
>> Agreed; it's useful to be clear to whether your mechanism introduces
>> some sort of susceptibility to such errors that isn't there for
>> RFC1323-hosts.
>>
>> Joe
>>
>>>> -----Original Message-----
>>>> From: Joe Touch [mailto:touch@isi.edu]
>>>> Sent: Mittwoch, 01. Juni 2011 18:21
>>>> To: Scheffenegger, Richard
>>>> Cc: tcpm@ietf.org
>>>> Subject: Re: [tcpm] feedback from group to
> draft-scheffenegger-tcpm-
>>>> timestamp-negotiation-02.txt
>>>>
>>>> Hi, Richard,
>>>>
>>>> On 6/1/2011 4:33 AM, Scheffenegger, Richard wrote:
>>>>>
>>>>> Hi Joe,
>>>>>
>>>>>>
>>>>>>> If the receiver determines that a sender compliant to this draft
>>> is
>>>>>>> negotiating, the<SYN,ACK>     TSecr is set to (<SYN>     TSval)
> XOR
>>>>>> (receiver
>>>>>>> TS capabilities).
>>>>>>
>>>>>> How do you know whether it's a sender compliant to the draft
>>>>>> negotiating, vs. a noncompliant RFC1323 host?
>>>>>
>>>>>
>>>>> There are three aspects to this:
>>>>>
>>>>> a) The receiver may think a higher version sender is trying to
>>>>> negotiate.
>>>>> Assuming a non-compliant RFC1323 sender has the<SYN>    TSecr bits
>> set
>>>> in
>>>>> a random way, the chances for this are EXO=1 (50%) * VER=[1..3]
>>>> (75%),
>>>>> so ~37.5%.
>>>>
>>>> I find this kind of analysis unconvincing; these aren't bits
>> generated
>>>> by a PRNG. A given host will either set some of these bits with
> 100%
>>>> probability on a given date (or what it thinks is that date) or
> not.
>>>> They're definitely *not* independent or random. Sure, the above
>> would
>>>> happen for sure 1/23/2055 at 10:02pm GMT or so for hosts using
>>>> reasonably valid clocks - or before, for those that (correctly or
>> not)
>>>> pick times near this as their timestamp.
>>>>
>>>> IMO, the overall analysis needs to take that into account.
>>>>
>>>>> b) The receiver may coaxed into enabling local algorithms
> exceeding
>>>> PAWS
>>>>> (ie. OWD variance). This is more problematic, as the receiver (or
>>>>> passive sender) may use TSval as input signal into congestion
>>> control
>>>> or
>>>>> loss recovery.
>>>>>
>>>>> To reduce the chances of this happening, the RES bits field MUST
> be
>>>> set
>>>>> to zero by a compliant sender.
>>>>>
>>>>> The likelihood that a misbehaving sender sends these fields to
>>>>> EXO=1, VER=00b, RES=00000000b, by random chance is about 2^-11...
>>>>
>>>> Again, random chance isn't the problem. This particular problem
>> *will*
>>>> occur on 1/19/2038 at 3:14am GMT, for hosts using reasonably valid
>>>> clocks.
>>>>
>>>> Sure, these dates are far into the future. But we have NO idea:
>>>> 	a) how long these changes will be in use
>>>> 	b) whether someone will decide to 'randomize' the dates
>>>> 	for some (false) sense of security (no, please - don't!)
>>>>
>>>> I.e., you're playing with a space that has no requirements. There
> is
>>> no
>>>> absolute that "TCP must use date stamps that are reasonably
> accurate
>>> to
>>>> the current date/time". Any such assumption is asking for trouble,
>>> IMO.
>>>>
>>>> Joe
>>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From hkchu@google.com  Mon Jun  6 04:53:40 2011
Return-Path: <hkchu@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDEC11E80F8 for <tcpm@ietfa.amsl.com>; Mon,  6 Jun 2011 04:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln6pbfttz5ZM for <tcpm@ietfa.amsl.com>; Mon,  6 Jun 2011 04:53:38 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 82AB611E80D6 for <tcpm@ietf.org>; Mon,  6 Jun 2011 04:53:38 -0700 (PDT)
Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p56BraOn014768 for <tcpm@ietf.org>; Mon, 6 Jun 2011 04:53:36 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307361217; bh=Yv001fIjCzqpbO1d2n+eHVtTusg=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding; b=lTsMM60mX14groMQrfcwXX2lJPVttwrekyA2GCww5tzQ2XGc4IJsbOOVI+2Jn7lKd uOuyfhHJjhKPy/CbWHE3Q==
Received: from yxj19 (yxj19.prod.google.com [10.190.3.83]) by hpaq12.eem.corp.google.com with ESMTP id p56BrYQS018618 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <tcpm@ietf.org>; Mon, 6 Jun 2011 04:53:35 -0700
Received: by yxj19 with SMTP id 19so1095767yxj.4 for <tcpm@ietf.org>; Mon, 06 Jun 2011 04:53:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=au+HTmCdy0zFJ4NNliSxLX2sYa+KMyLfVAYmBEkIEds=; b=tDOzA5Szwx79DN6zj55QqtYQ7GQmvX6jpzJRe7DVnj8NUt6L3I1wOVUs8/y1FKDN4X xNc7DHXEakTgGGi9Rl9Q==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RnYBNNhJFT77mv0WCkSKpV6SdK1vIjM03oDp5VV/v/2xByOl30fqGygUW/nsFhhEbH Vy8lfSbE7tm2WcVBex8A==
MIME-Version: 1.0
Received: by 10.150.236.15 with SMTP id j15mr4169949ybh.294.1307361214257; Mon, 06 Jun 2011 04:53:34 -0700 (PDT)
Received: by 10.151.142.17 with HTTP; Mon, 6 Jun 2011 04:53:34 -0700 (PDT)
Date: Mon, 6 Jun 2011 04:53:34 -0700
Message-ID: <BANLkTimb2BEOAw9wA-8unDGNTUO9AUoXHw@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: David Borman <david.borman@windriver.com>
Subject: [tcpm] upcoming consensus call on IW10
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jun 2011 11:53:40 -0000

Folks,

It's been a while since our last IW related discussion/debate, and
it's getting close for the WG to decide on the status of our IW10
proposal at the upcoming meeting in Quebec City. To get ready for
a consensus call, we have produced a major revision of the draft to
include all the up-to-date information for your peruse below.

We believe our IW10 proposal is ready for standardization now,
considering the following facts:

1. We have been experimenting with IW10 in a very large scale for
more than 9 months by now, and have observed its positive performance
impact consistently with no issue reported so far.

2. We have conducted a number of testbed studies to address concerns,
mainly on IW10's impact on slow links or other flows with smaller
IW. All the results show little or no negative impact from IW10, with
the only exception being some extreme overload cases where both IW10
and IW3 perform terribly. The full testbed results can be found at
http://research.csc.ncsu.edu/netsrv/?q=3Dcontent/iw10

3. An informal poll by Mark Allman early this year seemed to show
the majority of people responding to the poll favored a simple,
static increase of IW right away.

4. The latest Linux kernel has adopted 10 as the default initial
congestion window size.

Once again, we believe a modest, static increase of IW to 10 is the
best, simplest, timely solution to a serious web performance problem
with little downside. We appreciate the value of two other related
proposals by M. Allman and J. Touch respectively, but believe, due
to their complexity (especially the one by Joe), they are best suited
for experiemental (e.g., likely need to refine the suggested formula),
and will best serve to carve out a growh path for IW beyond 10.

Comments and suggestions on how to move things forward are welcomed.
Also a complete set of IW10 related papers and past presentations
can be found at http://code.google.com/speed/protocols/tcpm-IW10.html

Best,

Jerry on behalf of all co-authors

On Thu, Apr 14, 2011 at 6:00 PM, <Internet-Drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the TCP Maintenance and Minor Extensions Wor=
king Group of the IETF.
>
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Increasing TCP's Initial Windo=
w
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : J. Chu, et al.
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-tcpm-initcwnd-01.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 20
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-04-14
>
> This document proposes an increase in the permitted TCP initial
> window (IW) from between 2 and 4 segments, as specified in RFC 3390,
> to 10 segments. It discusses the motivation behind the increase, the
> advantages and disadvantages of the higher initial window, and
> presents results from several large scale experiments showing that
> the higher initial window improves the overall performance of many
> web services without risking congestion collapse. The document closes
> with a discussion of a list of concerns, and some results from recent
> studies to address the concerns.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

From mallman@icir.org  Mon Jun  6 06:07:52 2011
Return-Path: <mallman@icir.org>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3296E11E8133 for <tcpm@ietfa.amsl.com>; Mon,  6 Jun 2011 06:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-8r9ighuFqQ for <tcpm@ietfa.amsl.com>; Mon,  6 Jun 2011 06:07:51 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id C1CA611E8132 for <tcpm@ietf.org>; Mon,  6 Jun 2011 06:07:51 -0700 (PDT)
Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p56D7l4v024503; Mon, 6 Jun 2011 06:07:48 -0700 (PDT)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AEC8C4032594; Mon,  6 Jun 2011 09:07:47 -0400 (EDT)
To: Jerry Chu <hkchu@google.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <BANLkTimb2BEOAw9wA-8unDGNTUO9AUoXHw@mail.gmail.com> 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Empty Sky
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma53537-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 06 Jun 2011 09:07:47 -0400
Sender: mallman@icir.org
Message-Id: <20110606130747.AEC8C4032594@lawyers.icir.org>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, David Borman <david.borman@windriver.com>
Subject: Re: [tcpm] upcoming consensus call on IW10
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jun 2011 13:07:52 -0000

----------ma53537-1
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


> > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Increasing TCP's Initial Win=
dow
> > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : J. Chu, et al.
> > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-tcpm-initcwnd-01.txt
> > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 20
> > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-04-14

(1) We should Make This So.=20=20

    Nobody has offered any illustrations of concrete and broad problems
    caused by this and to the contrary we have quite a bunch of evidence
    that addresses the concerns that have been raised.

    There is always One More Case that might be problematic, but we have
    been down that road quite a bit and seemingly things are OK.

    There is always some ratty network that will end up being
    problematic, but we should not hold everyone up based on corner
    cases.=20

    The bottom line is that we will **never** **know** how it will work
    in the whole Internet until we deploy it in the actual whole
    Internet.

    So, I think unless someone can readily identify issues via concrete
    experiments and/or measurements that suggest this is a bad idea that
    the time has come to agree this is a reasonable path.

(2) I prefer a solution that does not specify an initial window, but
    rather a tolerance for problems caused by an initial window.  I
    think we should still move something like this forward so we don't
    ever have to consider a precise IW value again.  But, at this point
    it seems we should not hold up an IW bump for something that might
    or might not happen and has shown somewhat variable energy behind
    it.

allman




----------ma53537-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk3s0SIACgkQWyrrWs4yIs7rSACePca2GJcJn0BHxL+0N/bylLfM
M9cAn0NQs2wyA68L7cpqqjCMcKBAWS51
=phRq
-----END PGP SIGNATURE-----
----------ma53537-1--

From wes@mti-systems.com  Tue Jun  7 22:17:40 2011
Return-Path: <wes@mti-systems.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD6B11E80D6 for <tcpm@ietfa.amsl.com>; Tue,  7 Jun 2011 22:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wysg5mbU3kHJ for <tcpm@ietfa.amsl.com>; Tue,  7 Jun 2011 22:17:38 -0700 (PDT)
Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 90CAD11E80B2 for <tcpm@ietf.org>; Tue,  7 Jun 2011 22:17:38 -0700 (PDT)
Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p585HbaO007645 for <tcpm@ietf.org>; Wed, 8 Jun 2011 01:17:37 -0400
Authentication-Results: cm-omr9 smtp.user=wes@mti-systems.com; auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [209.181.118.241] ([209.181.118.241:44059] helo=[172.20.100.57]) by cm-omr9 (envelope-from <wes@mti-systems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 95/87-02642-1F50FED4; Wed, 08 Jun 2011 01:17:37 -0400
Message-ID: <4DEF05F3.4050505@mti-systems.com>
Date: Wed, 08 Jun 2011 01:17:39 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: tcpm@ietf.org
References: <2BD9239D-7DCE-4AC7-838F-BA915AABC756@windriver.com>
In-Reply-To: <2BD9239D-7DCE-4AC7-838F-BA915AABC756@windriver.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [tcpm] Start of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2011 05:17:40 -0000

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 Michael.Scharf@alcatel-lucent.com  Tue Jun 14 06:50:55 2011
Return-Path: <Michael.Scharf@alcatel-lucent.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3A111E812A for <tcpm@ietfa.amsl.com>; Tue, 14 Jun 2011 06:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J39SDMTeZgo4 for <tcpm@ietfa.amsl.com>; Tue, 14 Jun 2011 06:50:54 -0700 (PDT)
Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 3D86B11E812E for <tcpm@ietf.org>; Tue, 14 Jun 2011 06:50:54 -0700 (PDT)
Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p5EDoq1o011207; Tue, 14 Jun 2011 15:50:52 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 14 Jun 2011 15:50:52 +0200
Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0607B676@SLFSNX.rcs.alcatel-research.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TCPM meeting in Quebec City: Call for agenda items
Thread-Index: AcwqmhMy3Lq5oLbgSqq0R8Kt81WFTQ==
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
To: <tcpm@ietf.org>
X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73
Cc: tcpm-chairs@tools.ietf.org
Subject: [tcpm] TCPM meeting in Quebec City: Call for agenda items
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2011 13:50:55 -0000

Dear all,

the TCPM WG is expected to meet in Quebec City. If you want to present a
draft there, please drop a note to the TCPM WG co-chairs as soon as
possible.

The deadline for agenda requests is July 1. Please provide the following
information:

* draft name / presentation title
* presenter
* estimated duration

In order to ensure an efficient meeting, all presenters should also
provide an initial version of the planned presentation to the chairs by
July 8.

Thanks a lot!

David Borman and Michael Scharf
(TCPM WG co-chairs)

From mattmathis@google.com  Fri Jun 17 18:39:44 2011
Return-Path: <mattmathis@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA7511E81CF for <tcpm@ietfa.amsl.com>; Fri, 17 Jun 2011 18:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jfx4XD6mmj0 for <tcpm@ietfa.amsl.com>; Fri, 17 Jun 2011 18:39:44 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1A80611E80BF for <tcpm@ietf.org>; Fri, 17 Jun 2011 18:39:43 -0700 (PDT)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p5I1dhi8010846 for <tcpm@ietf.org>; Fri, 17 Jun 2011 18:39:43 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308361183; bh=ONjCwwhcdBXmjCjroc8gAL3a7Ck=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=O+nz/wGK3pDMtlrCREzYa+5k/HwRyS13djHeuz6osOZmBO4gM2/IX3llcTu7/9+/P /aQoORqFEWHy6FknmHSZQ==
Received: from ewy8 (ewy8.prod.google.com [10.241.103.8]) by wpaz5.hot.corp.google.com with ESMTP id p5I1dfT6027093 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <tcpm@ietf.org>; Fri, 17 Jun 2011 18:39:41 -0700
Received: by ewy8 with SMTP id 8so664674ewy.40 for <tcpm@ietf.org>; Fri, 17 Jun 2011 18:39:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P7HvwB3QggygmCkWSAVRUGz7bJZVvyhnKCkxlJ1cR2w=; b=BrEtmiD+sN6/k53NXeSB1bZLSLTtUU0tBRiCmAkHx2LoKaYfQZ5BR5SSH/rNgTYpsr 4IvXIFCNr/a0nnhfsGkw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T2SbTyuxKDYkXuy7nk0TiiU+MoVrlQ/zLwlgGBlCeq7ViNtj/kjoM4QFGBfQKWqHra ZsBO0V08RbLbP6WI4csw==
MIME-Version: 1.0
Received: by 10.213.15.83 with SMTP id j19mr1159430eba.89.1308361180392; Fri, 17 Jun 2011 18:39:40 -0700 (PDT)
Received: by 10.213.114.2 with HTTP; Fri, 17 Jun 2011 18:39:40 -0700 (PDT)
In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C026F62E6@SLFSNX.rcs.alcatel-research.de>
References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> <BANLkTi=3atVLYA81WdS9=aK8Q-is5BPQgQ@mail.gmail.com> <5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com> <BANLkTimorO7k2S_RxV7goqnEYLry3m2yqA@mail.gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C026F62E6@SLFSNX.rcs.alcatel-research.de>
Date: Fri, 17 Jun 2011 18:39:40 -0700
Message-ID: <BANLkTik5MsrES40A1PfVi0FMhwx8MvRX+awwU=poC1g+5bP8Xw@mail.gmail.com>
From: Matt Mathis <mattmathis@google.com>
To: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>, David Borman <dab@weston.borman.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jun 2011 01:39:44 -0000

So I am withdrawing any thought of changing the scope.  We do have an
incremental tweak (an additional algorithm) but it does not change the
problem statement or document scope.

However, I never heard the final word: are we approved for WG status
(doc name draft-ietf-tcpm-proportional-rate-reduction-00.txt) or
updating the existing independent submission
(draft-mathis-tcpm-proportional-rate-reduction-01.txt)?

We will address all of the comments from the list, etc.

Thanks,
--MM--
The best way to predict the future is to create it. =A0- Alan Kay

On Fri, Apr 1, 2011 at 12:07 AM, SCHARF, Michael
<Michael.Scharf@alcatel-lucent.com> wrote:
> Matt,
>
>> When you said "interest", did you actually mean as a WG item?=A0=A0 You
>> didn't quite ask the question.
>>
>> We plan to update the document and bring it to the next IETF in any
>> case, and we know of=A0 a number of individuals who have expressed
>> interest.
>
> It would be excellent to have an update that addresses the comments on th=
e
> list.
>
>> My only reservation with making it a WG item is that we expect to
>> broaden the scope somewhat, and the current file and document names
>> may not be appropriate.=A0=A0 As long as a future scope changes are not =
a
>> problem, a WG item would be preferred.
>
> Could you please detail these expected scope changes?
>
> Thanks
>
> Michael

From Michael.Scharf@alcatel-lucent.com  Wed Jun 22 07:14:13 2011
Return-Path: <Michael.Scharf@alcatel-lucent.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2653311E809F for <tcpm@ietfa.amsl.com>; Wed, 22 Jun 2011 07:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxdn8U6wynIf for <tcpm@ietfa.amsl.com>; Wed, 22 Jun 2011 07:14:12 -0700 (PDT)
Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 57F3311E808F for <tcpm@ietf.org>; Wed, 22 Jun 2011 07:14:12 -0700 (PDT)
Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p5MEDoSc027707; Wed, 22 Jun 2011 16:13:50 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 22 Jun 2011 16:13:49 +0200
Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0607BA59@SLFSNX.rcs.alcatel-research.de>
In-Reply-To: <BANLkTik5MsrES40A1PfVi0FMhwx8MvRX+awwU=poC1g+5bP8Xw@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00?
Thread-Index: AcwtWJw75BzgNIn9QvqqcpUcDsmWGgDh8p5g
References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de><1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no><BANLkTi=3atVLYA81WdS9=aK8Q-is5BPQgQ@mail.gmail.com><5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com><BANLkTimorO7k2S_RxV7goqnEYLry3m2yqA@mail.gmail.com><133D9897FB9C5E4E9DF2779DC91E947C026F62E6@SLFSNX.rcs.alcatel-research.de> <BANLkTik5MsrES40A1PfVi0FMhwx8MvRX+awwU=poC1g+5bP8Xw@mail.gmail.com>
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
To: "Matt Mathis" <mattmathis@google.com>, "David Borman" <dab@weston.borman.com>
X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2011 14:14:13 -0000

Hi Matt,

as I mentioned before, it would be excellent to have an individual =
update of the draft, addressing the comments from the list. I personally =
also found the examples sent to the list very helpful, but I haven't =
seen much discussion on that so far.

If the WG adopts the -01 draft, it is trivial to resubmit it immediately =
as draft-ietf-tcpm-*.

Best regards

Michael
=20

> -----Original Message-----
> From: Matt Mathis [mailto:mattmathis@google.com]=20
> Sent: Saturday, June 18, 2011 3:40 AM
> To: SCHARF, Michael; David Borman
> Cc: Nandita Dukkipati; Yuchung Cheng; TCP Maintenance and=20
> Minor Extensions WG
> Subject: Re: [tcpm] Interest=20
> indraft-mathis-tcpm-proportional-rate-reduction-00?
>=20
> So I am withdrawing any thought of changing the scope.  We do=20
> have an incremental tweak (an additional algorithm) but it=20
> does not change the problem statement or document scope.
>=20
> However, I never heard the final word: are we approved for WG=20
> status (doc name=20
> draft-ietf-tcpm-proportional-rate-reduction-00.txt) or=20
> updating the existing independent submission=20
> (draft-mathis-tcpm-proportional-rate-reduction-01.txt)?
>=20
> We will address all of the comments from the list, etc.
>=20
> Thanks,
> --MM--
> The best way to predict the future is to create it. =A0- Alan Kay
>=20
> On Fri, Apr 1, 2011 at 12:07 AM, SCHARF, Michael=20
> <Michael.Scharf@alcatel-lucent.com> wrote:
> > Matt,
> >
> >> When you said "interest", did you actually mean as a WG=20
> item?=A0=A0 You=20
> >> didn't quite ask the question.
> >>
> >> We plan to update the document and bring it to the next=20
> IETF in any=20
> >> case, and we know of=A0 a number of individuals who have expressed=20
> >> interest.
> >
> > It would be excellent to have an update that addresses the=20
> comments on=20
> > the list.
> >
> >> My only reservation with making it a WG item is that we expect to=20
> >> broaden the scope somewhat, and the current file and=20
> document names=20
> >> may not be appropriate.=A0=A0 As long as a future scope=20
> changes are not a=20
> >> problem, a WG item would be preferred.
> >
> > Could you please detail these expected scope changes?
> >
> > Thanks
> >
> > Michael
>=20

From johnwheffner@gmail.com  Wed Jun 22 08:53:28 2011
Return-Path: <johnwheffner@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0C211E8135 for <tcpm@ietfa.amsl.com>; Wed, 22 Jun 2011 08:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2l08dHl4-Meq for <tcpm@ietfa.amsl.com>; Wed, 22 Jun 2011 08:53:27 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22B2911E807A for <tcpm@ietf.org>; Wed, 22 Jun 2011 08:53:26 -0700 (PDT)
Received: by bwz13 with SMTP id 13so988647bwz.31 for <tcpm@ietf.org>; Wed, 22 Jun 2011 08:53:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=og4s9KiXNanruXCluqzqYyLpLpkEwdLMe/PQbDPRQjw=; b=cDhyLy4c1OVbvq3TmB9xZiCNQkV1qJcyQ8TQCWBAXhTVN7mQga35IzZbQrtWStHMO5 VkqJLeHWS72sTugDv60KW8zsSDinLt7r+uB0oDQ8aB1Zriv0xf81hj58cle/M+o6J1kn hQwm344YQ1DR+Nb5u9f3Mh60wCIO/tKZXH7j4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=irmcMKJ1+LdVZLhcYR39H4aM6vhFDQ9AoKZtwNxEwuZZUBLE6BJKcHW/K23MDdX/8U gXoTNtGk1IDboz0ZqxqlFJ9ch5R/CRHtpCpzNCMP+XHuRe5/k9alhxY051J2tBROJoAT UUJlk1woEdoDGOLE7ADAtK7CJwGqt3fjat1Po=
MIME-Version: 1.0
Received: by 10.204.136.217 with SMTP id s25mr359458bkt.13.1308758005725; Wed, 22 Jun 2011 08:53:25 -0700 (PDT)
Received: by 10.204.16.131 with HTTP; Wed, 22 Jun 2011 08:53:25 -0700 (PDT)
In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0607BA59@SLFSNX.rcs.alcatel-research.de>
References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> <BANLkTi=3atVLYA81WdS9=aK8Q-is5BPQgQ@mail.gmail.com> <5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com> <BANLkTimorO7k2S_RxV7goqnEYLry3m2yqA@mail.gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C026F62E6@SLFSNX.rcs.alcatel-research.de> <BANLkTik5MsrES40A1PfVi0FMhwx8MvRX+awwU=poC1g+5bP8Xw@mail.gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C0607BA59@SLFSNX.rcs.alcatel-research.de>
Date: Wed, 22 Jun 2011 11:53:25 -0400
Message-ID: <BANLkTi=XHReKG5Do7uFZKTMBbZpMoBBSxQ@mail.gmail.com>
From: John Heffner <johnwheffner@gmail.com>
To: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: David Borman <dab@weston.borman.com>, TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>, Matt Mathis <mattmathis@google.com>
Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2011 15:53:28 -0000

I've read through the doc and think it should be adopted this wg.
Standardizing a rate-reduction algorithm is important, and the
algorithms described by this doc seem very promising, and are real
improvement over the old rate-halving draft and current Linux
implementation.

Thanks,
  -John


On Wed, Jun 22, 2011 at 10:13 AM, SCHARF, Michael
<Michael.Scharf@alcatel-lucent.com> wrote:
> Hi Matt,
>
> as I mentioned before, it would be excellent to have an individual update=
 of the draft, addressing the comments from the list. I personally also fou=
nd the examples sent to the list very helpful, but I haven't seen much disc=
ussion on that so far.
>
> If the WG adopts the -01 draft, it is trivial to resubmit it immediately =
as draft-ietf-tcpm-*.
>
> Best regards
>
> Michael
>
>
>> -----Original Message-----
>> From: Matt Mathis [mailto:mattmathis@google.com]
>> Sent: Saturday, June 18, 2011 3:40 AM
>> To: SCHARF, Michael; David Borman
>> Cc: Nandita Dukkipati; Yuchung Cheng; TCP Maintenance and
>> Minor Extensions WG
>> Subject: Re: [tcpm] Interest
>> indraft-mathis-tcpm-proportional-rate-reduction-00?
>>
>> So I am withdrawing any thought of changing the scope. =A0We do
>> have an incremental tweak (an additional algorithm) but it
>> does not change the problem statement or document scope.
>>
>> However, I never heard the final word: are we approved for WG
>> status (doc name
>> draft-ietf-tcpm-proportional-rate-reduction-00.txt) or
>> updating the existing independent submission
>> (draft-mathis-tcpm-proportional-rate-reduction-01.txt)?
>>
>> We will address all of the comments from the list, etc.
>>
>> Thanks,
>> --MM--
>> The best way to predict the future is to create it. =A0- Alan Kay
>>
>> On Fri, Apr 1, 2011 at 12:07 AM, SCHARF, Michael
>> <Michael.Scharf@alcatel-lucent.com> wrote:
>> > Matt,
>> >
>> >> When you said "interest", did you actually mean as a WG
>> item?=A0=A0 You
>> >> didn't quite ask the question.
>> >>
>> >> We plan to update the document and bring it to the next
>> IETF in any
>> >> case, and we know of=A0 a number of individuals who have expressed
>> >> interest.
>> >
>> > It would be excellent to have an update that addresses the
>> comments on
>> > the list.
>> >
>> >> My only reservation with making it a WG item is that we expect to
>> >> broaden the scope somewhat, and the current file and
>> document names
>> >> may not be appropriate.=A0=A0 As long as a future scope
>> changes are not a
>> >> problem, a WG item would be preferred.
>> >
>> > Could you please detail these expected scope changes?
>> >
>> > Thanks
>> >
>> > Michael
>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

From wwwrun@rfc-editor.org  Wed Jun 22 20:39:27 2011
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DC711E80BD; Wed, 22 Jun 2011 20:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.532
X-Spam-Level: 
X-Spam-Status: No, score=-105.532 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkC60ROZJ8z3; Wed, 22 Jun 2011 20:39:27 -0700 (PDT)
Received: from rfc-editor.org (rfcpa.amsl.com [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C611E8092; Wed, 22 Jun 2011 20:39:27 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 65FE298C518; Wed, 22 Jun 2011 20:39:27 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20110623033927.65FE298C518@rfc-editor.org>
Date: Wed, 22 Jun 2011 20:39:27 -0700 (PDT)
Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org
Subject: [tcpm] RFC 6298 on Computing TCP's Retransmission Timer
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2011 03:39:28 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6298

        Title:      Computing TCP's Retransmission Timer 
        Author:     V. Paxson, M. Allman,
                    J. Chu, M. Sargent
        Status:     Standards Track
        Stream:     IETF
        Date:       June 2011
        Mailbox:    vern@icir.org, 
                    mallman@icir.org, 
                    hkchu@google.com,  mts71@case.edu
        Pages:      11
        Characters: 22454
        Obsoletes:  RFC2988
        Updates:    RFC1122

        I-D Tag:    draft-paxson-tcpm-rfc2988bis-02.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6298.txt

This document defines the standard algorithm that Transmission Control
Protocol (TCP) senders are required to use to compute and manage their
retransmission timer.  It expands on the discussion in Section 4.2.3.1
of RFC 1122 and upgrades the requirement of supporting the algorithm
from a SHOULD to a MUST.  This document obsoletes RFC 2988.  
[STANDARDS-TRACK]

This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From Michael.Scharf@alcatel-lucent.com  Sat Jun 25 00:28:40 2011
Return-Path: <Michael.Scharf@alcatel-lucent.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00CB21F8477 for <tcpm@ietfa.amsl.com>; Sat, 25 Jun 2011 00:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A7vJb3ZjZcW for <tcpm@ietfa.amsl.com>; Sat, 25 Jun 2011 00:28:39 -0700 (PDT)
Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD9E21F8476 for <tcpm@ietf.org>; Sat, 25 Jun 2011 00:28:38 -0700 (PDT)
Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p5P7RvXV026201; Sat, 25 Jun 2011 09:27:57 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 25 Jun 2011 09:27:56 +0200
Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAA@SLFSNX.rcs.alcatel-research.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: End of WGLC for draft-ietf-tcpm-rfc1948bis
Thread-Index: AQHMG8LVtu3LcaoxVUOf5xEU3d1gTZTN1Ncg
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
To: "TCP Maintenance and Minor Extensions WG" <tcpm@ietf.org>
X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73
Cc: Fernando Gont <fernando@gont.com.ar>
Subject: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jun 2011 07:28:40 -0000

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
=20

-----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

From fernando.gont.netbook.win@gmail.com  Sat Jun 25 06:56:58 2011
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CEF21F84F8 for <tcpm@ietfa.amsl.com>; Sat, 25 Jun 2011 06:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.953
X-Spam-Level: 
X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odQSO-AWRYJt for <tcpm@ietfa.amsl.com>; Sat, 25 Jun 2011 06:56:57 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE09E21F84DF for <tcpm@ietf.org>; Sat, 25 Jun 2011 06:56:57 -0700 (PDT)
Received: by gya6 with SMTP id 6so104933gya.31 for <tcpm@ietf.org>; Sat, 25 Jun 2011 06:56:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=ynsmus3ZStANC1jznOiGIolnsP9wLlYyP5GrOtIHUTs=; b=suRrazsmRgy9MuggxS4CBghFVX2EhEG8tOewb9r9+6iT8rDOgVIx+AzH2EmYugy/6H VPr4CJ4eprT90o0sQ+n6r//hAy/RZO/04/vKa174di6huPhq19W3qzdoaPQHoKqfxpHu FBq5fIqhUxchpw8IZkn8Iis+TL3xAZuzFdY9E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=gpkA0ARpVE+y/SPJPcSEVxuj46WJUB6Ug75UXFhAxFai0v+XAUi1uPhaCVM4lZp3bj jBVnWpIL+UvPQ9WRV2sUqI/moJtyu+7hh1k2UpUiMLkASIdRSQOMxecspBNlOA5MCWfX /eOqu4/HmlAnrNZMl9MPARLHCQiHpG5dphjjM=
Received: by 10.91.159.13 with SMTP id l13mr4841671ago.123.1309010217138; Sat, 25 Jun 2011 06:56:57 -0700 (PDT)
Received: from [192.168.0.188] ([190.190.97.123]) by mx.google.com with ESMTPS id k3sm3570899ano.11.2011.06.25.06.56.47 (version=SSLv3 cipher=OTHER); Sat, 25 Jun 2011 06:56:55 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4E05E8EB.8080504@gont.com.ar>
Date: Sat, 25 Jun 2011 10:55:55 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: Wesley Eddy <wes@mti-systems.com>
References: <2BD9239D-7DCE-4AC7-838F-BA915AABC756@windriver.com> <4DEF05F3.4050505@mti-systems.com>
In-Reply-To: <4DEF05F3.4050505@mti-systems.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Start of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jun 2011 13:56:58 -0000

Hi, Wes,

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

On 06/08/2011 02:17 AM, Wesley Eddy wrote:
> 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,"?

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



> - 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

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


> - 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.

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 ----


> - 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?

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?



> - "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?

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 ----



> - is the 2nd to last paragraph of section 3 something that requires
>   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.



> - 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.

Please see above.



> 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

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).



> - in Abstract: "attacker of guessing" -> "attacker guessing" ?
> 
> - same as previous comment, but for Introduction, 2nd paragraph also

Fixed!



> - 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

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. :-)



> - can section 1, paragraph 2 elaborate in 1 sentence or so about the
>   "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: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From wes@mti-systems.com  Sat Jun 25 12:47:04 2011
Return-Path: <wes@mti-systems.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F50228011 for <tcpm@ietfa.amsl.com>; Sat, 25 Jun 2011 12:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.299
X-Spam-Level: 
X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_OFF=2.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RPUNL7VjK61 for <tcpm@ietfa.amsl.com>; Sat, 25 Jun 2011 12:47:02 -0700 (PDT)
Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id B906122800E for <tcpm@ietf.org>; Sat, 25 Jun 2011 12:47:00 -0700 (PDT)
Received: from cm-omr13 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p5PJkxBi026485 for <tcpm@ietf.org>; Sat, 25 Jun 2011 15:46:59 -0400
Authentication-Results: cm-omr13 smtp.user=wes@mti-systems.com; auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [174.130.90.206] ([174.130.90.206:62575] helo=[192.168.1.100]) by cm-omr13 (envelope-from <wes@mti-systems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B1/5F-16370-33B360E4; Sat, 25 Jun 2011 15:46:59 -0400
Message-ID: <4E063B33.9000504@mti-systems.com>
Date: Sat, 25 Jun 2011 15:46:59 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <2BD9239D-7DCE-4AC7-838F-BA915AABC756@windriver.com> <4DEF05F3.4050505@mti-systems.com> <4E05E8EB.8080504@gont.com.ar>
In-Reply-To: <4E05E8EB.8080504@gont.com.ar>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Start of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jun 2011 19:47:04 -0000

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

On 6/25/2011 9:55 AM, Fernando Gont wrote:
>
>
>> - 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?
>
> 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?

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


>> - "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?
>
> 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 ----
>

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 Michael.Scharf@alcatel-lucent.com  Sun Jun 26 00:28:29 2011
Return-Path: <Michael.Scharf@alcatel-lucent.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E6721F84D4 for <tcpm@ietfa.amsl.com>; Sun, 26 Jun 2011 00:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boS+GMAc-Oiy for <tcpm@ietfa.amsl.com>; Sun, 26 Jun 2011 00:28:29 -0700 (PDT)
Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id AAFCB21F84D5 for <tcpm@ietf.org>; Sun, 26 Jun 2011 00:28:28 -0700 (PDT)
Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p5Q7SQ0k026161 for <tcpm@ietf.org>; Sun, 26 Jun 2011 09:28:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 26 Jun 2011 09:28:25 +0200
Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAB@SLFSNX.rcs.alcatel-research.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Please help the Nomcom 
Thread-Index: AcwysIWHySRhFO1jTPuv5AA8Yj8FhwBIfL4g
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
To: "TCP Maintenance and Minor Extensions WG" <tcpm@ietf.org>
X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73
Subject: [tcpm] FW: Please help the Nomcom
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jun 2011 07:28:29 -0000

-----Original Message-----
From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On
Behalf Of NomCom Chair
Sent: Friday, June 24, 2011 8:35 PM
To: Working Group Chairs
Subject: Please help the Nomcom=20

Hi WG chairs,
  We have had a good response to the first call for volunteers but the
rate at which new volunteers are coming in is slowing down. The Nomcom
process is best served by a large pool of volunteers drawn from a wide
spectrum of IETF attendees. Where else would we find this wide spectrum
if not in the WG mailing lists.

I would really appreciate it if you can forward the message onto your
working group mailing lists.=20

The latest volunteer status and the second call for volunteers can be
found at https://datatracker.ietf.org/ann/nomcom/2964/

Thanks in advance for your help.

Suresh Krishnan
Nomcom Chair 2011-2012
Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com

From ananth@cisco.com  Sun Jun 26 03:48:02 2011
Return-Path: <ananth@cisco.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E17311E8078 for <tcpm@ietfa.amsl.com>; Sun, 26 Jun 2011 03:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.181
X-Spam-Level: 
X-Spam-Status: No, score=-10.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcUV-cXpwKfq for <tcpm@ietfa.amsl.com>; Sun, 26 Jun 2011 03:47:58 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3E26111E8077 for <tcpm@ietf.org>; Sun, 26 Jun 2011 03:47:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=5032; q=dns/txt; s=iport; t=1309085278; x=1310294878; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MO/XSw9mC5H1qSvprXD5w2OvVsxq0Zi8Go4ukEZLhhw=; b=FtmcnjSKl8vVzXM2BkSkoxQlf6LXk3+WFZnwLVydoif2+jxjhNy4X6ms yn5rjrRecQ15a1aHznWPGfcSJ2Vfm84Twx5177/GJx0WVKpXLKdxSYuE2 HULH6tAIHeG7xpBCbkQSFk5wl6XaJKnKecGgHpzFSZQ1FyLOgU4iR3i66 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvQAAEUNB06rRDoJ/2dsb2JhbABFDpgYjy53rQ6dAoMfgxEEhyyPTotE
X-IronPort-AV: E=Sophos;i="4.65,427,1304294400"; d="scan'208";a="347522773"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 26 Jun 2011 10:47:58 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5QAlv61029110; Sun, 26 Jun 2011 10:47:58 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 26 Jun 2011 03:47:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 26 Jun 2011 03:47:56 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC580D0E68CD@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAA@SLFSNX.rcs.alcatel-research.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
Thread-Index: AQHMG8LVtu3LcaoxVUOf5xEU3d1gTZTN1NcggAHAxIA=
References: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAA@SLFSNX.rcs.alcatel-research.de>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>, "TCP Maintenance and Minor Extensions WG" <tcpm@ietf.org>
X-OriginalArrivalTime: 26 Jun 2011 10:47:57.0521 (UTC) FILETIME=[82B7AC10:01CC33EE]
Cc: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jun 2011 10:48:02 -0000

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?=20


   "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 :- =20

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
>=20
> Dear all,
>=20
> 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.
>=20
> If you should have any further comment but somehow missed the
deadline,
> please speak up now. We should move forward this small draft.
>=20
> Thanks
>=20
> Michael
>=20
>=20
> -----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
>=20
> 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.
>=20
> 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.
>=20
> 			-David Borman & Michael Scharf, TCPM WG
> co-chairs
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From fernando.gont.netbook.win@gmail.com  Mon Jun 27 00:07:05 2011
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7FE21F85D1 for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 00:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level: 
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_36=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqucajg0U9jH for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 00:07:04 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABCBC11E80B1 for <tcpm@ietf.org>; Mon, 27 Jun 2011 00:07:04 -0700 (PDT)
Received: by gya6 with SMTP id 6so635246gya.31 for <tcpm@ietf.org>; Mon, 27 Jun 2011 00:07:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=PEL/Hjq5yi/x+qNCdGg+RWLjTeSuUDFt4BbCn8jA1CA=; b=QOlbwCCQBEls1pYN85KBkOHnYcoTP0+fJ5XrKMwcXVgZ0VDX0cFmM/QlQUpk3guWUy NS5xc5g/W76oHVEKeqHyXxETdFfCG/uLteQOG6Ti8BCQ/XU505UVojAQ3GQY6XRTUA/N oh+Q4oVjslexQbpXI/woSncDsKlnAjLfJz0kU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=bp8kLBWALkQIttgbKOElGQ1v8c+A5UEdiFaqlW6iEeaHjzx1C7IczEpfc4AAQfAKKC i2ga6Z7g20iuMz1Y/k+WWWy9xkCYIlTJpMl+q0k5xW2jb+PTpXXVAQMU1aR+ZEtmnrcx fd7mEvvaL7bp58OL8fq4MGRLNzyNsA7BH5QL0=
Received: by 10.150.253.9 with SMTP id a9mr1171340ybi.78.1309158423717; Mon, 27 Jun 2011 00:07:03 -0700 (PDT)
Received: from [192.168.1.101] (104-140-17-190.fibertel.com.ar [190.17.140.104]) by mx.google.com with ESMTPS id i14sm4802676ann.8.2011.06.27.00.07.00 (version=SSLv3 cipher=OTHER); Mon, 27 Jun 2011 00:07:02 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4E082C12.8000708@gont.com.ar>
Date: Mon, 27 Jun 2011 04:06:58 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAA@SLFSNX.rcs.alcatel-research.de> <0C53DCFB700D144284A584F54711EC580D0E68CD@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC580D0E68CD@xmb-sjc-21c.amer.cisco.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2011 07:07:05 -0000

Hi, Anantha,

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

On 06/26/2011 07:47 AM, Anantha Ramaiah (ananth) wrote:
> 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)



> 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"

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



> 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.

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).



>    "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.

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



> 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, 

Not sure what you mean....


> 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? 

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



>    "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". 

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


> 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?

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.



> 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...)

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.



> Appendix B
> "This document aims at Standards Track (rather than Informaitonal)."
> 
> Fix the typo :-)

Fixed :-)



> 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.?

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: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From ananth@cisco.com  Mon Jun 27 00:32:18 2011
Return-Path: <ananth@cisco.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B09011E808C for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 00:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.299
X-Spam-Level: 
X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmX+MjPG1uEH for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 00:32:17 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3814011E8086 for <tcpm@ietf.org>; Mon, 27 Jun 2011 00:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=5766; q=dns/txt; s=iport; t=1309159937; x=1310369537; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MsP3M90yVH7T6wwYad4lINPtfwkHSRL0/QxVrngSiV8=; b=VtfW0CaaFnzZrcOm8bx4q/uup2mcoKcUrF5QONY5Mik7pXKmOwdji6gs 8PI1HsWgCw1ZXTcIaNmL4RMjTUWM1fFa0Jzt8xS9mzbnj1o3TOY/T0ifN q7HfCwwHltU+x9HNpXUf0cv6cO5Yxu9FToouRK0Wpm4ulMZ63v4vHqeW6 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAFIxCE6rRDoJ/2dsb2JhbABEDqdDd4h0oUOdOoMfgxEEhyyPTotE
X-IronPort-AV: E=Sophos;i="4.65,431,1304294400"; d="scan'208";a="470356338"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 27 Jun 2011 07:32:16 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5R7WG8G024153; Mon, 27 Jun 2011 07:32:16 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 27 Jun 2011 00:32:16 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 Jun 2011 00:32:15 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC580D0E6980@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <4E082C12.8000708@gont.com.ar>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
Thread-Index: Acw0mNNHpejyOjyvTUWRDm2e4UglagAAG8fA
References: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAA@SLFSNX.rcs.alcatel-research.de> <0C53DCFB700D144284A584F54711EC580D0E68CD@xmb-sjc-21c.amer.cisco.com> <4E082C12.8000708@gont.com.ar>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Fernando Gont" <fernando@gont.com.ar>
X-OriginalArrivalTime: 27 Jun 2011 07:32:16.0752 (UTC) FILETIME=[57163F00:01CC349C]
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2011 07:32:18 -0000

> > 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.
>=20
> 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).

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

>=20
>=20
>=20
> >    "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.
>=20
> Not sure what you mean. Could you elaborate a little more?

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.

>=20
>=20
>=20
> > 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,
>=20
> 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?=20


<snip>

> >    "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".
>=20
> 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.

>=20
>=20
> > 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?
>=20
> MD5 is "suggested", but not required.=20

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

> 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.

Maybe this would get reviewed by the secdir folks during IESG review.
I'll leave it to them to comment on this aspect..
=20
>=20
>=20
>=20
> > 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...)
>=20
> 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.

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)

>=20
>=20
> > 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.?
>=20
> 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.
>=20
> -- I personally don't have a strong preference for one over the
> other...

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.netbook.win@gmail.com  Mon Jun 27 00:56:25 2011
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE1A11E8086 for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 00:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.255
X-Spam-Level: 
X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[AWL=1.044,  BAYES_00=-2.599, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yT7Y4WWtk2L for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 00:56:25 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4AF311E8081 for <tcpm@ietf.org>; Mon, 27 Jun 2011 00:56:24 -0700 (PDT)
Received: by yie30 with SMTP id 30so2657856yie.31 for <tcpm@ietf.org>; Mon, 27 Jun 2011 00:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=q8C+HAdX/+nyUaRhEQDgq06rFDpGf78U3hVxEU+JLtg=; b=xdkO7jii5reHWRGaJ8FKYcI+SQ+aHEHR7oFW35Y7mcs/LabBQJfT/4RDp0XmzDOZBf YzcY6CGqGrJYOlxKC/Y73JK0eTOtkI93/Axvl+5UA7Zcmq+if5JmAIKDOUT5pX7DYv3f Cqp60Oo/CeZV7OL7LHRbI94FnxoTwA4ANTIEc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=M45GnmRa3VuyisBGiBo/bQ00ouBGIqbS4byoXXM0Tq2J+v/MhWp/B80HspDkO7WWMQ KBknljb40cplZfReAGWwvIRx8Rca8hmONKX9MLf6aTIyhTZlMgaX7Z+8qLR0Ag3ZqBdl /ltIBXdQKxTb/AjEtk40y8yeAV2JaItQM01qM=
Received: by 10.101.205.36 with SMTP id h36mr2378986anq.74.1309161384155; Mon, 27 Jun 2011 00:56:24 -0700 (PDT)
Received: from [192.168.1.101] (104-140-17-190.fibertel.com.ar [190.17.140.104]) by mx.google.com with ESMTPS id l4sm4326128ano.9.2011.06.27.00.56.21 (version=SSLv3 cipher=OTHER); Mon, 27 Jun 2011 00:56:22 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4E0837A3.6030902@gont.com.ar>
Date: Mon, 27 Jun 2011 04:56:19 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAA@SLFSNX.rcs.alcatel-research.de>	<0C53DCFB700D144284A584F54711EC580D0E68CD@xmb-sjc-21c.amer.cisco.com>	<4E082C12.8000708@gont.com.ar> <0C53DCFB700D144284A584F54711EC580D0E6980@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC580D0E6980@xmb-sjc-21c.amer.cisco.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2011 07:56:25 -0000

Hi, Anantha,

On 06/27/2011 04:32 AM, Anantha Ramaiah (ananth) wrote:
> 
>>> 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.
>> 
>> 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).
> 
> 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.


>>> "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."
[....]
> 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.

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.



>>> 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,
>> 
>> 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?

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
>>> 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".
>> 
>> 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.

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
>>> reviewed by the security working groups?
>> 
>> MD5 is "suggested", but not required.
> 
> This is unclear in the document. Explicit language would help.

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



>>> 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...)
>> 
>> 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.
> 
> 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 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,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From fernando.gont.netbook.win@gmail.com  Mon Jun 27 04:47:21 2011
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3208521F8553 for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 04:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level: 
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=1.672,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPLJsQ5oY-4W for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 04:47:20 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D13B721F859B for <tcpm@ietf.org>; Mon, 27 Jun 2011 04:47:14 -0700 (PDT)
Received: by ywp31 with SMTP id 31so2748924ywp.31 for <tcpm@ietf.org>; Mon, 27 Jun 2011 04:47:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=JKjnZEM2yjV8qhIq3TaxrC18EdkUD2qsQFMUOKSp2ko=; b=Ly3ZUduQ1OVIB9iAHGs6Fjmvxn8OmaUGuXhd/p8UPcCgJYv7tyfEF2D5DX1EV0z7RT 63GOOn2r7Pxbvpmt8xduKD3jLZuGAwbCGN7ELH32eKV/Dya9DY13sxgJYy6WM6QZfgVY VAkb30eThxya8w7ofuKoIDmyiOBjBvtTE+lW0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=YilQEwvygPKA/tZtBenvOqohttfGJ6xn0FfiJYByREzs1yCbhRYRZDs52iKbHlZR5P 4NzkxR7nzexgScCLfe/kYubwWAHPdScP57UiV3/syUizZf3uzAc4O7TkEGfivlFGP6KZ 7PNnSK/jDJC6pZQZgIX6VsEO1vydya+swh2+A=
Received: by 10.150.31.18 with SMTP id e18mr6647493ybe.449.1309171684078; Mon, 27 Jun 2011 03:48:04 -0700 (PDT)
Received: from [192.168.1.101] (104-140-17-190.fibertel.com.ar [190.17.140.104]) by mx.google.com with ESMTPS id k3sm5399304ano.37.2011.06.27.03.48.01 (version=SSLv3 cipher=OTHER); Mon, 27 Jun 2011 03:48:02 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4E085FE0.90706@gont.com.ar>
Date: Mon, 27 Jun 2011 07:48:00 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: Wesley Eddy <wes@mti-systems.com>
References: <2BD9239D-7DCE-4AC7-838F-BA915AABC756@windriver.com>	<4DEF05F3.4050505@mti-systems.com> <4E05E8EB.8080504@gont.com.ar> <4E063B33.9000504@mti-systems.com>
In-Reply-To: <4E063B33.9000504@mti-systems.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Start of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2011 11:47:21 -0000

Hi, Wes,

On 06/25/2011 04:46 PM, Wesley Eddy wrote:
[....]
>> I've changed the discussion of the secret key to:
>>
[....]
>>
> 
> 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."

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,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From ananth@cisco.com  Mon Jun 27 08:09:49 2011
Return-Path: <ananth@cisco.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEE221F8699 for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 08:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.299
X-Spam-Level: 
X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLT1lj-V-ETl for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 08:09:48 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 5B77B21F8596 for <tcpm@ietf.org>; Mon, 27 Jun 2011 08:09:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=3021; q=dns/txt; s=iport; t=1309187352; x=1310396952; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TBfHZWGzXEKnxXhvJc7gDidmMY0V8bx/9iWvRLstQYM=; b=mTok+llLeTxhxMOAs/jtbl9BKvcTA/VAJVdocAQ+cK+w30xTSIiVj/Xm WyO0EA0ua4mcdme0ZrKU+yFEvzCPQAHvAzD+SXLCVV0wWYaiBeoO51eqf wQ7bc+WEMgMM7zhXeEQrniIdBq6DxrA+OYZYPE70YiKD+UJLjZ/EwDpCZ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAHmcCE6rRDoH/2dsb2JhbABSp0J3qy+dboYwBIcsj06LRA
X-IronPort-AV: E=Sophos;i="4.65,432,1304294400"; d="scan'208";a="722779920"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2011 15:09:11 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5RF9BVD005201; Mon, 27 Jun 2011 15:09:11 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 27 Jun 2011 08:09:11 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 Jun 2011 08:09:10 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC580D0E69ED@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <4E0837A3.6030902@gont.com.ar>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
thread-index: Acw0n82B50sqNJTWSbeXlNZio+RNxAAOAEwg
References: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAA@SLFSNX.rcs.alcatel-research.de>	<0C53DCFB700D144284A584F54711EC580D0E68CD@xmb-sjc-21c.amer.cisco.com>	<4E082C12.8000708@gont.com.ar><0C53DCFB700D144284A584F54711EC580D0E6980@xmb-sjc-21c.amer.cisco.com> <4E0837A3.6030902@gont.com.ar>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Fernando Gont" <fernando@gont.com.ar>
X-OriginalArrivalTime: 27 Jun 2011 15:09:11.0759 (UTC) FILETIME=[2BB455F0:01CC34DC]
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] End of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2011 15:09:49 -0000

>=20
>=20
>=20
> >>> 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,
> >>
> >> 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?
>=20
> I mean "any other party that does not know the secret".

I think making such a clarification helps readability.=20

>=20
>=20
>=20
> >>> "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".
> >>
> >> 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.
>=20
> I'm lost. :-) Isn't "...we consider that use of MD5 in the specified
> 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.

> >
> > 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.
>=20
> The output of F() is constant for each destination endpoint. See this
> example:
>=20
> 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?
>=20
> The concept is similar to the "idle scan" that leverages the IPv4
> Identification field.

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

From wes@mti-systems.com  Mon Jun 27 09:14:36 2011
Return-Path: <wes@mti-systems.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF8811E807A for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 09:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykh3VF1PfwNp for <tcpm@ietfa.amsl.com>; Mon, 27 Jun 2011 09:14:35 -0700 (PDT)
Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 13EE221F8587 for <tcpm@ietf.org>; Mon, 27 Jun 2011 09:13:49 -0700 (PDT)
Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p5RGDikN010887 for <tcpm@ietf.org>; Mon, 27 Jun 2011 12:13:48 -0400
Authentication-Results: cm-omr9 smtp.user=wes@mti-systems.com; auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [107.46.176.128] ([107.46.176.128:55362] helo=[192.168.9.2]) by cm-omr9 (envelope-from <wes@mti-systems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CE/F2-10086-73CA80E4; Mon, 27 Jun 2011 12:13:44 -0400
Message-ID: <4E08AC37.8030205@mti-systems.com>
Date: Mon, 27 Jun 2011 12:13:43 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <2BD9239D-7DCE-4AC7-838F-BA915AABC756@windriver.com>	<4DEF05F3.4050505@mti-systems.com> <4E05E8EB.8080504@gont.com.ar> <4E063B33.9000504@mti-systems.com> <4E085FE0.90706@gont.com.ar>
In-Reply-To: <4E085FE0.90706@gont.com.ar>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Start of WGLC for draft-ietf-tcpm-rfc1948bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2011 16:14:36 -0000

On 6/27/2011 6:48 AM, Fernando Gont wrote:
 >
>> 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."
>
> Should I s/reasonable/appropriate/?

That would be fine with me.


-- 
Wes Eddy
MTI Systems

From internet-drafts@ietf.org  Tue Jun 28 14:21:46 2011
Return-Path: <internet-drafts@ietf.org>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A1811E80C4; Tue, 28 Jun 2011 14:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.531
X-Spam-Level: 
X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oFJTZghXhpw; Tue, 28 Jun 2011 14:21:45 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6176F11E808C; Tue, 28 Jun 2011 14:21:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110628212140.7534.33439.idtracker@ietfa.amsl.com>
Date: Tue, 28 Jun 2011 14:21:40 -0700
Cc: tcpm@ietf.org
Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc1948bis-01.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2011 21:21:46 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the TCP Maintenance and Minor Extensions =
Working Group of the IETF.

	Title           : Defending Against Sequence Number Attacks
	Author(s)       : Fernando Gont
                          Steven M. Bellovin
	Filename        : draft-ietf-tcpm-rfc1948bis-01.txt
	Pages           : 13
	Date            : 2011-06-28

   This document specifies an algorithm for the generation of TCP
   Initial Sequence Numbers (ISNs), such that the chances of an off-path
   attacker guessing the sequence numbers in use by a target connection
   are reduced.  This document revises (and formally obsoletes) RFC
   1948, and takes the ISN generation algorithm originally proposed in
   that document to Standards Track.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc1948bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-rfc1948bis-01.txt

From fernando.gont.netbook.win@gmail.com  Tue Jun 28 14:29:52 2011
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD7811E811C for <tcpm@ietfa.amsl.com>; Tue, 28 Jun 2011 14:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.307
X-Spam-Level: 
X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHTz4tTkfFOZ for <tcpm@ietfa.amsl.com>; Tue, 28 Jun 2011 14:29:51 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFDD111E8100 for <tcpm@ietf.org>; Tue, 28 Jun 2011 14:29:51 -0700 (PDT)
Received: by gxk19 with SMTP id 19so315457gxk.31 for <tcpm@ietf.org>; Tue, 28 Jun 2011 14:29:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=sFKgElZIYHkAvgBzOpzK/Gqd5GnhvAaSWQSkSs+M5pA=; b=giPS/EQojkNRHlPXMCklUgpDum04y48rR795FBdvtcKNMNj35vxEdpVZQaL5W+1U/b pay2Lb9F8ILv8dnfiboGSD0Z3AtUUc6WRO5GfZkjoucgZ3StH7O2uTpuYmCPQd28noVj jnzYgUlLQlYalMMY22r7+mVh8Scrb2pGy0BgI=
Received: by 10.91.20.10 with SMTP id x10mr69181agi.204.1309296586717; Tue, 28 Jun 2011 14:29:46 -0700 (PDT)
Received: from [192.168.0.184] ([190.190.97.123]) by mx.google.com with ESMTPS id u10sm304893ann.31.2011.06.28.14.29.38 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 14:29:45 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4E0A47B8.2040901@gont.com.ar>
Date: Tue, 28 Jun 2011 18:29:28 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
CC: tcpm@ietf.org
References: <20110628212140.7534.33439.idtracker@ietfa.amsl.com>
In-Reply-To: <20110628212140.7534.33439.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc1948bis-01.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2011 21:29:52 -0000

Folks,

FYI: While I had noted in my response to Wes that I had published a rev
of this document this weekend, it seems that I forgot to complete the
confirmation procedure, and hence nothing was actually posted. As a
result, I have been able to address all the WGLC comments in version
-01, which I've just posted.

Thanks,
Fernando




On 06/28/2011 06:21 PM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.
> 
> 	Title           : Defending Against Sequence Number Attacks
> 	Author(s)       : Fernando Gont
>                           Steven M. Bellovin
> 	Filename        : draft-ietf-tcpm-rfc1948bis-01.txt
> 	Pages           : 13
> 	Date            : 2011-06-28
> 
>    This document specifies an algorithm for the generation of TCP
>    Initial Sequence Numbers (ISNs), such that the chances of an off-path
>    attacker guessing the sequence numbers in use by a target connection
>    are reduced.  This document revises (and formally obsoletes) RFC
>    1948, and takes the ISN generation algorithm originally proposed in
>    that document to Standards Track.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc1948bis-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-rfc1948bis-01.txt
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 


-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1