From groo@old-ones.com Fri Feb 27 15:12:51 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4C43A68A4 for ; Fri, 27 Feb 2009 15:12:51 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qY5tFvQUmkb for ; Fri, 27 Feb 2009 15:12:50 -0800 (PST) Received: from homiemail-a3.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 69C123A6862 for ; Fri, 27 Feb 2009 15:12:50 -0800 (PST) Received: from [192.168.1.100] (ool-4351bf61.dyn.optonline.net [67.81.191.97]) by homiemail-a3.dreamhost.com (Postfix) with ESMTP id 23D0AC54C3; Fri, 27 Feb 2009 15:13:12 -0800 (PST) Message-Id: From: Bill Squier To: christos@zoulas.com (Christos Zoulas) In-Reply-To: <20090227222910.4AAF55654E@rebar.astron.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 18:13:11 -0500 References: <20090227222910.4AAF55654E@rebar.astron.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Sun, 01 Mar 2009 18:38:37 -0800 Cc: groo@netbsd.org, James Chacon , tcpm@ietf.org, Fernando Gont , Jerry Leichter Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 23:16:43 -0000 On Feb 27, 2009, at 5:29 PM, Christos Zoulas wrote: > In article <49A83600.9090807@gont.com.ar> you write: >> Hello, folks, >> >> We have published a revision of our IETF Internet-Draft entitled >> "On the >> implementation of TCP urgent data". The document is available at: >> http://tools.ietf.org/id/draft-gont-tcpm-urgent-data-01.txt (you can >> also get the document in other fancy formats, such as PDF, at >> http://www.gont.com.ar/drafts). >> >> This document describes current issues relevant to the implementation >> and use of TCP urgent data, aims to change the IETF specifications so >> that they accommodate what virtually all implementations have been >> doing >> wrt urgent data. >> >> The TCPM working group of the IETF is currently deciding whether to >> adopt this document as a working group item, so that your input >> will be >> very much appreciated. >> >> To voice your opinion, please send it to tcpm@ietf.org, and CC me >> (fernando@gont.com.ar), so that I make sure that your post makes it >> to >> the mailing-list, even if you are not subscribed to it. >> (Alternatively, >> you can send me your input, and I could forward it to the tcpm@ietf.org >> mailing-list). > > The behavior on Windows is more complex than this. I think that it > maintains > much more data than a single byte and this can lead to resource > exhaustion. > This behavior is used and required to be present by SQL Server, so > Microsoft > is unwilling to change it. Bill Squier discovered > this and > can provide you with details. I haven't had time to read the article completely, but I did skim the Windows section, and Christos is correct. Windows exhausts a non- paged fixed size pool of kernel memory (leading to a crash) whenever the receiver does not drain OOB data. Thus, any Windows TCP receiver which does not expect OOB data is an avenue of attack. For example, the NetBIOS listener. I refer here to Windows versions <= XP. I have not performed any testing on Vista and later. Microsoft has been aware of this issue for years. Jerry and James can speak to whether they have ever addressed it. Further, I noticed that some of your analysis discusses OOB data bleeding in-line. This is almost certainly caused by an interaction (on the _sender_) of Nagle and the fact that TCP defines only a single OOB pointer. The receiver is not returning bytes which it knows to be OOB bytes inline, the _sender_ is accidentally placing more than a single byte of OOB in each packet that it sends. The receiver has no way to know that, as the only means of communication about OOB data between sender and receiver is a single pointer. I have added James and Jerry to this thread as well. [note to tcpm@ietf.org; we are not subscribers, please preserve the cc: if you wish to solicit our feedback] -wps From leichter@lrw.com Sat Feb 28 13:51:37 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443F13A69CD for ; Sat, 28 Feb 2009 13:51:37 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvmP-rnbXWR8 for ; Sat, 28 Feb 2009 13:51:36 -0800 (PST) Received: from smtp2.bestweb.net (smtp2.bestweb.net [209.94.103.42]) by core3.amsl.com (Postfix) with ESMTP id A00613A6870 for ; Sat, 28 Feb 2009 13:51:33 -0800 (PST) Received: from [10.0.1.3] (unknown [69.177.11.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.bestweb.net (Postfix) with ESMTPSA id 566ED119C38; Sat, 28 Feb 2009 16:51:56 -0500 (EST) Message-Id: <6F1AF259-F2A0-4266-8A92-C3712E9E1430@lrw.com> From: Jerry Leichter To: Fernando Gont In-Reply-To: <49A9A056.30207@gont.com.ar> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 28 Feb 2009 16:51:55 -0500 References: <20090227222910.4AAF55654E@rebar.astron.com> <49A9A056.30207@gont.com.ar> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Sun, 01 Mar 2009 18:38:37 -0800 Cc: ayourtch@cisco.com, groo@netbsd.org, James Chacon , tcpm@ietf.org, Bill Squier , Christos Zoulas Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 22:13:55 -0000 I haven't seen a copy of the paper, so I have to respond indirectly. Microsoft confirmed the problem. It was present in all their stacks prior to Vista. Based on our repeated complaints, they eventually produced a patch for XP. For some time, it was one of their "if you know to ask we'll give it to you" patches. For all I know, they eventually decided to roll it in to some regular patch release. The "OOB data leaking in line" has many causes. I know of at least two completely different mechanisms: - On the sender, the problem can occur because you can only send one OOB byte per segment, but there is no correlation between segments and OOB write requests. Consider the situation where the segmentation code wants to send a segment, and within the range of bytes it wants to send, there are two that were marked OOB. The only way to handle this correctly is to send two segments, even if one of them is artificially short - perhaps even a single byte. I haven't checked implementations in detail, but I've never seen this mentioned and I would be surprised if implementations get this right. - On the receiver, there is a messy case, the details of which I forget, in which the implementation doesn't keep enough state to properly handle two "close" OOB bytes. If you look in Stevens, he actually reproduces a comment from the original BSD code which describes the problem, but basically says "you lose". It's not clear anyone ever bothered to fix this. The fundamental issue is this: OOB bytes exist at the socket API level, but there is no such concept at the TCP level. The urgent pointer exists at the TCP level, but it's basically invisible at the socket API level. The theory is that you can use the urgent pointer to implement OOB bytes - and, in fact, that's true. I've convinced myself of this by writing out a semi-formal definition of the theoretical semantics at the two levels and sketching an implementation that actually presents the right semantics at the socket API level. I'm pretty sure that no one actually implements this right other than Microsoft (ironically) because it requires the ability to allocate space for OOB bytes at the receiver dynamically, and I know of no implementations that do so other than Microsoft's. By counting the allocated bytes against the window size you are willing you offer, you can avoid the problem that MS ran into, where there's no way to bound the amount of space allocated. The implementation is potentially expensive, but it's only expensive for applications that actually send many OOB bytes - which is a reasonable tradeoff. What actually happens is that the TCP stack implementers seem never to have believed in OOB on general principles, and in any case it seems that the TCP stack implementors (the network guys) and the socket API implementers (the OS guys) don't seem to talk to each other much. So this delicate implementation issue, which lives exactly at the interface between the two, gets lost in the shuffle. (Note that the multiple-OOB-bytes-in-a-segment problem probably cannot be solved without changing the TCP stack/socket API interface, since typically there is no way for the segmentation layer even to *see* that there are multiple outstanding OOB bytes: The only available interface is a single urgent pointer value that gets passed across.) There's an even more fundamental problem that it's worth pointing out: The actual urgent pointer protocol has a flaw. The UP is a 16- bit offset into the stream. As long as no segment can be more than 2^16 bytes - as was true when TCP was designed, because the windows size is represented in 16 bits - this works. But if you use scaled windows, it's possible to be in a situation where you need to send a UP value that cannot be represented, because it's too far into a large segment. There's an obvious work-around - send a short segment when this happens - but I doubt anyone does this. In fact, I would guess that the offset gets calculated ignoring the 16-bit limitation and the actual UP sent is the lower 16 bits of the true UP. Obviously, this can cause severe problems to any use of TCP that actually relies on the UP being correct! Finally, there's yet another level of problem: Some router-like devices (Cisco PIX firewalls - in their default configuration! - are a known example) simply turn off the Urgent bit! This is to block a very old (10+ years?) Windows bug. However, this is a disaster for any program that actually relies on OOB data/the UP. -- Jerry On Feb 28, 2009, at 3:36 PM, Fernando Gont wrote: > Bill Squier wrote: > > (Added Andrew Yourtchenko (draft co-author) to the recipient's list) > > Comments inline... > > >> I haven't had time to read the article completely, but I did skim the >> Windows section, and Christos is correct. > > IIRC, we did the windows tests with cygwin. Maybe this is what lead to > different results? > > That said, the next version of our Internet Draft will include text > describing the buggy implementations you are referring to. > > >> Further, I noticed that some of your analysis discusses OOB data >> bleeding in-line. This is almost certainly caused by an >> interaction (on >> the _sender_) of Nagle and the fact that TCP defines only a single >> OOB >> pointer. The receiver is not returning bytes which it knows to be >> OOB >> bytes inline, the _sender_ is accidentally placing more than a single >> byte of OOB in each packet that it sends. > > There is no problem with that. TCP just provides a mechanism for > marking > the end of urgent data. Just a mark. > > > >> The receiver has no way to know that, as the only means of >> communication >> about OOB data between sender and receiver is a single pointer. > > Exactly. Any data that's before the pointer should be considered > "urgent". > > Thanks! > > Kind 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 prvs=3056ab36b=jheitz@redback.com Sun Mar 1 20:26:37 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB5828C1FB for ; Sun, 1 Mar 2009 20:26:37 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vl+3q3Mxt0l9 for ; Sun, 1 Mar 2009 20:26:36 -0800 (PST) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 45B0028C1F7 for ; Sun, 1 Mar 2009 20:26:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,287,1233561600"; d="scan'208";a="79881" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 01 Mar 2009 20:27:02 -0800 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 06A1B3F68AD for ; Sun, 1 Mar 2009 20:27:02 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31316-10 for ; Sun, 1 Mar 2009 20:27:01 -0800 (PST) Received: from [127.0.0.1] (unknown [155.53.112.59]) by prattle.redback.com (Postfix) with ESMTP id 718E83F68AC for ; Sun, 1 Mar 2009 20:27:01 -0800 (PST) Message-ID: <49AB6016.40404@redback.com> Date: Sun, 01 Mar 2009 20:27:02 -0800 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: tcpm@ietf.org References: <20090227222910.4AAF55654E@rebar.astron.com> <49A9A056.30207@gont.com.ar> <6F1AF259-F2A0-4266-8A92-C3712E9E1430@lrw.com> In-Reply-To: <6F1AF259-F2A0-4266-8A92-C3712E9E1430@lrw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 04:38:42 -0000 inline... Jerry Leichter wrote: > I haven't seen a copy of the paper, so I have to respond indirectly. > > Microsoft confirmed the problem. It was present in all their stacks > prior to Vista. Based on our repeated complaints, they eventually > produced a patch for XP. For some time, it was one of their "if you > know to ask we'll give it to you" patches. For all I know, they > eventually decided to roll it in to some regular patch release. > > The "OOB data leaking in line" has many causes. I know of at least > two completely different mechanisms: > > - On the sender, the problem can occur because you can only send > one OOB byte per segment, but there is no correlation > between segments and OOB write requests. Consider the > situation where the segmentation code wants to send a > segment, and within the range of bytes it wants to send, > there are two that were marked OOB. The only way to handle > this correctly is to send two segments, even if one of them > is artificially short - perhaps even a single byte. I > haven't checked implementations in detail, but I've > never seen this mentioned and I would be surprised if > implementations get this right. > > - On the receiver, there is a messy case, the details of which > I forget, in which the implementation doesn't keep enough > state to properly handle two "close" OOB bytes. If you > look in Stevens, he actually reproduces a comment from > the original BSD code which describes the problem, but > basically says "you lose". It's not clear anyone ever > bothered to fix this. > > The fundamental issue is this: OOB bytes exist at the socket API > level, but there is no such concept at the TCP level. The urgent > pointer exists at the TCP level, but it's basically invisible at the > socket API level. The theory is that you can use the urgent pointer > to implement OOB bytes - and, in fact, that's true. I've convinced > myself of this by writing out a semi-formal definition of the > theoretical semantics at the two levels and sketching an > implementation that actually presents the right semantics at the > socket API level. I'm pretty sure that no one actually implements > this right other than Microsoft (ironically) because it requires the > ability to allocate space for OOB bytes at the receiver dynamically, > and I know of no implementations that do so other than Microsoft's. > By counting the allocated bytes against the window size you are > willing you offer, you can avoid the problem that MS ran into, where > there's no way to bound the amount of space allocated. The > implementation is potentially expensive, but it's only expensive for > applications that actually send many OOB bytes - which is a reasonable > tradeoff. > > What actually happens is that the TCP stack implementers seem never to > have believed in OOB on general principles, and neither does RFC 793. Urgent data does not represent OOB data. As soon as the urgent pointer is set, it means all data up to that point has become urgent. It wasn't urgent before. It basically means "The user has become bored with the output and has pressed Ctrl-C: all urgent data is to be flushed". Fine, this is just one interpretation, but if you fantasize any more into it than that, you run the risk of inventing really tiresome bugs. > and in any case it seems that the TCP stack implementors (the network > guys) and the socket API implementers (the OS guys) don't seem to talk > to each other much. So this delicate implementation issue, which > lives exactly at the interface between the two, gets lost in the > shuffle. (Note that the multiple-OOB-bytes-in-a-segment problem > probably cannot be solved without changing the TCP stack/socket API > interface, since typically there is no way for the segmentation layer > even to *see* that there are multiple outstanding OOB bytes: The only > available interface is a single urgent pointer value that gets passed > across.) There is never more than one OOB byte. Actually, there is never more than zero OOB btyes. If the urgent pointer changes, it means the user just pressed Ctrl-C again. Flush some more. > > There's an even more fundamental problem that it's worth pointing > out: The actual urgent pointer protocol has a flaw. The UP is a > 16-bit offset into the stream. As long as no segment can be more than > 2^16 bytes - as was true when TCP was designed, because the windows > size is represented in 16 bits - this works. But if you use scaled > windows, it's possible to be in a situation where you need to send a > UP value that cannot be represented, because it's too far into a large > segment. The urgent pointer is from the start of a segment, not the start of the window. How can you send a segment longer than 64k? The IP length field is only 16 bits. > There's an obvious work-around - send a short segment when this > happens - but I doubt anyone does this. In fact, I would guess that > the offset gets calculated ignoring the 16-bit limitation and the > actual UP sent is the lower 16 bits of the true UP. Obviously, this > can cause severe problems to any use of TCP that actually relies on > the UP being correct! > > Finally, there's yet another level of problem: Some router-like > devices (Cisco PIX firewalls - in their default configuration! - are a > known example) simply turn off the Urgent bit! This is to block a > very old (10+ years?) Windows bug. However, this is a disaster for > any program that actually relies on OOB data/the UP. > -- Jerry > > > On Feb 28, 2009, at 3:36 PM, Fernando Gont wrote: > >> Bill Squier wrote: >> >> (Added Andrew Yourtchenko (draft co-author) to the recipient's list) >> >> Comments inline... >> >> >>> I haven't had time to read the article completely, but I did skim the >>> Windows section, and Christos is correct. >> >> IIRC, we did the windows tests with cygwin. Maybe this is what lead to >> different results? >> >> That said, the next version of our Internet Draft will include text >> describing the buggy implementations you are referring to. >> >> >>> Further, I noticed that some of your analysis discusses OOB data >>> bleeding in-line. This is almost certainly caused by an interaction >>> (on >>> the _sender_) of Nagle and the fact that TCP defines only a single OOB >>> pointer. The receiver is not returning bytes which it knows to be OOB >>> bytes inline, the _sender_ is accidentally placing more than a single >>> byte of OOB in each packet that it sends. >> >> There is no problem with that. TCP just provides a mechanism for marking >> the end of urgent data. Just a mark. >> >> >> >>> The receiver has no way to know that, as the only means of >>> communication >>> about OOB data between sender and receiver is a single pointer. >> >> Exactly. Any data that's before the pointer should be considered >> "urgent". >> >> Thanks! >> >> Kind 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.com.ar Tue Mar 3 08:04:33 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B762A3A684F for ; Tue, 3 Mar 2009 08:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyJyk-BXBk9V for ; Tue, 3 Mar 2009 08:04:32 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 2B0183A6835 for ; Tue, 3 Mar 2009 08:04:31 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D534A6B6948 for ; Tue, 3 Mar 2009 13:04:59 -0300 (ART) Received: from [192.168.0.156] (235-131-17-190.fibertel.com.ar [190.17.131.235]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n23G4h6C020768; Tue, 3 Mar 2009 14:04:46 -0200 Message-ID: <49AD5520.1040607@gont.com.ar> Date: Tue, 03 Mar 2009 14:04:48 -0200 From: Fernando Gont User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 03 Mar 2009 13:04:56 -0300 (ART) Subject: [tcpm] Jerry Leichter: [Fwd: Re: On the implementation of TCP urgent data (IETF Internet Draft)] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:04:33 -0000 FYI -------- Original Message -------- Subject: Re: On the implementation of TCP urgent data (IETF Internet Draft) Date: Tue, 3 Mar 2009 10:14:55 -0500 From: Jerry Leichter To: Fernando Gont References: <20090227222910.4AAF55654E@rebar.astron.com> <49A9A056.30207@gont.com.ar> <6F1AF259-F2A0-4266-8A92-C3712E9E1430@lrw.com> <49A9B91A.7040100@gont.com.ar> <06E1ED3F-8652-4630-86D6-38F2C519228D@lrw.com> <49AC0DB8.5050007@gont.com.ar> OK, I read your draft. A number of comments: You refer to the data pointed to by the urgent pointer as the urgent data. This is incorrect. TCP doesn't directly have a concept of urgent *data*; what it has is an urgent *mode*. At best, you could describe data received while in urgent mode as being urgent data - and sometimes this is done. That's what the RFC means when it requires that any amount of urgent data must be supported: That one can send any amount of data while in urgent mode. And, in fact, you can - though you need to work at it: Since the UP can only be 2^16 bytes from the beginning of the current segment, what you need to do is keeping moving the UP forward as you send more data. There's no concept of "leaving and immediately re-entering urgent mode" - you simply stay in it. Note that this is a fine concept, but *it's completely unsupported by the socket API*. While the socket API can tell you that you've reached the end of the urgent data (a read() stops at the urgent byte, and there's an ioctl() that tells you that you've just read it), there's no way to know when you've *entered* urgent mode. At best, you can get a signal, but there's no way to figure out how that relates to the position in the TCP stream. (Of course, the TCP spec isn't entirely clear on how the sender can control when you enter urgent mode. At the receiver, it's easy: At the beginning of a segment that has UP set.) Given all that, I think your suggestion that there is no OOB data, only Urgent Mode, is exactly backwards. Unless I'm inside of the TCP stack, Urgent Mode is a meaningless concept. I can't control when it starts, I can't detect when it starts, I can't even ask if I'm *in* urgent mode. Yes, this is a TCP RFC, but it's simply repeating the existing problem: TCP implementers worry about urgent mode, socket API users see OOB data - and the how it all works remains a mystery. In fact, you consistently describe the socket API's that read OOB data as reading "urgent data". This is wrong; at best, it reads *the last byte* of urgent data. The rest of the urgent data is *always* read in line. You comment that based on tests under Cygwin, OOB data is always delivered in-line. If so, this is a Cygwin issue - I can tell you quite definitely that if you use the Windows socket implementation, by default OOB data does *not* get delivered in-line. You recommend that applications that use OOB data request that it be delivered in line. This is pointless - it fixes nothing. There are two cases: Either the code simply ignores the OOB setting, or it use an ioctl() to check if the last byte it just read was OOB. If the former - there's absolutely no point to using OOB data, hence no point to urgent mode. If the latter, the code is just as vulnerable as code that reads OOB data separately: When OOB data "slips in-band" in current implementations/middle boxes, *all information that it was ever OOB is lost*. A read won't be required to stop at that byte, and the ioctl() will never report that the byte was initially OOB. You've helped nothing. The RFC's today *do not allow* middle boxes to turn of the UP bit. Either we change the spec to completely eliminate the whole concept of urgent data, or we assert that the spec is right, and these middle boxes don't conform. It's absurd to specify something and then tell applications "well, it's in the spec, but you can't rely on it". And, frankly, if NDIS's can't get this right - too bad. Fix them. BTW, Microsoft actually *relies* on OOB data. I don't know the details - something to do with aborting database transactions. I expect you'd see significant opposition from them to an attempt to remove Urgent Mode from the specs. When you come right down to it, Urgent Mode as specified by TCP is unambiguous (ignoring the age-old RFC793/RFC961 which is irrelevant in today's world: Everyone has agreed on the same interpretation). The actual problems are: - Middle-box implementations that *illegally* modify data in transit; - Poorly specified, ambiguous definitions of how OOB data is supposed to work in the socket API; - Many incorrect implementations of the socket API. None of these can be fixed at the TCP spec level, since that's not where the problem is. (Well, the first is a matter of politics: Getting implementers to actually implement the specs as they exist!) So while I think it's important to raise these issues with IETF, this document is aimed at the wrong target. -- Jerry -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jmc@netbsd.org Mon Mar 2 20:18:51 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0D43A6A78 for ; Mon, 2 Mar 2009 20:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rp6pu4Miu38 for ; Mon, 2 Mar 2009 20:18:51 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 944AE3A6A59 for ; Mon, 2 Mar 2009 20:18:50 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with ESMTP id 4348063B120; Tue, 3 Mar 2009 04:19:14 +0000 (UTC) Message-Id: <2059A6D8-4BDA-44FF-827D-655814042138@netbsd.org> From: James Chacon To: Bill Squier In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 22:19:13 -0600 References: <20090227222910.4AAF55654E@rebar.astron.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Tue, 03 Mar 2009 08:08:09 -0800 Cc: groo@netbsd.org, Jerry Leichter , Christos Zoulas , Fernando Gont , tcpm@ietf.org Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 04:21:04 -0000 On Feb 27, 2009, at 5:13 PM, Bill Squier wrote: > > On Feb 27, 2009, at 5:29 PM, Christos Zoulas wrote: > >> In article <49A83600.9090807@gont.com.ar> you write: >>> Hello, folks, >>> >>> We have published a revision of our IETF Internet-Draft entitled >>> "On the >>> implementation of TCP urgent data". The document is available at: >>> http://tools.ietf.org/id/draft-gont-tcpm-urgent-data-01.txt (you can >>> also get the document in other fancy formats, such as PDF, at >>> http://www.gont.com.ar/drafts). >>> >>> This document describes current issues relevant to the >>> implementation >>> and use of TCP urgent data, aims to change the IETF specifications >>> so >>> that they accommodate what virtually all implementations have been >>> doing >>> wrt urgent data. >>> >>> The TCPM working group of the IETF is currently deciding whether to >>> adopt this document as a working group item, so that your input >>> will be >>> very much appreciated. >>> >>> To voice your opinion, please send it to tcpm@ietf.org, and CC me >>> (fernando@gont.com.ar), so that I make sure that your post makes >>> it to >>> the mailing-list, even if you are not subscribed to it. >>> (Alternatively, >>> you can send me your input, and I could forward it to the tcpm@ietf.org >>> mailing-list). >> >> The behavior on Windows is more complex than this. I think that it >> maintains >> much more data than a single byte and this can lead to resource >> exhaustion. >> This behavior is used and required to be present by SQL Server, so >> Microsoft >> is unwilling to change it. Bill Squier discovered >> this and >> can provide you with details. > > I haven't had time to read the article completely, but I did skim > the Windows section, and Christos is correct. Windows exhausts a > non-paged fixed size pool of kernel memory (leading to a crash) > whenever the receiver does not drain OOB data. Thus, any Windows > TCP receiver which does not expect OOB data is an avenue of attack. > For example, the NetBIOS listener. I refer here to Windows versions > <= XP. I have not performed any testing on Vista and later. > Microsoft has been aware of this issue for years. Jerry and James > can speak to whether they have ever addressed it. > > Further, I noticed that some of your analysis discusses OOB data > bleeding in-line. This is almost certainly caused by an interaction > (on the _sender_) of Nagle and the fact that TCP defines only a > single OOB pointer. The receiver is not returning bytes which it > knows to be OOB bytes inline, the _sender_ is accidentally placing > more than a single byte of OOB in each packet that it sends. > > The receiver has no way to know that, as the only means of > communication about OOB data between sender and receiver is a single > pointer. > Actually we have seen leaks in-band when simply sending one byte at a time of OOB. It appears if the distance between 2 bytes exceeds the available OOB marker (which from memory was 16 bits) and nothing reads on the receiving end then on some impls the bytes leak in-band. We've seen that on linux and on Solaris to my recollection. James From leichter@lrw.com Tue Mar 3 05:24:12 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88903A69BF for ; Tue, 3 Mar 2009 05:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkyqEaUNwMLq for ; Tue, 3 Mar 2009 05:24:12 -0800 (PST) Received: from smtp1.bestweb.net (smtp1.bestweb.net [209.94.103.41]) by core3.amsl.com (Postfix) with ESMTP id 186943A69E7 for ; Tue, 3 Mar 2009 05:24:11 -0800 (PST) Received: from [10.0.1.3] (unknown [69.177.11.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.bestweb.net (Postfix) with ESMTPSA id 8E5951254F5; Tue, 3 Mar 2009 08:24:37 -0500 (EST) Message-Id: <5D3A745D-9B59-4B31-87DB-23B29666A21D@lrw.com> From: Jerry Leichter To: James Chacon In-Reply-To: <2059A6D8-4BDA-44FF-827D-655814042138@netbsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 08:24:36 -0500 References: <20090227222910.4AAF55654E@rebar.astron.com> <2059A6D8-4BDA-44FF-827D-655814042138@netbsd.org> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Tue, 03 Mar 2009 08:08:09 -0800 Cc: groo@netbsd.org, tcpm@ietf.org, Christos Zoulas , Bill Squier , Fernando Gont Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 13:24:13 -0000 On Mar 2, 2009, at 11:19 PM, James Chacon wrote: > Actually we have seen leaks in-band when simply sending one byte at > a time of OOB. It appears if the distance between 2 bytes exceeds > the available OOB marker (which from memory was 16 bits) and nothing > reads on the receiving end then on some impls the bytes leak in-band. > > We've seen that on linux and on Solaris to my recollection. I don't dispute the observations, but the explanation makes no sense to me. Yes, the Urgent Pointer is a 16-bit offset from the beginning of the segment in which it appears (or something very much like that). It would make no sense to store the UP position as just the 16- bit offset inside the implementation, since that's impossible to interpret without the segment starting point. The received segment itself already has the (32 bit) position in the stream of the segment, and the pair is unambiguous. An implementation could store the pair, but why? The 32-bit sum of the UP and the segment starting position is 2 bytes smaller and contains exactly the same information. With bugs anything is possible, of course, but it's hard to see why having the distance between successive OOB bytes being > 2^16 should be significant in and of itself. How was this tested? Are you sure it's really "gap > 2^16" or could it be "gap large enough" or "enough data buffered"? I can see this leading to the failure mode that I described earlier: User receiver hasn't read data for a long time; receiving TCP lets its receive window close as it's running out of buffer space; data piles up in sender's TCP stack buffers; eventually we have two OOB bytes within the data to be sent; sender doesn't keep track of this, or tries to send a segment with two OOB bytes and can only encode one. -- Jerry From jmc@netbsd.org Tue Mar 3 07:24:18 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F023A67BD for ; Tue, 3 Mar 2009 07:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJqAvaoM844F for ; Tue, 3 Mar 2009 07:24:17 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 459753A6452 for ; Tue, 3 Mar 2009 07:24:17 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with ESMTP id 2886263B101; Tue, 3 Mar 2009 15:24:42 +0000 (UTC) Message-Id: <9C2D995C-D556-4669-86C6-68CF9C17F20F@netbsd.org> From: James Chacon To: Jerry Leichter In-Reply-To: <5D3A745D-9B59-4B31-87DB-23B29666A21D@lrw.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 09:24:41 -0600 References: <20090227222910.4AAF55654E@rebar.astron.com> <2059A6D8-4BDA-44FF-827D-655814042138@netbsd.org> <5D3A745D-9B59-4B31-87DB-23B29666A21D@lrw.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Tue, 03 Mar 2009 08:08:09 -0800 Cc: groo@netbsd.org, tcpm@ietf.org, Christos Zoulas , Bill Squier , Fernando Gont Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:24:18 -0000 On Mar 3, 2009, at 7:24 AM, Jerry Leichter wrote: > On Mar 2, 2009, at 11:19 PM, James Chacon wrote: >> Actually we have seen leaks in-band when simply sending one byte at >> a time of OOB. It appears if the distance between 2 bytes exceeds >> the available OOB marker (which from memory was 16 bits) and >> nothing reads on the receiving end then on some impls the bytes >> leak in-band. >> >> We've seen that on linux and on Solaris to my recollection. > I don't dispute the observations, but the explanation makes no sense > to me. Yes, the Urgent Pointer is a 16-bit offset from the > beginning of the segment in which it appears (or something very much > like that). It would make no sense to store the UP position as just > the 16-bit offset inside the implementation, since that's impossible > to interpret without the segment starting point. The received > segment itself already has the (32 bit) position in the stream of > the segment, and the pair is unambiguous. An implementation could > store the pair, but why? The 32-bit sum of the UP and the segment > starting position is 2 bytes smaller and contains exactly the same > information. > > With bugs anything is possible, of course, but it's hard to see why > having the distance between successive OOB bytes being > 2^16 should > be significant in and of itself. How was this tested? Are you sure > it's really "gap > 2^16" or could it be "gap large enough" or > "enough data buffered"? I can see this leading to the failure mode > that I described earlier: User receiver hasn't read data for a long > time; receiving TCP lets its receive window close as it's running > out of buffer space; data piles up in sender's TCP stack buffers; > eventually we have two OOB bytes within the data to be sent; sender > doesn't keep track of this, or tries to send a segment with two OOB > bytes and can only encode one. > -- Jerry > It's entirely possible your reasoning is also the cause. To be honest I never felt like diving into linux networking code to figure out the reason :) I just know we have a reasonably reliable test which can replicate this on linux and the likelihood of seeing that fixed was low based on experiences with the select API and it's bugs. James From fernando@gont.com.ar Tue Mar 3 08:51:12 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2669F3A684F for ; Tue, 3 Mar 2009 08:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHFd4R+cL9RR for ; Tue, 3 Mar 2009 08:51:10 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id B8F7A3A67AD for ; Tue, 3 Mar 2009 08:51:08 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4EE446B6954; Tue, 3 Mar 2009 13:51:38 -0300 (ART) X-ClientAddr: 190.17.131.235 Received: from [192.168.0.156] (235-131-17-190.fibertel.com.ar [190.17.131.235]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n23GpNqr030059; Tue, 3 Mar 2009 14:51:24 -0200 Message-ID: <49AD5FE4.4040100@gont.com.ar> Date: Tue, 03 Mar 2009 14:50:44 -0200 From: Fernando Gont User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Jerry Leichter References: <20090227222910.4AAF55654E@rebar.astron.com> <49A9A056.30207@gont.com.ar> <6F1AF259-F2A0-4266-8A92-C3712E9E1430@lrw.com> <49A9B91A.7040100@gont.com.ar> <06E1ED3F-8652-4630-86D6-38F2C519228D@lrw.com> <49AC0DB8.5050007@gont.com.ar> <8E1A8673-2072-4339-BE82-95AE85AA44C7@lrw.com> In-Reply-To: <8E1A8673-2072-4339-BE82-95AE85AA44C7@lrw.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 03 Mar 2009 13:51:34 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:51:12 -0000 Jerry Leichter wrote: > You refer to the data pointed to by the urgent pointer as the urgent > data. This is incorrect. TCP doesn't directly have a concept of urgent > *data*; what it has is an urgent *mode*. [....] This was the intent of the text. I'll go through the I-D again and will try to remove any instances of what you describe. > Note that this is a fine concept, but *it's completely unsupported by > the socket API*. While the socket API can tell you that you've reached > the end of the urgent data (a read() stops at the urgent byte, and > there's an ioctl() that tells you that you've just read it), there's no > way to know when you've *entered* urgent mode. At best, you can get a > signal, but there's no way to figure out how that relates to the > position in the TCP stream. Not sure what you mean. > Given all that, I think your suggestion that there is no OOB data, only > Urgent Mode, is exactly backwards. Isn't this the converse of what you stated at the very beginning of your post?? > Unless I'm inside of the TCP stack, > Urgent Mode is a meaningless concept. I can't control when it starts, I > can't detect when it starts, I can't even ask if I'm *in* urgent mode. huh? What about SIOCATMARK? > You comment that based on tests under Cygwin, OOB data is always > delivered in-line. If so, this is a Cygwin issue - I can tell you quite > definitely that if you use the Windows socket implementation, by default > OOB data does *not* get delivered in-line. Will try this. > You recommend that applications that use OOB data request that it be > delivered in line. This is pointless - it fixes nothing. This is the intented semantincs for TCP urgent mode. And nevertheless, the code should be prepared to handle "urgent data" in-band, because some middle-boxes while clear the URG bit, thus effectively putting "urgent data" back "in-line". > The RFC's today *do not allow* middle boxes to turn of the UP bit. And what? These are widely-deployed middleboxed. If your app depends on tcp urgent mode, it will break. > Either we change the spec to completely eliminate the whole concept of > urgent data, or we assert that the spec is right, and these middle boxes > don't conform. It's absurd to specify something and then tell > applications "well, it's in the spec, but you can't rely on it". It's absurd to neglect what's a fact. > And, > frankly, if NDIS's can't get this right - too bad. Fix them. This is impossible. The issue here is that there's the semantics of the UP as specified by the IETF specs, and there are the semantics that real implementations are using (which can be overridden by a system-wide toggle). > BTW, Microsoft actually *relies* on OOB data. I don't know the > details - something to do with aborting database transactions. I expect > you'd see significant opposition from them to an attempt to remove > Urgent Mode from the specs. Microsoft's implementation of TCP urgent mode is completely broken. Shame on them. > When you come right down to it, Urgent Mode as specified by TCP is > unambiguous (ignoring the age-old RFC793/RFC961 which is irrelevant in > today's world: Everyone has agreed on the same interpretation). The > actual problems are: > > - Middle-box implementations that *illegally* modify data in transit; huh? You claim that RFC 793 is irrelevant, and then claim that clearing the UP is illegal???? > None of these can be fixed at the TCP spec level, since that's not where > the problem is. (Well, the first is a matter of politics: Getting > implementers to actually implement the specs as they exist!) This is completely wrong. If you get implementers to implement the specs as they exist, you'd be e.g. changing the semantics of the urgent pointer (UP), which would basically break all those applications that have not yet been broken by middleboxes clearing the URG bit. Our draft aims at: * Clarifying the concept of TCP urgent mode (no "out of band" data channel. Simply a mark that signals whether you are in urgent mode or not) * Changing the specs so that the semantics of the UP accommodate all real implementations (i.e., "poinst to the last byte of urgent data" vs. "points to the byte following the last byte of urgent data". * Raising awareness about "urgent mode" not being reliable in the current Internet (e.g., Cisco PIX clears the URG bit). > So while I > think it's important to raise these issues with IETF, this document is > aimed at the wrong target. I'm not sure what's the target you think our I-D should aim at. Thanks! Kind 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 sallyfloyd@mac.com Tue Mar 3 14:19:51 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA483A6A14 for ; Tue, 3 Mar 2009 14:19:51 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDIjM+Hd1zRb for ; Tue, 3 Mar 2009 14:19:50 -0800 (PST) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by core3.amsl.com (Postfix) with ESMTP id 7235D3A68DC for ; Tue, 3 Mar 2009 14:19:50 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [192.168.1.85] ([70.132.3.41]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KFY00940BD9U590@asmtp020.mac.com> for tcpm@ietf.org; Tue, 03 Mar 2009 14:19:58 -0800 (PST) Message-id: From: Sally Floyd To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" In-reply-to: Date: Tue, 03 Mar 2009 14:19:56 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-ecnsyn-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 22:19:51 -0000 Eddy - Email from Feb. 12: > The chairs would like to start are 1-week TCPM working group > last call on draft-ietf-tcpm-ecnsyn-07 starting now, as this > draft has previously cleared WGLC modulo some alterations, > and some support has been expressed for the modifications. > Please comment by February 20. > > The draft is at: > http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-07 > > It's targeted for Proposed Standard, and given the prior > clearance of the WGLC state, we'll assume lack of any > expressed concerns will mean that it's ready to go > forward. There was feedback from Mark Allman on this, saying "Ship it." So is this ready to be forwarded to the IESG? (Just trying to wrap up loose ends...) Thanks, - Sally http://www.icir.org/floyd/ From A.Hoenes@tr-sys.de Tue Mar 3 18:48:17 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573FE3A68EC for ; Tue, 3 Mar 2009 18:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.28 X-Spam-Level: ** X-Spam-Status: No, score=2.28 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kd-Whsl08bNu for ; Tue, 3 Mar 2009 18:48:16 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 738EE3A67FD for ; Tue, 3 Mar 2009 18:48:15 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA230914808; Wed, 4 Mar 2009 03:46:48 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id DAA22822; Wed, 4 Mar 2009 03:46:47 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200903040246.DAA22822@TR-Sys.de> To: tcpm@ietf.org Date: Wed, 4 Mar 2009 03:46:46 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-ecnsyn-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 02:48:17 -0000 Sally, folks, First of all my apologies for having missed the WGLC because of the misbehaving upgraded Mailman instance that eventually has been fixed today by the Secretariat ... I generally agree that this document has a very useful direction, and I do not really want to hold it off in any way. However, as I had written in November off-list to the authors: > I have quickly followed up to your revised ECN SYN/ACK draft, > draft-ietf-tcpm-ecnsyn-07. > An interesting evolution of results! > > Since I guess there will be more follow-up research and more updates > to the draft, I defer another full pass over the document until later. > > For the moment, only ... /snip/ My assumption about continued research efforts had not been opposed by the authors in November, but I have not heard of any additional results announced to the wg since. Have there been more results in the meantime confirming the results that lead to the -07 modifications? Are we sure in the meantime that other scenarios and modified parameters will not lead, perhaps in the short term, to another shift in the observations from simulation results? I would not have any concerns if the draft were targeting Experimental, but it aims at Standards Track. Last year, at the first WGLC, all seemed rather stable, but now? Will the IESG challenge the soundness of the proposal, due to the recent change? How can we convince the IESG that the proposal is ripe for PS? Personally, I do not seriously expect additional research killing the arguments for the proposed algorithm, but additional results might still change the perspective slightly. I would appreciate to hear more than one voice from the research community regarding these considerations. A WGLC based on a single 'heavy-weight' +1 might not suffice to provide evidence of "strong support" to the IESG. Thus, the question arises whether the *normative* part of the proposal should better be split off into a relatively short PS document, accompanied by an Informational document with the detailed presentation of the motivation, quantitative research results and related work, etc. The former would be more concise and perhaps be preferred by implementers, and the latter could more easily be updated or amended if additional results became available. I'll try to resume the incremental review that had been paused in November quickly now and, if necessary, report more editorials to the authors within a few days. I do not insist on the split proposal made above, but I would appreciate it being discussed and the decision for progress be made based on consideration of the possible consequences of new results. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From taddyhatty@nifty.com Tue Mar 3 19:03:39 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A583A6A66 for ; Tue, 3 Mar 2009 19:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.292 X-Spam-Level: ** X-Spam-Status: No, score=2.292 tagged_above=-999 required=5 tests=[AWL=1.691, BAYES_50=0.001, J_CHICKENPOX_83=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+u7nLFq9CKO for ; Tue, 3 Mar 2009 19:03:38 -0800 (PST) Received: from userg501.nifty.com (userg501.nifty.com [202.248.238.81]) by core3.amsl.com (Postfix) with ESMTP id 603FC3A67FD for ; Tue, 3 Mar 2009 19:03:38 -0800 (PST) Received: from GATEWAY (nttkyo839039.tkyo.nt.ftth.ppp.infoweb.ne.jp [116.83.8.39])by userg501.nifty.com with SMTP id n2433w8f016988 for ; Wed, 4 Mar 2009 12:03:58 +0900 DomainKey-Signature: a=rsa-sha1; s=userg501; d=nifty.com; c=nofws; q=dns; h=message-id:reply-to:from:to:subject:date:organization: mime-version:content-type:content-transfer-encoding:x-priority: x-msmail-priority:x-mailer:x-mimeole; b=bfmlpfSo/xtik81LLnm1nb7/pWWHF0TkNcfjavtzWN9jHyA9DfGVSrD82ztWaIDHB i61bV46X+O2ibT6fquU9g== X-Nifty-SrcIP: [116.83.8.39] Message-ID: <27F09CEBE1E4455E9103957793C5B6AD@GATEWAY> From: "Tadayuki Abraham HATTORI" To: Date: Wed, 4 Mar 2009 12:03:58 +0900 Organization: TaddyHatty MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [tcpm] Proposal of democratic communication protocols, considering extensions of TCP/IP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tadayuki Abraham HATTORI List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 03:05:09 -0000 Dear professionals and experts, I'm looking for the discussion area about the communication technology for democratic activities, in order to create new RFC for democratic communication protocols considering the extensions of TCP/IP, and the central controlled information systems. Sincerely. Please give me recommendation or advices. Regards, --- Abraham TaddyHatty taddyhatty@acm.org taddyhatty@nifty.com ---------- Internet Draft for extension of the fundamental concpt of TCP/IP Donation for Political Party and The Digital Money System The Critical Social Security Hole of the Numerical Computer Architecture, Operating System and The TCP/IP Networking Abraham TADDYHATTY taddyhatty@acm.org T.B.D 1. Introduction The present computer architecture was originally invented as a numerical calculater. As you may know, the main circuit of central pocesser unit is indeed an arithmetic calculater. It was not created as an accelerator of interaction of humanities. Of cource, many core processor is also. As you may know, the CPU of computer is contorolled by Operationg System. And the concept of Operationg System was originally invented for both abstraction of hardware and resource management. It is originally invented by the programmer's point of view, so, the role of Operationg System can be said to be just making programming efficiently. Generally, in Operationg System, the power of controlling information is centrally concentrated. Is it adespotism? Is there no need to consider the separation of the power? And also, the TCP/IP networking was originally designed as a military network. It was invented for the objective of efficient communication in troop or army, not for optimization of democracy. There is no need to say, grasping and controlling information among people is a kind of power. In designing TCP/IP networking, the meaning of separation of the power among citizen was not considered. In modern nations, why the power is separated? for example, justice, legislation and administration. What is the principle of separation of the power? Does the scientific theorem of separation of the power exist ? Who should have the power grasping information among people? Historically both Operating System and the TCP/IP networking was not designed for optimization of democratic activities, so, using Operating System and the TCP/IP networking, the power of controling information will be centrally concentrated, and putting democracy out of balance. By the way, generally, we have two choices for understanding a nation. One is that a nation is considered as a set of organizations, and people always should belong to some organization. And another is that a nation is considered as a set of people or family, and organizations is just a method for people not a objective of people. Reminding and considering an idea of democratic egalitarianism, the correct answer is the later, a nation should be considered as a set of people. Any organization should be considered as just a method for people, not a objective for people. Using Operationg System and the TCP/IP networking as bridges of communication of humanities, the power to control information will be centrally gathered,and so, the companies or public organizations centric information system is tend to be constructed. Because the power of controlling information is gathered to managers of companies, and the managers of campanies are easy to modify or hide information of social system. For example, people can't check the duration for political parties by huge companies with the digital money through the TCP/IP networking. It would be difficult to check evil informatic activities by managers of campanies. As I mentioned above, a nation should be considered as a set of citizen, not a set of military organization, the trend will put democracy out of balance. Because democratic activities depends upon intensive gathering of people's decision making with correct balanced distributin of information. Generally, in a democratic nation, each people is both value judger and decision maker. Most of all, in the digital money system based upon Operating System and the TCP/IP networking, duration for political party by managers of large campanies can't be publically controlled. Because the current digital money system is based upon OS and the TCP/IP networking, the power to contol information is centrally gathered to managers. The organization oriented information system bring putting a national democracy out of balance. Basically, for public infrastructure such as digital money system, Operating System and the TCP/IP networking should not be used. We must modify the specifications, I think. Should we choose the central controlled information system in order to construct public digital money system ? Is it a correct choice? We should remember the faces of the people who selling digital money system. We should remind the faces of th people who promoting numerical computer network for social infrastructures. What ware thay saying ? Was their thought is sufficient? Was their insight is enough? Who was showing the academic direction and the trend of information science? There is no need to say, high level decision making is always going to affect the future rewards of people and the satisfaction of nation. When we discuss the communication technology for optimization of democratic activities, we should truely be careful of the history and the culture of each nations, and the deep insight will be required. So, I propose a concept of academic criminals. The concept is created for judging high level decision making in academic opinions and activities. Generally, academic opinions and activities can't be reviced by current social system such as administration justice and legislation. Because the present social systems always should be focusing the present problems, not focusing the far future of civilization. The intellectual method of prediction of the future should be included in academic activities. Historically, our civilization have been formed with characters, languages, mathematics and any culture based upon both paper and ink which have been used for a long time. As you may know, these tools are now going to be replaced with electro-maginetic-optical devices. It means that renovation of civilization is indeed under going. The concept of Academic Criminals will be useful for keeping general dicision making of direction of academic activities and opinions in balance, I think. Ultimate goal of this matter is finding out the theorem for how to locate the power to control information among the communication road of the people, where the power to control information should be located, and how to modify the location of the power to control information. And, according to the theorem, the specifications of Operationg System and the TCP/IP networking should be modified, I think. Generally, democratic systems can't be constructed by capitalism. It would be formed depending upon the idea or the theorem, I beleave. Sincerely. --- Abraham TaddyHatty taddyhatty@acm.org taddyhatty@nifty.com From lars.eggert@nokia.com Wed Mar 4 02:33:10 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935423A67BD for ; Wed, 4 Mar 2009 02:33:10 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvCD03hGaIMK for ; Wed, 4 Mar 2009 02:33:09 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 43E373A69CD for ; Wed, 4 Mar 2009 02:32:41 -0800 (PST) Received: from dhcp151.dagstuhl.de (dhcp151.dagstuhl.de [192.76.146.151]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n24AX3eq085655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Mar 2009 12:33:04 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <93FEE0ED-49F7-4A8B-8576-7BD6C07C62BD@nokia.com> From: Lars Eggert To: ah@tr-sys.de In-Reply-To: <200903040246.DAA22822@TR-Sys.de> Content-Type: multipart/signed; boundary=Apple-Mail-119-157540802; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 11:32:58 +0100 References: <200903040246.DAA22822@TR-Sys.de> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Wed, 04 Mar 2009 12:33:04 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9066/Wed Mar 4 08:03:21 2009 on fit.nokia.com X-Virus-Status: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-ecnsyn-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 10:33:10 -0000 --Apple-Mail-119-157540802 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-3-4, at 3:46, ah@tr-sys.de wrote: > I would not have any concerns if the draft were targeting > Experimental, but it aims at Standards Track. > > Last year, at the first WGLC, all seemed rather stable, but now? > Will the IESG challenge the soundness of the proposal, due to > the recent change? > How can we convince the IESG that the proposal is ripe for PS? the working group is the body of technical expertise for a given area of work. The IESG needs to make sure that the working group output doesn't conflict with work in other areas or with the overall architecture, but it is IMO not our job to rehash the detailed technical work and argumentation that lead the working group down a path to a proposed solution. In other words, if the WG has consensus for something, the IESG will normally trust their judgement. So, is the WG feels that ecnsyn is sufficiently well understood for PS, I don't see a reason why the IESG would disagree with that. (It sometimes happens, but that is rare.) > Personally, I do not seriously expect additional research killing > the arguments for the proposed algorithm, but additional results > might still change the perspective slightly. > I would appreciate to hear more than one voice from the research > community regarding these considerations. > A WGLC based on a single 'heavy-weight' +1 might not suffice to > provide evidence of "strong support" to the IESG. Additional results are always nice and useful, but the question at this time is: does the WG have consensus for asking for publication as PS? The purpose of the last call is to establish this consensus. > Thus, the question arises whether the *normative* part of the > proposal should better be split off into a relatively short PS > document, accompanied by an Informational document with the > detailed presentation of the motivation, quantitative research > results and related work, etc. > The former would be more concise and perhaps be preferred by > implementers, and the latter could more easily be updated or > amended if additional results became available. I don't think splitting the document is useful. Lars > I'll try to resume the incremental review that had been paused > in November quickly now and, if necessary, report more editorials > to the authors within a few days. > > I do not insist on the split proposal made above, but I would > appreciate it being discussed and the decision for progress > be made based on consideration of the possible consequences > of new results. > > > Kind regards, > Alfred. > > -- > > +------------------------ > +--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- > Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: > -18 | > | D-71254 Ditzingen | E-Mail: ah@TR- > Sys.de | > +------------------------ > +--------------------------------------------+ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-119-157540802 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTAzMDQxMDMyNThaMCMGCSqGSIb3DQEJBDEWBBSfZcIfZe8Sjnf0 WhBU1mwMIQXjdjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEANsdT2pHymYSnTEYvIRHRSPwe8X7pbtrfHwgzJY//LNv7+FngmBH+ 5vJgg6TbPw6DMV91bN5hp/HnCGdAmiy6F6y5uYqOoeLox7EnAQ6Q3lYJu9TxrJeYBGoUipMAWzP1 /CyopR9KDdzhgirFDMYT/HIqxaIDWOkQEwD65PqNFrR76wOqzQBt+51pZBfzyU73dmNkxNCf49PI OR/yum6H8I5YiR8raTKpTFY6B/BMsTIbtDLW+qn8GRIo/yfw929g1no0jnH16tYIDI0+FOCW/Fp+ IXj93PZb655OPWuL5z+RVIqz4/Zx2whQ1TnxzIbW76dlGriUrLSKfEceDCn4WwAAAAAAAA== --Apple-Mail-119-157540802-- From root@core3.amsl.com Wed Mar 4 10:45:02 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 22C3A28C150; Wed, 4 Mar 2009 10:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090304184502.22C3A28C150@core3.amsl.com> Date: Wed, 4 Mar 2009 10:45:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpmss-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:45:02 -0000 --NextPart 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 : TCP Options and MSS Author(s) : D. Borman Filename : draft-ietf-tcpm-tcpmss-00.txt Pages : 3 Date : 2009-03-04 This memo discusses what value to use with the TCP MSS option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpmss-00.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpmss-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-04104153.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Mar 4 15:30:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4766928C39E; Wed, 4 Mar 2009 15:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090304233001.4766928C39E@core3.amsl.com> Date: Wed, 4 Mar 2009 15:30:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-1323bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:30:01 -0000 --NextPart 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 : TCP Extensions for High Performance Author(s) : D. Borman, et al. Filename : draft-ietf-tcpm-1323bis-01.txt Pages : 47 Date : 2009-03-04 This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC 1323. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-1323bis-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-1323bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-04152332.I-D@ietf.org> --NextPart-- From david.borman@windriver.com Wed Mar 4 16:20:48 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5AE3A6A97 for ; Wed, 4 Mar 2009 16:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-2.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MANGLED_BACK=2.3, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhivZG37595G for ; Wed, 4 Mar 2009 16:20:43 -0800 (PST) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id D26B73A69EE for ; Wed, 4 Mar 2009 16:20:43 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n250LBqZ028763 for ; Wed, 4 Mar 2009 16:21:11 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 16:21:10 -0800 Received: from [172.25.44.5] ([172.25.44.5]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 16:21:09 -0800 Message-Id: From: David Borman To: tcpm@ietf.org In-Reply-To: <20090304233001.4766928C39E@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 18:21:08 -0600 References: <20090304233001.4766928C39E@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 05 Mar 2009 00:21:10.0138 (UTC) FILETIME=[48BD2DA0:01C99D28] Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-1323bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 00:20:48 -0000 Hi, I've just posted a new revision of 1323bis. I've tried to incorporate all the things from the Philadelphia meeting, including adding a real Security Considerations section. Some of my notes were a bit cryptic, as were the TCPM Meeting Minutes, so I've probably missed some things there. I'm attaching diffs from -00 to -01, that I've edited down to eliminate the trivial changes (like changing "RFC-XXXX" to "RFC XXXX", boilerplate changes, page alignment, etc.) Note that I've pulled out the TCP MSS discussion, and have posted that in a separate ID. I know there are more changes that will need to be done to this document, for example I there are changes that should be made due to Fernando's Timestamps document. But I wanted to get a new version of this out. A couple other things I've added: o) The shrinking window issue Matt Mathis brought up, due to the granularity of using the window scale option o) More comments on the need to adjust the RTO calculator when you are taking more RTTM samples per RTT. I'd also like to thank Alfred Hines for an off-list review of -00 that he sent me, many of his suggestions are incorporated in this document. So, please look over the new document, and please point out on the mailing list any additional changes that need to be made to this document. It's getting closer to something that we can publish, so the more feedback the better. This will be added to the agenda in the TCPM WG in San Francisco, and it'd be nice if we could bring up any new issues on the mailing list, prior to the meeting. :-) -David Borman 98,100c124,127 < 1 ms to 100 seconds. Work on TCP performance has shown that TCP can < work well over a variety of Internet paths, ranging from 800 Mbit/ sec < I/O channels to 300 bit/sec dial-up modems [Jacobson88a]. --- > 1 ms to 100 seconds. Work on TCP performance has shown that TCP > without the extensions described in this memo can work well over a > variety of Internet paths, ranging from 800 Mbit/sec I/O channels to > 300 bit/sec dial-up modems [Jacobson88a]. 137,143c156,161 < High-capacity packet satellite channels (e.g., DARPA's Wideband < Net) are LFN's. For example, a DS1-speed satellite channel has a < bandwidth*delay product of 10**6 bits or more; this corresponds to < 100 outstanding TCP segments of 1200 bytes each. Terrestrial < fiber-optical paths will also fall into the LFN class; for < example, a cross-country delay of 30 ms at a DS3 bandwidth < (45Mbps) also exceeds 10**6 bits. --- > High-capacity packet satellite channels are LFN's. For example, a > DS1-speed satellite channel has a bandwidth*delay product of 10**6 > bits or more; this corresponds to 100 outstanding TCP segments of > 1200 bytes each. Terrestrial fiber-optical paths will also fall > into the LFN class; for example, a cross-country delay of 30 ms at > a DS3 bandwidth (45Mbps) also exceeds 10**6 bits. 185,189c203,207 < LFN. In addition, if a congestion control mechanism based < upon some form of random dropping were introduced into < gateways, randomly spaced packet drops would become common, < possible increasing the probability of dropping more than one < packet per window. --- > LFN. In addition, since the publication of RFC 1323, > congestion control mechanism based upon some form of random > dropping have been introduced into gateways, and randomly > spaced packet drops have become common; this increases the > probability of dropping more than one packet per window. 313c356 < ARPANET 56kbps 7KBps 3*10**5 (~3.6 days) --- > Dialup 56kbps 7KBps 3*10**5 (~3.6 days) 316a360 > 10mbit 321c365,366 < FDDI 100Mbps 12.5MBps 170 --- > 100mbit > Ethernet 100Mbps 12.5MBps 170 323c368,369 < Gigabit 1Gbps 125MBps 17 --- > Gigabit > Ethernet 1Gbps 125MBps 17 329,332c375,378 < the other hand, at DS3 and FDDI speeds, Twrap is comparable to the --- > the other hand, at DS3 and 100mbit speeds, Twrap is comparable to 613a659,669 > When a non-zero scale factor is in use, there are instances when a > retracted window can be offered [Mathis08]. The end of the window > will be on a boundary based on the granularity of the scale factor > being used. If the sequence number is then updated by a number of > bytes smaller than that granularity, the TCP will have to either > advertise a new window that beyond what it previously advertised > (and perhaps beyond the buffer), or will have to advertise a > smaller window, which will cause the TCP window to shrink. > Implementations should ensure that they handle a shrinking window, > as specified in section 4.2.2.16 of RFC 1122 [Braden89]. > 724,725c780,785 < without a TSopt may be ACKed and dropped without further < processing. --- > without a TSopt may dropped without further processing, and an > ACK of the current SND.UNA generated. > > In the case of crossing SYN packets where one SYN contains a > TSopt and the other doesn't, both sides should put a TSopt in > the segment. 747,748c807 < received in a TSval field; these echoed values. labelled < "TS.Recent", are shown in parentheses. --- > received in a TSval field. 755,780c813 < < TCP A TCP B < < (TS.Recent) (TS.Recent) < < 1. (120) ---> (1) < < 2. (125) <--- (1) < < 3. (125) ---> (6) < < 4. (130) <--- (6) < < . . . ( Pause for 60 timestamp clock ticks ) . . . . < < < 5. (130) ---> (1) < < 6. (125) <--- (1) < < 4. (127) ---> ... < < 5. ... <--- (5) < 830c855,863 < into account the more frequent RTTMs. For example, --- > into account the more frequent RTTMs. For example, an > implementation could choose to just use one sample per RTT to > update the RTO estimator, or or vary the gain based on the > congestion window, or take an average of all the RTTM measurements > received over one RTT, and then use that value to update the RTO > estimator. This document does not prescribe any particular method > for modifying the RTO estimator, the important point is that the > implementation should do something more than just feeding > additional RTTM samples from one RTT into the RTO estimator. 977c1016 < 4. PAWS: PROTECT AGAINST WRAPPED SEQUENCE NUMBERS --- > 4. PAWS: PROTECTION AGAINST WRAPPED SEQUENCE NUMBERS 991,993c1022,1024 < mechanism PAWS (Protect Against Wrapped Sequence numbers). PAWS --- > mechanism PAWS (Protection Against Wrapped Sequence numbers). 1002,1004c1033,1035 < whose values are monotone non-decreasing in time. The basic idea --- > whose values are monotonically non-decreasing in time. The basic 1015,1024c1054,1064 < must guarantee a value that is monotone increasing. For example, --- > must guarantee a value that is monotonically increasing. For 1031c1071 < (An alternative un-symmetric algorithm would protect against old --- > (An alternative non-symmetric algorithm would protect against old 1053,1054c1085,1086 < RFC-1323 recommended that RST segments NOT carry timestamps, and < that they be accetable regardless of their timestamp. At that --- > RFC 1323 recommended that RST segments NOT carry timestamps, and > that they be acceptable regardless of their timestamp. At that 1070,1072c1110,1112 < and information from Timestamps option must not be use to update --- > and information from the Timestamps option must not be use to 1187c1230 < the receiver treats the timestamp as simply a monotone- --- > the receiver treats the timestamp as simply a monotonically 1201,1202c1244,1245 < worth of data, and even with the RFC-1072 window < extension, 2**31 bytes must be at least two windows. --- > worth of data, and even with the window extension defined > in Section 2.2, 2**31 bytes must be at least two windows. 1350,1355c1384,1397 < in step H1 is very unlikely to fail, and it requires interval < arithmetic on a finite field, a relatively expensive operation. < To perform this check on every single segment is contrary to < the philosophy of header prediction. We believe that this < change might reduce CPU time for TCP protocol processing by up < to 5-10% on high-speed networks. --- > in step H1 is very unlikely to fail, and it requires unsigned > modulo arithmetic, a relatively expensive operation. To > perform this check on every single segment is contrary to the > philosophy of header prediction. We believe that this change > might produce a measurable reduction in CPU time for TCP > protocol processing on high-speed networks. 1403,1406c1438,1441 < bit in the IP header. Setting the DF bit implies that Path MTU < Discovery as described in RFC-1191 [Mogul90]. Thus any TCP < implementation that implements PAWS must also implement Path < MTU Discovery. --- > bit in the IP header. Setting the DF bit implies the use of > Path MTU Discovery as described in RFC 1191 [Mogul90], thus any > TCP implementation that implements PAWS must also implement > Path MTU Discovery. 1466,1468c1501,1511 < publication of RFC-1323 originally occurred in the IETF TCP Large < Windows Working Group, later on in the End-to-End Taks Force, and < most recently in the IETF TCP Maintance Working Group. The authors --- > publication of RFC 1323 originally occurred in the IETF TCP Large > Windows Working Group, later on in the End-to-End Task Force, and > most recently in the IETF TCP Maintenance Working Group. The authors 1473c1516,1541 < Security issues are not discussed in this memo. --- > The TCP sequence space is a fixed size, and as the window becomes > larger it becomes easier for an attacker to generate forged packets > that can fall within the TCP window, and be accepted as valid > packets. While use of Timestamps and PAWS can help to mitigate this, > when using PAWS, if an attacker is able to forge a packet that is > acceptable to the TCP connection, a timestamp that is in the future > would cause valid packets to be dropped due to PAWS checks. Hence, > implementors should take care to not open the TCP window drastically > beyond the requirements of the connection. > > Middle boxes and options If a middle box removes TCP options from the > SYN, such as TSopt, a high speed connection that needs PAWS would not > have that protection. In this situation, an implementor could > provide a mechanism for the application to determine whether or not > PAWS is in use on the connection, and chose to terminate the > connection if that protection doesn't exist. > > Mechanisms to protect the TCP header from modification should also > protect the TCP options. > > Expanding the TCP window beyond 64K for IPv6 allows Jumbograms > [Borman99] to be used when the local network supports packets larger > than 64K. When larger TCP packets are used, the TCP checksum becomes > weaker. > > 7. IANA CONSIDERATIONS > > This document has no actions for IANA. 1568a1642,1644 > [Mathis08] Mathis, M., "[tcpm] Example of 1323 window retraction > problemPer my comments at the microphone at TCPM...", Message to > the tcpm mailing list, March 2008. 1574,1577c1650 < [Postel83] Postel, J., "The TCP Maximum Segment Size and Related < Topics", RFC-879, ISI, November 1983. 1681,1729c1739,1742 < < TCP Options and MSS < < There has been some confusion as to what value should be filled < in the TCP MSS option when using TCP options. RFC-879 < [Postel83] stated: < < The MSS counts only data octets in the segment, it does not < count the TCP header or the IP header. < < which is unclear about what to do about TCP options. RFC-1122 < [Braden89] attempted to clarify this in section 4.2.2.6, but < there still seems to be confusion. < < So, the MSS value to be sent in an MSS option should be equal to < the effective MTU minus the fixed IP and TCP headers. Since < both IP and TCP options are ignored when calculating the value < for the MSS option, if there are any IP or TCP options to be < sent in a packet, then the sender must decrease the size of the < TCP data accordingly. The reason for this can be seen in the < following table: < < +--------------------+--------------------+ < | MSS is adjusted | MSS isn't adjusted | < | to include options | to include options | < +----------------+--------------------+--------------------+ < | Sender adjusts | Packets are too | Packets are the | < | length for | short | correct length | < | options | | | < +----------------+--------------------+--------------------+ < | Sender doesn't | Packets are the | Packets are too | < | adjust length | correct length | long. | < | for options | | | < +----------------+--------------------+--------------------+ < < Since the goal is to not send IP datagrams that have to be < fragmented, and packets sent with the constraints in the lower < right of this grid will cause IP fragmentation, the only way to < guarantee that this doesn't happen is for the data sender to < decrease the TCP data length by the size of the IP and TCP < options. And since the sender will be adjusting the TCP data < length when sending IP and TCP options, there is no need to < include the IP and TCP option lengths in the MSS value. --- < 1827,1828c1832,1833 < strictly within a single connection; the last timestamp is < TS.Recent is kept in the connection control block, and --- > strictly within a single connection; the last timestamp > (TS.Recent) is kept in the connection control block, and 1922c1980 < which ever data packet made it to the destination. --- > whichever data packet made it to the destination. 1944c2002 < (f) It is now recommended that Timestamps options be included RST --- > (f) It is now recommended that Timestamps options be included in RST 1999c2057 < my.TSclock: System Wide Local source of 32-bit timestamp values --- > my.TSclock: System wide source of 32-bit timestamp values 2500c2616 < While the rules layed out for when to calculate RTTM produce the --- > While the rules laid out for when to calculate RTTM produce the From alexander.zimmermann@nets.rwth-aachen.de Thu Mar 5 02:37:10 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C323B28C45F for ; Thu, 5 Mar 2009 02:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTCANt3NDgdc for ; Thu, 5 Mar 2009 02:37:09 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id B367328C10E for ; Thu, 5 Mar 2009 02:37:09 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KG100A6346P81E0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 05 Mar 2009 11:37:37 +0100 (CET) X-IronPort-AV: E=Sophos; i="4.38,306,1233529200"; d="sig'?scan'208"; a="3797175" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 05 Mar 2009 11:37:38 +0100 Received: from chicago.informatik.RWTH-Aachen.DE (chicago.informatik.RWTH-Aachen.DE [137.226.12.187]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n25AbbjS020419; Thu, 05 Mar 2009 11:37:37 +0100 (CET) Message-id: <0F312D82-9D98-480C-AA47-81FBA440BE7E@nets.rwth-aachen.de> From: Alexander Zimmermann To: pasi.sarolahti@nokia.com Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-1-244216091 Content-transfer-encoding: 7bit Date: Thu, 05 Mar 2009 11:37:33 +0100 X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) Cc: tcpm@ietf.org Subject: [tcpm] Variable "recover" in F-RTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 10:37:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-244216091 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, I have an understanding problem with aforementioned variable "recover" in the current version (http://www.tools.ietf.org/html/draft-ietf-tcpm-rfc4138bis-04 ) of the F-RTO Algorithm. Section 2.1 The Algorithm (F-RTO, Reno/NewReno Case) Step 2): When the first ACK after RTO rexmit arrives at the TCP Sender, we store the highest sequence number transmitted so far in the variable "recover". then Step 2a) Check if the ACK from Step 2) is a DUPACK OR the ACK covers "recover" but not more than "recover"... Why is the check like this? IMHO we can only get an ACK that cover exactly "recover" (Lost Retransmission - SIGCOM Paper Section 4.2) or an ACK that cover less than "recover", but we cannot get ACK that cover more than "recover". Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-1-244216091 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmvq20ACgkQdyiq39b9uS6mDwCgl5JiC3aP8cu/jKNI+o12blm4 jmIAnjM3GyxRj03cyUmSxyxr1jBsyd8J =u9lE -----END PGP SIGNATURE----- --Apple-Mail-1-244216091-- From ilpo.jarvinen@helsinki.fi Thu Mar 5 04:15:10 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D2C28C2A2 for ; Thu, 5 Mar 2009 04:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[AWL=1.239, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYbWsMqlzuzn for ; Thu, 5 Mar 2009 04:15:04 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 036AD3A6980 for ; Thu, 5 Mar 2009 04:15:02 -0800 (PST) Received: from wrl-59.cs.helsinki.fi (wrl-59.cs.helsinki.fi [128.214.166.179]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 05 Mar 2009 14:15:30 +0200 id 001480F0.49AFC262.000012D6 Received: by wrl-59.cs.helsinki.fi (Postfix, from userid 50795) id 9191AA0096; Thu, 5 Mar 2009 14:15:30 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by wrl-59.cs.helsinki.fi (Postfix) with ESMTP id 8EDEBA0091; Thu, 5 Mar 2009 14:15:30 +0200 (EET) Date: Thu, 5 Mar 2009 14:15:30 +0200 (EET) From: "=?ISO-8859-1?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wrl-59.cs.helsinki.fi To: "tcpm@ietf.org" , Sally Floyd Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [tcpm] TCP ackcc and application limited X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 12:15:10 -0000 Hi, I read a while ago the ackcc draft (04)... I've one question about "Adjusting the ACK ratio" section's constraint 2... What is supposed to happen if a TCP flow becomes application limited with a large ACK ratio as only R=2R and R=R-1 are the allowed changes (and even that is limited additionally by the "should not attempt to change ACK ratio more than once per rtt" rule)? TCP receiver wouldn't be sending at least two ACKs for a window of data with the given constraint 2. It's somewhat similar to the case added in -05 with cwnd reductions which seem to suggest about possiblity of halving R. In that case as well with application limited such dramatic changes might be necessary to actually force two acks per window. Depending on scenario ack ratio would also need to be changed more often than once per rtt. In case of application limit even more than halving with application limited actually might be necessary and there's yet another problem that we really cannot know how much data we will finally have because the sender might generate more data at any point of time. In addition, the receiver should ACK FIN immediately which I think was not mentioned anywhere. I think that rfc4341 might miss application limited vs ack cc issues too and possibly the at-end-of-flow stuff too but I didn't read that too deeply (it discusses application limited but in different context)... -- i. From fernando@gont.com.ar Thu Mar 5 09:20:34 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903C028C465 for ; Thu, 5 Mar 2009 09:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vq8in7lGuCf for ; Thu, 5 Mar 2009 09:20:33 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8F2E028C44A for ; Thu, 5 Mar 2009 09:20:32 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 953186B6A27; Thu, 5 Mar 2009 14:21:03 -0300 (ART) Received: from [192.168.0.151] (235-131-17-190.fibertel.com.ar [190.17.131.235]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n25HKgxk020910; Thu, 5 Mar 2009 15:20:44 -0200 Message-ID: <49B009F7.2060400@gont.com.ar> Date: Thu, 05 Mar 2009 15:20:55 -0200 From: Fernando Gont User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Borman References: <20090304233001.4766928C39E@core3.amsl.com> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 05 Mar 2009 14:20:59 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-1323bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:20:34 -0000 Hello, David, > I've just posted a new revision of 1323bis. I've tried to incorporate > all the things from the Philadelphia meeting, including adding a real > Security Considerations section. Some of my notes were a bit cryptic, > as were the TCPM Meeting Minutes, so I've probably missed some things > there. There is a fairly lengthy discussion of the security implications of TCP timestamps and large windows in the document I authored for UK CPNI (available at http://www.gont.com.ar/papers). This document has also resulted in an IETF I-D (draft-gont-tcp-security-00.txt). So I guess that a small excerpt of what is there, and a pointer, would complete the security considerations section of rfc1323bis. Thanks! Kind 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 root@core3.amsl.com Mon Mar 9 12:00:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9B1F93A69DE; Mon, 9 Mar 2009 12:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309190001.9B1F93A69DE@core3.amsl.com> Date: Mon, 9 Mar 2009 12:00:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 19:00:01 -0000 --NextPart 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 : The TCP Authentication Option Author(s) : J. Touch, et al. Filename : draft-ietf-tcpm-tcp-auth-opt-04.txt Pages : 48 Date : 2009-03-09 This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key configuration or an external, out-of-band master key management mechanism; in either case, TCP-AO also protects connections when using the same master key across repeated instances of a connection, using traffic keys derived from the master key, and coordinates key changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses its own option identifier, even though used mutually exclusive of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is fully compatible with the requirements for the replacement of TCP MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-04.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-auth-opt-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09114833.I-D@ietf.org> --NextPart-- From touch@ISI.EDU Mon Mar 9 12:19:39 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DBF33A69B0 for ; Mon, 9 Mar 2009 12:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=1.457, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR4mf0BZEW-m for ; Mon, 9 Mar 2009 12:19:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6D2EE3A6919 for ; Mon, 9 Mar 2009 12:19:38 -0700 (PDT) Received: from [128.9.176.50] (c1-vpn11.isi.edu [128.9.176.50]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n29JJvmm012878; Mon, 9 Mar 2009 12:19:59 -0700 (PDT) Message-ID: <49B56BDC.2020205@isi.edu> Date: Mon, 09 Mar 2009 12:19:56 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: tcpm@ietf.org References: <20090309190001.9B1F93A69DE@core3.amsl.com> In-Reply-To: <20090309190001.9B1F93A69DE@core3.amsl.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 19:19:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, The changes to this document are summarized in the document; they include a major restructuring for readability, the addition of a key change coordination mechanism, and a clearer description of the purpose of the TSAD (now called the TAPD). Comments welcome, of course. Please do read this through, though - most if the doc has changed (hopefully for the better). The primary current open issue for SFO regards whether the key coordination mechanism requires support to prevent "backup" (changing back to a key previously used). FYI. Joe 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 : The TCP Authentication Option > Author(s) : J. Touch, et al. > Filename : draft-ietf-tcpm-tcp-auth-opt-04.txt > Pages : 48 > Date : 2009-03-09 > > This document specifies the TCP Authentication Option (TCP-AO), which > obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO > specifies the use of stronger Message Authentication Codes (MACs), > protects against replays even for long-lived TCP connections, and > provides more details on the association of security with TCP > connections than TCP MD5. TCP-AO is compatible with either static > master key configuration or an external, out-of-band master key > management mechanism; in either case, TCP-AO also protects > connections when using the same master key across repeated instances > of a connection, using traffic keys derived from the master key, and > coordinates key changes between endpoints. The result is intended to > support current infrastructure uses of TCP MD5, such as to protect > long-lived connections (as used, e.g., in BGP and LDP), and to > support a larger set of MACs with minimal other system and > operational changes. TCP-AO uses its own option identifier, even > though used mutually exclusive of TCP MD5 on a given TCP connection. > TCP-AO supports IPv6, and is fully compatible with the requirements > for the replacement of TCP MD5. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-04.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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm1a9wACgkQE5f5cImnZrtLSACgg0pamhFBN48BfHAQiVJlfc20 DPoAoIWbj0jCdkvrXfVyG+jATgvaBC27 =2EjV -----END PGP SIGNATURE----- From wesley.m.eddy@nasa.gov Tue Mar 10 08:32:26 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681A43A68C7 for ; Tue, 10 Mar 2009 08:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuO6wbgtD3-O for ; Tue, 10 Mar 2009 08:32:25 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 697DC3A6B22 for ; Tue, 10 Mar 2009 08:32:25 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id B38C32D81DB; Tue, 10 Mar 2009 10:32:58 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162] (may be forged)) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n2AFX44C015903; Tue, 10 Mar 2009 10:33:04 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Tue, 10 Mar 2009 10:32:58 -0500 From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" To: Sally Floyd Date: Tue, 10 Mar 2009 10:32:58 -0500 Thread-Topic: [tcpm] WGLC on draft-ietf-tcpm-ecnsyn-07 Thread-Index: AcmcTj011fF+UGnBS/qWD7lekfbSTwFRx4aA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-ecnsyn-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 15:32:26 -0000 We're considering the WGLC on this to be completed, and free of issues. I'll be writing the PROTO statement and sending it up this week. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- =20 >-----Original Message----- >From: Sally Floyd [mailto:sallyfloyd@mac.com]=20 >Sent: Tuesday, March 03, 2009 5:20 PM >To: Eddy, Wesley M. (GRC-RCN0)[Verizon] >Cc: tcpm@ietf.org >Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-ecnsyn-07 > >Eddy - > >Email from Feb. 12: >> The chairs would like to start are 1-week TCPM working group >> last call on draft-ietf-tcpm-ecnsyn-07 starting now, as this >> draft has previously cleared WGLC modulo some alterations, >> and some support has been expressed for the modifications. >> Please comment by February 20. >> >> The draft is at: >> http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-07 >> >> It's targeted for Proposed Standard, and given the prior >> clearance of the WGLC state, we'll assume lack of any >> expressed concerns will mean that it's ready to go >> forward. > >There was feedback from Mark Allman on this, saying "Ship it." >So is this ready to be forwarded to the IESG? > >(Just trying to wrap up loose ends...) > >Thanks, >- Sally >http://www.icir.org/floyd/ > >= From david.borman@windriver.com Wed Mar 11 13:36:07 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE5628C1D0 for ; Wed, 11 Mar 2009 13:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGs+I3fYNc3G for ; Wed, 11 Mar 2009 13:36:06 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 62AEC28C1CA for ; Wed, 11 Mar 2009 13:36:06 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2BKagL1021491 for ; Wed, 11 Mar 2009 13:36:42 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 13:36:42 -0700 Received: from [172.25.44.5] ([172.25.44.5]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 13:36:42 -0700 Message-Id: <69F982BA-FDE6-4A7C-BE41-BB0283446368@windriver.com> From: David Borman To: tcpm@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 15:36:40 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 Mar 2009 20:36:42.0582 (UTC) FILETIME=[16577760:01C9A289] Subject: [tcpm] Draft TCPM agenda for IETF74 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 20:36:07 -0000 I've just uploaded a draft agenda for the TCPM meeting in San Francisco, currently there are 4 items. We've reserved plenty of time for TCP AO. There is room to adjust times if someone had something to present that they didn't tell us about, so please replay ASAP if that is the case. -David Borman, TCPM co-chair ----------------- Note-Well Agenda Bashing WG Status - 10 minutes Current WG Items Authentication Option Draft draft-ietf-tcpm-tcp-auth-opt-04 "The TCP Authentication Option" Joe Touch 60 minutes RFC 1323bis / TCP MSS option draft-ietf-tcpm-1323bis-01 "TCP Extensions for High Performance" draft-ietf-tcpm-tcpmss-00 "TCP Options and MSS" David Borman 30 minutes Non-WG Items Alexander Zimmermann draft-zimmermann-tcp-lcd-00 "Make TCP more Robust to Long Connectivity Disruptions" 10 minutes David Borman Urgent Data draft-gont-tcpm-urgent-data-01 10 minutes From david.borman@windriver.com Wed Mar 11 13:55:44 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B329B28C20E for ; Wed, 11 Mar 2009 13:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9-enW4SfFAk for ; Wed, 11 Mar 2009 13:55:39 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 581DF28C20B for ; Wed, 11 Mar 2009 13:55:39 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2BKuGLt024473 for ; Wed, 11 Mar 2009 13:56:16 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 13:56:15 -0700 Received: from [172.25.44.5] ([172.25.44.5]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 13:56:15 -0700 Message-Id: From: David Borman To: tcpm@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 15:56:11 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 Mar 2009 20:56:15.0981 (UTC) FILETIME=[D1BDF1D0:01C9A28B] Subject: [tcpm] About the urgent pointer... X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 20:55:44 -0000 Hello, One of the items on the TCPM agenda for IETF 74 is the TCP Urgent pointer. I want this to be a very focused discussion around one question: Should the urgent pointer point to the last byte of urgent data, or the first byte of non-urgent data? RFC 793 has one place (p. 17) where it says that it is the first byte of non-urgent data, and at least two places (p. 41 and p. 56) where it says that it is the last byte of urgent data. Though RFC 961 and RFC 1122 resolve this ambiguity and are clear that the urgent pointer is defined to point to the last byte of urgent data, as draft-gont-tcpm- urgent-data-01 points out most systems actually implement it as the first byte of non-urgent data. This goes back to the original BSD code from CSRG. So, the question is *not* what do the RFCs say, because they are clear. The question is, what do we do about the mismatch between what the RFCs say, and what is generally implemented? -David Borman From gregory.ietf@gmail.com Wed Mar 11 18:50:06 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE583A6936 for ; Wed, 11 Mar 2009 18:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ85jLlt0cJS for ; Wed, 11 Mar 2009 18:50:05 -0700 (PDT) Received: from mail-gx0-f167.google.com (mail-gx0-f167.google.com [209.85.217.167]) by core3.amsl.com (Postfix) with ESMTP id DE8A83A6862 for ; Wed, 11 Mar 2009 18:50:04 -0700 (PDT) Received: by gxk11 with SMTP id 11so693942gxk.13 for ; Wed, 11 Mar 2009 18:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hC1OYW71kXEmopRi1tYM3icI/rJBCQvvcPlT04tQwe0=; b=SIx7x6K7T0OIu1dvIun7IVEBPLE3mOt0hwekbL+sR0cnKRqR69/uGXdKE/99Ym/hFG KcC6J1M9QUGmne7iIApDJ2gHHMwwxT6UTOjWH09SoUYEj/r0BLMOswGja12jKj17AAa5 SKgXEzuU0VER+sbMvpck3QQqOLosmOsuWpHbE= 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; b=bz/HVl5BW0njPsTH9gbFyBzwuuaoTZ7l2YOyEiiMWQPtsBTJAqWDDxIJ3cKJEthRRg rrpv1aY5nTUrT9vBylklGCPP8r+gEhjfa5On8Jllpk/pwlRz1tqF4Mk0cP26tWI2OBkG 0lCRA0+4BGIkZAspNEYc4VaEZee3RQ+4jsMV8= MIME-Version: 1.0 Received: by 10.231.15.74 with SMTP id j10mr2166398iba.10.1236822637913; Wed, 11 Mar 2009 18:50:37 -0700 (PDT) In-Reply-To: <69F982BA-FDE6-4A7C-BE41-BB0283446368@windriver.com> References: <69F982BA-FDE6-4A7C-BE41-BB0283446368@windriver.com> Date: Wed, 11 Mar 2009 18:50:37 -0700 Message-ID: From: Gregory Lebovitz To: David Borman , "Eddy, Wesley M. (GRC-RCN0)[Verizon]" Content-Type: multipart/alternative; boundary=00221532cba0fba8380464e235ec Cc: tcpm@ietf.org Subject: Re: [tcpm] Draft TCPM agenda for IETF74 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:50:06 -0000 --00221532cba0fba8380464e235ec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm probably going to need 10 or 15 min to discuss the TCP-AO-CRYPTO-00 document, the crypto helper to AO. Gregory. On Wed, Mar 11, 2009 at 1:36 PM, David Borman wrote: > I've just uploaded a draft agenda for the TCPM meeting in San Francisco, > currently there are 4 items. We've reserved plenty of time for TCP AO. > There is room to adjust times if someone had something to present that they > didn't tell us about, so please replay ASAP if that is the case. > > -David Borman, TCPM co-chair > > ----------------- > Note-Well > Agenda Bashing > WG Status - 10 minutes > > > Current WG Items > > Authentication Option Draft > draft-ietf-tcpm-tcp-auth-opt-04 > "The TCP Authentication Option" > Joe Touch > 60 minutes > > RFC 1323bis / TCP MSS option > draft-ietf-tcpm-1323bis-01 > "TCP Extensions for High Performance" > draft-ietf-tcpm-tcpmss-00 > "TCP Options and MSS" > David Borman > 30 minutes > > > Non-WG Items > > Alexander Zimmermann > draft-zimmermann-tcp-lcd-00 > "Make TCP more Robust to Long Connectivity Disruptions" > 10 minutes > > David Borman > Urgent Data > draft-gont-tcpm-urgent-data-01 > 10 minutes > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --00221532cba0fba8380464e235ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm probably going to need 10 or 15 min to discuss the TCP-AO-CRYP= TO-00 document, the crypto helper to AO.
=A0
Gregory.

