Re: [tcpm] WGLC for UTO
Lars Eggert <lars.eggert@nokia.com> Wed, 31 October 2007 07:48 UTC
Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8JU-0006Yt-7b; Wed, 31 Oct 2007 03:48:32 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1In8JT-0006Ym-6H for tcpm-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 03:48:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8JN-0006Vv-CZ for tcpm@ietf.org; Wed, 31 Oct 2007 03:48:25 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In8JD-00064o-Lf for tcpm@ietf.org; Wed, 31 Oct 2007 03:48:22 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V7m2Ad005660; Wed, 31 Oct 2007 09:48:03 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 09:47:41 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 09:47:41 +0200
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 09:47:41 +0200
Received: from [172.21.35.97] (esdhcp03597.research.nokia.com [172.21.35.97]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V7ldbx007692; Wed, 31 Oct 2007 09:47:39 +0200
In-Reply-To: <472756CC.8070809@isi.edu>
References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [tcpm] WGLC for UTO
Date: Wed, 31 Oct 2007 09:47:37 +0200
To: ext Joe Touch <touch@ISI.EDU>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 31 Oct 2007 07:47:41.0291 (UTC) FILETIME=[50AF73B0:01C81B92]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1985169914=="
Errors-To: tcpm-bounces@ietf.org
On 2007-10-30, at 18:07, ext Joe Touch wrote: > Lars Eggert wrote: >> The intent was to make UTO work with SYN cookie implementations that >> can't encode whether a UTO option was present in the cookie, by >> including the option also in the first non-SYN packets. > > That should be deemed non-compliant. The point of the SYN cookie is to > reestablish the entirety of state that would have been established by > the SYN; if the cookie can't do that, a cookie should not be used. Well, if the SYN requests (many) options and the receiver cannot encode them all in the cookie, it can always reply with a SYN-ACK that only echoes those that it can and does encode. That's compliant, no? > TCP has no provisions for post-SYN establishment of new connection > state > AFAIK. Requiring this of this option would be new, and, IMO, a bit > confusing for designers. What happens if the post-SYN packet lacks the > option? do you declare state mis-synchronization and drop it? No - the UTO option is purely advisory and not transmitted reliably. We had a long thread a while ago on the list that boiled down to that consensus. (I can dig it up if you like me to.) The gist was that it should be OK these days to send new options during a connection, even if the SYN exchange didn't negotiate their use. >> So there is some use to doing this. We could state that >> including UTo in the first non-SYN packets is only useful if the >> option >> was not included in the SYN? > > I'd prefer that, adjusted to say "if the option was not included in > the > SYN due to space limitations". That can certainly be done. >>> - sec 3 "A host that supports" >>> What happens if there is no option space in the next outgoing >>> segment? >>> What happens if there is no option space at all? Do you tell the >>> app? Do >>> you do anything special? IMO, this deserves a separate section >>> rather >>> than just a note at the end of 3.0 >> >> I don't know what we can say about this - this is a general issue >> with >> TCP. What should be done depends a lot on which other options are >> in use >> for a particular connection. Maybe UTO is considered more >> important than >> some options, but less important than others. Which options do you >> include and which ones do you not include, generally? Hard to say. > > I'm not making an assertion as to what to do, only that the doc > ought to > consider the issue. I'll suggest that it ought to send it within 2 > segments OR indicate to the application that it has failed; the latter > requires a new API variable, though. We can add that TCP should try for a few segments to include a TO option if it wants to send one, but I don't think notifying the application on failure is necessary, because UTO options are advisory and not transmitted reliably. Not being able to include it locally is equivalent to having the segment that it was included on being dropped in the network. >>> - sec 3.1 "In general" >>> This is contrary to the default values. CHANGEABLE defaults to >>> true, but >>> ENABLED defaults to false. That means, IMO, that received UTO >>> options >>> would be dropped, not acted upon, in the default case. >> >> When the draft was targeted as Experimental, having ENABLED >> default to >> false was needed, so that hosts would need to actively enable the >> mechanism to participate to experiment with the option. >> >> If we're going with PS (are we?), ENABLED should default to true, >> I guess. > > Sure - making the two consistent is the issue. Will do, as soon as the chairs declare consensus on which way they see the WG consensus go. > ... >>> Very minor points, if an edit occurs: >> ... >> >> Most of these are addressed in the next revision. But not these, >> so far: >> >>> - sec 3.1 "This means that" >>> This paragraph is part of a discussion on checks and limits; this >>> should >>> not be the first place you introduce the "max" concept. >> >> It's not - the formula further up introduces it. > > It might be useful to introduce the issue in prose first. The > reason for > using max is the issue, and it's not clear by just stating the > formula. > >>> - hysteresis? >>> The doc doesn't describe how quickly the UTO can be changed by the >>> remote end or application. Does it matter, e.g., for security >>> reasons? >> >> I don't think there are security implications here. The only >> result of >> changing the value very frequently is that all segments have the >> option >> attached, so there is some mild increase in bandwidth use. But the >> app >> can always just send more data anyway :-) > > Can someone on the path do something you don't want to your connection > by tacking this option on? So that's a different question than your original one, which was changing the value very frequently. An attacker that adds or modifies the content of UTO options may be able to affect how long the ends keep the connection alive. Since UTO is advisory, an attacker can't really do anything to the connection that couldn't happen anyway. And the security properties of UTO are similar to other TCP options (window scaling, timestamps), in that none of them are authenticated or encrypted. >>> - sec 3.2 >>> If you retransmit the option and attach it to a particular byte, >>> and the >>> byte is ACKd, then why don't you KNOW the option has been received >>> (i.e., second part of the handshake)? if the other end receives data >>> over 1 window away from that byte, why doesn't it KNOW the source >>> end >>> knows it has been recieved (i.e., third part of the handshake)? >> >> *If* you do this, yes, but there was consensus earlier that the WG >> didn't want the UTO exchange to be reliable, which is why this >> "attaching" the option to a byte is a MAY. > > Ah - it might be useful to explain that. I thought MAY implied that > the > information about reliability was in doubt, rather than that the > use of > the attachment was optional but would provide reliable UTO exchange > if used. The MAY is about that even though the spec says that an UTO is transmitted unreliably, *if* an implementation really wanted to, it could try to implement some local mechanisms to make transmission of its UTOs to the peer more reliable. (But it can't enforce reliability in the other direction.) >>> About retransmission, IMO, it SHOULD be done - or else what's the >>> point >>> of this? >> >> Is this related to your previous comment? If so, there was >> consensus to >> not make UTO reliable, i.e., retransmit lost options. > > I have no idea what the point of an unreliable option on a reliable > transport protocol means. IMO, options should be retransmitted when > their associated segments are. The control protocol ought to be at > least > as robust as the data. Although I appreciate that UTO isn't as > critical > as some other options or flags, introducing nondeterminism at this > level > doesn't seem appropriate, IMO. We had a long discussion on this a year or two ago on this list. The outcome was that because UTO is advisory, a simple, unreliable transmission is sufficient. We can certainly revisit this decision, but I'd personally would like to see strong WG consensus on changing this pretty central assumption behind UTO this late in the game. > I.e., I think there are separate questions: > > 1) is UTO critical enough to ensure correct exchange via > an explicitly ack'd handshake > no - I agree with the WG > > 2) should options associated with a segment be retransmitted > with that segment in general in TCP > I think the answer to this should be YES, always, > but I don't think it was asked. Lars
_______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm
- Re: [tcpm] WGLC for UTO Joe Touch
- [tcpm] Re: WGLC for UTO Mark Allman
- Re: [tcpm] WGLC for UTO Pasi Sarolahti
- Re: [tcpm] WGLC for UTO Joe Touch
- RE: [tcpm] WGLC for UTO Caitlin Bestler
- Re: [tcpm] WGLC for UTO Mark Allman
- [tcpm] WGLC for UTO Mark Allman
- RE: [tcpm] WGLC for UTO toby.moncaster
- Re: [tcpm] WGLC for UTO Lars Eggert
- Re: [tcpm] WGLC for UTO Pasi Sarolahti
- Re: [tcpm] WGLC for UTO Mark Allman
- Re: [tcpm] WGLC for UTO Pasi Sarolahti
- Re: [tcpm] WGLC for UTO Joe Touch
- Re: [tcpm] WGLC for UTO Brian Dickson
- Re: [tcpm] WGLC for UTO Lars Eggert
- Re: [tcpm] WGLC for UTO Joe Touch
- RE: [tcpm] WGLC for UTO Caitlin Bestler
- Re: [tcpm] WGLC for UTO Joe Touch
- RE: [tcpm] WGLC for UTO Caitlin Bestler
- Re: [tcpm] WGLC for UTO Lars Eggert
- Re: [tcpm] WGLC for UTO Joe Touch
- RE: [tcpm] WGLC for UTO Caitlin Bestler
- Re: [tcpm] WGLC for UTO Lars Eggert
- Re: [tcpm] WGLC for UTO Lars Eggert
- Re: [tcpm] WGLC for UTO Joe Touch
- Re: [tcpm] WGLC for UTO Lars Eggert
- Re: [tcpm] WGLC for UTO Ted Faber
- Re: [tcpm] WGLC for UTO Joe Touch
- Re: [tcpm] WGLC for UTO Joe Touch
- RE: [tcpm] WGLC for UTO toby.moncaster
- Re: [tcpm] WGLC for UTO Lars Eggert
- Re: [tcpm] WGLC for UTO (fwd) Alfred Hönes
- Re: [tcpm] WGLC for UTO (fwd) Lars Eggert