On Wed, Mar 11, 2009 at 1:36 PM, David Borman <david.bor= man@windriver.com> wrote:
I've just uploaded a draft a= genda for the TCPM meeting in San Francisco, currently there are 4 items. = =A0We've reserved plenty of time for TCP AO. =A0There is room to adjust= times if someone had something to present that they didn't tell us abo= ut, so please replay ASAP if that is the case.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-David Borman, TCPM co-chair

----= -------------
Note-Well
Agenda Bashing
WG Status - 10 minutes
<= br>
Current WG Items

=A0 =A0 =A0 =A0Authentication Option Draft=A0 =A0 =A0 =A0draft-ietf-tcpm-tcp-auth-opt-04
=A0 =A0 =A0 =A0 =A0 =A0"The TCP Authentication Option"
=A0 =A0= =A0 =A0Joe Touch
=A0 =A0 =A0 =A060 minutes

=A0 =A0 =A0 =A0RFC 13= 23bis / TCP MSS option
=A0 =A0 =A0 =A0draft-ietf-tcpm-1323bis-01
=A0 = =A0 =A0 =A0 =A0 =A0"TCP Extensions for High Performance"
=A0 =A0 =A0 =A0draft-ietf-tcpm-tcpmss-00
=A0 =A0 =A0 =A0 =A0 =A0"TC= P Options and MSS"
=A0 =A0 =A0 =A0David Borman
=A0 =A0 =A0 =A030= minutes


Non-WG Items

=A0 =A0 =A0 =A0Alexander Zimmermann=
=A0 =A0 =A0 =A0draft-zimmermann-tcp-lcd-00
=A0 =A0 =A0 =A0 =A0 =A0"Make TCP more Robust to Long Connectivity Disr= uptions"
=A0 =A0 =A0 =A010 minutes

=A0 =A0 =A0 =A0David Borm= an
=A0 =A0 =A0 =A0Urgent Data
=A0 =A0 =A0 =A0draft-gont-tcpm-urgent-d= ata-01
=A0 =A0 =A0 =A010 minutes

________________________________= _______________
tcpm mailing list
tcp= m@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm



--
----
IETF related email from
G= regory M. Lebovitz
Juniper Networks
--00221532cba0fba8380464e235ec-- From wesley.m.eddy@nasa.gov Wed Mar 11 19:17:41 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753E63A67D9 for ; Wed, 11 Mar 2009 19:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2p95s06vXQ8 for ; Wed, 11 Mar 2009 19:17:40 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 42C243A67E6 for ; Wed, 11 Mar 2009 19:17:40 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 72A143280F7; Wed, 11 Mar 2009 21:18:16 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02.ndc.nasa.gov [198.117.4.161] (may be forged)) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n2C2IIc5024161; Wed, 11 Mar 2009 21:18:18 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.4.161]) with mapi; Wed, 11 Mar 2009 21:18:16 -0500 From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" To: Joe Touch , "tcpm@ietf.org" Date: Wed, 11 Mar 2009 21:18:15 -0500 Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-04.txt Thread-Index: Acmg7Bbszkap8v3oTrGm8XJRjo7avwBy9VXi Message-ID: References: <20090309190001.9B1F93A69DE@core3.amsl.com>, <49B56BDC.2020205@isi.edu> In-Reply-To: <49B56BDC.2020205@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 02:17:41 -0000 As comments are made on this, I'm planning to put any issues identified int= o the issue tracker that'll be linked from our IETF tools page: http://tools.ietf.org/wg/tcpm/ that Henrik just nicely setup for us. If there are current issues people h= ave with version 04 of the draft, and you send them to me or the list, I'll ent= er them in. This will be a little new for TCPM, but I think it'll help keep track of th= ings as we finish the document off. ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe Touch = [touch@ISI.EDU] Sent: Monday, March 09, 2009 3:19 PM To: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-04.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, The changes to this document are summarized in the document; they include a major restructuring for readability, the addition of a key change coordination mechanism, and a clearer description of the purpose of the TSAD (now called the TAPD). Comments welcome, of course. Please do read this through, though - most if the doc has changed (hopefully for the better). The primary current open issue for SFO regards whether the key coordination mechanism requires support to prevent "backup" (changing back to a key previously used). FYI. Joe 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. > > > Title : The TCP Authentication Option > Author(s) : J. Touch, et al. > Filename : draft-ietf-tcpm-tcp-auth-opt-04.txt > Pages : 48 > Date : 2009-03-09 > > This document specifies the TCP Authentication Option (TCP-AO), which > obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO > specifies the use of stronger Message Authentication Codes (MACs), > protects against replays even for long-lived TCP connections, and > provides more details on the association of security with TCP > connections than TCP MD5. TCP-AO is compatible with either static > master key configuration or an external, out-of-band master key > management mechanism; in either case, TCP-AO also protects > connections when using the same master key across repeated instances > of a connection, using traffic keys derived from the master key, and > coordinates key changes between endpoints. The result is intended to > support current infrastructure uses of TCP MD5, such as to protect > long-lived connections (as used, e.g., in BGP and LDP), and to > support a larger set of MACs with minimal other system and > operational changes. TCP-AO uses its own option identifier, even > though used mutually exclusive of TCP MD5 on a given TCP connection. > TCP-AO supports IPv6, and is fully compatible with the requirements > for the replacement of TCP MD5. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-04.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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm1a9wACgkQE5f5cImnZrtLSACgg0pamhFBN48BfHAQiVJlfc20 DPoAoIWbj0jCdkvrXfVyG+jATgvaBC27 =3D2EjV -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm= From wesley.m.eddy@nasa.gov Wed Mar 11 19:20:01 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E1C3A67E6 for ; Wed, 11 Mar 2009 19:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpH31ERQrqVC for ; Wed, 11 Mar 2009 19:20:00 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 5DB623A67D9 for ; Wed, 11 Mar 2009 19:20:00 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 5E6BB328156 for ; Wed, 11 Mar 2009 21:20:37 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162] (may be forged)) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n2C2KduC026524 for ; Wed, 11 Mar 2009 21:20:39 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Wed, 11 Mar 2009 21:20:37 -0500 From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" To: "tcpm@ietf.org" Date: Wed, 11 Mar 2009 21:20:36 -0500 Thread-Topic: updated milestones Thread-Index: AQHJorkhzmvT5uRla0Kuv7s7mrWi3g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C304DB494AC0C04C87C6A6E2FF5603DB220CA8C6DENDJSSCC01ndcn_" MIME-Version: 1.0 Subject: [tcpm] updated milestones X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 02:20:01 -0000 --_000_C304DB494AC0C04C87C6A6E2FF5603DB220CA8C6DENDJSSCC01ndcn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some of you will be happy to see that we finally got the TCPM milestones udpated on our charter webpage: http://www.ietf.org/html.charters/tcpm-charter.html Thanks for your patience while waiting for that :). --_000_C304DB494AC0C04C87C6A6E2FF5603DB220CA8C6DENDJSSCC01ndcn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Some of= you will be happy to see that we finally got the TCPM milestones
udpated on our charter we= bpage:
 
 
Thanks for your patience = while waiting for that :).
 
--_000_C304DB494AC0C04C87C6A6E2FF5603DB220CA8C6DENDJSSCC01ndcn_-- From david.borman@windriver.com Thu Mar 12 07:08:11 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9169F3A6806 for ; Thu, 12 Mar 2009 07:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+3heMEed-FZ for ; Thu, 12 Mar 2009 07:08:10 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id DD5573A6B78 for ; Thu, 12 Mar 2009 07:07:43 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2CE8HJ9000302; Thu, 12 Mar 2009 07:08:17 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 07:08:16 -0700 Received: from [172.25.44.5] ([172.25.44.5]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 07:08:16 -0700 Message-Id: <1B1A4A5F-2692-4161-B8D6-7DFD28804063@windriver.com> From: David Borman To: Gregory Lebovitz In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Mar 2009 09:08:14 -0500 References: <69F982BA-FDE6-4A7C-BE41-BB0283446368@windriver.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Mar 2009 14:08:16.0624 (UTC) FILETIME=[FD523F00:01C9A31B] Cc: tcpm@ietf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]" Subject: Re: [tcpm] Draft TCPM agenda for IETF74 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:08:11 -0000 Ok, I'll add that as part of the TCP-AO time slot. -David On Mar 11, 2009, at 8:50 PM, Gregory Lebovitz wrote: > I'm probably going to need 10 or 15 min to discuss the TCP-AO- > CRYPTO-00 document, the crypto helper to AO. > > Gregory. > > On Wed, Mar 11, 2009 at 1:36 PM, David Borman > wrote: > I've just uploaded a draft agenda for the TCPM meeting in San > Francisco, currently there are 4 items. We've reserved plenty of > time for TCP AO. There is room to adjust times if someone had > something to present that they didn't tell us about, so please > replay ASAP if that is the case. > > -David Borman, TCPM co-chair > > ----------------- > Note-Well > Agenda Bashing > WG Status - 10 minutes > > > Current WG Items > > Authentication Option Draft > draft-ietf-tcpm-tcp-auth-opt-04 > "The TCP Authentication Option" > Joe Touch > 60 minutes > > RFC 1323bis / TCP MSS option > draft-ietf-tcpm-1323bis-01 > "TCP Extensions for High Performance" > draft-ietf-tcpm-tcpmss-00 > "TCP Options and MSS" > David Borman > 30 minutes > > > Non-WG Items > > Alexander Zimmermann > draft-zimmermann-tcp-lcd-00 > "Make TCP more Robust to Long Connectivity Disruptions" > 10 minutes > > David Borman > Urgent Data > draft-gont-tcpm-urgent-data-01 > 10 minutes > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From wesley.m.eddy@nasa.gov Thu Mar 12 07:21:09 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12143A6B84 for ; Thu, 12 Mar 2009 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D+AAGXRbHPx for ; Thu, 12 Mar 2009 07:21:09 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id D92F43A6B15 for ; Thu, 12 Mar 2009 07:21:08 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id EC8FC108109; Thu, 12 Mar 2009 09:21:44 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164] (may be forged)) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n2CELliq032490; Thu, 12 Mar 2009 09:21:47 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Thu, 12 Mar 2009 09:21:44 -0500 From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" To: David Borman , Gregory Lebovitz Date: Thu, 12 Mar 2009 09:21:41 -0500 Thread-Topic: [tcpm] Draft TCPM agenda for IETF74 Thread-Index: AcmjHAEohQtzmZQrT5usjTRx+9+MMgAAQTsg Message-ID: References: <69F982BA-FDE6-4A7C-BE41-BB0283446368@windriver.com> <1B1A4A5F-2692-4161-B8D6-7DFD28804063@windriver.com> In-Reply-To: <1B1A4A5F-2692-4161-B8D6-7DFD28804063@windriver.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Draft TCPM agenda for IETF74 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:21:09 -0000 The draft is here: http://tools.ietf.org/id/draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00.txt The WG should look at it in the near-term if possible, because it goes together with the AO document, and in Minneapolis there seemed to be consensus for breaking the algorithms out of the AO spec in this way, which would also make this a WG document even though it's an individual submission at the moment. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- =20 >-----Original Message----- >From: David Borman [mailto:david.borman@windriver.com]=20 >Sent: Thursday, March 12, 2009 10:08 AM >To: Gregory Lebovitz >Cc: Eddy, Wesley M. (GRC-RCN0)[Verizon]; tcpm@ietf.org >Subject: Re: [tcpm] Draft TCPM agenda for IETF74 > >Ok, I'll add that as part of the TCP-AO time slot. > > -David > >On Mar 11, 2009, at 8:50 PM, Gregory Lebovitz wrote: > >> I'm probably going to need 10 or 15 min to discuss the TCP-AO-=20 >> CRYPTO-00 document, the crypto helper to AO. >> >> Gregory. >> >> On Wed, Mar 11, 2009 at 1:36 PM, David Borman=20 >> > wrote: >> I've just uploaded a draft agenda for the TCPM meeting in San =20 >> Francisco, currently there are 4 items. We've reserved plenty of =20 >> time for TCP AO. There is room to adjust times if someone had =20 >> something to present that they didn't tell us about, so please =20 >> replay ASAP if that is the case. >> >> -David Borman, TCPM co-chair >> >> ----------------- >> Note-Well >> Agenda Bashing >> WG Status - 10 minutes >> >> >> Current WG Items >> >> Authentication Option Draft >> draft-ietf-tcpm-tcp-auth-opt-04 >> "The TCP Authentication Option" >> Joe Touch >> 60 minutes >> >> RFC 1323bis / TCP MSS option >> draft-ietf-tcpm-1323bis-01 >> "TCP Extensions for High Performance" >> draft-ietf-tcpm-tcpmss-00 >> "TCP Options and MSS" >> David Borman >> 30 minutes >> >> >> Non-WG Items >> >> Alexander Zimmermann >> draft-zimmermann-tcp-lcd-00 >> "Make TCP more Robust to Long Connectivity Disruptions" >> 10 minutes >> >> David Borman >> Urgent Data >> draft-gont-tcpm-urgent-data-01 >> 10 minutes >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> >> --=20 >> ---- >> IETF related email from >> Gregory M. Lebovitz >> Juniper Networks >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > >= From david.borman@windriver.com Thu Mar 12 08:14:02 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546863A69E2 for ; Thu, 12 Mar 2009 08:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr9uQLIqqaR9 for ; Thu, 12 Mar 2009 08:13:57 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 483433A6826 for ; Thu, 12 Mar 2009 08:13:55 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2CFEWEr012262 for ; Thu, 12 Mar 2009 08:14:32 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 08:14:32 -0700 Received: from [172.25.44.5] ([172.25.44.5]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 08:14:32 -0700 Message-Id: <7B9BFE24-C237-4E79-ADF0-C9CA9EE04102@windriver.com> From: David Borman To: tcpm@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Mar 2009 10:14:30 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Mar 2009 15:14:32.0665 (UTC) FILETIME=[3F39F490:01C9A325] Subject: [tcpm] Request to change TCPM time slot X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:14:02 -0000 There has been a request to swap the DCCP and TCPM time slots. This would move TCPM one slot earlier, to Monday at 1520-1720. If this would present a problem, please speak up. This would place TCPM at the same time as: 1520-1720 Afternoon Session II Continental 3 APP sieve Sieve Mail Filtering Language WG Imperial B INT 6lowpan IPv6 over Low power WPAN WG Continental 4 INT savi Source Address Validation Improvements WG Continental 6 OPS opsarea Operations & Management Area Open Meeting Continental 5 RAI ecrit Emergency Context Resolution with Internet Technologies WG Imperial A RTG forces Forwarding and Control Element Separation WG Continental 1&2 RTG rtgwg Routing Area Working Group WG We would especially like to hear if this an issue for any of the presenters, or for those who are actively involved in the TCP AO discussion. -David Borman, WG co-chair From touch@ISI.EDU Thu Mar 12 08:41:16 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC753A6A0B for ; Thu, 12 Mar 2009 08:41:16 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbknh57CZS89 for ; Thu, 12 Mar 2009 08:41:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1593C3A67B3 for ; Thu, 12 Mar 2009 08:41:16 -0700 (PDT) Received: from [10.88.25.209] (mobile-032-166-183-153.mycingular.net [32.166.183.153] (may be forged)) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n2CFf5OV021521; Thu, 12 Mar 2009 08:41:08 -0700 (PDT) From: Joe Touch To: David Borman In-Reply-To: <7B9BFE24-C237-4E79-ADF0-C9CA9EE04102@windriver.com> X-Mailer: iPhone Mail (5H11) References: <7B9BFE24-C237-4E79-ADF0-C9CA9EE04102@windriver.com> Message-Id: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 5H11) Date: Thu, 12 Mar 2009 11:41:01 -0400 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Request to change TCPM time slot X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:41:16 -0000 Ok for me. Sent from my iPhone On Mar 12, 2009, at 11:14 AM, David Borman wrote: > There has been a request to swap the DCCP and TCPM time slots. This > would move TCPM one slot earlier, to Monday at 1520-1720. If this > would present a problem, please speak up. This would place TCPM at > the same time as: > > 1520-1720 Afternoon Session II > Continental 3 APP sieve Sieve Mail Filtering Language WG > Imperial B INT 6lowpan IPv6 over Low power WPAN WG > Continental 4 INT savi Source Address Validation > Improvements WG > Continental 6 OPS opsarea Operations & Management Area Open > Meeting > Continental 5 RAI ecrit Emergency Context Resolution with > Internet Technologies WG > Imperial A RTG forces Forwarding and Control Element > Separation WG > Continental 1&2 RTG rtgwg Routing Area Working Group WG > > We would especially like to hear if this an issue for any of the > presenters, or for those who are actively involved in the TCP AO > discussion. > > -David Borman, WG co-chair > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From alexander.zimmermann@nets.rwth-aachen.de Thu Mar 12 10:21:33 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9C128C210 for ; Thu, 12 Mar 2009 10:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW2MkRCOjZxp for ; Thu, 12 Mar 2009 10:21:32 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 6483B28C20F for ; Thu, 12 Mar 2009 10:21:32 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KGE004NTLKWYIB0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 12 Mar 2009 18:22:08 +0100 (CET) X-IronPort-AV: E=Sophos; i="4.38,351,1233529200"; d="sig'?scan'208"; a="4629971" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 12 Mar 2009 18:22:08 +0100 Received: from chicago.informatik.RWTH-Aachen.DE (chicago.informatik.RWTH-Aachen.DE [137.226.12.187]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n2CHM87G015716; Thu, 12 Mar 2009 18:22:08 +0100 (CET) Message-id: <46FBF8C8-2176-4457-ADA2-D2DB1A3645A8@nets.rwth-aachen.de> From: Alexander Zimmermann To: David Borman In-reply-to: <7B9BFE24-C237-4E79-ADF0-C9CA9EE04102@windriver.com> Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-4-873285450 Content-transfer-encoding: 7bit Date: Thu, 12 Mar 2009 18:22:03 +0100 References: <7B9BFE24-C237-4E79-ADF0-C9CA9EE04102@windriver.com> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Request to change TCPM time slot X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 17:21:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4-873285450 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit me too Am 12.03.2009 um 16:14 schrieb David Borman: > There has been a request to swap the DCCP and TCPM time slots. This > would move TCPM one slot earlier, to Monday at 1520-1720. If this > would present a problem, please speak up. This would place TCPM at > the same time as: > > 1520-1720 Afternoon Session II > Continental 3 APP sieve Sieve Mail Filtering Language WG > Imperial B INT 6lowpan IPv6 over Low power WPAN WG > Continental 4 INT savi Source Address Validation > Improvements WG > Continental 6 OPS opsarea Operations & Management Area Open > Meeting > Continental 5 RAI ecrit Emergency Context Resolution with > Internet Technologies WG > Imperial A RTG forces Forwarding and Control Element > Separation WG > Continental 1&2 RTG rtgwg Routing Area Working Group WG > > We would especially like to hear if this an issue for any of the > presenters, or for those who are actively involved in the TCP AO > discussion. > > -David Borman, WG co-chair > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-4-873285450 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkm5RLsACgkQdyiq39b9uS5S4QCfe1/XUlvDQ9GqZRYAoyJ0Gx6e 7kYAn1b35wAIbcOry9HBCCIQvCnFMux1 =EYrL -----END PGP SIGNATURE----- --Apple-Mail-4-873285450-- From david.borman@windriver.com Thu Mar 12 11:03:38 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE3128C262 for ; Thu, 12 Mar 2009 11:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujR9FBYca0uo for ; Thu, 12 Mar 2009 11:03:37 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id E113528C2A4 for ; Thu, 12 Mar 2009 11:02:49 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2CI3Qif014360 for ; Thu, 12 Mar 2009 11:03:26 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 11:03:25 -0700 Received: from [172.25.34.42] ([172.25.34.42]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 11:03:25 -0700 Message-Id: <305E1A03-DC67-44E2-9FD0-1982E345076B@windriver.com> From: David Borman To: tcpm@ietf.org In-Reply-To: <69F982BA-FDE6-4A7C-BE41-BB0283446368@windriver.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Mar 2009 13:03:24 -0500 References: <69F982BA-FDE6-4A7C-BE41-BB0283446368@windriver.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Mar 2009 18:03:26.0074 (UTC) FILETIME=[D73575A0:01C9A33C] Subject: Re: [tcpm] Draft TCPM agenda for IETF74 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:03:38 -0000 I've updated the TCPM agenda for IETF-74, you can find it at: http://www.ietf.org/proceedings/09mar/agenda/tcpm.txt -David Borman, TCPM co-chair From fernando@gont.com.ar Thu Mar 12 11:15:03 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9033A6C0D for ; Thu, 12 Mar 2009 11:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ldc3O16aj531 for ; Thu, 12 Mar 2009 11:15:02 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 2FD4E3A6BF6 for ; Thu, 12 Mar 2009 11:15:01 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id C4F136B66E8; Thu, 12 Mar 2009 15:15:40 -0300 (ART) Received: from [192.168.1.136] (91-130-17-190.fibertel.com.ar [190.17.130.91]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n2CIFTTd028878; Thu, 12 Mar 2009 16:15:30 -0200 Message-ID: <49B94896.9020202@gont.com.ar> Date: Thu, 12 Mar 2009 15:38:30 -0200 From: Fernando Gont User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: David Borman References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 12 Mar 2009 15:15:40 -0300 (ART) Cc: Alfred , tcpm@ietf.org Subject: Re: [tcpm] About the urgent pointer... X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:15:03 -0000 Hello, David, > So, the question is *not* what do the RFCs say, because they are clear. > The question is, what do we do about the mismatch between what the RFCs > say, and what is generally implemented? One important thing to note is that it is impossible to tell (without any additional mechanism) what semantics for the UP a TCP implements. This means that if were were to try to get real stacks implement the semantics for the UP as specified in RFC 1122, we would basically break the urgent mechanism. My understanding from the talks that I had with a few folks at the last IETF is that the only sensible thing to do is to change the spec (considering that whether the UP points to the last byte of urgent data vs. the byte following that chunk, does not really matter -- as long as all stacks do the same... which is already the case). Nevertheles, my personal feeling is that regardless of which specific outcome, we agree that tcpm wg should do something on this issue (and probably the last posts on this subject are an indication that at least is clarification is needed). That said, I believe it would be a good thing to poll the wg to adopt this I-D -- if anything, to have a starting point to work on this issue. (FWIW, this last revision has been substantially revised to address the feedback I got from you and Joe at the last IETF, and feedback from Alfred that I got while he was helping (a lot) with a related document). Thanks! Kind 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 david.borman@windriver.com Thu Mar 12 13:45:09 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EEC3A68FD for ; Thu, 12 Mar 2009 13:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEfdokB6dWQJ for ; Thu, 12 Mar 2009 13:45:08 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 2E9AD3A69AB for ; Thu, 12 Mar 2009 13:45:08 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2CKjYxY012730; Thu, 12 Mar 2009 13:45:34 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 13:45:33 -0700 Received: from [172.25.34.42] ([172.25.34.42]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 13:45:32 -0700 Message-Id: <8645DB74-13BD-4B2C-B408-4DA7FE7DB95A@windriver.com> From: David Borman To: Fernando Gont , Jerry Leichter In-Reply-To: <49AD5FE4.4040100@gont.com.ar> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Mar 2009 15:45:30 -0500 References: <20090227222910.4AAF55654E@rebar.astron.com> <49A9A056.30207@gont.com.ar> <6F1AF259-F2A0-4266-8A92-C3712E9E1430@lrw.com> <49A9B91A.7040100@gont.com.ar> <06E1ED3F-8652-4630-86D6-38F2C519228D@lrw.com> <49AC0DB8.5050007@gont.com.ar> <8E1A8673-2072-4339-BE82-95AE85AA44C7@lrw.com> <49AD5FE4.4040100@gont.com.ar> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Mar 2009 20:45:33.0540 (UTC) FILETIME=[7D3AFA40:01C9A353] Cc: tcpm@ietf.org Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 20:45:09 -0000 On Mar 3, 2009, at 10:50 AM, Fernando Gont wrote: > Jerry Leichter wrote: > >> You refer to the data pointed to by the urgent pointer as the >> urgent >> data. This is incorrect. TCP doesn't directly have a concept of >> urgent >> *data*; what it has is an urgent *mode*. > [....] > > This was the intent of the text. I'll go through the I-D again and > will > try to remove any instances of what you describe. RFC 793 specifies all three: the urgent pointer, urgent mode, and urgent data. Urgent data is *all* the data before the urgent pointer. Urgent mode is when you are reading the urgent data. What TCP does not have is out of band (OOB) data. Writing just one byte in urgent mode makes all the previously written and unread data urgent data. >> Note that this is a fine concept, but *it's completely unsupported by >> the socket API*. While the socket API can tell you that you've >> reached >> the end of the urgent data (a read() stops at the urgent byte, and >> there's an ioctl() that tells you that you've just read it), >> there's no >> way to know when you've *entered* urgent mode. At best, you can >> get a >> signal, but there's no way to figure out how that relates to the >> position in the TCP stream. > > Not sure what you mean. select() should tell you when you have entered urgent mode, through the errorfds descriptor set (which is exceptional conditions, not just errors). >> Given all that, I think your suggestion that there is no OOB data, >> only >> Urgent Mode, is exactly backwards. > > Isn't this the converse of what you stated at the very beginning of > your > post?? > > > >> Unless I'm inside of the TCP stack, >> Urgent Mode is a meaningless concept. I can't control when it >> starts, I >> can't detect when it starts, I can't even ask if I'm *in* urgent >> mode. > > huh? What about SIOCATMARK? The sender controls when the connection leaves urgent mode, and by doing so, implicitly makes all the previously unread data urgent data. On the receiver, select() will tell you when you've gone into urgent mode, and SIOCATMARK will tell you when you are at the mark. >> You comment that based on tests under Cygwin, OOB data is always >> delivered in-line. If so, this is a Cygwin issue - I can tell you >> quite >> definitely that if you use the Windows socket implementation, by >> default >> OOB data does *not* get delivered in-line. > > Will try this. There is no OOB data in TCP. BSD was wrong when it implemented it as such, but there were existing applications (telnet) that were using the OOB interface, so in order to not break existing binaries, the SO_OOBINLINE socket option was created so that you could turn off the broken OOB semantics. That option has been around since at least 4.4BSD. Any application that uses the TCP urgent pointer and does *not* turn on SO_OOBINLINE has to deal with that decision, but it is out of scope for the IETF. >> You recommend that applications that use OOB data request that it >> be >> delivered in line. This is pointless - it fixes nothing. > > This is the intented semantincs for TCP urgent mode. And nevertheless, > the code should be prepared to handle "urgent data" in-band, because > some middle-boxes while clear the URG bit, thus effectively putting > "urgent data" back "in-line". There is no OOB data in TCP. Applications should be setting SO_OOBINLINE and using select to find out when they have transitioned into urgent mode, and using SIOCATMARK to determine when they are at the end of urgent mode. >> The RFC's today *do not allow* middle boxes to turn of the UP bit. > > And what? These are widely-deployed middleboxed. If your app depends > on > tcp urgent mode, it will break. > > > >> Either we change the spec to completely eliminate the whole concept >> of >> urgent data, or we assert that the spec is right, and these middle >> boxes >> don't conform. It's absurd to specify something and then tell >> applications "well, it's in the spec, but you can't rely on it". > > It's absurd to neglect what's a fact. Middle boxes shouldn't be turning off the URG bit. Applications shouldn't be using or relying the OOB socket interface on TCP connections. TCP provides the urgent pointer as mechanism that the applications can use to indicate an "interesting" point in the TCP data stream. It is not a record marker. It is not one-to-one (if you don't read up to the mark before a new urgent pointer arrives, you lose the knowledge of the earlier urgent pointer). It is up to the application to define what "interesting" means, what it should do with the data it reads while in urgent mode, and what to do once it gets to the mark. An application can even be written so that it tolerates whether the implementation implemented the urgent pointer as a pointer to the last byte of urgent data, or the first byte of non-urgent data. >> And, >> frankly, if NDIS's can't get this right - too bad. Fix them. > > This is impossible. The issue here is that there's the semantics of > the > UP as specified by the IETF specs, and there are the semantics that > real > implementations are using (which can be overridden by a system-wide > toggle). > > > >> BTW, Microsoft actually *relies* on OOB data. I don't know the >> details - something to do with aborting database transactions. I >> expect >> you'd see significant opposition from them to an attempt to remove >> Urgent Mode from the specs. > > Microsoft's implementation of TCP urgent mode is completely broken. > Shame on them. OOB != Urgent mode. TCP does not have OOB data. You can't get rid of something that was never there. > > > > >> When you come right down to it, Urgent Mode as specified by TCP is >> unambiguous (ignoring the age-old RFC793/RFC961 which is irrelevant >> in >> today's world: Everyone has agreed on the same interpretation). The >> actual problems are: >> >> - Middle-box implementations that *illegally* modify data in >> transit; > > huh? You claim that RFC 793 is irrelevant, and then claim that > clearing > the UP is illegal???? > > > > >> None of these can be fixed at the TCP spec level, since that's not >> where >> the problem is. (Well, the first is a matter of politics: Getting >> implementers to actually implement the specs as they exist!) > > This is completely wrong. If you get implementers to implement the > specs > as they exist, you'd be e.g. changing the semantics of the urgent > pointer (UP), which would basically break all those applications that > have not yet been broken by middleboxes clearing the URG bit. > > Our draft aims at: > > * Clarifying the concept of TCP urgent mode (no "out of band" data > channel. Simply a mark that signals whether you are in urgent mode > or not) > > * Changing the specs so that the semantics of the UP accommodate all > real implementations (i.e., "poinst to the last byte of urgent data" > vs. > "points to the byte following the last byte of urgent data". > > * Raising awareness about "urgent mode" not being reliable in the > current Internet (e.g., Cisco PIX clears the URG bit). Yep, those are the issues. >> So while I >> think it's important to raise these issues with IETF, this document >> is >> aimed at the wrong target. > > I'm not sure what's the target you think our I-D should aim at. TCPM is the right place to discuss whether the urgent pointer is the last byte of urgent data, or the first byte of non-urgent data. -David Borman > > > Thanks! > > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From david.borman@windriver.com Fri Mar 13 07:55:26 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6F328C15E for ; Fri, 13 Mar 2009 07:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxRmS7ENcsKV for ; Fri, 13 Mar 2009 07:55:20 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 9D94C3A6991 for ; Fri, 13 Mar 2009 07:55:00 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2DEtXDF025464; Fri, 13 Mar 2009 07:55:33 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 07:55:33 -0700 Received: from [172.25.44.5] ([172.25.44.5]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 07:55:32 -0700 Message-Id: <4948B93B-A894-4617-BDE8-F5D83B86DD0B@windriver.com> From: David Borman To: Jerry Leichter In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Mar 2009 09:55:31 -0500 References: <20090227222910.4AAF55654E@rebar.astron.com> <49A9A056.30207@gont.com.ar> <6F1AF259-F2A0-4266-8A92-C3712E9E1430@lrw.com> <49A9B91A.7040100@gont.com.ar> <06E1ED3F-8652-4630-86D6-38F2C519228D@lrw.com> <49AC0DB8.5050007@gont.com.ar> <8E1A8673-2072-4339-BE82-95AE85AA44C7@lrw.com> <49AD5FE4.4040100@gont.com.ar> <8645DB74-13BD-4B2C-B408-4DA7FE7DB95A@windriver.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Mar 2009 14:55:33.0023 (UTC) FILETIME=[C25C22F0:01C9A3EB] Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 14:55:26 -0000 Jerry, On Mar 12, 2009, at 5:32 PM, Jerry Leichter wrote: > On Mar 12, 2009, at 4:45 PM, David Borman wrote: >> On Mar 3, 2009, at 10:50 AM, Fernando Gont wrote: >> >>> Jerry Leichter wrote: >>> >>>> You refer to the data pointed to by the urgent pointer as the >>>> urgent >>>> data. This is incorrect. TCP doesn't directly have a concept of >>>> urgent >>>> *data*; what it has is an urgent *mode*. >>> [....] >>> >>> This was the intent of the text. I'll go through the I-D again and >>> will >>> try to remove any instances of what you describe. >> >> RFC 793 specifies all three: the urgent pointer, urgent mode, and >> urgent data. Urgent data is *all* the data before the urgent >> pointer. Urgent mode is when you are reading the urgent data. >> What TCP does not have is out of band (OOB) data. Writing just one >> byte in urgent mode makes all the previously written and unread >> data urgent data.... > A couple of comments: > > - *TCP* has no notion of "unread data" - as it has no notion of > *read* data either. TCP can't possibly be altered to introduce > any such concept without first adding in a whole model of > the interaction between the TCP stack and its buffering and > user mode and its interaction with that buffering. I can't > imagine why you would want to do that - or how you would do it > in a way that accurately reflects all existing implementations. TCP buffers in sequence received data until the application reads it, that is what I mean by unread data. TCP can even buffer data and defer making it available to the application until more data arrives; that is why there is a PUSH bit, so that the sender can indicate that no further data is coming, and any buffered data up to that point should be made available to the application for reading. When you have unread data, and a new packet arrives with the URG bit, all that unread data becomes urgent data. > - Because of this, "urgent data" is not a very interesting concept. > Urgent mode is to some degree, but even that's a mess. Actual > TCP implementations involve two weakly-synchronized state > machines, one implementing TCP, one implementing the user code. > Urgent mode is a property of the former. You mention later that > you can use the exception flags from select() to tell if you > entered urgent mode - one of the synchronization points between > the two machines. However, it's a very limited synchronization. > For one thing, entering urgent mode is not the only thing that > causes the exception flag to be set - and you have no effective > way to check what the bit really means. For another, if you're > executing a read() at user level when a segment with URG bit > set arrives, you're stuck. I suppose you could alternate > select()'s with one-byte read()'s, but let's get real here. You can register for the SIGURG signal to get out of band notification when urgent data has arrived. If you have more than one file descriptor, you can use select() to determine which descriptor has the urgent condition. You then use read() and SIOCATMARK to read the urgent data. You can do reasonable read() calls, because read() will not return data that spans the mark in a single read() call. The mechanisms for dealing with TCP urgent pointer through the socket interface have been around for at least 20 years, since the days of 4.3/4.4 BSD networking, none of this is new. > - I completely agree with you that TCP doesn't have OOB data. I > said as much. So? TCP doesn't "have" ASCII or Unicode or HTTP > either. All of these can be *built on top of* TCP. > > - Then again, *TCP* doesn't have a user API either. That, too, is > built over a TCP implementation. > > > - *The socket API* has OOB data. The implementer's problem is how > to build a correct implementation of the socket API's OOB data > on top of the TCP primitives. In fact, as I showed in a separate > message to Mr. Gont (which I'd be happy for forward if you're > interested; it's a bit long, and I don't want to just dump it > on a list of unknown size), it's actually not hard to implement > the socket OOB semantics of TCP, using urgent mode, as it is > specified today. The implementation can even be equivalent in > performance to today's implementations, for streams that never > use OOB data. It's true that one can improve the implementation > by making minor changes to TCP - but realistically the costs > would far outweigh the benefits. > > In summary: This is not, and has never been, a TCP problem. The > issues are at the boundary between the TCP stack and the socket API, > affecting code on both sides of that boundary. The only TCP issue is the mismatch between the definition of the Urgent pointer as being the last byte of the Urgent data, and the typical implementation of it being the first byte of non-urgent data. > Finally, on the question of whether the socket API should be changed > to eliminate OOB data: That's perhaps an arguable position, exactly > because the implementations are so bad; but the implicit message in > the way you state it - that TCP is what matters, and the socket API > is just some minor thing - is exactly backwards. There are at most, > what, a couple of hundred engineers in the entire world, working on > at most a few tens of distinct code bases, who actually deal with > *TCP*. There are hundreds of thousands of engineers dealing with > millions of applications that depend on the socket API. > > > Changing TCP is a big job, but one that would be doable if there > were sufficient need: Look at IPv6. Changing the socket API is > impossible - if you think IPv6 is taking a long time to roll out, > that's nothing compared to how long it would take a new, > incompatible socket API replacement. Chances are it would never > happen. I never said the socket API should be changed. The mechanisms for dealing with TCP urgent data have existed for a long time. The MSG_OOB flag provides a mechanism for an application to set the Urgent pointer when writing to a TCP socket. On the receiver side, setting SO_OOBINLINE leaves all the TCP data inline (as it should). Using SIGURG, SIOCATMARK and read() (and select() when needed), the application is notified when it should go into Urgent mode, and is able to identify when it has read up to the mark. This all works today. There is nothing to change at either the socket or TCP level. -David Borman > > > > -- Jerry > From david.borman@windriver.com Fri Mar 13 09:20:18 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1391C3A68F9 for ; Fri, 13 Mar 2009 09:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.293 X-Spam-Level: X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK08t6TJ6CBZ for ; Fri, 13 Mar 2009 09:20:17 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 47CBD3A687F for ; Fri, 13 Mar 2009 09:20:17 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2DGIdSC011437 for ; Fri, 13 Mar 2009 09:20:52 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 09:20:22 -0700 Received: from [172.25.44.5] ([172.25.44.5]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 09:20:21 -0700 Message-Id: <93BDDFCA-62F7-47D0-89C8-A3BF25F097BA@windriver.com> From: David Borman To: tcpm@ietf.org In-Reply-To: <7B9BFE24-C237-4E79-ADF0-C9CA9EE04102@windriver.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Mar 2009 11:20:20 -0500 References: <7B9BFE24-C237-4E79-ADF0-C9CA9EE04102@windriver.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 13 Mar 2009 16:20:21.0930 (UTC) FILETIME=[9B95B8A0:01C9A3F7] Subject: Re: [tcpm] Request to change TCPM time slot X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 16:20:18 -0000 The change has happened. TCPM is now scheduled for the 1520-1720 timeslot on Monday. I've updated the agenda to reflect this time change. -David Borman On Mar 12, 2009, at 10:14 AM, David Borman wrote: > There has been a request to swap the DCCP and TCPM time slots. This > would move TCPM one slot earlier, to Monday at 1520-1720. If this > would present a problem, please speak up. This would place TCPM at > the same time as: > > 1520-1720 Afternoon Session II > Continental 3 APP sieve Sieve Mail Filtering Language WG > Imperial B INT 6lowpan IPv6 over Low power WPAN WG > Continental 4 INT savi Source Address Validation > Improvements WG > Continental 6 OPS opsarea Operations & Management Area Open > Meeting > Continental 5 RAI ecrit Emergency Context Resolution with > Internet Technologies WG > Imperial A RTG forces Forwarding and Control Element > Separation WG > Continental 1&2 RTG rtgwg Routing Area Working Group WG > > We would especially like to hear if this an issue for any of the > presenters, or for those who are actively involved in the TCP AO > discussion. > > -David Borman, WG co-chair From leichter@lrw.com Thu Mar 12 15:31:41 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC8D3A6C1E for ; Thu, 12 Mar 2009 15:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KAtFk76GJN0 for ; Thu, 12 Mar 2009 15:31:40 -0700 (PDT) Received: from smtp3.bestweb.net (smtp3.bestweb.net [209.94.103.43]) by core3.amsl.com (Postfix) with ESMTP id 38D7F3A6C1B for ; Thu, 12 Mar 2009 15:31:38 -0700 (PDT) Received: from [10.0.1.3] (unknown [69.177.11.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp3.bestweb.net (Postfix) with ESMTPSA id 423915C40; Thu, 12 Mar 2009 18:32:14 -0400 (EDT) Message-Id: From: Jerry Leichter To: David Borman In-Reply-To: <8645DB74-13BD-4B2C-B408-4DA7FE7DB95A@windriver.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Mar 2009 18:32:13 -0400 References: <20090227222910.4AAF55654E@rebar.astron.com> <49A9A056.30207@gont.com.ar> <6F1AF259-F2A0-4266-8A92-C3712E9E1430@lrw.com> <49A9B91A.7040100@gont.com.ar> <06E1ED3F-8652-4630-86D6-38F2C519228D@lrw.com> <49AC0DB8.5050007@gont.com.ar> <8E1A8673-2072-4339-BE82-95AE85AA44C7@lrw.com> <49AD5FE4.4040100@gont.com.ar> <8645DB74-13BD-4B2C-B408-4DA7FE7DB95A@windriver.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Fri, 13 Mar 2009 09:45:58 -0700 Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 22:31:41 -0000 On Mar 12, 2009, at 4:45 PM, David Borman wrote: > On Mar 3, 2009, at 10:50 AM, Fernando Gont wrote: > >> Jerry Leichter wrote: >> >>> You refer to the data pointed to by the urgent pointer as the >>> urgent >>> data. This is incorrect. TCP doesn't directly have a concept of >>> urgent >>> *data*; what it has is an urgent *mode*. >> [....] >> >> This was the intent of the text. I'll go through the I-D again and >> will >> try to remove any instances of what you describe. > > RFC 793 specifies all three: the urgent pointer, urgent mode, and > urgent data. Urgent data is *all* the data before the urgent > pointer. Urgent mode is when you are reading the urgent data. What > TCP does not have is out of band (OOB) data. Writing just one byte > in urgent mode makes all the previously written and unread data > urgent data.... A couple of comments: - *TCP* has no notion of "unread data" - as it has no notion of *read* data either. TCP can't possibly be altered to introduce any such concept without first adding in a whole model of the interaction between the TCP stack and its buffering and user mode and its interaction with that buffering. I can't imagine why you would want to do that - or how you would do it in a way that accurately reflects all existing implementations. - Because of this, "urgent data" is not a very interesting concept. Urgent mode is to some degree, but even that's a mess. Actual TCP implementations involve two weakly-synchronized state machines, one implementing TCP, one implementing the user code. Urgent mode is a property of the former. You mention later that you can use the exception flags from select() to tell if you entered urgent mode - one of the synchronization points between the two machines. However, it's a very limited synchronization. For one thing, entering urgent mode is not the only thing that causes the exception flag to be set - and you have no effective way to check what the bit really means. For another, if you're executing a read() at user level when a segment with URG bit set arrives, you're stuck. I suppose you could alternate select()'s with one-byte read()'s, but let's get real here. - I completely agree with you that TCP doesn't have OOB data. I said as much. So? TCP doesn't "have" ASCII or Unicode or HTTP either. All of these can be *built on top of* TCP. - Then again, *TCP* doesn't have a user API either. That, too, is built over a TCP implementation. - *The socket API* has OOB data. The implementer's problem is how to build a correct implementation of the socket API's OOB data on top of the TCP primitives. In fact, as I showed in a separate message to Mr. Gont (which I'd be happy for forward if you're interested; it's a bit long, and I don't want to just dump it on a list of unknown size), it's actually not hard to implement the socket OOB semantics of TCP, using urgent mode, as it is specified today. The implementation can even be equivalent in performance to today's implementations, for streams that never use OOB data. It's true that one can improve the implementation by making minor changes to TCP - but realistically the costs would far outweigh the benefits. In summary: This is not, and has never been, a TCP problem. The issues are at the boundary between the TCP stack and the socket API, affecting code on both sides of that boundary. Finally, on the question of whether the socket API should be changed to eliminate OOB data: That's perhaps an arguable position, exactly because the implementations are so bad; but the implicit message in the way you state it - that TCP is what matters, and the socket API is just some minor thing - is exactly backwards. There are at most, what, a couple of hundred engineers in the entire world, working on at most a few tens of distinct code bases, who actually deal with *TCP*. There are hundreds of thousands of engineers dealing with millions of applications that depend on the socket API. Changing TCP is a big job, but one that would be doable if there were sufficient need: Look at IPv6. Changing the socket API is impossible - if you think IPv6 is taking a long time to roll out, that's nothing compared to how long it would take a new, incompatible socket API replacement. Chances are it would never happen. -- Jerry From ayourtch@cisco.com Fri Mar 13 13:30:47 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778C73A6A8B for ; Fri, 13 Mar 2009 13:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAqj-dDtBXTO for ; Fri, 13 Mar 2009 13:30:46 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 421213A6AB3 for ; Fri, 13 Mar 2009 13:30:46 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2DKVHS06086; Fri, 13 Mar 2009 21:31:18 +0100 (CET) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2DKVBt18133; Fri, 13 Mar 2009 21:31:12 +0100 (CET) Date: Fri, 13 Mar 2009 21:32:50 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Jerry Leichter In-Reply-To: Message-ID: References: <20090227222910.4AAF55654E@rebar.astron.com> <49A9A056.30207@gont.com.ar> <6F1AF259-F2A0-4266-8A92-C3712E9E1430@lrw.com> <49A9B91A.7040100@gont.com.ar> <06E1ED3F-8652-4630-86D6-38F2C519228D@lrw.com> <49AC0DB8.5050007@gont.com.ar> <8E1A8673-2072-4339-BE82-95AE85AA44C7@lrw.com> <49AD5FE4.4040100@gont.com.ar> <8645DB74-13BD-4B2C-B408-4DA7FE7DB95A@windriver.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tcpm@ietf.org, David Borman , Fernando Gont Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 20:30:47 -0000 On Thu, 12 Mar 2009, Jerry Leichter wrote: > > In summary: This is not, and has never been, a TCP problem. The issues are > at the boundary between the TCP stack and the socket API, affecting code on > both sides of that boundary. That's somewhat the problem is that it's "noone's problem". In my opinion, the best thing is a strongest possible message to the application developers "if you were planning to use this, don't". Whether the definition of is one byte left or right does not matter - the ambiguity is *already* there. Granted, it can be mitigated within the specific administrative domain, but if I talk to you across the internet, there's absolutely no guarantee whatsoever (try to interrupt an FTP transfer from a randomly selected server and see how many actually do not hang - amongst those that keep the tcp/21 connection of course) > > Finally, on the question of whether the socket API should be changed to > eliminate OOB data: That's perhaps an arguable position, exactly because the > implementations are so bad; but the implicit message in the way you state it > - that TCP is what matters, and the socket API is just some minor thing - is > exactly backwards. There are at most, what, a couple of hundred engineers in > the entire world, working on at most a few tens of distinct code bases, who > actually deal with *TCP*. There are hundreds of thousands of engineers > dealing with millions of applications that depend on the socket API. The initial discussion we had with Fernando that gave a rise to this draft was of the flavour "TCP Urgent considered harmful for application developers". > > Changing TCP is a big job, but one that would be doable if there were > sufficient need: Look at IPv6. Changing the socket API is impossible - if > you think IPv6 is taking a long time to roll out, that's nothing compared to > how long it would take a new, incompatible socket API replacement. Chances > are it would never happen. All depends on the business needs, but the TCP Urgent is indeed not among the most widely used ones. A clear and well-structured semantics of Out-Of-Band Notifications might be of some use though, IMHO - but then, one could as well use the separate UDP channel along - though it is not as "convenient". thanks, andrew From rfc-editor@rfc-editor.org Mon Mar 16 17:01:11 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C4728C196; Mon, 16 Mar 2009 17:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.953 X-Spam-Level: X-Spam-Status: No, score=-16.953 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxXef+jfxVUJ; Mon, 16 Mar 2009 17:01:10 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 721FB28C189; Mon, 16 Mar 2009 17:01:10 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 2DD4D257711; Mon, 16 Mar 2009 16:59:32 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090316235932.2DD4D257711@bosco.isi.edu> Date: Mon, 16 Mar 2009 16:59:32 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 5482 on TCP User Timeout Option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 00:01:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5482 Title: TCP User Timeout Option Author: L. Eggert, F. Gont Status: Standards Track Date: March 2009 Mailbox: lars.eggert@nokia.com, fernando@gont.com.ar Pages: 14 Characters: 33568 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-tcp-uto-11.txt URL: http://www.rfc-editor.org/rfc/rfc5482.txt The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [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 USC/Information Sciences Institute From david.borman@windriver.com Thu Mar 19 13:16:47 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1D728C14D for ; Thu, 19 Mar 2009 13:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C65touKXKn4o for ; Thu, 19 Mar 2009 13:16:46 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 7C5CB28C145 for ; Thu, 19 Mar 2009 13:16:46 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2JKHWCd010715 for ; Thu, 19 Mar 2009 13:17:32 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 13:17:32 -0700 Received: from [172.25.34.49] ([172.25.34.49]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 13:17:31 -0700 Message-Id: From: David Borman To: tcpm@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Mar 2009 15:17:30 -0500 References: <20090227222910.4AAF55654E@rebar.astron.com> <49A9A056.30207@gont.com.ar> <6F1AF259-F2A0-4266-8A92-C3712E9E1430@lrw.com> <49A9B91A.7040100@gont.com.ar> <06E1ED3F-8652-4630-86D6-38F2C519228D@lrw.com> <49AC0DB8.5050007@gont.com.ar> <8E1A8673-2072-4339-BE82-95AE85AA44C7@lrw.com> <49AD5FE4.4040100@gont.com.ar> <8645DB74-13BD-4B2C-B408-4DA7FE7DB95A@windriver.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Mar 2009 20:17:32.0132 (UTC) FILETIME=[BBECBA40:01C9A8CF] Subject: Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 20:16:47 -0000 Hello TCPM members, At the TCPM session on Monday, I intend to take a hum on whether or not the WG wants to take on the issue of the definition of the TCP Urgent pointer (the last byte of urgent data), and its contradiction with most TCP implementations (the first byte after the urgent data), as documented in draft-gont-tcpm-urgent-data-01.txt. It would be nice to get a feel from the mailing list prior to the meeting. Please reply whether you are in favor of, against or have no opinion on adopting this as a WG item. -David Borman, TCPM co-chair From ekr@networkresonance.com Thu Mar 19 17:07:26 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222BE3A6B22 for ; Thu, 19 Mar 2009 17:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drFwuYy7sLxX for ; Thu, 19 Mar 2009 17:07:25 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 1578F3A6991 for ; Thu, 19 Mar 2009 17:07:25 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 5E79150822 for ; Thu, 19 Mar 2009 17:31:06 -0700 (PDT) Date: Thu, 19 Mar 2009 17:31:06 -0700 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090320003106.5E79150822@romeo.rtfm.com> Subject: [tcpm] Review of draft-tcp-mtcp-auth-opt-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 00:07:26 -0000 [Resent from an account that's subscribed.] -Ekr $Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00-rev.txt,v 1.1 2009/03/19 22:37:19 ekr Exp $ S 2.1. This whole {SHOULD,MUST}{+,-,*,?} thing is a bad idea. It's hard enough for developers to understand SHOULD vs. MUST, but now we have 5 separate options for implementors to understand and us to argue over. I don't remember there being WG consensus on this point. S 2.2. The assignment of HMAC-SHA-1 to MUST- and AES-CMAC to SHOULD+ is basically unjustified. There's no good reason to believe that HMAC-SHA1 will be broken before AES-CMAC. This is exactly the confusion fostered by the +/- regime. Make HMAC-SHA1 MUST and AES-CMAC SHOULD. S 3. You repeat the phrase "Each MAC algorithm MUST..." twice. S 3.1. It's confusing to talk about KDFs having an interface and then have the function named "PRF". I would rewrite this as: All KDFs used in TCP-AO have the following interface: Derived_Key = KDF(Master_Key, Context, Output_Length) Where these values are defined as.... [blah blah] Then: The KDFs defined in this document are all based on pseudorandom functions (PRFs) which take a key and an input and emit a fixed-length pseudorandom value. Given PRF X, the associated KDF, KDF_X, is constructed as follows: KDF_X(Master_Key, Context, Output_Length) = X(Master_Key, Input) Where Input is constructed as:... Where you say that the master key isn't random, that's not quite right. The point is not that it doesn't contain high entropy. For instance HEX(X) where X is a 128-bit random number has high entropy but may or may not be suitable for use keying a MAC function. This section of the document is pretty confusing about the concept of output length. To recap: 1. The underlying PRFs have fixed sized output lengths, 128 bits in the case of AES-CMAC, 160 bits in the case of HMAC-SHA1. 2. It is possible to generate an arbitrary number of output bits with a given PRF by operating it in a feedback or counter mode. The FIPS-whatever KDFs incorporate this feature, hence the leading "0". 3. Each MAC needs a key of a specific length. 4. Not totally uncoincidentally, the KDFs we have chosen to use with each MAC happen to generate the right key size for use with the MAC, thus avoiding the need for the procedure in (2). 5. If you wanted to use these KDFs with a MAC requiring a longer key (e.g., HMAC-SHA-256) you would, however need to use the procedure. 6. For some reason, the FIPS-whatever KDFs seem to think it's a useful idea to mix the desired number of bits produced by the KDF into the KDF input. I don't see the point of this, but whatever. You'll note that the PRF does not need to be parametrized in terms of output length. It's fixed. IMO, this could be a lot clearer. S 3.1.1. Is this an ASCII 0 (0x30) or a NUL (0x00) S 3.1.2. It's pretty unclear what problem you're trying to solve here. I would write: RFC 4615 is designed to take an arbitrary length key but for any key length other than 128 bits, whitens it by first computing an AES-CMAC with key 0. Because the keys in use with TCP-AO will likely be arbitrary-length ASCII strings, TCP AO always performs this whitening step even if the key happens to be 16 bytes long. In other words, using the terminology of RFC 4615: K = AES-CMAC(0^128, MK, MKlen) S 4. This UI labels section should be entirely removed. As far as I know, there was never WG consensus to include it and it just creates extra confusion. In AO, the MAC completely defines the KDF, so the concept of suites just adds an extra name. Moreover, since MACs have obvious names and the suites have opaque, confusing names, this is doubly bad. From ekr@networkresonance.com Thu Mar 19 17:09:01 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A763A6A0B for ; Thu, 19 Mar 2009 17:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwaoqTCBkOI7 for ; Thu, 19 Mar 2009 17:09:00 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 51E8B3A6924 for ; Thu, 19 Mar 2009 17:09:00 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E345150822 for ; Thu, 19 Mar 2009 17:32:41 -0700 (PDT) Date: Thu, 19 Mar 2009 17:32:41 -0700 From: Eric Rescorla To: tcpm@ietf.org In-Reply-To: <86r60tf31x.wl%ekr@networkresonance.com> References: <86r60tf31x.wl%ekr@networkresonance.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090320003241.E345150822@romeo.rtfm.com> Subject: Re: [tcpm] Review of draft-tcp-mtcp-auth-opt-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 00:09:01 -0000 At Thu, 19 Mar 2009 17:31:06 -0700, Doh. This review was of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00 A review of auth-opt is forthcoming. -Ekr At Thu, 19 Mar 2009 17:31:06 -0700, Eric Rescorla wrote: > > [Resent from an account that's subscribed.] > > -Ekr > > $Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00-rev.txt,v 1.1 2009/03/19 22:37:19 ekr Exp $ > > S 2.1. > This whole {SHOULD,MUST}{+,-,*,?} thing is a bad idea. It's hard > enough for developers to understand SHOULD vs. MUST, but now we have 5 > separate options for implementors to understand and us to argue > over. I don't remember there being WG consensus on this point. > > > S 2.2. > The assignment of HMAC-SHA-1 to MUST- and AES-CMAC to SHOULD+ is > basically unjustified. There's no good reason to believe that > HMAC-SHA1 will be broken before AES-CMAC. This is exactly the > confusion fostered by the +/- regime. Make HMAC-SHA1 MUST and > AES-CMAC SHOULD. > > > S 3. > You repeat the phrase "Each MAC algorithm MUST..." twice. > > > S 3.1. > It's confusing to talk about KDFs having an interface and then > have the function named "PRF". > > I would rewrite this as: > > All KDFs used in TCP-AO have the following interface: > > Derived_Key = KDF(Master_Key, Context, Output_Length) > > Where these values are defined as.... [blah blah] > > Then: > The KDFs defined in this document are all based on pseudorandom > functions (PRFs) which take a key and an input and emit a > fixed-length pseudorandom value. Given PRF X, the associated > KDF, KDF_X, is constructed as follows: > > KDF_X(Master_Key, Context, Output_Length) = > X(Master_Key, Input) > > Where Input is constructed as:... > > Where you say that the master key isn't random, that's not quite > right. The point is not that it doesn't contain high entropy. > For instance HEX(X) where X is a 128-bit random number has high > entropy but may or may not be suitable for use keying a MAC > function. > > This section of the document is pretty confusing about the concept of > output length. To recap: > > 1. The underlying PRFs have fixed sized output lengths, 128 bits in the > case of AES-CMAC, 160 bits in the case of HMAC-SHA1. > 2. It is possible to generate an arbitrary number of output bits with > a given PRF by operating it in a feedback or counter mode. > The FIPS-whatever KDFs incorporate this feature, hence the > leading "0". > 3. Each MAC needs a key of a specific length. > 4. Not totally uncoincidentally, the KDFs we have chosen to use with > each MAC happen to generate the right key size for use with the > MAC, thus avoiding the need for the procedure in (2). > 5. If you wanted to use these KDFs with a MAC requiring a longer key > (e.g., HMAC-SHA-256) you would, however need to use the procedure. > 6. For some reason, the FIPS-whatever KDFs seem to think it's > a useful idea to mix the desired number of bits produced by the > KDF into the KDF input. I don't see the point of this, but > whatever. > > You'll note that the PRF does not need to be parametrized in terms > of output length. It's fixed. > > IMO, this could be a lot clearer. > > S 3.1.1. > Is this an ASCII 0 (0x30) or a NUL (0x00) > > > S 3.1.2. > It's pretty unclear what problem you're trying to solve here. I would > write: > > RFC 4615 is designed to take an arbitrary length key but for any > key length other than 128 bits, whitens it by first computing an > AES-CMAC with key 0. Because the keys in use with TCP-AO will > likely be arbitrary-length ASCII strings, TCP AO always performs > this whitening step even if the key happens to be 16 bytes long. > In other words, using the terminology of RFC 4615: > > K = AES-CMAC(0^128, MK, MKlen) > > > S 4. > This UI labels section should be entirely removed. As far as I know, > there was never WG consensus to include it and it just creates > extra confusion. In AO, the MAC completely defines the KDF, so > the concept of suites just adds an extra name. Moreover, since > MACs have obvious names and the suites have opaque, confusing names, > this is doubly bad. > > > > > > > > > > > > > > > > > > > > > > > > > > > From ekr@networkresonance.com Thu Mar 19 18:13:04 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193553A684E for ; Thu, 19 Mar 2009 18:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K864xnkFvj+r for ; Thu, 19 Mar 2009 18:13:02 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 9806E3A63EC for ; Thu, 19 Mar 2009 18:13:02 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2E62350822 for ; Thu, 19 Mar 2009 18:36:44 -0700 (PDT) Date: Thu, 19 Mar 2009 18:36:44 -0700 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090320013644.2E62350822@romeo.rtfm.com> Subject: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-04 [This time for sure] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 01:13:04 -0000 $Id: draft-ietf-tcpm-tcp-auth-opt-04-rev.txt,v 1.1 2009/03/20 00:18:59 ekr Exp $ I've just given this document a complete readthrough. Comments below. GENERAL COMMENTS Now that I read the document end to end, I find it to be extremely hard to follow. I don't know if it's always been like that and I'm just noticing it as the technical issues come into focus or if it's the result of multiple technical revisions, but in any case, IMO some significant editorial work is needed. The most serious problem is the confusion in the text between three concepts: - Master Keys - Key-Ids - Traffic keys As an example, S 8.1 reads: At any given time, a single TCP connection may have multiple KeyIDs specified for each segment direction (incoming, outgoing). TCP-AO provides a mechanism to indicate when a new KeyID is ready, to allow It's not that you have multiple key-ids. Indeed, if we're using keys with different outgoing and incoming key-ids, you will *always* have multiple key-ids. Rather, it's that you have multiple master keys. The basic unit of operation here is not the key-id but rather the master key, which comprises the following values (at least): - master_key - send key_id - receive key_id - MAC algorithm If you want to invent a new concept (e.g., security association) that holds all of these, that's fine I suppose. However, it's really confusing to use key-id here. I suspect this is a holdover from previous text. In any case, I think the document would benefit from some explanatory text along the lines of the above. The second clarity point is the relationship between master keys and traffic keys is. I would think a diagram like the following might be in order: Master_Key_A Master_Key_B - Send_Key_Id = 1 - Send_Key_Id = 5 - Recv_Key_Id = 2 - Recv_Key_Id = 6 - Algorithm = HMAC-SHA1 - Algorithm = AES-CMAC | | | | +----------------+-----------------+ | | | | v v v Connection 1 Connection 2 Connection 3 - Send_SYN_key - Send_SYN_key - Send_SYN_key - Recv_SYN_key - Recv_SYN_key - Recv_SYN_key - Send_Other_key - Send_Other_key - Send_Other_key - Send_Other_key - Send_Other_key - Send_Other_key I realize this is imperfect since you could have two master keys, but it's the best I can do right now. As I've indicated previously, I find the TSAD/TAPD concept incredibly unhelpful. There may well be implementations for which it is natural, but I don't consider it the natural one, and making it in effect a mandatory feature of the protocol seems like an undue burden on implementors. I appreciate that this has been in the document since day one, but if you go back to my review of -00 a year ago, I raised exactly the same concern and we have never taken the discussion to closure or had a consensus call, so I don't consider this in any respect a settled issue. If there are those who feel it's important to keep this design, I would ask the chairs to make this topic an explicit agenda item and I would like agenda time to present an alternative design. DETAILED COMMENTS S 5. 2. A TCP option flag. When 0, this flag allows default operation, i.e., TCP options are included in the MAC calculation, with TCP- AO's MAC field zeroed out. When 1, all options (excluding TCP-AO) are excluded from all MAC calculations (skipped over, not simply zeroed). The option flag applies to TCP options in both directions (incoming and outgoing segments). This text has two problems. First, the whole concept of a default is meaningless here (I believe we agreed on this in e-mail, but I'm adding the comment to make sure). Second, since this flag has no wire encoding, it doesn't make any sense to discuss what 0 and 1 mean. >> The set of TAPD master key tuples MAY change during a connection, but KeyIDs of those tuples MUST NOT overlap. I.e., tuple parameter changes MUST be accompanied by master key changes. I think this is a little problematic because of concreteness about "master key". If I'm using master key "ABC" and I decide to change the MAC algorithm, I can still use "ABC". This is an argument for a higher level "security association" type construct, I suppose. >> A TAPD implementation MUST support at least two KeyIDs per connection per direction, and MAY support up to 256. This is another example of confusion between master keys and key-ids. It's two master keys you need to be able to support. >> When a TAPD entry matches a new connection, TCP-AO is required. This is true regardless of whether there are any master key tuples present. Even if we accept the TAPD construct, this is too much requirement on the implementation. Why can't I have a TPAD entry that means "don't do AO". For a particular endpoint (i.e., IP address) there would be exactly one TAPD that is consulted by all pending connections, the same way that there is only one table of TCBs (a database can support multiple endpoints, but an endpoint is represented in only one database). Multiple databases could be used to support virtual hosts, i.e., groups of interfaces. Again, TMI. This is one implementation, but there are sensible implementations with multiple TAPDs. NOTE: an open issue is whether to require actions when master keys are added to the TAPD. In particular, there is a suggestion to force new added keys to update current_key to the newly added value, and to set a timer or flag on previous current_key values. If a timer, the value is unclear (2*MSL isn't appropriate, because we don't know how long a key changeover may take, and we're not reacting to messages from the other side). If a flag, this would require that flagged entries could never be advertised as NextKeyID. This is pretty unclear, but I don't think it's what people are recommending. Rahter that once a key is displaced, it should time out. S 6. 1. Current_key - the KeyID of the master key tuple currently used to authenticate outgoing segments, inserted in outgoing segments as It's not the KeyID that should be stored but rather the master key tuple. 3. A pair of Extended Sequence Numbers (ESNs). ESNs are used to prevent replay attacks, as described in Section 8.2. Each ESN is initialized to zero upon connection establishment. Its use in the MAC calculation is described in Section 7.1. The term "extended sequence number" is confusing here. The entire 64-bit quantity is an ESN. If anything, this is a sequence number extension (SNE). Master key tuples are used, together with other parameters of a connection, to create traffic keys unique to each connection, as described in Section 7.2. These traffic keys can be cached after computation, and are typically stored in the TCB with the corresponding master key tuple information. They can be considered part of the per-connection parameters. Typically? We don't have enough implementations to talk about typical. S7.1. o MAC_truncation - the number of bytes to truncate the output of the MAC to. This is indicated by the MAC algorithm, as specified in [ao-crypto]. I don't think it makes sense to talk about truncation here. The MACs produce a value that is crammed into the packet. If there's a separate spec that describes the MACs, it's not AO's business whether those MACs were produced by a truncation process. o MAC - the fixed-length output of the MAC algorithm, given the parameters provided. If the MAC_alg output is smaller than the desired MAC_truncation, it is padded with trailing zeroes as needed. This padding seems extraordinarily unsafe. If this ever happens, something has gone badly wrong. >> To allow a TCP-AO implementation to compute any implicit MAC algorithm padding required, the specification for each algorithm used with TCP-AO MUST specify the padding modulus for the algorithm, if one is required. S 7.2. I don't even know what a padding modulus is, but every MAC I know of does it's own padding. MAC algorithm indicates how to use the traffic key, e.g., as HMACs do in general [RFC2104][RFC2403]. The traffic key is derived from the s/in general//. ensures that connection keys generated for each direction are unique. s/connection keys/traffic keys/ o Send_SYN_traffic_key - the traffic key used to authenticate outgoing SYNs. The source ISN known (the TCP connection's local ISN), and the destination (remote) ISN is unknown (and so the value 0 is used). o Receive_SYN_traffic_key - the traffic key used to authenticate incoming SYNs. The source ISN known (the TCP connection's remote ISN), and the destination (remote) ISN is unknown (and so the value 0 is used). You should probably mention that in most cases (except for simultaneous opens) only one of these is needed per side. S 7.3. Much of the text here is now overtaken by events. S 8.1. At any given time, a single TCP connection may have multiple KeyIDs specified for each segment direction (incoming, outgoing). TCP-AO provides a mechanism to indicate when a new KeyID is ready, to allow See above for my comments on this. the sender to commence use of that new KeyID. This supported by using two key ID fields in the header: o KeyID o NextKeyID It's probably worth mentioning that these may (often will) be the same. A diagram here seems like it might be useful. S 9.2. >> A TAPD entry MAY underspecify the TCP connection for the LISTEN state. Such an entry MUST NOT be used for more than one connection progressing out of the LISTEN state. I don't see why this is a problem with the current system. On the contrary, it would be quite attractive to simply set the listening socket with a single master key. -Ekr From A.Hoenes@tr-sys.de Fri Mar 20 15:31:48 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9573A6BE2 for ; Fri, 20 Mar 2009 15:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.933 X-Spam-Level: * X-Spam-Status: No, score=1.933 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LZUAVDcq0bV for ; Fri, 20 Mar 2009 15:31:47 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 64E9B3A6ABA for ; Fri, 20 Mar 2009 15:31:45 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA045438232; Fri, 20 Mar 2009 23:30:32 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA29496; Fri, 20 Mar 2009 23:30:31 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200903202230.XAA29496@TR-Sys.de> To: tcpm@ietf.org Date: Fri, 20 Mar 2009 23:30:31 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [tcpm] On TCP Urgent processing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 22:31:48 -0000 On Wed, 11 Mar 2009 15:56:11 -0500, TCPM co-chair David Borman wrote: > One of the items on the TCPM agenda for IETF 74 is the TCP Urgent > pointer. I want this to be a very focused discussion around one > question: Should the urgent pointer point to the last byte of > urgent data, or the first byte of non-urgent data? IMO that is the most worse question to start with. This question should be posed -- if at all -- *after* exploring and conceptionally resolving the basic inconsistencies. Therefore, I very much appreciate the message sent today as a step forward in a good direction: > At the TCPM session on Monday, I intend to take a hum on whether > or not the WG wants to take on the issue of the definition of > the TCP Urgent pointer (the last byte of urgent data), and its > contradiction with most TCP implementations (the first byte > after the urgent data), as documented in > draft-gont-tcpm-urgent-data-01.txt. > It would be nice to get a feel from the mailing list prior > to the meeting. > > Please reply whether you are in favor of, against or have no > opinion on adopting this as a WG item. > > -David Borman, TCPM co-chair > I very much support adopting TCP URG clarifications as a work item for TCPM, and to base that on draft-gont-tcpm-urgent-data-01 as a starting point, but I strongly oppose using the term "Urgent Data" as a given in this context. IMO, "Urgent Data" is the term that needs clarification. The task should be organized in a very different way than proposed by David. The utmost first step for any follow-on draft must be to replace "Urgent Data" by "Urgent Processing" or "Urgent Mode" in the document title and similarly in the draft name. See below! For the moment: Please don't yawl, read on first! I'd like to use a picture to start explaining my position: If the fire-brigade is called to fight a conflagration, it should not ask the question whether the flames are more hot on the left-hand side of the fire or on the right-hand side, it should try to extinct the fire; and if the fire is fed by fermentation gas, the main problem is to get rid of the mould this gas is continuing to emanate from. However, the most important task to be undertaken initially by the fire-brigade would be to rescue the people affected by the fire ! Quite some time ago, I had started investigations on the background of the Urgent Processing mess, and studied the historical documents available online. This work had been interrupted and resumed later, but it could not be taken to an exhaustive end, since in the meantime the RFC Editor has made available a wealth of old IENs; sadly, these documents are only available as scanned facsimile copies of mediocre quality, and hence not amenable to `grep`ing and other text search methods at hand. David already has explained many of the historical facts in his recent postings in response to implementer discussions on the list. In particularly, he has emphasized that there's no concept of 'out-of-band data' in TCP. This was present in X.25 and the old ARPANET, and in Telnet, and in the socket API (cf. AF_CCITT functionality!), when TCP has been specified, and governments and agencies aligned with CCITT and evolving ISO activities had blindly overtaken the requirement to support this concept for any 'officially acceptable' Transport Protocol, and so apparently the 'TCP committee' was forced to cheet a bit to defeat the pressure they have been faced and get their proposal socialized. I will try to get a detailed summary of my results so far posted to the list by Sunday evening (European time), i.e. early afternoon Pacific Time, with my conclusions drawn, and more rationale for the proposal made below -- but IETF-unrelated circumstances might absorb my cycles. I hope the details here should suffice to explain my point of view. The 'mould' in the picture above, applied to TCP Urgent processing lies in the term "urgent data". There are at least a handfull of different and incompatible definitions of this term buried in various documents, in the brains of developers, and in implementations -- both of TCP stacks and of applications. The basic concept in RFC 793 and all its predecessors since the introduction of the Urgent Pointer into TCP per RFC 675 (Dec. 1974) is "Urgent Processing", designating the TCP receiver skipping quickly over data sent beforehand but having become 'OBE' by some event at the TCP sender -- typically a human user hitting some "Interrupt" key. As a Mathematician, I'm used to start with precise definitions before talking about properties and drawing conclusions. Thus, I insist on going back to the fundamental terms and not try to base arguing on fuzzy, derived terms like "Urgent Data". The two terms precisely defined in the glossary of RFC 793 and its predecessors are "URG" and "urgent pointer" (RFC 793, pg.84): | URG | A control bit (urgent), occupying no sequence space, used to | indicate that the receiving user should be notified to do | urgent processing as long as there is data to be consumed with | sequence numbers less than the value indicated in the urgent | pointer. | | urgent pointer | A control field meaningful only when the URG bit is on. This | field communicates the value of the urgent pointer which | indicates the data octet associated with the sending user's | urgent call. Since these definitions are rather precise, all considerations and conclusions should take these as the starting point. IMO, it does not make any sense to talk about the relationship of the Urgent Pointer and "urgent data" before we have found consensus on what "urgent data" shall mean, with a definition solely based on the basic terms and the processing model laid out in Section 3.7 of RFC 793, on pp. 41/42. Unfortunately, RFC 793 contains text passages that apparently introduce the term "urgent data" with three different meanings. This issue needs to be investigated and resolved *before* attempting to decide what should be corrected/updated. For some details and ideas, see below. The basic reason of why implementations did not follow the 'corrections' to RFC 793 first published in RFC 924 ( not: RFC 961, as indicated in the last paragraph of Section 2.2 of draft-gont-tcpm-urgent-data-01 ! ) and finally codified in RFC 1122, seems to be that the terminology and the processing rules were partially contradictory from the beginning -- and that apparently was caused by historical circumstances and pressure exerted on the "TCP committee" over a long time span in these old days. Therefore, any attempt to clarify the Urgent Processing in TCP should thoroughly assess all the contradictions and find a fully consistent way to describe the intended processing. Only a fully consistent description and specification has a chance to become accepted and adopted by implementers in the future. Now, that's all interesting and very important for future TCP implementations, but we need to acknowledge the inertia of mass of the deployed TCP kernel code. Therefore, returning to the picture painted above, the *first* step should be to formulate strong recommendations for how applications and in particular implementations of applications should make use of TCP Urgent Processing (if any). This IMO should be based on the concepts explained in the two definitions from RFC 793 quoted above. Since decades, Telnet makes use of URG, and apparently this all works (almost) properly, independent of the underlying TCP stacks' behavior at the sending and receiving side. (BTW: the discussion in RFC 1123 seems also to be disturbed.) The reason seems to be simple: being defensive, and not assigning semantics to the data delivered with the sending side's urgent call. According to RFC 854, the Telnet client sends a DM NVT control character which is a transparent NOP for the Telnet server. Thus, it does not matter for the Telnet server how the TCP stack interprets the Urgent pointer. I therefore recommend to put on the agenda of a new TCPM work item on TCP URG, in total comprised of two steps: (1) Give recommendations for application protocol designers and application programmers of how to best use the common Sockets API for Urgent Processing, in order to accommodate the legacy problems and the inconsistencies in the specifications. This should target BCP status, and it should have a tight milestone of not more than 6 months for passing to the IESG. Most elements of such document already are in draft-gont-tspm-urgent-data-01 ; my personal expectations for the basic recommendations are: o MUST always use OOBINLINE; o SHOULD only send a single octet in the urgent call; o SHOULD use syntactically transparent data in the urgent call (equivalent to DM == NOP in Telnet); o intermediate systems MUST NOT scrub the TCP URG flag (URG is an entirely end-to-end indication); o a hint that a parallel TCP connection ('control channel') SHOULD be used if an application needs true OOB data transfer. The second step to be undertaken by the WG should be a thorough review of the most important specifications (RFC 793 and RFC 1122 for TCP, RFC 854 and RFC 1123 for Telnet) w.r.t. Urgent Processing. Since so many folks stick with the term "Urgent Data", I painfully am aware of that my favorite goal, eliding that term from the specifications, is hopelessly inachievable. Based on the captured intent of the original specifications, therefore, a unique definition for "Urgent Data" should be found. In RFC 793, three possible candidate definitions are sublimely used: a) the data 'temporally' ahead of the Urgent Pointer, i.e. the all the buffered data that are being invalidated by the 'urgent' call (TCP 'SEND' call in the abstract TCP 'User Interface' of RFC 793, section 3.8, pp. 46/47, with URGENT flag set); b) the data sent with the 'urgent' call; c) the union of both a) and b). Note #1: Another possible definition -- closely related to b) --, d) the "out-of-band-data"; should not be a candidate for consideration, because TCP is based on the idea that maintaining a parallel connection for 'control' data (if needed at all) is much more efficient and cost effective in TCP/IP than the protocol overhead that would be needed for OOB data, like it was in X.25; the single, flow- controlled byte-stream pipe model was the basic concept for TCP. Note #2: Apparently, for the most time RFC 793 assumes definition a), whereas RFCs 924, 944, 961, 991, 1011, and finally RFC 1122 assume definition c). This explains part of the trouble we have. Note #3: The ambiguity in RFC 793 mostly stems from that it remains underspecified whether the urgent pointer refers to the state of the sequence number at entry to the event processing or at its end, i.e. whether (on pg. 56) "SND.UP <- SND.NXT - 1" should happen before of after processing the data handed over in the SEND with URGENT flag set. Note #4: There is more trouble in RFC 793 related to Urgent mode; in particular, the event processing rules deal with URGENT flag for the OPEN call whereas the OPEN Interface definition does not contain such flag at all. After that analysis and definition have been done, the necessary updates for the old specifications to make tme consistently use the definition can be derived. Thus, the second delivery of the TCP URG work item should be: (2) A Normative (Standards Track) document clarifying the definition of the term "Urgent Data" for TCP and Updating primarily RFC 793 and RFC 1122, but for consistency also RFC 854 and RFC 1123, to make them conformant to the clarified definition and provide consistent and self- consistent processing rules. This should be subject to an ambitious milestone of one year until being passed to the IESG. I will not be able to attend the meeting next week, but ... I'd offer to work as a co-editor with Fernando Gont for a TCPM work item shaped along the ideas and guidelines presented above, but more volunteers to help with completing the investigations of the TCP-related IEN documents would be heartfully welcome, in order to give the whole effort the best possible foundation to be in the spirit of the original designers of TCP. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From fernando@gont.com.ar Fri Mar 20 18:52:51 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C8E3A6A12 for ; Fri, 20 Mar 2009 18:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N08f+-YWYRs8 for ; Fri, 20 Mar 2009 18:52:50 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 2DB623A69C4 for ; Fri, 20 Mar 2009 18:52:48 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id EFCA46B6594; Fri, 20 Mar 2009 22:53:39 -0300 (ART) Received: from [192.168.0.156] (235-131-17-190.fibertel.com.ar [190.17.131.235]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n2L1rL9b005983; Fri, 20 Mar 2009 22:53:22 -0300 Message-ID: <49C44899.6090003@gont.com.ar> Date: Fri, 20 Mar 2009 22:53:29 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <200903202230.XAA29496@TR-Sys.de> In-Reply-To: <200903202230.XAA29496@TR-Sys.de> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 20 Mar 2009 22:53:39 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] On TCP Urgent processing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 01:52:51 -0000 Alfred � wrote: > The utmost first step for any follow-on draft must be to replace > "Urgent Data" by "Urgent Processing" or "Urgent Mode" in the > document title and similarly in the draft name. See below! Well, this one shouldn't be a problem. I can live with it. :-) > The basic reason of why implementations did not follow > the 'corrections' to RFC 793 first published in RFC 924 > ( not: RFC 961, as indicated in the last paragraph of > Section 2.2 of draft-gont-tcpm-urgent-data-01 ! ) > and finally codified in RFC 1122, seems to be that the > terminology and the processing rules were partially contradictory > from the beginning -- and that apparently was caused by historical > circumstances and pressure exerted on the "TCP committee" over a > long time span in these old days. My take is that the "corrections" would not have interoperated with the deployed code, and that even then, there was no ROI in e.g. changing the semantics of the urgent pointer. > Therefore, returning to the picture painted above, the *first* > step should be to formulate strong recommendations for how > applications and in particular implementations of applications > should make use of TCP Urgent Processing (if any). > This IMO should be based on the concepts explained in the two > definitions from RFC 793 quoted above. [....] > Since decades, Telnet makes use of URG, and apparently this > all works (almost) properly, independent of the underlying > TCP stacks' behavior at the sending and receiving side. Well, the "underlying TCP stacks' behavior" is homogeneous -- everyone implements the same non-compliant behavior. > (BTW: the discussion in RFC 1123 seems also to be disturbed.) > The reason seems to be simple: being defensive, and not > assigning semantics to the data delivered with the sending > side's urgent call. > According to RFC 854, the Telnet client sends a DM NVT control > character which is a transparent NOP for the Telnet server. > Thus, it does not matter for the Telnet server how the TCP > stack interprets the Urgent pointer. It should matter. If a system sends data with the deployed semantics for the UP (i.e., it points to the byte following the last byte of urgent data), but the receiver implements the compliant (RFC 1122) behavior (i.e., points to the last byte of urgent data), then one control byte (after DM NVT) will be skipped. OTOH, if a system sends data with the IETF-compliant (RFC1122) semantics, and the receiver implements the deployed semantics, the "urgent byte" will not be skipped (this would be safe for telnet, as you point out). > (1) Give recommendations for application protocol designers > and application programmers of how to best use the common > Sockets API for Urgent Processing, in order to accommodate the > legacy problems and the inconsistencies in the specifications. > > This should target BCP status, and it should have a tight > milestone of not more than 6 months for passing to the IESG. > > Most elements of such document already are in > draft-gont-tspm-urgent-data-01 ; > my personal expectations for the basic recommendations are: > > o MUST always use OOBINLINE; Agreed. > o SHOULD only send a single octet in the urgent call; This would contradict RFC 793 and RFC 1122 (?) > o SHOULD use syntactically transparent data in the urgent call > (equivalent to DM == NOP in Telnet); But... what about the deployed sender to RFC112-compliant receiver case sketched above? Or are you also thinking about updating the semantics of the UP so that they reflect the deployed code? > o intermediate systems MUST NOT scrub the TCP URG flag > (URG is an entirely end-to-end indication); Agreed. But... they have been deployed. And Cisco PIX is widely deployed, and does scrub the URG bit! > o a hint that a parallel TCP connection ('control channel') > SHOULD be used if an application needs true OOB data transfer. Agreed. > Based on the captured intent of the original specifications, > therefore, a unique definition for "Urgent Data" should be found. > In RFC 793, three possible candidate definitions are sublimely used: > > a) the data 'temporally' ahead of the Urgent Pointer, Did you mean "behind"? > i.e. the all the buffered data that are being invalidated > by the 'urgent' call (TCP 'SEND' call in the abstract TCP > 'User Interface' of RFC 793, section 3.8, pp. 46/47, with > URGENT flag set); > > b) the data sent with the 'urgent' call; > > c) the union of both a) and b). Well, ironically, what's "urgent" is the first non-urgent data! :-) i.e., with "urgent data" being whatever you read while being in "urgent mode", you basically want to skip those data, such that you can quickly get to the first non-urgent data (i.e., get out of urgent mode). > Note #3: The ambiguity in RFC 793 mostly stems from that it remains > underspecified whether the urgent pointer refers to the state of > the sequence number at entry to the event processing or at its > end, i.e. whether (on pg. 56) "SND.UP <- SND.NXT - 1" should > happen before of after processing the data handed over in the > SEND with URGENT flag set. It should happen *after*. Remember that a TCP is allowed to send sequences of urgent data of any length. (yeah, I hate to use the term "urgent data"... but you know what I mean). > Note #4: There is more trouble in RFC 793 related to Urgent mode; > in particular, the event processing rules deal with URGENT flag > for the OPEN call whereas the OPEN Interface definition does not > contain such flag at all. Good grief! > Thus, the second delivery of the TCP URG work item should be: > > (2) A Normative (Standards Track) document clarifying the > definition of the term "Urgent Data" for TCP and Updating > primarily RFC 793 and RFC 1122, but for consistency also > RFC 854 and RFC 1123, to make them conformant to the > clarified definition and provide consistent and self- > consistent processing rules. What, specifically, would this I-D update? > I'd offer to work as a co-editor with Fernando Gont for a TCPM > work item shaped along the ideas and guidelines presented above, > but more volunteers to help with completing the investigations > of the TCP-related IEN documents would be heartfully welcome, > in order to give the whole effort the best possible foundation > to be in the spirit of the original designers of TCP. So you argue that tcpm should adopt draft-gont-tcpm-urgent-data, and use that I-D as a basis for the BCP document, and also work on another (std track) I-D that we'd both co-author? BTW, is there a need to actually dig at the IENs, etc.? I'm not saying it wouldn't be worth the effort, but... I' not sure it would be actually "required"/needed to clarify TCP's urgent mode, etc. Thanks! Kind 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 touch@ISI.EDU Sun Mar 22 12:44:40 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA163A6BDD for ; Sun, 22 Mar 2009 12:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XafpCQLKa0WG for ; Sun, 22 Mar 2009 12:44:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 587EA3A68EC for ; Sun, 22 Mar 2009 12:44:38 -0700 (PDT) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n2MJiRW3027494; Sun, 22 Mar 2009 12:44:29 -0700 (PDT) Message-ID: <49C55B0E.5020000@isi.edu> Date: Sat, 21 Mar 2009 14:24:30 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eric Rescorla References: <20090320013644.2E62350822@romeo.rtfm.com> In-Reply-To: <20090320013644.2E62350822@romeo.rtfm.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-04 [This time for sure] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 19:44:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric, Some questions below. Overall, the specific issues you raise can be addressed. The chairs can address the need for a rewrite. Eric Rescorla wrote: ... > The most serious problem is the confusion in the text between > three concepts: > > - Master Keys > - Key-Ids > - Traffic keys We can clean up specific cases you can point us to, however the primary components are: master key tuples which are uniquely specified by a TCP socket pair together with a KeyID; a keyID alone is insufficient traffic keys which are derived from master key tuples and instantiated connection information (i.e., from the TCP TCB) The text needs a few more passes and a few more eyes to catch the ripples of the last revision. > As an example, S 8.1 reads: > > At any given time, a single TCP connection may have multiple KeyIDs > specified for each segment direction (incoming, outgoing). TCP-AO > provides a mechanism to indicate when a new KeyID is ready, to allow > > It's not that you have multiple key-ids. In each direction, there can be more than one KeyID inside the TCP segment header - at least that's what the ext is supposed to say. > Indeed, if we're using > keys with different outgoing and incoming key-ids, you will *always* > have multiple key-ids. Rather, it's that you have multiple > master keys. Multiple keyIDs within a single connection means multiple master key tuples; the text can indicate that as well. That doesn't mean we don't have multiple keyIDs, though. > The basic unit of operation here is not the key-id but rather > the master key, which comprises the following values (at least): > > - master_key > - send key_id > - receive key_id > - MAC algorithm The basic unit is the master key tuple, as per section 5: master key - i.e., the key string keyID MAC algorhtm Whenever the keyID appears in a segment (sent or received), that tuple is used to validate the contents. As per the most recent coordination, keyIDs are bidirectional, so there is no send or receive difference. > If you want to invent a new concept (e.g., security association) > that holds all of these, that's fine I suppose. However, it's really > confusing to use key-id here. I suspect this is a holdover from > previous text. > > In any case, I think the document would benefit from some explanatory > text along the lines of the above. Sure; see above, and let me know if that covers it. > The second clarity point is the relationship between master keys and > traffic keys is. I would think a diagram like the following might > be in order: > > > > > Master_Key_A Master_Key_B > - Send_Key_Id = 1 - Send_Key_Id = 5 > - Recv_Key_Id = 2 - Recv_Key_Id = 6 > - Algorithm = HMAC-SHA1 - Algorithm = AES-CMAC > | | > | | > +----------------+-----------------+ | > | | | > v v v > Connection 1 Connection 2 Connection 3 > - Send_SYN_key - Send_SYN_key - Send_SYN_key > - Recv_SYN_key - Recv_SYN_key - Recv_SYN_key > - Send_Other_key - Send_Other_key - Send_Other_key > - Send_Other_key - Send_Other_key - Send_Other_key I like that diagram; here's an update as follows: - -- only one KeyID (bidirectional) - -- changes name of top set to 'master_tuple' (as per Section 5) - -- adds the master key, which is the shared secret Master_tuple_A Master_tuple_B keyID 34 keyID 22 master_string = ABCDEF master_string = 123456 Algorithm = HMAC-SHA1 Algorithm = AES-CMACNow | | | | +------------------------+ | | | | v v v Connection 1 Connection 2 Connection 3 - - Send_SYN_key - Send_SYN_key - Send_SYN_key - - Recv_SYN_key - Recv_SYN_key - Recv_SYN_key - - Send_Other_key - Send_Other_key - Send_Other_key - - Recv_Other_key - Recv_Other_key - Recv_Other_key > I realize this is imperfect since you could have two master keys, but > it's the best I can do right now. The diagram you show is only how connection keys are derived from master tuples and connection info. Each connection has per-connection parameters as described in section 6: current-key next-key send-ESN recv-ESN [one or more master-tuples] I.e., it is in the per-connection parameters that multiple master key tuples are indicated. > As I've indicated previously, I find the TSAD/TAPD concept incredibly > unhelpful. There may well be implementations for which it is natural, > but I don't consider it the natural one, and making it in effect a > mandatory feature of the protocol seems like an undue burden on > implementors. I appreciate that this has been in the document since > day one, but if you go back to my review of -00 a year ago, I raised > exactly the same concern and we have never taken the discussion to > closure or had a consensus call, so I don't consider this in any > respect a settled issue. If there are those who feel it's important to > keep this design, I would ask the chairs to make this topic an > explicit agenda item and I would like agenda time to present an > alternative design. I've explained this in detail to Gregory, but I'm not sure if all of our discussion ended up in the text. Here's my recollection of that: Regardless of what happens outside TCP, when a new connection starts (initiating or responding), TCP needs to know whether TCP-AO is required or not. We need some way to describe policy for uninstantiated connections, and a way to tie that policy to keying material. That's what the TAPD is, and why it was thus renamed. I'll let the chairs address your concerns about a consensus call. > DETAILED COMMENTS > S 5. > 2. A TCP option flag. When 0, this flag allows default operation, > i.e., TCP options are included in the MAC calculation, with TCP- > AO's MAC field zeroed out. When 1, all options (excluding TCP-AO) > are excluded from all MAC calculations (skipped over, not simply > zeroed). The option flag applies to TCP options in both directions > (incoming and outgoing segments). > > This text has two problems. First, the whole concept of a default is > meaningless here (I believe we agreed on this in e-mail, but I'm > adding the comment to make sure). Second, since this flag has no > wire encoding, it doesn't make any sense to discuss what 0 and 1 > mean. We agreed; I missed it in the edits. > >> The set of TAPD master key tuples MAY change during a > connection, but KeyIDs of those tuples MUST NOT overlap. I.e., > tuple parameter changes MUST be accompanied by master key changes. > > I think this is a little problematic because of concreteness about > "master key". If I'm using master key "ABC" and I decide to change > the MAC algorithm, I can still use "ABC". This is an argument for > a higher level "security association" type construct, I suppose. I need to scrub "master key" and correct it to refer to the master key tuple in most places. > >> A TAPD implementation MUST support at least two KeyIDs per > connection per direction, and MAY support up to 256. > > This is another example of confusion between master keys and key-ids. > It's two master keys you need to be able to support. It's two master key tuples we need to support; will fix. > >> When a TAPD entry matches a new connection, TCP-AO is required. > This is true regardless of whether there are any master key tuples > present. > > Even if we accept the TAPD construct, this is too much requirement > on the implementation. Why can't I have a TPAD entry that means > "don't do AO". That's what the text implies. I.e., a TAPD entry without any master key tuples is equivalent to one that says "don't do AO". it doesn't make sense to have master key tuples and say "don't do AO" at the same time. I can clarify this if useful, but I thought it was clear enough as-is. Can others comment? > For a particular endpoint (i.e., IP address) there would be exactly > one TAPD that is consulted by all pending connections, the same way > that there is only one table of TCBs (a database can support multiple > endpoints, but an endpoint is represented in only one database). > Multiple databases could be used to support virtual hosts, i.e., > groups of interfaces. > > Again, TMI. This is one implementation, but there are sensible > implementations with multiple TAPDs. How ever many TAPDs an implementation has, they must act as if they were a single TAPD. Otherwise, I could have this: TAPD 1 TAPD 2 SRCIP=*,DSTIP=10.0.0.1 SRCIP=192.168.1.1,DSTIP=* -> MKT ID=23 -> MKT ID=54 Which one wins? > NOTE: an open issue is whether to require actions when master keys > are added to the TAPD. In particular, there is a suggestion to force > new added keys to update current_key to the newly added value, and to > set a timer or flag on previous current_key values. If a timer, the > value is unclear (2*MSL isn't appropriate, because we don't know how > long a key changeover may take, and we're not reacting to messages > from the other side). If a flag, this would require that flagged > entries could never be advertised as NextKeyID. > > > This is pretty unclear, but I don't think it's what people are recommending. > Rahter that once a key is displaced, it should time out. There were three different suggestions: 1) when a key is displaced, a timeout is used to prevent a user from inadvertently removing it from the TAPD and thus losing reordered segments FWIW, that's in there already without a note because there was [some] consensus on the call 2) when a key is displaced, it cannot be reactivated i.e., if the timer is ever set, never switch back this is possibly problematic because reordering can cause key lockout 3) MKT are always preferred when they are added to the TAPD i.e., when adding MKT, update nextID for all active connections this is possibly problematic because it requires both sides to enter keys in the same order; it is equivalent to the following explicit user-level actions: - add MKT - update all active connections to use that MKT as nextID > S 6. > 1. Current_key - the KeyID of the master key tuple currently used to > authenticate outgoing segments, inserted in outgoing segments as > > It's not the KeyID that should be stored but rather the master key tuple. Agreed - it's a pointer to the MKT. > 3. A pair of Extended Sequence Numbers (ESNs). ESNs are used to > prevent replay attacks, as described in Section 8.2. Each ESN is > initialized to zero upon connection establishment. Its use in the > MAC calculation is described in Section 7.1. > > The term "extended sequence number" is confusing here. The entire > 64-bit quantity is an ESN. If anything, this is a sequence number > extension (SNE). They're sequence number extension numbers, or sequence extension numbers), i.e., SNENs or SENs, more specifically. I prefer SEN. (though we could posit the remaining permutations, e.g.: ENS, NES and NSE ;-) > Master key tuples are used, together with other parameters of a > connection, to create traffic keys unique to each connection, as > described in Section 7.2. These traffic keys can be cached after > computation, and are typically stored in the TCB with the > corresponding master key tuple information. They can be considered > part of the per-connection parameters. > > Typically? We don't have enough implementations to talk about typical. Will fix. they *can* be stored... > S7.1. > o MAC_truncation - the number of bytes to truncate the output of the > MAC to. This is indicated by the MAC algorithm, as specified in > [ao-crypto]. > > I don't think it makes sense to talk about truncation here. > The MACs produce a value that is crammed into the packet. > If there's a separate spec that describes the MACs, it's not > AO's business whether those MACs were produced by a truncation process. That's missing from the companion doc, then. TCP-AO should then assume that the MAC comes out at whatever length it comes out. > o MAC - the fixed-length output of the MAC algorithm, given the > parameters provided. If the MAC_alg output is smaller than the > desired MAC_truncation, it is padded with trailing zeroes as > needed. > > This padding seems extraordinarily unsafe. If this ever happens, > something has gone badly wrong. Given the update just above, this can be removed. > >> To allow a TCP-AO implementation to compute any implicit MAC > algorithm padding required, the specification for each algorithm used > with TCP-AO MUST specify the padding modulus for the algorithm, if > one is required. > > S 7.2. > I don't even know what a padding modulus is, but every MAC I know of > does it's own padding. That goes away too. > MAC algorithm indicates how to use the traffic key, e.g., as HMACs do > in general [RFC2104][RFC2403]. The traffic key is derived from the > > s/in general//. Will do. > ensures that connection keys generated for each direction are unique. > s/connection keys/traffic keys/ Will do. > o Send_SYN_traffic_key - the traffic key used to authenticate > outgoing SYNs. The source ISN known (the TCP connection's local > ISN), and the destination (remote) ISN is unknown (and so the > value 0 is used). > > o Receive_SYN_traffic_key - the traffic key used to authenticate > incoming SYNs. The source ISN known (the TCP connection's remote > ISN), and the destination (remote) ISN is unknown (and so the > value 0 is used). > > You should probably mention that in most cases (except for simultaneous > opens) only one of these is needed per side. We define them, and mention that they can be cached, but there's clearly no utility in either one after the TWHS is complete anyway. I don't see a reason to get into details on whether both of these are used or not. > S 7.3. > Much of the text here is now overtaken by events. I disagree. We still need to say we assume external mechanisms (manual or automatic) negotiate the master key tuples. We can coordinate key changover (as per section 8.1), but somebody needs to decide when to insert the new keys on both ends or no change will ever occur. We aren't robust to master key (string) mistypes - even after a connection starts, and this needs to be noted. > S 8.1. > At any given time, a single TCP connection may have multiple KeyIDs > specified for each segment direction (incoming, outgoing). TCP-AO > provides a mechanism to indicate when a new KeyID is ready, to allow > > See above for my comments on this. Will fix. > the sender to commence use of that new KeyID. This supported by using > two key ID fields in the header: > > o KeyID > > o NextKeyID > > It's probably worth mentioning that these may (often will) be the same. > A diagram here seems like it might be useful. Will do. > S 9.2. > >> A TAPD entry MAY underspecify the TCP connection for the LISTEN > state. Such an entry MUST NOT be used for more than one connection > progressing out of the LISTEN state. > > I don't see why this is a problem with the current system. On the > contrary, it would be quite attractive to simply set the listening > socket with a single master key. That is an artifact from before we had master tuples and unique traffic keys, and should have been removed. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknFWw4ACgkQE5f5cImnZrummQCg1TQWGR3m2lYjl+14Wu0zP5z+ xOwAoKLG1Z8UclxDTOVb3i4M1YTbU3tQ =S0cJ -----END PGP SIGNATURE----- From A.Hoenes@tr-sys.de Sun Mar 22 14:07:11 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321C03A6C1D for ; Sun, 22 Mar 2009 14:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.23 X-Spam-Level: ** X-Spam-Status: No, score=2.23 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qkmm7E1ZRhav for ; Sun, 22 Mar 2009 14:07:09 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id CC5AC3A6AB7 for ; Sun, 22 Mar 2009 14:07:07 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA053675957; Sun, 22 Mar 2009 22:05:57 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA03649 for tcpm@ietf.org; Sun, 22 Mar 2009 22:05:56 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200903222105.WAA03649@TR-Sys.de> To: tcpm@ietf.org Date: Sun, 22 Mar 2009 22:05:56 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] On TCP Urgent processing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 21:07:11 -0000 Fernando, thanks for your response. I assume that engaging in this discussion is more important now than consolidating the reference material I promised to present, so please see my elaborations in-line below. > Alfred HÎnes wrote: > >> The utmost first step for any follow-on draft must be to replace >> "Urgent Data" by "Urgent Processing" or "Urgent Mode" in the >> document title and similarly in the draft name. See below! > > Well, this one shouldn't be a problem. I can live with it. :-) > > >> The basic reason of why implementations did not follow >> the 'corrections' to RFC 793 first published in RFC 924 >> ( not: RFC 961, as indicated in the last paragraph of >> Section 2.2 of draft-gont-tcpm-urgent-data-01 ! ) >> and finally codified in RFC 1122, seems to be that the >> terminology and the processing rules were partially contradictory >> from the beginning -- and that apparently was caused by historical >> circumstances and pressure exerted on the "TCP committee" over a >> long time span in these old days. > > My take is that the "corrections" would not have interoperated > with the deployed code, and that even then, there was no ROI > in e.g. changing the semantics of the urgent pointer. > > >> Therefore, returning to the picture painted above, the *first* >> step should be to formulate strong recommendations for how >> applications and in particular implementations of applications >> should make use of TCP Urgent Processing (if any). >> This IMO should be based on the concepts explained in the two >> definitions from RFC 793 quoted above. > [....] >> Since decades, Telnet makes use of URG, and apparently this >> all works (almost) properly, independent of the underlying >> TCP stacks' behavior at the sending and receiving side. > > Well, the "underlying TCP stacks' behavior" is homogeneous -- everyone > implements the same non-compliant behavior. > > > >> (BTW: the discussion in RFC 1123 seems also to be disturbed.) >> The reason seems to be simple: being defensive, and not >> assigning semantics to the data delivered with the sending >> side's urgent call. >> According to RFC 854, the Telnet client sends a DM NVT control >> character which is a transparent NOP for the Telnet server. >> Thus, it does not matter for the Telnet server how the TCP >> stack interprets the Urgent pointer. > > It should matter. If a system sends data with the deployed semantics for > the UP (i.e., it points to the byte following the last byte of urgent > data), but the receiver implements the compliant (RFC 1122) behavior > (i.e., points to the last byte of urgent data), then one control byte > (after DM NVT) will be skipped. > > OTOH, if a system sends data with the IETF-compliant (RFC1122) > semantics, and the receiver implements the deployed semantics, the > "urgent byte" will not be skipped (this would be safe for telnet, > as you point out). Appparently, we all here also suffer from the ambiguity of the term "urgent data". It looks like RFC 1122 calls "urgent data" what RFC 793 tells "the data octet associated with the URGENT [SEND] call", whereas RFC 793 associates the term "urgent data" with the data declared obsolete and hence (cumulatively) to be skipped over in urgent mode, i.e. the data already in the transmisison pipeline when such URGENT SEND call is made. "A sequence of urgent data of any length" in RFC 1123 does not refer to an URGENT SEND with more than 1 data octet, but to the case of multiple URGENT calls that cumulatively add to the urgent data (in the sense of RFC 793). RFC 793 talks about "_the_ octet" in the URGENT call. RFC 793 explains the URGENT flag for the SEND call as the means to send an "urgent indication", and on page 42, it says: To send an urgent indication, the user must also send at least one data octet. Indeed, one might argue that the whole problem stems from the fact that TCP did not assign the urgent indication, i.e. the cutting point separating the data to be processed in urgent mode (skipped over, ignored) from the data where normal mode resumes. Since the TCP SN is attached to octets in the data stream and not to the 'separation line' between two octets, the URGENT call needs to send data -- otherwise the sending TCP would not have an opportunity to transport the urgent indication to the receiver. >> (1) Give recommendations for application protocol designers >> and application programmers of how to best use the common >> Sockets API for Urgent Processing, in order to accommodate the >> legacy problems and the inconsistencies in the specifications. >> >> This should target BCP status, and it should have a tight >> milestone of not more than 6 months for passing to the IESG. >> >> Most elements of such document already are in >> draft-gont-tspm-urgent-data-01 ; >> my personal expectations for the basic recommendations are: >> >> o MUST always use OOBINLINE; > > Agreed. > > >> o SHOULD only send a single octet in the urgent call; > > This would contradict RFC 793 and RFC 1122 (?) No, not strictly. :-) When the URGENT SEND is issued with one octet of data and with PUSH, the sending TCP would have to send a segment with one octet that the receiver should deliver to the application in normal mode. We provisionally agree that RFC 793 on page 56 intends to perform SND.UP <- SND.NXT-1 _after_ processing this octet, the UP would point to this single octet, thus designating all previous data as urgent (definition of URG on pg. 84: "... urgent processing as long as there is data to be consumed with sequence numbers less than the value indicated in the urgent pointer"). RFC 1122 -- under the influence of the many implementers that erroneously assumed OOB data in TCP and re-interpreted the (normal mode!) data sent in the URGENT call as "Urgent Data" -- now talks about "a sequence of urgent data" for the case a user hits "Interrupt" multiple times, but AFAICS still assumes as in RFC 793 a single octet sent in each URGENT call, and replaces the definition of URG in RFC 793 with the apparent re-definition, "the urgent pointer points to the sequence number of the LAST octet in a sequence of urgent data." But this is exactly what RFC 793 had specified, yet using another definition of "urgent data". That use of the same term with different meaning was, and still is, the basic reason for the trouble we see. Hence, as long as each URGENT SEND call carries exactly one octet of data, RFC 1123 and (most parts of) RFC 793 state exactly the same rules, but with effectively different terms. The ambiguity only arises when an URGENT SEND carries more than one octet of data and this octet string is considered the "urgent data", contrary to the basic intent of RFC 793. >> o SHOULD use syntactically transparent data in the urgent call >> (equivalent to DM == NOP in Telnet); > > But... what about the deployed sender to RFC112-compliant receiver > case sketched above? Or are you also thinking about updating the > semantics of the UP so that they reflect the deployed code? I do not think that we should update the semantics of the UP. IMO, we should take the definition of URG on page 84 of RFC 793 as the "constitutional law". The real need to change is fixing one single definition of "urgent data", if we want to remain stick with that fuzzy term. Once this is done, it will become clear without any controversy which parts of the various RFCs need to be updated to make use of that single definition, and change the wording where necessary. My personal preference (but once more: I will not insist on it) would be to avoid that legacy term already meaning different things in the brains of folks, as far as possible; each use of it incurs the risk to again raise the erroneous expectation of something like "OOB data" in TCP. One possibility would be to denote the data with SN < UP as the "OBE data" ("outdated by events") (as soon as an urgent signal has been sent out), and denote "the octet associated with the URGENT call" (RFC 793) as the "restart of Normal Mode data". >> o intermediate systems MUST NOT scrub the TCP URG flag >> (URG is an entirely end-to-end indication); > > Agreed. But... they have been deployed. And Cisco PIX is widely > deployed, and does scrub the URG bit! There should be a clear position that this behavior is in violation of the TCP standard. Further, it breaks all integrity protection security protocols. Only real B2BUAs (Proxies, NAT ALGs, etc.) that are able to share security associations with both ends of the TCP connection they effectively operate on as a man-in-the-middle, are allowed to interfere with a fully end-to-end protocol like TCP. >> o a hint that a parallel TCP connection ('control channel') >> SHOULD be used if an application needs true OOB data transfer. > > Agreed. > > > >> Based on the captured intent of the original specifications, >> therefore, a unique definition for "Urgent Data" should be found. >> In RFC 793, three possible candidate definitions are sublimely used: >> >> a) the data 'temporally' ahead of the Urgent Pointer, > > Did you mean "behind"? Hmmm. Why? With 'temporally ahead' I mean the data sent earlier (with smaller UTC values) and still in the pipeline (send buffer, network, and unread receive buffers), when an URGENT call is made (and thus having a numerically smaller SN), and which thus shall be skipped over by the TCP receiver in urgent mode, per RFC 793. The urgent pointer terminates the data to be processed in urgent mode. RFC 793 defines "... urgent processing ... [for] data ... with sequence numbers less than the value indicated in the urgent pointer." >> i.e. the all the buffered data that are being invalidated >> by the 'urgent' call (TCP 'SEND' call in the abstract TCP >> 'User Interface' of RFC 793, section 3.8, pp. 46/47, with >> URGENT flag set); >> >> b) the data sent with the 'urgent' call; >> >> c) the union of both a) and b). > > Well, ironically, what's "urgent" is the first non-urgent data! :-) Hmm -- that kind of reasoning is stuck with the OOB data paradigm! The TCP design does not have such data; TCP carries an indication to enter urgent processing, i.e. to skip over and ignore some data; since there's only a single data stream, *skipping* is urgent! > i.e., with "urgent data" being whatever you read while being in "urgent > mode", you basically want to skip those data, such that you can quickly > get to the first non-urgent data (i.e., get out of urgent mode). Exactly! >> Note #3: The ambiguity in RFC 793 mostly stems from that it remains >> underspecified whether the urgent pointer refers to the state of >> the sequence number at entry to the event processing or at its >> end, i.e. whether (on pg. 56) "SND.UP <- SND.NXT - 1" should >> happen before of after processing the data handed over in the >> SEND with URGENT flag set. > > It should happen *after*. Remember that a TCP is allowed to send > sequences of urgent data of any length. (yeah, I hate to use the term > "urgent data"... but you know what I mean). Sigh, no, some parts of your draft have confused me even more, by using that term in different meanings as well! So, the more I consider the topic, the more my desire increases to indeed get entirely rid of that term. Otherwise, notwithstanding a clear definition, people will come back again and again and associate it with OOB data. > [...] > >> Thus, the second delivery of the TCP URG work item should be: >> >> (2) A Normative (Standards Track) document clarifying the >> definition of the term "Urgent Data" for TCP and Updating >> primarily RFC 793 and RFC 1122, but for consistency also >> RFC 854 and RFC 1123, to make them conformant to the >> clarified definition and provide consistent and self- >> consistent processing rules. > > What, specifically, would this I-D update? That depends on the definition(s) the WG comes to consensus to use. I have shed some light on how I would tackle the issue, but I will support any reasonable way to achieve full consistency in the definitions and their use in the (updated) specs, as long as it remains clear that we do _not_ change the original TCP philosophy and try to introduce actual OOB data. >> I'd offer to work as a co-editor with Fernando Gont for a TCPM >> work item shaped along the ideas and guidelines presented above, >> but more volunteers to help with completing the investigations >> of the TCP-related IEN documents would be heartfully welcome, >> in order to give the whole effort the best possible foundation >> to be in the spirit of the original designers of TCP. > > So you argue that tcpm should adopt draft-gont-tcpm-urgent-data, > and use that I-D as a basis for the BCP document, and also work > on another (std track) I-D that we'd both co-author? Some parts of the current draft might go into the second document. To reduce the risk of controversies and lenghty debates, IMO the BCP ideally should not talk about internal details of the TCP stack at all. Of course, the BCP preferably should not use terminology not unambiguously defined. > BTW, is there a need to actually dig at the IENs, etc.? I'm not saying > it wouldn't be worth the effort, but... I' not sure it would be actually > "required"/needed to clarify TCP's urgent mode, etc. If there is a sound support in the WG to base the work on the definitions in the Glossary of RFC 793 without further confirmation of the original rationale applied in the development of TCP, I'll be fine with skipping that tiresome work! However, I am well aware of a strong position in the WG to not change the original intent of the TCP specs in any way; and thus, proofing more evidence that the intended work is strictly in line with that philosophy might help to speed up the process, and to gain strong consensus on it. > Thanks! > > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From ekr@rtfm.com Mon Mar 23 04:43:07 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4593A6AD3 for ; Mon, 23 Mar 2009 04:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7aQjiBPOLFh for ; Mon, 23 Mar 2009 04:43:06 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 311473A6807 for ; Mon, 23 Mar 2009 04:43:06 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so3249550ywh.49 for ; Mon, 23 Mar 2009 04:43:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.85.1 with SMTP id m1mr2390833vcl.46.1237808635464; Mon, 23 Mar 2009 04:43:55 -0700 (PDT) Date: Mon, 23 Mar 2009 04:43:55 -0700 Message-ID: From: Eric Rescorla To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-04 [This time for sure] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 11:43:07 -0000 Eric Rescorla wrote: ... > > The most serious problem is the confusion in the text between > > three concepts: > > > > - Master Keys > > - Key-Ids > > - Traffic keys > > We can clean up specific cases you can point us to, however the primary > components are: > > master key tuples > which are uniquely specified by a TCP socket pair > together with a KeyID; a keyID alone is insufficient > > traffic keys > which are derived from master key tuples and > instantiated connection information (i.e., from the > TCP TCB) Fine, but this version of the document repeatedly uses "key-id" as synechdoche for both of these concepts, which is extraordinarily confusing. A key-id is a label that points to another object. > > As an example, S 8.1 reads: > > > > At any given time, a single TCP connection may have multiple KeyIDs > > specified for each segment direction (incoming, outgoing). TCP-AO > > provides a mechanism to indicate when a new KeyID is ready, to allow > > > > It's not that you have multiple key-ids. > > In each direction, there can be more than one KeyID inside the TCP > segment header - at least that's what the ext is supposed to say. OK, well, I don't think that's what it says, and if so it's even more confusing. An endpoint may have up to 256 master key tuples (MKT) specified for each connection. It uses one and advertises up to one more, but it is quite possible it would accept all 256. > > Indeed, if we're using > > keys with different outgoing and incoming key-ids, you will *always* > > have multiple key-ids. Rather, it's that you have multiple > > master keys. > > Multiple keyIDs within a single connection means multiple master key > tuples; the text can indicate that as well. That doesn't mean we don't > have multiple keyIDs, though. Yes, but that's a representational issue, not a conceptual issue. Again, it's a mistake to use "key-id" to stand for MKT. > The basic unit is the master key tuple, as per section 5: > > master key - i.e., the key string > keyID > MAC algorhtm > > Whenever the keyID appears in a segment (sent or received), that tuple > is used to validate the contents. As per the most recent coordination, > keyIDs are bidirectional, so there is no send or receive difference. It was not my understanding that we agreed that key-ids were bidirectional. Rather, I believe we agreed that MKTs were bidirectional and that there was a separate key-id in each direction, to address Russ's concern. > > Master_Key_A Master_Key_B > > - Send_Key_Id = 1 - Send_Key_Id = 5 > > - Recv_Key_Id = 2 - Recv_Key_Id = 6 > > - Algorithm = HMAC-SHA1 - Algorithm = AES-CMAC > > | | > > | | > > +----------------+-----------------+ | > > | | | > > v v v > > Connection 1 Connection 2 Connection 3 > > - Send_SYN_key - Send_SYN_key - Send_SYN_key > > - Recv_SYN_key - Recv_SYN_key - Recv_SYN_key > > - Send_Other_key - Send_Other_key - Send_Other_key > > - Send_Other_key - Send_Other_key - Send_Other_key > > I like that diagram; here's an update as follows: > - -- only one KeyID (bidirectional) As noted above, I think this is not correct. > - -- changes name of top set to 'master_tuple' (as per Section 5) > - -- adds the master key, which is the shared secret Sure. > > As I've indicated previously, I find the TSAD/TAPD concept incredibly > > unhelpful. There may well be implementations for which it is natural, > > but I don't consider it the natural one, and making it in effect a > > mandatory feature of the protocol seems like an undue burden on > > implementors. I appreciate that this has been in the document since > > day one, but if you go back to my review of -00 a year ago, I raised > > exactly the same concern and we have never taken the discussion to > > closure or had a consensus call, so I don't consider this in any > > respect a settled issue. If there are those who feel it's important to > > keep this design, I would ask the chairs to make this topic an > > explicit agenda item and I would like agenda time to present an > > alternative design. > > I've explained this in detail to Gregory, but I'm not sure if all of our > discussion ended up in the text. Here's my recollection of that: > > Regardless of what happens outside TCP, when a new connection starts > (initiating or responding), TCP needs to know whether TCP-AO is required > or not. We need some way to describe policy for uninstantiated > connections, and a way to tie that policy to keying material. That's > what the TAPD is, and why it was thus renamed. This may or may not be true, but it doesn't follow that we need a TAPD. As I indicated in a previous message, an alternative design is to simply attach policy information to an individual *socket* at the time it's instantiated: - Sockets instantiated in LISTEN mode would get a list of potential remote addresses and MKTs (one could think of this as a mini-TAPD if one wanted). - Sockets instantiated with CONNECT would get a list of MKTs. If a packet is received for a connection in neither state it would be assumed that AO did not apply. My point is *not* that this is necessarily a superior implementation, but that it's up to the implementor how to do things and that the TSAD/TAPD concept is over-prescriptive (and confusing). All that is required of the implementation is that it be unambiguous which policy is to be applied. > I'll let the chairs address your concerns about a consensus call. OK. Chairs: I strongly object to this material remaining as-is without live WG discussion. How would you like to handle it? > > >> When a TAPD entry matches a new connection, TCP-AO is required. > > This is true regardless of whether there are any master key tuples > > present. > > > > Even if we accept the TAPD construct, this is too much requirement > > on the implementation. Why can't I have a TPAD entry that means > > "don't do AO". > > That's what the text implies. I.e., a TAPD entry without any master key > tuples is equivalent to one that says "don't do AO". it doesn't make > sense to have master key tuples and say "don't do AO" at the same time. > > I can clarify this if useful, but I thought it was clear enough as-is. > Can others comment? But that is not in fact what the later text says, Rather, 9.5 (ii) says: ii. If there is a TAPD entry with zero master key tuples, silently discard the segment and cease further TCP processing. > > For a particular endpoint (i.e., IP address) there would be exactly > > one TAPD that is consulted by all pending connections, the same way > > that there is only one table of TCBs (a database can support multiple > > endpoints, but an endpoint is represented in only one database). > > Multiple databases could be used to support virtual hosts, i.e., > > groups of interfaces. > > > > Again, TMI. This is one implementation, but there are sensible > > implementations with multiple TAPDs. > > How ever many TAPDs an implementation has, they must act as if they were > a single TAPD. Otherwise, I could have this: > > TAPD 1 TAPD 2 > > SRCIP=*,DSTIP=10.0.0.1 SRCIP=192.168.1.1,DSTIP=* > -> MKT ID=23 -> MKT ID=54 > > Which one wins? I agree that it needs to be unambigous what packet processing needs to be applied. But you're specifying one implementation. -Ekr From touch@ISI.EDU Mon Mar 23 07:37:59 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D67B63A67DD for ; Mon, 23 Mar 2009 07:37:59 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc0XbSyUFz+a for ; Mon, 23 Mar 2009 07:37:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DE2E63A6BBD for ; Mon, 23 Mar 2009 07:37:51 -0700 (PDT) Received: from [75.211.77.114] (114.sub-75-211-77.myvzw.com [75.211.77.114]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n2NEc8LS009906; Mon, 23 Mar 2009 07:38:10 -0700 (PDT) Message-ID: <49C79ECF.2010501@isi.edu> Date: Mon, 23 Mar 2009 07:38:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-04 [This time for sure] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:37:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: > Eric Rescorla wrote: > ... >>> The most serious problem is the confusion in the text between >>> three concepts: >>> >>> - Master Keys >>> - Key-Ids >>> - Traffic keys >> We can clean up specific cases you can point us to, however the primary >> components are: >> >> master key tuples >> which are uniquely specified by a TCP socket pair >> together with a KeyID; a keyID alone is insufficient >> >> traffic keys >> which are derived from master key tuples and >> instantiated connection information (i.e., from the >> TCP TCB) > > Fine, but this version of the document repeatedly uses "key-id" > as synechdoche for both of these concepts, which is extraordinarily > confusing. A key-id is a label that points to another object. Agreed. Let's agree on what to fix (I think we have) and scrub the doc on that point. >>> As an example, S 8.1 reads: >>> >>> At any given time, a single TCP connection may have multiple KeyIDs >>> specified for each segment direction (incoming, outgoing). TCP-AO >>> provides a mechanism to indicate when a new KeyID is ready, to allow >>> >>> It's not that you have multiple key-ids. >> In each direction, there can be more than one KeyID inside the TCP >> segment header - at least that's what the ext is supposed to say. > > OK, well, I don't think that's what it says, and if so it's even > more confusing. An endpoint may have up to 256 master key tuples > (MKT) specified for each connection. It uses one and advertises > up to one more, but it is quite possible it would accept all 256. Will fix. >>> Indeed, if we're using >>> keys with different outgoing and incoming key-ids, you will *always* >>> have multiple key-ids. Rather, it's that you have multiple >>> master keys. >> Multiple keyIDs within a single connection means multiple master key >> tuples; the text can indicate that as well. That doesn't mean we don't >> have multiple keyIDs, though. > > Yes, but that's a representational issue, not a conceptual issue. > Again, it's a mistake to use "key-id" to stand for MKT. Yes. Will fix. >> The basic unit is the master key tuple, as per section 5: >> >> master key - i.e., the key string >> keyID >> MAC algorhtm >> >> Whenever the keyID appears in a segment (sent or received), that tuple >> is used to validate the contents. As per the most recent coordination, >> keyIDs are bidirectional, so there is no send or receive difference. > > It was not my understanding that we agreed that key-ids were bidirectional. > Rather, I believe we agreed that MKTs were bidirectional and that > there was a separate key-id in each direction, to address Russ's > concern. Russ can clarify. First, let's clarify some terms: key-id = a digit in [0..255] that, together with a connection's socket pair (as per RFC793, i.e., srcIP, dstIP, srcport, dstport) indicates a single MKT. key-id field = the value in the TCP-AO option key-id fields are unidirectional - they indicate the key-id used to authenticate that TCP segment key-ids are bidirectional - they indicate (with the socket pair) a MKT that can be used in either direction However, there is no utility in referring to the same MKT with different key-id values for the different directions of a single connection. Russ - can you clarify if that's what you were requesting? ... >> - -- changes name of top set to 'master_tuple' (as per Section 5) >> - -- adds the master key, which is the shared secret > > Sure. > > >>> As I've indicated previously, I find the TSAD/TAPD concept incredibly >>> unhelpful. There may well be implementations for which it is natural, >>> but I don't consider it the natural one, and making it in effect a >>> mandatory feature of the protocol seems like an undue burden on >>> implementors. I appreciate that this has been in the document since >>> day one, but if you go back to my review of -00 a year ago, I raised >>> exactly the same concern and we have never taken the discussion to >>> closure or had a consensus call, so I don't consider this in any >>> respect a settled issue. If there are those who feel it's important to >>> keep this design, I would ask the chairs to make this topic an >>> explicit agenda item and I would like agenda time to present an >>> alternative design. >> I've explained this in detail to Gregory, but I'm not sure if all of our >> discussion ended up in the text. Here's my recollection of that: >> >> Regardless of what happens outside TCP, when a new connection starts >> (initiating or responding), TCP needs to know whether TCP-AO is required >> or not. We need some way to describe policy for uninstantiated >> connections, and a way to tie that policy to keying material. That's >> what the TAPD is, and why it was thus renamed. > > This may or may not be true, but it doesn't follow that we need a > TAPD. As I indicated in a previous message, an alternative design > is to simply attach policy information to an individual *socket* > at the time it's instantiated: > > - Sockets instantiated in LISTEN mode would get a list of potential > remote addresses and MKTs (one could think of this as a mini-TAPD if > one wanted). > - Sockets instantiated with CONNECT would get a list of MKTs. > > If a packet is received for a connection in neither state it would > be assumed that AO did not apply. A system may want to force TCP-AO (or allow non-TCP-AO) on connections it is not yet ready to listen to (e.g., before any communications process starts). > My point is *not* that this is necessarily a superior implementation, > but that it's up to the implementor how to do things and that the > TSAD/TAPD concept is over-prescriptive (and confusing). All that > is required of the implementation is that it be unambiguous which > policy is to be applied. I agree that it's up to the implementer. IMO, it's useful to explain the behavior in terms of a central dbase - any implementation that is equivalent is fine. Do we need to say that more directly? >>> >> When a TAPD entry matches a new connection, TCP-AO is required. >>> This is true regardless of whether there are any master key tuples >>> present. >>> >>> Even if we accept the TAPD construct, this is too much requirement >>> on the implementation. Why can't I have a TPAD entry that means >>> "don't do AO". >> That's what the text implies. I.e., a TAPD entry without any master key >> tuples is equivalent to one that says "don't do AO". it doesn't make >> sense to have master key tuples and say "don't do AO" at the same time. >> >> I can clarify this if useful, but I thought it was clear enough as-is. >> Can others comment? > > But that is not in fact what the later text says, Rather, 9.5 (ii) > says: > > ii. If there is a TAPD entry with zero master key tuples, > silently discard the segment and cease further TCP > processing. Ahhh. Thanks. We need to change the text to allow for two variants: 1) TAPD without a key that MUST be TCP-AO'd (i.e., before a key is available) 2) TAPD to allow non-TCP-AO I can fix the text accordingly. >>> For a particular endpoint (i.e., IP address) there would be exactly >>> one TAPD that is consulted by all pending connections, the same way >>> that there is only one table of TCBs (a database can support multiple >>> endpoints, but an endpoint is represented in only one database). >>> Multiple databases could be used to support virtual hosts, i.e., >>> groups of interfaces. >>> >>> Again, TMI. This is one implementation, but there are sensible >>> implementations with multiple TAPDs. >> How ever many TAPDs an implementation has, they must act as if they were >> a single TAPD. Otherwise, I could have this: >> >> TAPD 1 TAPD 2 >> >> SRCIP=*,DSTIP=10.0.0.1 SRCIP=192.168.1.1,DSTIP=* >> -> MKT ID=23 -> MKT ID=54 >> >> Which one wins? > > I agree that it needs to be unambigous what packet processing > needs to be applied. But you're specifying one implementation. I'm trying to say that an implementation must act like a system with one TSAD (and can say that explicitly). A database is a property of relationships between sets of data (i.e., values and MKTs). Databases can be implemented in various ways, so long as that relationship is preserved. We rely on that relationship for correct operation, though. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknHns8ACgkQE5f5cImnZruKIQCdHi0nUBMsYwdaekjiRcnxZ9YZ 2DkAoOmtBJeDhDj2levO92ts0hxNrBH+ =ozcN -----END PGP SIGNATURE----- From wesley.m.eddy@nasa.gov Mon Mar 23 07:56:15 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA233A6835 for ; Mon, 23 Mar 2009 07:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeaRQGEiyb8h for ; Mon, 23 Mar 2009 07:56:15 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id D4A643A6857 for ; Mon, 23 Mar 2009 07:56:14 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id D6E71A80CD; Mon, 23 Mar 2009 09:57:04 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164] (may be forged)) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n2NEv99k020191; Mon, 23 Mar 2009 09:57:09 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Mon, 23 Mar 2009 09:57:04 -0500 From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" To: Joe Touch , Eric Rescorla Date: Mon, 23 Mar 2009 09:57:03 -0500 Thread-Topic: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-04 [This time for sure] Thread-Index: AcmrxR8VeDUBz+PvRP2NuB8UukhA4gAAd2uA Message-ID: References: <49C79ECF.2010501@isi.edu> In-Reply-To: <49C79ECF.2010501@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-04 [This time for sure] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:56:15 -0000 >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >Behalf Of Joe Touch >Sent: Monday, March 23, 2009 10:38 AM > > ... > >>> >>> Whenever the keyID appears in a segment (sent or received),=20 >that tuple >>> is used to validate the contents. As per the most recent=20 >coordination, >>> keyIDs are bidirectional, so there is no send or receive difference. >>=20 >> It was not my understanding that we agreed that key-ids were=20 >bidirectional. >> Rather, I believe we agreed that MKTs were bidirectional and that >> there was a separate key-id in each direction, to address Russ's >> concern. > >Russ can clarify. First, let's clarify some terms: > >key-id =3D a digit in [0..255] that, together with a connection's socket >pair (as per RFC793, i.e., srcIP, dstIP, srcport, dstport) indicates a >single MKT. > >key-id field =3D the value in the TCP-AO option > >key-id fields are unidirectional - they indicate the key-id used to >authenticate that TCP segment > >key-ids are bidirectional - they indicate (with the socket pair) a MKT >that can be used in either direction > >However, there is no utility in referring to the same MKT with=20 >different >key-id values for the different directions of a single connection. > This set of definitions makes sense to me, and I think it clarifies what we mean by bidirectional versus unidirectional, which was what seemed to be a major point of disconnect in conversation. Eric or Russ, do you agree? --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- = From gregory.ietf@gmail.com Mon Mar 23 10:33:22 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1293A6936 for ; Mon, 23 Mar 2009 10:33:22 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQDyA96SFRHc for ; Mon, 23 Mar 2009 10:33:21 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 0288D3A67C1 for ; Mon, 23 Mar 2009 10:33:20 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so3444436yxm.49 for ; Mon, 23 Mar 2009 10:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=rJSIlwf+5IPl6bIIGCYxyvPo2eNFZB7GfP65OQQarIY=; b=W7+fA82zosQT+Um9BN+VUhmT9YBGGc5OY4mCBHoFngU1HrGo4aVEjtYHaquEpiTSTN f7cnjfy5isolCbaWOZI1d0SM9m+bPOWZNkOpDpuuLHmvfUy7QnNLhEDr3hyD0WESCbcs N3Wbe0TKZzXe7hk7iNeLjd/vfXDjcbZ14FTqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=Om3RChNjDp4MsDaomrOBqB0xN6mV97KoDxdXG6p6kDBlDkODoIvzh8tr5WKOdVxpMJ JNJXNxN3eJhFVFjbbCMxXGn89VZ9qEFl1fM9jXZU+k7b5WIMlO187G4YRJj4wmOrKigY W2SUzzNIUQFDd4B28VFEGbJgiKCiNAQyxsO4g= Received: by 10.143.166.10 with SMTP id t10mr2951730wfo.210.1237829649893; Mon, 23 Mar 2009 10:34:09 -0700 (PDT) Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id 30sm11714761wfa.38.2009.03.23.10.34.07 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Mar 2009 10:34:09 -0700 (PDT) Message-ID: <49c7c811.1e018e0a.6ac9.ffffbfcb@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Mar 2009 10:34:09 -0700 To: Eric Rescorla ,tcpm@ietf.org From: "Gregory M. Lebovitz" In-Reply-To: <20090320003241.E345150822@romeo.rtfm.com> References: <86r60tf31x.wl%ekr@networkresonance.com> <20090320003241.E345150822@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [tcpm] Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:33:22 -0000 Hey all, So far EKR's is the only review I've seen of this draft. And many of you might have missed it, for the wrong subject line he used. So I'm resending my one and only precious review to the list w/ correct subject line. Gregory. At 05:32 PM 3/19/2009, Eric Rescorla wrote: >At Thu, 19 Mar 2009 17:31:06 -0700, >Doh. This review was of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00 > >A review of auth-opt is forthcoming. >-Ekr > > >At Thu, 19 Mar 2009 17:31:06 -0700, >Eric Rescorla wrote: > > > > [Resent from an account that's subscribed.] > > > > -Ekr > > > > $Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00-rev.txt,v 1.1 > 2009/03/19 22:37:19 ekr Exp $ > > > > S 2.1. > > This whole {SHOULD,MUST}{+,-,*,?} thing is a bad idea. It's hard > > enough for developers to understand SHOULD vs. MUST, but now we have 5 > > separate options for implementors to understand and us to argue > > over. I don't remember there being WG consensus on this point. > > > > > > S 2.2. > > The assignment of HMAC-SHA-1 to MUST- and AES-CMAC to SHOULD+ is > > basically unjustified. There's no good reason to believe that > > HMAC-SHA1 will be broken before AES-CMAC. This is exactly the > > confusion fostered by the +/- regime. Make HMAC-SHA1 MUST and > > AES-CMAC SHOULD. > > > > > > S 3. > > You repeat the phrase "Each MAC algorithm MUST..." twice. > > > > > > S 3.1. > > It's confusing to talk about KDFs having an interface and then > > have the function named "PRF". > > > > I would rewrite this as: > > > > All KDFs used in TCP-AO have the following interface: > > > > Derived_Key = KDF(Master_Key, Context, Output_Length) > > > > Where these values are defined as.... [blah blah] > > > > Then: > > The KDFs defined in this document are all based on pseudorandom > > functions (PRFs) which take a key and an input and emit a > > fixed-length pseudorandom value. Given PRF X, the associated > > KDF, KDF_X, is constructed as follows: > > > > KDF_X(Master_Key, Context, Output_Length) = > > X(Master_Key, Input) > > > > Where Input is constructed as:... > > > > Where you say that the master key isn't random, that's not quite > > right. The point is not that it doesn't contain high entropy. > > For instance HEX(X) where X is a 128-bit random number has high > > entropy but may or may not be suitable for use keying a MAC > > function. > > > > This section of the document is pretty confusing about the concept of > > output length. To recap: > > > > 1. The underlying PRFs have fixed sized output lengths, 128 bits in the > > case of AES-CMAC, 160 bits in the case of HMAC-SHA1. > > 2. It is possible to generate an arbitrary number of output bits with > > a given PRF by operating it in a feedback or counter mode. > > The FIPS-whatever KDFs incorporate this feature, hence the > > leading "0". > > 3. Each MAC needs a key of a specific length. > > 4. Not totally uncoincidentally, the KDFs we have chosen to use with > > each MAC happen to generate the right key size for use with the > > MAC, thus avoiding the need for the procedure in (2). > > 5. If you wanted to use these KDFs with a MAC requiring a longer key > > (e.g., HMAC-SHA-256) you would, however need to use the procedure. > > 6. For some reason, the FIPS-whatever KDFs seem to think it's > > a useful idea to mix the desired number of bits produced by the > > KDF into the KDF input. I don't see the point of this, but > > whatever. > > > > You'll note that the PRF does not need to be parametrized in terms > > of output length. It's fixed. > > > > IMO, this could be a lot clearer. > > > > S 3.1.1. > > Is this an ASCII 0 (0x30) or a NUL (0x00) > > > > > > S 3.1.2. > > It's pretty unclear what problem you're trying to solve here. I would > > write: > > > > RFC 4615 is designed to take an arbitrary length key but for any > > key length other than 128 bits, whitens it by first computing an > > AES-CMAC with key 0. Because the keys in use with TCP-AO will > > likely be arbitrary-length ASCII strings, TCP AO always performs > > this whitening step even if the key happens to be 16 bytes long. > > In other words, using the terminology of RFC 4615: > > > > K = AES-CMAC(0^128, MK, MKlen) > > > > > > S 4. > > This UI labels section should be entirely removed. As far as I know, > > there was never WG consensus to include it and it just creates > > extra confusion. In AO, the MAC completely defines the KDF, so > > the concept of suites just adds an extra name. Moreover, since > > MACs have obvious names and the suites have opaque, confusing names, > > this is doubly bad. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From gregory.ietf@gmail.com Mon Mar 23 10:39:16 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA4A3A6A97 for ; Mon, 23 Mar 2009 10:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeQ57JrkRlTq for ; Mon, 23 Mar 2009 10:39:15 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 136FE3A69A2 for ; Mon, 23 Mar 2009 10:39:15 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2842211wfg.31 for ; Mon, 23 Mar 2009 10:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:mime-version:content-type; bh=cDMZiHxl7FyFdpAkn+rMym4hiEmmydjrTmPEDr/3q7c=; b=RXlf7olbeMuiVHme7OPQLL+4hgk4xsLLXuB5hN8Rfmi3WIbm5HuGYAZtiiUrxkMza8 af7ZUe8kcoYuPot8lFwsqByEUczsx358VQBtULfrzPEh7hD22nFAVYMDZgtkhFtH2zuS iV0XmuJbj7CZ7fpXyz2Tujpix12x7ax/M11J4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:mime-version:content-type; b=XnveueMabD/L6j0a+4NdtRPqb9snFmijuJ2ho+y3RDHozqiPCqEdoh88BNdjmUSDZA 21RGkq1eUrdRyx4OnCd21ULXJ7x8XIs66P9m/8TGOINKwGXqIcrd0hCxd3tt0YoZgsnm fuOpc/NKC97c4aHOTjy3UEnZbbwcyd188uBxw= Received: by 10.142.77.11 with SMTP id z11mr2946644wfa.277.1237830005325; Mon, 23 Mar 2009 10:40:05 -0700 (PDT) Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id 29sm11836374wfg.13.2009.03.23.10.40.04 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Mar 2009 10:40:04 -0700 (PDT) Message-ID: <49c7c974.1d078e0a.1586.ffffee09@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Mar 2009 10:40:05 -0700 To: Joe Touch ,tcpm@ietf.org From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_353616859==.ALT" Subject: [tcpm] AO-04: proposed text for describing all the traffic keys X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:39:16 -0000 --=====================_353616859==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I sent this to Joe before -04 was published, but he didn't have time to include it. I send it to list for review. I believe this text makes it quite explicit how many traffic keys for each connection there will be, and how they are contructed. > === BEGIN TEXT ===== > Because the Traffic key is created with conn_block as an input, and part > of Conn_block is the SourceISN and DestinationISN, each peer will > generate multiple direction-specific traffic keys for each TCP > connection in the following format: > > Kx,y^N = F(s, d) > > Where: > a - Alice, the initiator of the TCP connection, > b - Bob, the other end-point in the TCP connection, > Kx,y - Conn_Key of directionality x,y , where x is the segment > source, either a or b, and y is the segment destination, either b or a, > ^N - where N is an integer labeling a unique traffic key for a > specific sender for this connection, > F - abstractly, the funtion of the KDF where the elements within the > parenthesis are changing variables, and all other KDF elements are > understood as held constant, or irrelevant to the description, > (s, d) - where h is the Source ESN and i is the Destination ESN, > > Following this format, the traffic keys generated on Alice and Bob > respectively for a normal, one way open TCP connection will be three each: > > ALICE BOB > ======== ======== > > 1| Ka,b^1 = F(ISNa, 0) -------> Ka,b^1 = F(ISNa, 0) > 2| Kb,a^2 = F(ISNb, ISNa) <------- Kb,a^2 = F(ISNb,ISNa) > 3| Ka,b^3 = F(ISNa, ISNb) -------> Ka,b^3 = F(ISNa, ISNb) > > > In the above, > - line 1 is a SYN from a to b. > - line 2 is a SYN/ACK segment from b to a > - line 3 is an ACK segment from a to b > > Thus, in the simple case, each side creates 3 Traffic keys, ^1, ^2, and ^3. > In the more rare case where there is a simultaneous open [REF??], each > side will generate four traffic keys: > > 1| Ka,b^1 = F(ISNa, 0) -------> Ka,b^1 = F(ISNa, 0) > 2| Kb,a^2 = F(ISNb, 0) <------- Kb,a^2 = F(ISNb, 0) > 3| Kb,a^3 = F(ISNb, ISNa) <------- Kb,a^3 = F(ISNb,ISNa) > 4| Ka,b^4 = F(ISNa, ISNb) -------> Ka,b^4 = F(ISNa, ISNb) > > In the above, > - line 1 is a SYN from a to b. > - line 2 is a possible simultaneous open SYN from b to a > - line 3 is a SYN/ACK segment from b to a > - line 4 is an ACK segment from a to b > === END TEXT ====== Thoughts? Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_353616859==.ALT Content-Type: text/html; charset="us-ascii" I sent this to Joe before -04 was published, but he didn't have time to include it. I send it to list for review. I believe this text makes it quite explicit how many traffic keys for each connection there will be, and how they are contructed.

> === BEGIN TEXT =====
> Because the Traffic key is created with conn_block as an input, and part
> of Conn_block is the SourceISN and DestinationISN, each peer will
> generate multiple direction-specific traffic keys for each TCP
> connection in the following format:
>
>     Kx,y^N = F(s, d)
>
> Where:
>    a - Alice, the initiator of the TCP connection,
>    b - Bob, the other end-point in the TCP connection,
>    Kx,y - Conn_Key of directionality x,y , where x is the segment
> source, either a or b, and y is the segment destination, either b or a,
>    ^N - where N is an integer labeling a unique traffic key for a
> specific sender for this connection,
>    F - abstractly, the funtion of the KDF where the elements within the
> parenthesis are changing variables, and all other KDF elements are
> understood as held constant, or irrelevant to the description,
>   (s, d) - where h is the Source ESN and i is the Destination ESN,
>
> Following this format, the traffic keys generated on Alice and Bob
> respectively for a normal, one way open TCP connection will be three each:
>
>         ALICE                               BOB
>        ========                           ========
>
> 1|  Ka,b^1 = F(ISNa, 0)    ------->  Ka,b^1 = F(ISNa, 0)
> 2|  Kb,a^2 = F(ISNb, ISNa) <-------  Kb,a^2 = F(ISNb,ISNa)
> 3|  Ka,b^3 = F(ISNa, ISNb) ------->  Ka,b^3 = F(ISNa, ISNb)
>
>
> In the above,
>    - line 1 is a SYN from a to b.
>    - line 2 is a SYN/ACK segment from b to a
>    - line 3 is an ACK segment from a to b
>
> Thus, in the simple case, each side creates 3 Traffic keys, ^1, ^2, and ^3.
> In the more rare case where there is a simultaneous open [REF??], each
> side will generate four traffic keys:
>
> 1|  Ka,b^1 = F(ISNa, 0)    ------->  Ka,b^1 = F(ISNa, 0)
> 2|  Kb,a^2 = F(ISNb, 0)    <-------  Kb,a^2 = F(ISNb, 0)
> 3|  Kb,a^3 = F(ISNb, ISNa) <-------  Kb,a^3 = F(ISNb,ISNa)
> 4|  Ka,b^4 = F(ISNa, ISNb) ------->  Ka,b^4 = F(ISNa, ISNb)
>
> In the above,
>    - line 1 is a SYN from a to b.
>    - line 2 is a possible simultaneous open SYN from b to a
>    - line 3 is a SYN/ACK segment from b to a
>    - line 4 is an ACK segment from a to b
> === END TEXT ======

Thoughts?

Gregory.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m --=====================_353616859==.ALT-- From gregory.ietf@gmail.com Mon Mar 23 11:22:00 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A603A6C5F for ; Mon, 23 Mar 2009 11:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+dRBOcF3UE4 for ; Mon, 23 Mar 2009 11:21:59 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 71B5A3A6981 for ; Mon, 23 Mar 2009 11:21:59 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so3471219ywh.49 for ; Mon, 23 Mar 2009 11:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:mime-version:content-type; bh=UNo7ORO8fa2txWHuD666LJSWlqz1u5gwcP9ZC2AH/Aw=; b=N6b9bgfev9HFppZT4OUHfjvXKQ+U10GlFDGk2zzA4KGXibNAqqb4eRXwuFJlpIqFaC zT5Q+VBxY5kPRKuuDOckvLCaS9Cs3ifc/LPxi8RNnD3WMDJmtwVgJUfZf+e8Z+Dz49bC zZpADqHikXiOq8VLdVQF86ccpKEP3nPzFUqJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:mime-version:content-type; b=PwkZMBE+QlN9jrJouVBCCAovauZlKMUFRxREBTAoAPV2amBbMiA6kN9GOuUJdgOMVf c1AzRqyyRGmk6bXG23TFkH1z9i91kN+UZRyQ6C0eZlz7cXLloQ+OUqrYHRJKuKPZrGQ7 psRCYsFCxxMbHP0eHPFIRfNtxOLOfxiRCgNgU= Received: by 10.142.84.11 with SMTP id h11mr2956213wfb.337.1237832568677; Mon, 23 Mar 2009 11:22:48 -0700 (PDT) Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id 22sm11710902wfd.46.2009.03.23.11.22.47 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Mar 2009 11:22:48 -0700 (PDT) Message-ID: <49c7d378.16048e0a.3d85.ffffcfea@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Mar 2009 11:22:43 -0700 To: Joe Touch ,tcpm@ietf.org From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_356183609==.ALT" Subject: [tcpm] AO-04: Text for Key Coordination X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 18:22:01 -0000 --=====================_356183609==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hey all, I sent this text to Joe for -04, but it didn't quite make it. This text may or may not need to be in the spec. Personally, I'd like to see it in an example, or in an appendix, because I think it really makes clear how the coordination occurs in tricky case. I do think the rules need to be included in the main body text. Pls comment: > ============ > For three keys K1, K# and Kx > When only K1 is entered into TCP, set > KeyID = K1 > NextKeyID = KeyID > > send K1,K1 (per KeyID, NextKeyID convention) > > When K# is entered, set > KeyID = K1 > NextKeyID = K# > send K1,K# and continue sending K1,K# until K*,K# is received (where > "*" is wildcard ANY) > > Once receive K*,K# > K1 - start 2MSL timer > set KeyID = K# > AND > SEND K#, K# > -thus, will no longer send with K1, even if receive a segment out of > order with K1,K1 because already know that other side has and can use > K#, and K# has higher preference over K1. > > When Kx is entered > K1 - MSLtimer !=0 > KeyID = K# > NextKeyID = Kx > AND > SEND K#, Kx until K*,Kx is received. > > Once receive K*,Kx > K1 - MSLtimer !=0 > set > K# - start 2MSLtimer > KeyID = Kx > AND > SEND Kx, Kx > > In the below case, we assume K1 was current, then K# and Kx respectively > where entered in quick succession. > > KeyID = K1 > NextKeyID = K# > > if no segments are received from Alice with K# in NextKeyID, then K# > never gets set to KeyID, and as such no segement is ever sent MAC'd > using K#. > > Then Kx is entered into Bob's TCP. Now: > > KeyID = K1 > K# - start 2MSL timer > NextKeyID = Kx > > because > (a) we never made the shift to sending protected with K#, and > (b) K1 is the only known good key for both me and Alice, so far, and > (c) there can only be one NextKeyID, and Kx was the last entered, so > it gets NextKeyID > > In JT's out of order arrival example... > > The following flag settings would exist on Bob: > KeyID = K1 > K# - 2MSLtimer !=0 > NextKeyID = Kx > > For snd = what Alice sends, rcv = what Bob receives, rply = what Bob > sends next (and we drop the "Ks" for ease of notation) > > snd rcv rply > ----- ---- ------- > 1,1 1,1 1,x > 1,# 1,x x,x Bob executes K1 start 2MSLtimer, AND KeyID = Kx, > AND NextKeyID=KeyID > 1,x 1,# x,x > (at this point Alice would start sending x,x) > (even if she didn't for some reason, like she hadn't yet received back > an x,x from Bob due to drops or latency, it would look like: > 1,x 1,x x,x > 1,x 1,x x,x > 1,x 1,x x,x > ... > (until Alice finally received an x,x from Bob, and thus started sending x,x) > x,x x,x x,x > x,x x,x x,x > The rules describing all this are: > > For local values of > KeyID > NextKeyID > SENDING: > IF NextKeyID = KeyID, send KeyID(KeyID), NextKeyID(KeyID) > ELSE send KeyID(KeyID), NextKeyID(NextKeyID) > KEY MOVEMENT: > when you receive a NextKeyID = Ky from peer: > IF for local Ky 2MSLtime != 0, then do nothing > IF local KeyID = Ky, do nothing > IF local NextKeyID = Ky, and NextKeyID != KeyID > THEN, given a current KeyID = Kx, start Kx 2MSLtimer > AND set local KeyID = Ky > AND set local NextKeyID = KeyID > ENTERING KEYS INTO TCP: > When a new key Ky is entered into TCP, for an existing Kx: > IF NextKeyID = KeyID, THEN set NextKeyID = Ky, now KextKeyID = Ky and KeyID = Kx > IF local Kx = NextKeyID != KeyID, THEN set Kx 2MSLtimer, > AND set NextKeyID = Ky > IF Ky 2MSLtimer != 0, THEN set Ky 2MSLtimer = 0, AND NextKeyID = Ky > (This one is for repeated keyID value usage, or correcting a config > mixup.) > or we might want to say: > IF Ky 2MSLtimer !=0, THEN throw error "Ky already in aging state, > cannot install" > Thoughts? Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_356183609==.ALT Content-Type: text/html; charset="us-ascii" Hey all,
I sent this text to Joe for -04, but it didn't quite make it. This text may or may not need to be in the spec. Personally, I'd like to see it in an example, or in an appendix, because I think it really makes clear how the coordination occurs in tricky case. I do think the rules need to be included in the main body text.  Pls comment:

> ============
> For three keys K1, K# and Kx
> When only K1 is entered into TCP, set
>   KeyID = K1
>   NextKeyID = KeyID
>
>  send K1,K1  (per KeyID, NextKeyID convention)
>
> When K# is entered, set
>   KeyID = K1
>   NextKeyID = K#
>  send K1,K# and continue sending K1,K# until K*,K# is received (where
> "*" is wildcard ANY)
>
> Once receive K*,K#
>    K1 - start 2MSL timer
>   set KeyID = K#
> AND
>   SEND K#, K#
>  -thus, will no longer send with K1, even if receive a segment out of
> order with K1,K1 because already know that other side has and can use
> K#, and K# has higher preference over K1.
>
> When Kx is entered
>   K1 - MSLtimer !=0
>   KeyID = K#
>   NextKeyID = Kx
> AND
>   SEND K#, Kx  until K*,Kx is received.
>
> Once receive K*,Kx
>    K1 - MSLtimer !=0
>  set
>    K# - start 2MSLtimer
>    KeyID = Kx
> AND
>    SEND Kx, Kx
>
> In the below case, we assume K1 was current, then K# and Kx respectively
> where entered in quick succession.
>
>   KeyID = K1
>   NextKeyID = K#
>
> if no segments are received from Alice with K# in NextKeyID, then K#
> never gets set to KeyID, and as such no segement is ever sent MAC'd
> using K#.
>
> Then Kx is entered into Bob's TCP. Now:
>
>   KeyID = K1
>   K# - start 2MSL timer
>   NextKeyID = Kx
>
> because
>   (a) we never made the shift to sending protected with K#, and
>   (b) K1 is the only known good key for both me and Alice, so far, and
>   (c) there can only be one NextKeyID, and Kx was the last entered, so
> it gets NextKeyID
>
> In JT's out of order arrival example...
>
> The following flag settings would exist on Bob:
>   KeyID = K1
>   K# - 2MSLtimer !=0
>   NextKeyID = Kx
>
> For snd = what Alice sends, rcv = what Bob receives, rply = what Bob
> sends next (and we drop the "Ks" for ease of notation)
>
> snd  rcv  rply
> -----  ----   -------
> 1,1  1,1   1,x
> 1,#  1,x   x,x  Bob executes K1 start 2MSLtimer, AND KeyID = Kx,
>                      AND NextKeyID=KeyID
> 1,x  1,#   x,x
> (at this point Alice would start sending x,x)
> (even if she didn't for some reason, like she hadn't yet received back
> an x,x from Bob due to drops or latency, it would look like:
> 1,x  1,x   x,x
> 1,x  1,x   x,x
> 1,x  1,x   x,x
> ...
> (until Alice finally received an x,x from Bob, and thus started sending x,x)
> x,x  x,x   x,x
> x,x  x,x   x,x


> The rules describing all this are:
>
> For local values of
>    KeyID
>    NextKeyID

> SENDING:
> IF NextKeyID = KeyID, send KeyID(KeyID), NextKeyID(KeyID)
>   ELSE send KeyID(KeyID), NextKeyID(NextKeyID)

> KEY MOVEMENT:
>  when you receive a NextKeyID = Ky from peer:

>   IF for local Ky 2MSLtime != 0, then do nothing
>   IF local KeyID = Ky, do nothing
>   IF local NextKeyID = Ky, and NextKeyID != KeyID
>      THEN, given a current KeyID = Kx, start Kx 2MSLtimer
>    AND set local KeyID = Ky
>    AND set local NextKeyID = KeyID

> ENTERING KEYS INTO TCP:
>   When a new key Ky is entered into TCP, for an existing Kx:

>   IF NextKeyID = KeyID, THEN set NextKeyID = Ky,
             now KextKeyID = Ky and KeyID = Kx
>   IF local Kx = NextKeyID != KeyID, THEN set Kx 2MSLtimer,
>        AND set NextKeyID = Ky
>   IF Ky 2MSLtimer != 0, THEN set Ky 2MSLtimer = 0, AND NextKeyID = Ky
>      (This one is for repeated keyID value usage, or correcting a config
> mixup.)
>     or we might want to say:
>    IF Ky 2MSLtimer !=0, THEN throw error "Ky already in aging state,
> cannot install"
>

Thoughts?
Gregory.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m --=====================_356183609==.ALT-- From touch@ISI.EDU Mon Mar 23 11:54:06 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9FD3A6981 for ; Mon, 23 Mar 2009 11:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1sMDoP01lQi for ; Mon, 23 Mar 2009 11:54:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9B8A03A68AF for ; Mon, 23 Mar 2009 11:54:05 -0700 (PDT) Received: from [75.210.1.40] (40.sub-75-210-1.myvzw.com [75.210.1.40]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n2NIrjax015341; Mon, 23 Mar 2009 11:53:47 -0700 (PDT) Message-ID: <49C7DAB9.107@isi.edu> Date: Mon, 23 Mar 2009 11:53:45 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <49c7d378.16048e0a.3d85.ffffcfea@mx.google.com> In-Reply-To: <49c7d378.16048e0a.3d85.ffffcfea@mx.google.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] AO-04: Text for Key Coordination X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 18:54:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, The key coordination mechanism described in -04 assumes that MKTs can be used and changed in each direction independently. In specific, it assumes that: sending NextKeyID=N means that the sender is "ready to receive" that the MKT indicated by N i.e., it hopefully causes the other site to start sending with MKT=N The text below tries to extend that to imply that the same signal also means a desire to force both sides to send with MKT=N, i.e., that NextKeyID means "wants to send AND is ready to receive". I.e., it implies that MKTs should be used symmetrically, and that coordination should result in closure to that state. This has several issues: 1) the mechanism is more complex, as described below 2) the mechanism requires resolution when both sides set different NextKeyID values i.e., if both sides change to different nextkeyID's that differ before closure to a new MKT, then it's not clear whether closure will be achieved or to what value. It's not clear why symmetric key *use* should be encouraged or required. I favor the current mechanism for its simplicity and, IMO, sufficiency. Further, I don't see a reason why we would need to require the API to force new keys entered into the TSAD to immediately be favored; a single TSAD entry could apply to multiple active connections, and it's not clear they should all change immediately as a result. I prefer to allow the API to have the user explicitly indicate the next_key for a given active connection (note that next_key isn't meaningful for connections not yet active anyway). Joe Gregory M. Lebovitz wrote: > Hey all, > I sent this text to Joe for -04, but it didn't quite make it. This text > may or may not need to be in the spec. Personally, I'd like to see it in > an example, or in an appendix, because I think it really makes clear how > the coordination occurs in tricky case. I do think the rules need to be > included in the main body text. Pls comment: > > > ============ > > For three keys K1, K# and Kx > > When only K1 is entered into TCP, set > > KeyID = K1 > > NextKeyID = KeyID > > > > send K1,K1 (per KeyID, NextKeyID convention) > > > > When K# is entered, set > > KeyID = K1 > > NextKeyID = K# > > send K1,K# and continue sending K1,K# until K*,K# is received (where > > "*" is wildcard ANY) > > > > Once receive K*,K# > > K1 - start 2MSL timer > > set KeyID = K# > > AND > > SEND K#, K# > > -thus, will no longer send with K1, even if receive a segment out of > > order with K1,K1 because already know that other side has and can use > > K#, and K# has higher preference over K1. > > > > When Kx is entered > > K1 - MSLtimer !=0 > > KeyID = K# > > NextKeyID = Kx > > AND > > SEND K#, Kx until K*,Kx is received. > > > > Once receive K*,Kx > > K1 - MSLtimer !=0 > > set > > K# - start 2MSLtimer > > KeyID = Kx > > AND > > SEND Kx, Kx > > > > In the below case, we assume K1 was current, then K# and Kx > respectively > > where entered in quick succession. > > > > KeyID = K1 > > NextKeyID = K# > > > > if no segments are received from Alice with K# in NextKeyID, then K# > > never gets set to KeyID, and as such no segement is ever sent MAC'd > > using K#. > > > > Then Kx is entered into Bob's TCP. Now: > > > > KeyID = K1 > > K# - start 2MSL timer > > NextKeyID = Kx > > > > because > > (a) we never made the shift to sending protected with K#, and > > (b) K1 is the only known good key for both me and Alice, so far, and > > (c) there can only be one NextKeyID, and Kx was the last entered, so > > it gets NextKeyID > > > > In JT's out of order arrival example... > > > > The following flag settings would exist on Bob: > > KeyID = K1 > > K# - 2MSLtimer !=0 > > NextKeyID = Kx > > > > For snd = what Alice sends, rcv = what Bob receives, rply = what Bob > > sends next (and we drop the "Ks" for ease of notation) > > > > snd rcv rply > > ----- ---- ------- > > 1,1 1,1 1,x > > 1,# 1,x x,x Bob executes K1 start 2MSLtimer, AND KeyID = Kx, > > AND NextKeyID=KeyID > > 1,x 1,# x,x > > (at this point Alice would start sending x,x) > > (even if she didn't for some reason, like she hadn't yet received back > > an x,x from Bob due to drops or latency, it would look like: > > 1,x 1,x x,x > > 1,x 1,x x,x > > 1,x 1,x x,x > > ... > > (until Alice finally received an x,x from Bob, and thus started > sending x,x) > > x,x x,x x,x > > x,x x,x x,x > > > > The rules describing all this are: > > > > For local values of > > KeyID > > NextKeyID > > > SENDING: > > IF NextKeyID = KeyID, send KeyID(KeyID), NextKeyID(KeyID) > > ELSE send KeyID(KeyID), NextKeyID(NextKeyID) > > > KEY MOVEMENT: > > when you receive a NextKeyID = Ky from peer: > > > IF for local Ky 2MSLtime != 0, then do nothing > > IF local KeyID = Ky, do nothing > > IF local NextKeyID = Ky, and NextKeyID != KeyID > > THEN, given a current KeyID = Kx, start Kx 2MSLtimer > > AND set local KeyID = Ky > > AND set local NextKeyID = KeyID > > > ENTERING KEYS INTO TCP: > > When a new key Ky is entered into TCP, for an existing Kx: > > > IF NextKeyID = KeyID, THEN set NextKeyID = Ky, > now KextKeyID = Ky and KeyID = Kx > > IF local Kx = NextKeyID != KeyID, THEN set Kx 2MSLtimer, > > AND set NextKeyID = Ky > > IF Ky 2MSLtimer != 0, THEN set Ky 2MSLtimer = 0, AND NextKeyID = Ky > > (This one is for repeated keyID value usage, or correcting a > config > > mixup.) > > or we might want to say: > > IF Ky 2MSLtimer !=0, THEN throw error "Ky already in aging state, > > cannot install" > > > > Thoughts? > Gregory. > > +++++++++++++++++++++++ > IETF-related email from > Gregory M. Lebovitz > Juniper Networks > g r e go r y d o t i e tf a t g m a i l do t c o m > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknH2rkACgkQE5f5cImnZrv4cgCdGGl76ducLvmgwR8lyXKp0RZS eaAAoLiPUq9nn/h3axscGxn6NaiJ/xOU =pFhi -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Mar 23 11:58:19 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170D63A6B32 for ; Mon, 23 Mar 2009 11:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79ZIzIdpsktM for ; Mon, 23 Mar 2009 11:58:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0CAC73A6B1D for ; Mon, 23 Mar 2009 11:58:18 -0700 (PDT) Received: from [75.210.1.40] (40.sub-75-210-1.myvzw.com [75.210.1.40]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n2NIvmm6016436; Mon, 23 Mar 2009 11:57:50 -0700 (PDT) Message-ID: <49C7DBAB.7080808@isi.edu> Date: Mon, 23 Mar 2009 11:57:47 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <49c7c974.1d078e0a.1586.ffffee09@mx.google.com> In-Reply-To: <49c7c974.1d078e0a.1586.ffffee09@mx.google.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] AO-04: proposed text for describing all the traffic keys X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 18:58:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 See end of section 7.2, which describes the four keys, their derivation, and their use. Joe Gregory M. Lebovitz wrote: > I sent this to Joe before -04 was published, but he didn't have time to > include it. I send it to list for review. I believe this text makes it > quite explicit how many traffic keys for each connection there will be, > and how they are contructed. > > > === BEGIN TEXT ===== > > Because the Traffic key is created with conn_block as an input, > and part > > of Conn_block is the SourceISN and DestinationISN, each peer will > > generate multiple direction-specific traffic keys for each TCP > > connection in the following format: > > > > Kx,y^N = F(s, d) > > > > Where: > > a - Alice, the initiator of the TCP connection, > > b - Bob, the other end-point in the TCP connection, > > Kx,y - Conn_Key of directionality x,y , where x is the segment > > source, either a or b, and y is the segment destination, either b > or a, > > ^N - where N is an integer labeling a unique traffic key for a > > specific sender for this connection, > > F - abstractly, the funtion of the KDF where the elements > within the > > parenthesis are changing variables, and all other KDF elements are > > understood as held constant, or irrelevant to the description, > > (s, d) - where h is the Source ESN and i is the Destination ESN, > > > > Following this format, the traffic keys generated on Alice and Bob > > respectively for a normal, one way open TCP connection will be > three each: > > > > ALICE BOB > > ======== ======== > > > > 1| Ka,b^1 = F(ISNa, 0) -------> Ka,b^1 = F(ISNa, 0) > > 2| Kb,a^2 = F(ISNb, ISNa) <------- Kb,a^2 = F(ISNb,ISNa) > > 3| Ka,b^3 = F(ISNa, ISNb) -------> Ka,b^3 = F(ISNa, ISNb) > > > > > > In the above, > > - line 1 is a SYN from a to b. > > - line 2 is a SYN/ACK segment from b to a > > - line 3 is an ACK segment from a to b > > > > Thus, in the simple case, each side creates 3 Traffic keys, ^1, > ^2, and ^3. > > In the more rare case where there is a simultaneous open [REF??], each > > side will generate four traffic keys: > > > > 1| Ka,b^1 = F(ISNa, 0) -------> Ka,b^1 = F(ISNa, 0) > > 2| Kb,a^2 = F(ISNb, 0) <------- Kb,a^2 = F(ISNb, 0) > > 3| Kb,a^3 = F(ISNb, ISNa) <------- Kb,a^3 = F(ISNb,ISNa) > > 4| Ka,b^4 = F(ISNa, ISNb) -------> Ka,b^4 = F(ISNa, ISNb) > > > > In the above, > > - line 1 is a SYN from a to b. > > - line 2 is a possible simultaneous open SYN from b to a > > - line 3 is a SYN/ACK segment from b to a > > - line 4 is an ACK segment from a to b > > === END TEXT ====== > > Thoughts? > > Gregory. > > +++++++++++++++++++++++ > IETF-related email from > Gregory M. Lebovitz > Juniper Networks > g r e go r y d o t i e tf a t g m a i l do t c o m > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknH26sACgkQE5f5cImnZrt05QCfekYPs+TgPvlP8qzn7GzTe+71 hw0AoOkA+Nk40WMaCLuV8pEjpY6K7u+T =6XS2 -----END PGP SIGNATURE----- From gregory.ietf@gmail.com Mon Mar 23 14:47:07 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D2528C121 for ; Mon, 23 Mar 2009 14:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McYd6Ioiz7T9 for ; Mon, 23 Mar 2009 14:47:05 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id B10F428C130 for ; Mon, 23 Mar 2009 14:47:05 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2942669wfg.31 for ; Mon, 23 Mar 2009 14:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=rjpfqnvIrKg1OSVGHYCN18I4Up7e88St4uRdJcRS5rI=; b=uUEs9EQ3n6IW4deDYdpOrglqHMG3omKD7je/qWTSh7QtlM44/MLRWIowUryWzMwb5/ V3rlAvEqb0GPQOmzGk5b0cohXribsndskwWqy8SZut4B/RLbN3JJhUGpIl9+4Jat1yWR lVyaz3mUFxND4FFpFxV3bDbEZcQjIsGRkfSl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=fByEft5OQTr7ToBjo8aZnsiqyEGAqTrdo4Rm8tk7BOuu+0z0LvFeRQD/fyMcoTJua1 UfsN6joAZUY0/plDSYyG92U4dLamaeS+fswFKbLqHSODQvQ85aXCyK7bW0dCg1QUodfN 3xmzYvYgnNazcgb5iqN7gojdRCkLGuUknSBtM= Received: by 10.142.84.11 with SMTP id h11mr3037413wfb.337.1237844876181; Mon, 23 Mar 2009 14:47:56 -0700 (PDT) Received: from Gregory-T60.gmail.com ([67.99.198.2]) by mx.google.com with ESMTPS id 22sm12226589wfd.26.2009.03.23.14.47.54 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Mar 2009 14:47:55 -0700 (PDT) Message-ID: <49c8038b.16048e0a.3757.ffffa82f@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Mar 2009 14:44:05 -0700 To: Eric Rescorla ,tcpm@ietf.org From: "Gregory M. Lebovitz" In-Reply-To: <7.1.0.9.2.20090323103201.05f68ec0@gmail.com> References: <86r60tf31x.wl%ekr@networkresonance.com> <20090320003241.E345150822@romeo.rtfm.com> <7.1.0.9.2.20090323103201.05f68ec0@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_368489671==.ALT" Subject: Re: [tcpm] Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 21:47:07 -0000 --=====================_368489671==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable my comments inline... At 10:34 AM 3/23/2009, Gregory M. Lebovitz wrote: >To: Eric Rescorla , tcpm@ietf.org >From: "Gregory M. Lebovitz" >Subject: Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00 >Bcc: =83\IETF\tcpm >In-Reply-To: <20090320003241.E345150822@romeo.rtfm.com> >References:=20 ><86r60tf31x.wl%ekr@networkresonance.com>=20 ><20090320003241.E345150822@romeo.rtfm.com> > >Hey all, >So far EKR's is the only review I've seen of=20 >this draft. And many of you might have missed=20 >it, for the wrong subject line he used. So I'm=20 >resending my one and only precious review to the list w/ correct subject= line. > >Gregory. > >At 05:32 PM 3/19/2009, Eric Rescorla wrote: >>At Thu, 19 Mar 2009 17:31:06 -0700, >>Doh. This review was of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00 >> >>A review of auth-opt is forthcoming. >>-Ekr >> >> >>At Thu, 19 Mar 2009 17:31:06 -0700, >>Eric Rescorla wrote: >> > >> > [Resent from an account that's subscribed.] >> > >> > -Ekr >> > >> > $Id:=20 >> draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00-rev.txt,v=20 >> 1.1 2009/03/19 22:37:19 ekr Exp $ >> > >> > S 2.1. >> > This whole {SHOULD,MUST}{+,-,*,?} thing is a bad idea. It's hard >> > enough for developers to understand SHOULD vs. MUST, but now we have 5 >> > separate options for implementors to understand and us to argue >> > over. I don't remember there being WG consensus on this point. >> > >> > >> > S 2.2. >> > The assignment of HMAC-SHA-1 to MUST- and AES-CMAC to SHOULD+ is >> > basically unjustified. There's no good reason to believe that >> > HMAC-SHA1 will be broken before AES-CMAC. This is exactly the >> > confusion fostered by the +/- regime. Make HMAC-SHA1 MUST and >> > AES-CMAC SHOULD. For last two, I remember MSP's meeting different,=20 that we discussed this "move away from" and "move=20 toward" stuff there. However, I'm not stuck on it. Let's let WG decide= today. >> > >> > >> > S 3.1. >> > It's confusing to talk about KDFs having an interface and then >> > have the function named "PRF". >> > >> > I would rewrite this as: >> > >> > All KDFs used in TCP-AO have the following interface: >> > >> > Derived_Key =3D KDF(Master_Key, Context, Output_Length) See the point and I'm fine with the change. re: "Context" vs "Input", I was using the lingo=20 so as to align with [NIST-SP800-108]. So, unless=20 someone has a really good reason why, I'll stick with "Input" in this case. >> > >> > Where these values are defined as.... [blah blah] >> > >> > Then: >> > The KDFs defined in this document are all based on pseudorandom >> > functions (PRFs) which take a key and an input and emit a >> > fixed-length pseudorandom value. Given PRF X, the associated >> > KDF, KDF_X, is constructed as follows: >> > >> > KDF_X(Master_Key, Context, Output_Length) =3D >> > X(Master_Key, Input) to be more clear about the use of the PRF could=20 this be simplified to use the same descriptive=20 text above, but then the formula is: KDF_X =3D PRF_X(Master_Key, Input) Or am I missing something? >> > >> > Where Input is constructed as:... >> > >> > Where you say that the master key isn't random, that's not quite >> > right. The point is not that it doesn't contain high entropy. >> > For instance HEX(X) where X is a 128-bit random number has high >> > entropy but may or may not be suitable for use keying a MAC >> > function. Text currently says "We assume that, in manual key mode, this is a=20 human readable pre-shared key (PSK), thus we=20 assume that it is of variable length, and we also=20 assume it is in no way random." The point is that someone might enter "dogfood"=20 as Master_Key, so we are creating a mechanism=20 that assumes it most likely is NOT 128-bit random with high entropy. What would you prefer the text say? >> > >> > This section of the document is pretty confusing about the concept of >> > output length. To recap: >> > >> > 1. The underlying PRFs have fixed sized output lengths, 128 bits in the >> > case of AES-CMAC, 160 bits in the case of HMAC-SHA1. >> > 2. It is possible to generate an arbitrary number of output bits with >> > a given PRF by operating it in a feedback or counter mode. >> > The FIPS-whatever KDFs incorporate this feature, hence the >> > leading "0". >> > 3. Each MAC needs a key of a specific length. >> > 4. Not totally uncoincidentally, the KDFs we have chosen to use with >> > each MAC happen to generate the right key size for use with the >> > MAC, thus avoiding the need for the procedure in (2). >> > 5. If you wanted to use these KDFs with a MAC requiring a longer key >> > (e.g., HMAC-SHA-256) you would, however need to use the procedure. I'll put this stuff in to add clarification. >> > 6. For some reason, the FIPS-whatever KDFs seem to think it's >> > a useful idea to mix the desired number of bits produced by the >> > KDF into the KDF input. I don't see the point of this, but >> > whatever. >> > >> > You'll note that the PRF does not need to be parametrized in terms >> > of output length. It's fixed. but you need it for #6 above, as it's part of the=20 "FIPS-whatever" as you call it. So that's why=20 it's there, because implementers will need it as=20 a variable for runing the function. Can you live w/ that? >> > >> > IMO, this could be a lot clearer. >> > >> > S 3.1.1. >> > Is this an ASCII 0 (0x30) or a NUL (0x00) I'll look up the FIPS thing and call it out in=20 the next rev, unless someone clarifies in the WG session. >> > >> > >> > S 3.1.2. >> > It's pretty unclear what problem you're trying to solve here. I would >> > write: >> > >> > RFC 4615 is designed to take an arbitrary length key but for any >> > key length other than 128 bits, whitens it by first computing an >> > AES-CMAC with key 0. Because the keys in use with TCP-AO will >> > likely be arbitrary-length ASCII strings, TCP AO always performs >> > this whitening step even if the key happens to be 16 bytes long. >> > In other words, using the terminology of RFC 4615: >> > >> > K =3D AES-CMAC(0^128, MK, MKlen) ok. I'm fine with that text. >> > >> > >> > S 4. >> > This UI labels section should be entirely removed. As far as I know, >> > there was never WG consensus to include it and it just creates >> > extra confusion. In AO, the MAC completely defines the KDF, so >> > the concept of suites just adds an extra name. Moreover, since >> > MACs have obvious names and the suites have opaque, confusing names, >> > this is doubly bad. I'm fine with that. We'll make the final call at WG today. Thx EKR, Gregory. >> > >> > >> > >> > >> > >> > >> > >> > >>_______________________________________________ >>tcpm mailing list >>tcpm@ietf.org >>https://www.ietf.org/mailman/listinfo/tcpm --=====================_368489671==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable my comments inline...

At 10:34 AM 3/23/2009, Gregory M. Lebovitz wrote:

To: Eric Rescorla <ekr@networkresonance.com>, tcpm@ietf.org
From: "Gregory M. Lebovitz" <gregory.ietf@gmail.com>
Subject: Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00
Bcc: =83\IETF\tcpm
In-Reply-To: <20090320003241.E345150822@romeo.rtfm.com>
References: <86r60tf31x.wl%ekr@networkresonance.com> <20090320003241.E345150822@romeo.rtfm.com>

Hey all,
So far EKR's is the only review I've seen of this draft. And many of you might have missed it, for the wrong subject line he used. So I'm resending my one and only precious review to the list w/ correct subject line.

Gregory.

At 05:32 PM 3/19/2009, Eric Rescorla wrote:
At Thu, 19 Mar 2009 17:31:06 -0700,
Doh. This review was of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00

A review of auth-opt is forthcoming.
-Ekr


At Thu, 19 Mar 2009 17:31:06 -0700,
Eric Rescorla wrote:
>
> [Resent from an account that's subscribed.]
>
> -Ekr
>
> $Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00-rev.txt,v 1.1 2009/03/19 22:37:19 ekr Exp $
>
> S 2.1.
> This whole {SHOULD,MUST}{+,-,*,?} thing is a bad idea. It's hard
> enough for developers to understand SHOULD vs. MUST, but now we have 5
> separate options for implementors to understand and us to argue
> over. I don't remember there being WG consensus on this point.
>
>
> S 2.2.
> The assignment of HMAC-SHA-1 to MUST- and AES-CMAC to SHOULD+ is
> basically unjustified. There's no good reason to believe that
> HMAC-SHA1 will be broken before AES-CMAC.  This is exactly the
> confusion fostered by the +/- regime.  Make HMAC-SHA1 MUST and
> AES-CMAC SHOULD.

For last two, I remember MSP's meeting different, that we discussed this "move away from" and "move toward" stuff there. However, I'm not stuck on it. Let's let WG decide today.


>
>
> S 3.1.
> It's confusing to talk about KDFs having an interface and then
> have the function named "PRF".
>
> I would rewrite this as:
>
>      All KDFs used in TCP-AO have the following interface:
>     
>       Derived_Key =3D KDF(Master_Key, Context, Output_Length)

See the point and I'm fine with the change.

re:  "Context" vs "Input", I was using the lingo so as to align with [NIST-SP800-108]. So, unless someone has a really good reason why, I'll stick with "Input" in this case.


>     
>      Where these values are defined as.... [blah blah]
>
> Then:
>      The KDFs defined in this document are all based on pseudorandom
>      functions (PRFs) which take a key and an input and emit a
>      fixed-length pseudorandom value.  Given PRF X, the associated
>      KDF, KDF_X, is constructed as follows:
>
>      KDF_X(Master_Key, Context, Output_Length) =3D
>          X(Master_Key, Input)

to be more clear about the use of the PRF could this be simplified to use the same descriptive text above, but then the formula is:
      KDF_X =3D
           PRF_X(Master_Key, Input)

Or am I missing something?

>
>      Where Input is constructed as:...
>
> Where you say that the master key isn't random, that's not quite
> right. The point is not that it doesn't contain high entropy.
> For instance HEX(X) where X is a 128-bit random number has high
> entropy but may or may not be suitable for use keying a MAC
> function.

Text currently says=20
"We assume that, in manual key mode, this is a human readable pre-shared key (PSK), thus we assume that it is of variable length, and we also assume it is in no way random."=20
The point is that someone might enter "dogfood" as Master_Key, so we are creating a mechanism that assumes it most likely is NOT 128-bit random with high entropy.

What would you prefer the text say?


>
> This section of the document is pretty confusing about the concept of
> output length. To recap:
>
> 1. The underlying PRFs have fixed sized output lengths, 128 bits in the
>    case of AES-CMAC, 160 bits in the case of HMAC-SHA1.
> 2. It is possible to generate an arbitrary number of output bits with
>    a given PRF by operating it in a feedback or counter mode.
>    The FIPS-whatever KDFs incorporate this feature, hence the
>    leading "0".
> 3. Each MAC needs a key of a specific length.
> 4. Not totally uncoincidentally, the KDFs we have chosen to use with
>    each MAC happen to generate the right key size for use with the
>    MAC, thus avoiding the need for the procedure in (2).
> 5. If you wanted to use these KDFs with a MAC requiring a longer key
>    (e.g., HMAC-SHA-256) you would, however need to use the procedure.

I'll put this stuff in to add clarification.

> 6. For some reason, the FIPS-whatever KDFs seem to think it's
>    a useful idea to mix the desired number of bits produced by the
>    KDF into the KDF input. I don't see the point of this, but
>    whatever.
>
> You'll note that the PRF does not need to be parametrized in terms
> of output length. It's fixed.

but you need it for #6 above, as it's part of the "FIPS-whatever" as you call it. So that's why it's there, because implementers will need it as a variable for runing the function. Can you live w/ that?

>
> IMO, this could be a lot clearer.
>
> S 3.1.1.
> Is this an ASCII 0 (0x30) or a NUL (0x00)

I'll look up the FIPS thing and call it out in the next rev, unless someone clarifies in the WG session.

>
>
> S 3.1.2.
> It's pretty unclear what problem you're trying to solve here. I would
> write:
>
> RFC 4615 is designed to take an arbitrary length key but for any
> key length other than 128 bits, whitens it by first computing an
> AES-CMAC with key 0. Because the keys in use with TCP-AO will
> likely be arbitrary-length ASCII strings, TCP AO always performs
> this whitening step even if the key happens to be 16 bytes long.
> In other words, using the terminology of RFC 4615:
>
>    K =3D AES-CMAC(0^128, MK, MKlen)

ok. I'm fine with that text.

>
>
> S 4.
> This UI labels section should be entirely removed. As far as I know,
> there was never WG consensus to include it and it just creates
> extra confusion. In AO, the MAC completely defines the KDF, so
> the concept of suites just adds an extra name. Moreover, since
> MACs have obvious names and the suites have opaque, confusing names,
> this is doubly bad.

I'm fine with that. We'll make the final call at WG today.

Thx EKR,
Gregory.

>
>
>
>
>
>
>
>
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--=====================_368489671==.ALT-- From david.borman@windriver.com Mon Mar 23 18:39:44 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963843A6C7B for ; Mon, 23 Mar 2009 18:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WSvY06AQCiH for ; Mon, 23 Mar 2009 18:39:43 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 9B8453A6C79 for ; Mon, 23 Mar 2009 18:39:43 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2O1eVBL023676; Mon, 23 Mar 2009 18:40:31 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 18:40:31 -0700 Received: from dhcp-53da.meeting.ietf.org ([147.11.233.54]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 18:40:31 -0700 Message-Id: From: David Borman To: tcpm@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 20:40:30 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Mar 2009 01:40:31.0165 (UTC) FILETIME=[84617ED0:01C9AC21] Cc: tcpm-chairs@tools.ietf.org, tsv-ads@tools.ietf.org Subject: [tcpm] TCPM meeting part 2 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 01:39:44 -0000 Due to the extended TCP AO discussions at today's TCPM meeting, the presentations/discussions that we did not get to will be added onto the agenda for the Transport Area Open Meeting on Wednesday, March 25, 1300-1500 Continental 6. -David Borman * David Borman "TCP Extensions for High Performance" draft-ietf-tcpm-1323bis-01 "TCP Options and MSS" draft-ietf-tcpm-tcpmss-00 TCP Urgent Data draft-gont-tcpm-urgent-data-01 * Yoshifumi Nishida A small issue in RFC3782 http://www.us.nishida.org/newreno * Markku Kojo "Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation" draft-jarvinen-tcpm-sack-recovery-entry-00.txt From Pasi.Sarolahti@nokia.com Tue Mar 24 07:21:35 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7210E28C288 for ; Tue, 24 Mar 2009 07:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpTiUGJm-zsn for ; Tue, 24 Mar 2009 07:21:34 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 439DB3A6898 for ; Tue, 24 Mar 2009 07:21:34 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2OEMAKJ024459; Tue, 24 Mar 2009 09:22:25 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 16:22:21 +0200 Received: from [216.112.108.70] ([10.162.253.69]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 16:22:08 +0200 In-Reply-To: <0F312D82-9D98-480C-AA47-81FBA440BE7E@nets.rwth-aachen.de> References: <0F312D82-9D98-480C-AA47-81FBA440BE7E@nets.rwth-aachen.de> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97DA840B-B3B8-409B-ABB0-CEF856CA2CC2@nokia.com> Content-Transfer-Encoding: 7bit From: Pasi Sarolahti Date: Tue, 24 Mar 2009 07:21:51 -0700 To: ext Alexander Zimmermann X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 24 Mar 2009 14:22:09.0029 (UTC) FILETIME=[EA6E2B50:01C9AC8B] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Variable "recover" in F-RTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 14:21:35 -0000 Hi Alex, Sorry that it took this long to reply. The condition 'but not more than "recover"' is there just to cover the case of invalid ACKs arriving for some strange reason, and in such case revert to normal TCP operation, to be on a safe side. In a well-behaving environment one should not receive such an ACK. - Pasi On Mar 5, 2009, at 2:37, ext Alexander Zimmermann wrote: > Dear all, > > I have an understanding problem with aforementioned variable "recover" > in the current version (http://www.tools.ietf.org/html/draft-ietf- > tcpm-rfc4138bis-04) > of the F-RTO Algorithm. > > Section 2.1 The Algorithm (F-RTO, Reno/NewReno Case) > > Step 2): When the first ACK after RTO rexmit arrives at the TCP > Sender, > we store the highest sequence number transmitted so far in the > variable > "recover". > > then > > Step 2a) Check if the ACK from Step 2) is a DUPACK OR the ACK covers > "recover" but not more than "recover"... > > > Why is the check like this? IMHO we can only get an ACK that cover > exactly "recover" > (Lost Retransmission - SIGCOM Paper Section 4.2) or an ACK that > cover less than > "recover", but we cannot get ACK that cover more than "recover". > > Alex > > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22220 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > From lars.eggert@nokia.com Tue Mar 24 09:47:21 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112B23A6977; Tue, 24 Mar 2009 09:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4W7ixIqZAvD; Tue, 24 Mar 2009 09:47:20 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id B36FC3A6D48; Tue, 24 Mar 2009 09:47:19 -0700 (PDT) Received: from [IPv6:2001:df8::80:219:e3ff:fe06:dc74] ([IPv6:2001:df8:0:80:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2OGm1tY011506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2009 18:48:03 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <56A4BDBF-F07C-4C3B-99B8-3B7853EAF97B@nokia.com> From: Lars Eggert To: David Borman , TSV Area In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-6--239441362; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 09:47:59 -0700 References: X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Tue, 24 Mar 2009 18:48:07 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9159/Tue Mar 24 16:59:06 2009 on fit.nokia.com X-Virus-Status: Clean Cc: "tcpm-chairs@tools.ietf.org" , "tsv-ads@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] TCPM meeting part 2 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:47:21 -0000 --Apple-Mail-6--239441362 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, I asked the secretariat to shorten the TSVAREA slot to 13:00-14:00 (we have a light agenda) and schedule a second TCPM meeting in the same room from 14:00-15:00. The agenda will be changed later today. Lars On 2009-3-23, at 18:40, David Borman wrote: > Due to the extended TCP AO discussions at today's TCPM meeting, the > presentations/discussions that we did not get to will be added onto > the agenda for the Transport Area Open Meeting on Wednesday, March 25, > 1300-1500 Continental 6. > > -David Borman > > * David Borman > "TCP Extensions for High Performance" > draft-ietf-tcpm-1323bis-01 > "TCP Options and MSS" > draft-ietf-tcpm-tcpmss-00 > TCP Urgent Data > draft-gont-tcpm-urgent-data-01 > > * Yoshifumi Nishida > A small issue in RFC3782 > http://www.us.nishida.org/newreno > > * Markku Kojo > "Using TCP Selective Acknowledgement (SACK) Information to > Determine > Duplicate Acknowledgements for Loss Recovery Initiation" > draft-jarvinen-tcpm-sack-recovery-entry-00.txt > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-6--239441362 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTAzMjQxNjQ3NjBaMCMGCSqGSIb3DQEJBDEWBBSqrhvd91KFE+qf fTKd+sPf6OlFszCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAPS5ZgDsrh8r/5vusXAoPRtEz6ebwidhdHbmQVDz2/BjX3WZaJtME R0FK06njyEqUGiulzYhccy8gHWn6rpbQNOz4Jelf1WXaaRtGD6ZWIGjlW8RV7dZeL2aVDs9zhSzg gmcx4oqObaABdwGkWZRWM7l6CUePpKMS6kgH7g6YWLUJdu7D1DuTF8njttyvqpbFhearoNaboUnP pIkVE+T5Muy8K6Wr9BGwjK52S1uxxHluOAf8JTpsmPXn9IHkQs+LciUExzsEii1PfXbBwLxYsjpE DglBQmBqah5oWxY7FN7Of6D3Tg37XRS4molgxNP5dzcVNvrg98h3EKRS5HyJnAAAAAAAAA== --Apple-Mail-6--239441362-- From gregory.ietf@gmail.com Tue Mar 24 16:27:16 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7F03A67E1 for ; Tue, 24 Mar 2009 16:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0k+b++nbq9C for ; Tue, 24 Mar 2009 16:27:15 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 5688F3A67B4 for ; Tue, 24 Mar 2009 16:27:15 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3586089wfg.31 for ; Tue, 24 Mar 2009 16:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=1rODiD5ZVkBY66mtvm3WOxRxMNl+6+fGG1zLvHgs2Uk=; b=VAEPiLLxgG8ghCUSAjoqI+2IQLcFQPMKXon+KeYLGa6z+98b85Qe3bEHAII20dXDBO V+shJ4xfuQhH2NEurabXy7S7Gh4TtpE8N3tEUDuxJwxUNZumu63AiT573pgdL9goauaa 39UGPe4PgZIfrGvaAuUkWoCB8DYs1ZCGa/Mss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=jbFFH7vAWAruOxXbwhWK1XDSjzx/XMNtvcbZV+rDmrbI6NA9Y3Oorlbcg6s8mjfj9l 8z1d13+ehL0heCC5XvN/jkUXxnTU3iMlvpZ7ZIXrTDjNom/L2pjlUAe2ZlirKx2HqK5d 53epHwG28hPxtSrjY49XEBGUPrfDqjxaOtQN4= Received: by 10.142.12.14 with SMTP id 14mr3623639wfl.54.1237937285464; Tue, 24 Mar 2009 16:28:05 -0700 (PDT) Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id 32sm14877403wfa.19.2009.03.24.16.28.04 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Mar 2009 16:28:04 -0700 (PDT) Message-ID: <49c96c84.20018e0a.7c3a.68fd@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Mar 2009 16:28:01 -0700 To: David Borman ,tcpm@ietf.org From: "Gregory M. Lebovitz" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: tcpm-chairs@tools.ietf.org, tsv-ads@tools.ietf.org Subject: Re: [tcpm] TCPM meeting part 2 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:27:16 -0000 Damn security guys... DoS'ing other people's WGs. We need to put an end to this. Hopefully we made sufficient progress that we won't need to have an -AO preso in stockholm, or ever again, at least in TCPM. Thanks for putting up with us, Gregory. At 06:40 PM 3/23/2009, David Borman wrote: >Due to the extended TCP AO discussions at today's TCPM meeting, the >presentations/discussions that we did not get to will be added onto >the agenda for the Transport Area Open Meeting on Wednesday, March 25, >1300-1500 Continental 6. > > -David Borman > >* David Borman > "TCP Extensions for High Performance" > draft-ietf-tcpm-1323bis-01 > "TCP Options and MSS" > draft-ietf-tcpm-tcpmss-00 > TCP Urgent Data > draft-gont-tcpm-urgent-data-01 > > * Yoshifumi Nishida > A small issue in RFC3782 > http://www.us.nishida.org/newreno > > * Markku Kojo > "Using TCP Selective Acknowledgement (SACK) Information to Determine > Duplicate Acknowledgements for Loss Recovery Initiation" > draft-jarvinen-tcpm-sack-recovery-entry-00.txt > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From wwwrun@core3.amsl.com Tue Mar 24 10:07:10 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A585328C158; Tue, 24 Mar 2009 10:07:10 -0700 (PDT) From: IETF Agenda To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090324170710.A585328C158@core3.amsl.com> Date: Tue, 24 Mar 2009 10:07:10 -0700 (PDT) X-Mailman-Approved-At: Wed, 25 Mar 2009 08:01:38 -0700 Cc: 74all@ietf.org, tcpm@ietf.org Subject: [tcpm] 74TH IETF - TCPM and TSVAREA X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:07:10 -0000 TCPM will have a second session on Wednesday, March 26 from 1400-1500 in Continental 6. TCPM will use the second hour of the TSVAREA meeting slot. From david.borman@windriver.com Wed Mar 25 18:52:07 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9B43A6A0A for ; Wed, 25 Mar 2009 18:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7r9r+Sp4YRA for ; Wed, 25 Mar 2009 18:52:06 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 9F99F3A680A for ; Wed, 25 Mar 2009 18:52:06 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2Q1qw79025476 for ; Wed, 25 Mar 2009 18:52:58 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 18:52:57 -0700 Received: from dhcp-53da.meeting.ietf.org ([147.11.233.50]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 18:52:58 -0700 Message-Id: <511AB862-06E0-40EB-B6C8-E490D82E7DC0@windriver.com> From: David Borman To: tcpm@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 20:52:57 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Mar 2009 01:52:58.0184 (UTC) FILETIME=[96770C80:01C9ADB5] Subject: [tcpm] TCP MSS option - FYI original discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:52:07 -0000 In today's TCPM session, Matt Mathis asked when the TCP MSS option discussion first happened. I looked it up, and I originally posted the discussion to the tcplw@cray.com mailing list in 1993. Here's the text of that original message, taken from my mail archives. -David Borman > From dab Thu Jan 7 14:12:10 1993 > To: tcplw@cray.com > Subject: TCP MSS & Timestamps > > > In recent private mail conversation, it has come to my > attention that we probably don't all have a common view on > what to do with the TCP MSS value in the presence of TCP > options, since the TCP MSS value only refers to the TCP > data part of the packet, and the presence of TCP options > will affect that value. > > Since 1323 is eligible for elevation to Draft status, this > is a good time to revise the document to clarify this issue. > > First, there is a maximum packet size. When you insert options, > the amount of space available for TCP data within a non-fragmented > IP packet goes down by the length of the options. So, the option > length needs to be accounted for. > > The "be conservative in what you send" rule can be applied > in two ways. The first is in the generation of the MSS > value, you can say "well, I'll assume that the other side > won't adjust for the length of the options, so I'll adjust > for the option length when sending the MSS". Meanwhile, > on the other side, when sending a packet, you can say "well, > I'll assume that the other side did not adjust for the options > length when it sent the MSS, and so I'll decrease the data > size by the option length". You can do both, but then the > packets will usually be short. So, you should pick one or the > other, but not both. > > With two places to do the accounting for the options vs. > the MSS value, you get a grid like: > > | MSS is adjusted | MSS is not adjusted > | for options | for options > ----------------+-----------------------+-------------------- > Sender adjusts | packets are too | packets are the > length for | short | correct length > options | | > ----------------+-----------------------+-------------------- > Sender doesn't | packets are the | packets are too > adjust length | correct length | long. > for options | | > > The bottom right-hand corner is what we want to avoid, since that > is the case when IP will have to fragment the packet. The only > way that the side that is sending the datagrams can guarantee that > it doesn't send IP packets that are too long is to always adjust > the data length by the length of the options. It would be better > to send a packet that is a few bytes too short rather than one > that is a few bytes too long. > > So, the bottom line is that I'd like to see a paragraph added > to 1323 stating that the generated MSS value only takes into > account the fixed IP and TCP header lengths, and that the side > that is generating the datagrams needs to adjust the length of > the TCP data to account for any IP or TCP options that it inserts > into the datagram. > > Anyone disagree? > > -David Borman, dab@cray.com > From Alexander.Zimmermann@nets.rwth-aachen.de Thu Mar 26 15:31:25 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A5E3A682F for ; Thu, 26 Mar 2009 15:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n8L763wDP6c for ; Thu, 26 Mar 2009 15:31:24 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 4F59F3A6452 for ; Thu, 26 Mar 2009 15:31:24 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KH400C89X9SMAG0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 26 Mar 2009 23:32:16 +0100 (CET) X-IronPort-AV: E=Sophos; i="4.38,428,1233529200"; d="sig'?scan'208"; a="6191935" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 26 Mar 2009 23:32:16 +0100 Received: from dhcp-12ac.meeting.ietf.org ([unknown] [130.129.18.172]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KH400IHXX9QJS20@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 26 Mar 2009 23:32:16 +0100 (CET) Message-id: <13F895CC-7740-4976-8EDF-7FA473936AC1@nets.rwth-aachen.de> From: Alexander Zimmermann To: David Borman Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-14--45988424 Date: Thu, 26 Mar 2009 23:32:12 +0100 X-Pgp-Agent: GPGMail 1.2.0 (v56) Content-transfer-encoding: 7bit X-Mailer: Apple Mail (2.930.3) Cc: "tcpm@ietf.org" Subject: [tcpm] 1323bis Review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:31:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-14--45988424 Content-Type: multipart/mixed; boundary=Apple-Mail-13--45988465 --Apple-Mail-13--45988465 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi David, here is a patch file for some small errors/misspellings in the 1323bis-01draft. Alex --Apple-Mail-13--45988465 Content-Disposition: attachment; filename=1323bis.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="1323bis.patch" Content-Transfer-Encoding: 7bit --- draft-ietf-tcpm-1323bis-01.txt 2009-03-05 00:23:31.000000000 +0100 +++ draft-ietf-tcpm-1323bis-01.new.txt 2009-03-26 22:44:58.000000000 +0100 @@ -936,7 +936,7 @@ (2) If: - SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent + SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent then SEG.TSval is copied to TS.Recent; otherwise, it is ignored. @@ -973,7 +973,7 @@ advanced the left window edge is echoed, until the missing segment arrives; it is echoed according to Case (C). The same sequence would occur if segments B and D were lost and - retransmitted.. + retransmitted. @@ -1982,12 +1982,12 @@ (b) In RFC 1323, section 3.4, step (2) of the algorithm to control which timestamp is echoed was incorrect in two regards: - (1) It failed to update TSrecent for a retransmitted segment + (1) It failed to update TS.Recent for a retransmitted segment that resulted from a lost ACK. (2) It failed if SEG.LEN = 0. - In the new algorithm, the case of SEG.TSval = TSrecent is + In the new algorithm, the case of SEG.TSval >= TS.Recent is included for consistency with the PAWS test. (c) One correction was made to the Event Processing Summary in @@ -2478,8 +2478,8 @@ true, then the segment is not acceptable; follow steps below for an unacceptable segment. - If SEG.SEQ is equal to Last.ACK.sent, then save SEG.ECopt in - variable TS.Recent. + If SEG.SEQ is less or equal to Last.ACK.sent, then save + SEG.TSval in variable TS.Recent. There are four cases for the acceptability test for an incoming --Apple-Mail-13--45988465 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-13--45988465-- --Apple-Mail-14--45988424 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknMAmwACgkQdyiq39b9uS7PxACggWedWzgvog+RMZK3zZkwe1bn f/0AoKJqc6UZsCQq3a8aJ3ckh1MOteKP =LR8B -----END PGP SIGNATURE----- --Apple-Mail-14--45988424-- From alexander.zimmermann@nets.rwth-aachen.de Thu Mar 26 16:09:38 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097DA3A69A2 for ; Thu, 26 Mar 2009 16:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_26=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-wm9-sirO7O for ; Thu, 26 Mar 2009 16:09:37 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 03D6D3A682F for ; Thu, 26 Mar 2009 16:09:37 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KH4000ZLZ1H5610@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Fri, 27 Mar 2009 00:10:29 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.38,429,1233529200"; d="txt'?sig'?scan'208";a="6194923" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 27 Mar 2009 00:10:29 +0100 Received: from dhcp-12ac.meeting.ietf.org ([unknown] [130.129.18.172]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KH400IUNZ1FJS20@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Fri, 27 Mar 2009 00:10:29 +0100 (CET) Message-id: <1E6B7C58-4AE4-4B82-B110-F26D8F76F71B@nets.rwth-aachen.de> From: Alexander Zimmermann To: David Borman Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-11--43695090 Date: Fri, 27 Mar 2009 00:10:26 +0100 X-Pgp-Agent: GPGMail 1.2.0 (v56) Content-transfer-encoding: 7bit X-Mailer: Apple Mail (2.930.3) Cc: tcpm@ietf.org Subject: [tcpm] 1323bis - PAWS check's problem with reodering on the reverse path X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 23:09:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-11--43695090 Content-Type: multipart/mixed; boundary=Apple-Mail-10--43695151 --Apple-Mail-10--43695151 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi David, hi TCPM Folks, in the 1323bis draft the PAWS check has a problem (discarding ACKs) if reordering is present on the reverse path and no data is piggybacked. Actually, it's not the PAWS check itself, it's the modification of section 3.4: "Which Timestamp to Echo". The important parts of the RFC1323 and the draft (in this order) are --- (2) If Last.ACK.sent falls within the range of sequence numbers of an incoming segment: SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN then the TSval from the segment is copied to TS.Recent; otherwise, the TSval is ignored. --- (2) If: SEG.TSval >= TS.recent and SEG.SEQ <= Last.ACK.sent then SEG.TSval is copied to TS.Recent; otherwise, it is ignored. --- The addition of "SEG.TSval >= TS.recent" is not important for us at moment. As the appendix said, this check is included for consistency with the PAWS test only. The relevant paragraph is the change from "SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN" to the reduced form "SEG.SEQ <= Last.ACK.sent". Again, the appendix said that this change was made since the original algorithm to control which timestamp is echoed was incorrect in two regards: (1) It failed to update TSrecent for a retransmitted segment that resulted from a lost ACK. (2) It failed if SEG.LEN = 0. It's right that the 1323bis algo fix these two problems, however, it's introduced the new problem mentioned already above. Following situation: - One-way flow from TCP A to TCP B - Reordering on the reverse path Consequence - TCP A will discard all ACKs with were delayed - Harmful in the case ABC (RFC 3465) is off, since we count ACKs for slow-start and congestion avoidance Examples are attached. Alex --Apple-Mail-10--43695151 Content-Disposition: attachment; filename="PAWS 1323.txt" Content-Type: text/plain; x-unix-mode=0644; name="PAWS 1323.txt" Content-Transfer-Encoding: quoted-printable PAWS Test 1323=0D =0D time t TCP A TCP B=0D =0D 0 TS.Recent =3D 0 = TS.Recent =3D 0=0D Last.ACK.Sent =3D 0 = Last.ACK.Sent =3D 0=0D =0D 1 -> | ACK=3DY, SEQ=3DX, TSval=3D1 | ->=0D (data X)=0D =0D TS.Recent =3D 0 = TS.Recent =3D 0=0D Last.ACK.Sent =3D Y = Last.ACK.Sent =3D 0=0D =0D 2 (delayed) | ACK=3DX+1, SEQ=3DY, TSval=3D102 | = <-=0D (ACK for data X)=0D =0D TS.Recent =3D 0 = TS.Recent =3D 1=0D Last.ACK.Sent =3D Y = Last.ACK.Sent =3D X+1=0D =0D 3 -> | ACK=3DY, SEQ=3DX+1, TSval=3D3 | = ->=0D (data X+1)=0D =0D TS.Recent =3D 0 = TS.Recent =3D 1=0D Last.ACK.Sent =3D Y = Last.ACK.Sent =3D X+1=0D =0D 4 <- | ACK=3DX+2, SEQ=3DY, TSval=3D104 | = <-=0D (ACK for data X+1)=0D =0D TS.Recent =3D 0 (!!!) = TS.Recent =3D 3=0D Last.ACK.Sent =3D Y = Last.ACK.Sent =3D X+2=0D =0D 5 <- | ACK=3DX, SEQ=3DY, TSval=3D102 | = (reordered from t=3D2 arrives)=0D (ACK for data X)= --Apple-Mail-10--43695151 Content-Disposition: attachment; filename="PAWS 1323bis.txt" Content-Type: text/plain; x-unix-mode=0644; name="PAWS 1323bis.txt" Content-Transfer-Encoding: quoted-printable PAWS Test 1323bis-01=0D =0D time t TCP A TCP B=0D =0D 0 TS.Recent =3D 0 = TS.Recent =3D 0=0D Last.ACK.Sent =3D 0 = Last.ACK.Sent =3D 0=0D =0D 1 -> | ACK=3DY, SEQ=3DX, TSval=3D1 | ->=0D (data X)=0D =0D TS.Recent =3D 0 = TS.Recent =3D 0=0D Last.ACK.Sent =3D Y = Last.ACK.Sent =3D 0=0D =0D 2 (delayed) | ACK=3DX+1, SEQ=3DY, TSval=3D102 | = <-=0D (ACK for data X)=0D =0D TS.Recent =3D 0 = TS.Recent =3D 1=0D Last.ACK.Sent =3D Y = Last.ACK.Sent =3D X+1=0D =0D 3 -> | ACK=3DY, SEQ=3DX+1, TSval=3D3 | = ->=0D (data X+1)=0D =0D TS.Recent =3D 0 = TS.Recent =3D 1=0D Last.ACK.Sent =3D Y = Last.ACK.Sent =3D X+1=0D =0D 4 <- | ACK=3DX+2, SEQ=3DY, TSval=3D104 | = <-=0D (ACK for data X+1)=0D =0D TS.Recent =3D 104 (!!!) = TS.Recent =3D 3=0D Last.ACK.Sent =3D Y = Last.ACK.Sent =3D X+2=0D =0D 5 <- | ACK=3DX, SEQ=3DY, TSval=3D102 | = (reordered from t=3D2 arrives)=0D (ACK for data X)=0D =0D TS.Recent =3D 104 > TSval =3D 102 =3D> ACK for data X is = not acceptable=0D --Apple-Mail-10--43695151 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-10--43695151-- --Apple-Mail-11--43695090 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknMC2IACgkQdyiq39b9uS5HrACg4KzDkJSMpJ2SgVEgTbFpI2b1 /9AAn3rOV3boNWAo6h8P1h0r1QMGP/Nc =X9Vj -----END PGP SIGNATURE----- --Apple-Mail-11--43695090-- From magnus.westerlund@ericsson.com Fri Mar 27 10:14:56 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77703A6968; Fri, 27 Mar 2009 10:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yab3WM+ikTnj; Fri, 27 Mar 2009 10:14:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D5D9C3A6C3F; Fri, 27 Mar 2009 10:14:55 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1A50B201E4; Fri, 27 Mar 2009 18:15:49 +0100 (CET) X-AuditID: c1b4fb3e-af7bcbb000006d6d-8f-49cd09c446dd Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E854820089; Fri, 27 Mar 2009 18:15:48 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Mar 2009 18:15:48 +0100 Received: from [153.88.49.36] ([153.88.49.36]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Mar 2009 18:15:47 +0100 Message-ID: <49CD09C2.40806@ericsson.com> Date: Fri, 27 Mar 2009 10:15:46 -0700 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: softwires@ietf.org, tcpm@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Mar 2009 17:15:48.0342 (UTC) FILETIME=[AC106960:01C9AEFF] X-Brightmail-Tracker: AAAAAA== Subject: [tcpm] TCP MSS clamping to try to deal with MTU issues in Dual-Stack Lite X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 17:14:57 -0000 Hi, There is a proposal to use TCP MSS clamping to deal with MTU issues that comes from Dual-stack lite's tunnel encapsulation. I think it would be good if TCPM could provide some feedback on this proposal. The relevant document and section: http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00 7.4. MTU Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over IPv6 will reduce the effective MTU of the datagrams. Unfortunately, path MTU discovery is not a reliable method to deal with this. As such a combination of solutions is suggested: o For TCP traffic, let the carrier-grade NAT rewrite the MSS in the first SYN packet to a lower value. o For non-TCP traffic, perform fragmentation and reassembly over the tunnel between the home gateway and the carrier grade NAT. In practice, this means put the IPv4 packet into a large IPv6 packet and fragment/reassemble the IPv6 packet at each endpoint of the tunnel. There is a performance price to pay for this. Fragmentation is not very expensive, but reassembly can be, especially on the carrier-grade NAT that would have to keep track of a lot of flows. However, such a carrier-grade NAT would only have to perform reassembly for large UDP packets sourced by customers, not for large UDP packets received by customers. In other words, streaming video to a customer would not have a significant impact on the performance of the carrier-grade NAT, but will require more work on the home gateway side. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From david.borman@windriver.com Mon Mar 30 08:13:48 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDCD3A6A47 for ; Mon, 30 Mar 2009 08:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMWU903mt4+1 for ; Mon, 30 Mar 2009 08:13:47 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id C7EEF3A6A71 for ; Mon, 30 Mar 2009 08:13:47 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n2UFEjQe013660; Mon, 30 Mar 2009 08:14:45 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 08:14:44 -0700 Received: from [172.25.34.51] ([172.25.34.51]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 08:14:44 -0700 Message-Id: <41C4F87F-2AB5-4EC1-B2FF-BE57C785AF8D@windriver.com> From: David Borman To: Alexander Zimmermann In-Reply-To: <13F895CC-7740-4976-8EDF-7FA473936AC1@nets.rwth-aachen.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 30 Mar 2009 10:14:40 -0500 References: <13F895CC-7740-4976-8EDF-7FA473936AC1@nets.rwth-aachen.de> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 30 Mar 2009 15:14:44.0999 (UTC) FILETIME=[42037970:01C9B14A] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 1323bis Review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 15:13:48 -0000 Thanks! These will be incorporated into the next version of the document. -David On Mar 26, 2009, at 5:32 PM, Alexander Zimmermann wrote: > Hi David, > > here is a patch file for some small errors/misspellings in the > 1323bis-01draft. > > Alex > > <1323bis.patch> > > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22220 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // >