From tcpm-bounces@ietf.org Mon Jan 5 13:11:33 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6983A6809; Mon, 5 Jan 2009 13:11:32 -0800 (PST) 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 D79853A6809 for ; Mon, 5 Jan 2009 13:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_20=-0.74] 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 CWOHjj1pM-Cp for ; Mon, 5 Jan 2009 13:11:31 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 3253C3A67CC for ; Mon, 5 Jan 2009 13:11:31 -0800 (PST) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n05LBF27011516; Mon, 5 Jan 2009 13:11:18 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 922E73745A30; Mon, 5 Jan 2009 16:11:11 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6C37CB13069; Mon, 5 Jan 2009 16:11:09 -0500 (EST) To: Alexander Zimmermann From: Mark Allman In-Reply-To: <69BB101E-E2C2-4367-977A-1354C84F66DA@nets.rwth-aachen.de> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Ramble On MIME-Version: 1.0 Date: Mon, 05 Jan 2009 16:11:08 -0500 Message-Id: <20090105211109.6C37CB13069@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-allman-tcp-early-rexmt-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1261770207==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1261770207== Content-Type: multipart/signed; boundary="--------ma30570-1"; micalg=pgp-sha1; protocol="application/pgp-signature" ----------ma30570-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Alex- > on page 4 of aforementioned draft you introduce the variable "ownd". > According to 2581bis (and also other drafts/RFCs), it seems to me to > better use the variable "FightSize". It's not a big deal, however I > thing it is a little bit more consistent. Thanks for the comment. One reason to not use the same language is that "ownd" is not always exactly the same as FlightSize. When doing byte-based ER it is, however, when doing packet-based ER it is actually a packet count. So, if there are no huge objections I'd prefer to stick with the current language and add a note to the document that ownd is the equivalent of FlightSize in the byte-based case. Reasonable? Thanks! allman ----------ma30570-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAklid2sACgkQWyrrWs4yIs4VpQCfcULlBgVfxqBmlruwLqfGieB/ YWAAn0owcibJGtVoMe/U/VYPXRUDZSqs =ZV9n -----END PGP SIGNATURE----- ----------ma30570-1-- --===============1261770207== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1261770207==-- From tcpm-bounces@ietf.org Fri Jan 9 05:21:14 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480BC3A6936; Fri, 9 Jan 2009 05:21:14 -0800 (PST) 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 9284A3A6936 for ; Fri, 9 Jan 2009 05:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_40=-0.185] 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 hq5zLbdcclZi for ; Fri, 9 Jan 2009 05:21:13 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 01B193A67BD for ; Fri, 9 Jan 2009 05:21:12 -0800 (PST) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n09DKwGL016025 for ; Fri, 9 Jan 2009 05:20:59 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id DF18D3756349 for ; Fri, 9 Jan 2009 08:20:54 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B712DB601BA for ; Fri, 9 Jan 2009 08:20:47 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Cheap Sunglasses MIME-Version: 1.0 Date: Fri, 09 Jan 2009 08:20:47 -0500 Message-Id: <20090109132047.B712DB601BA@lawyers.icir.org> Subject: [tcpm] need some early retransmit input X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0754322508==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0754322508== Content-Type: multipart/signed; boundary="--------ma20269-1"; micalg=pgp-sha1; protocol="application/pgp-signature" ----------ma20269-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- I plan to rev the Early Retransmit draft (draft-ietf-tcpm-early-rexmt-00.txt) soon. My general feeling is that it is in OK shape. We would, however, appreciate some input on the document. Many thanks! allman ----------ma20269-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAklnTy8ACgkQWyrrWs4yIs5nHgCdEp6sqdBMqHnGMLYODuOJH8mj 4wkAoIGB3HOYS+QfS7r4WUEBPsmxqHdH =b/Ri -----END PGP SIGNATURE----- ----------ma20269-1-- --===============0754322508== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0754322508==-- From tcpm-bounces@ietf.org Tue Jan 13 15:18:34 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C062A3A6A71; Tue, 13 Jan 2009 15:18:34 -0800 (PST) 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 DD0C13A6A71 for ; Tue, 13 Jan 2009 15:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.651 X-Spam-Level: * X-Spam-Status: No, score=1.651 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 jbkPBA11+8IE for ; Tue, 13 Jan 2009 15:18:32 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 1D9A43A68F6 for ; Tue, 13 Jan 2009 15:18:30 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA248588591; Wed, 14 Jan 2009 00:16:31 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA17717; Wed, 14 Jan 2009 00:16:30 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200901132316.AAA17717@TR-Sys.de> To: tcpm@ietf.org Date: Wed, 14 Jan 2009 00:16:29 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: [tcpm] draft-gont-tcpm-tcp-timestamps-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, I have reviewed the I-D, draft-gont-tcpm-tcp-timestamps-00, which has been submitted to the WG for consideration. The basic idea in the draft seems to be so logical and such an immediate step forward in the spirit of RFC 1122 that, if the TCP timestamps option already had been defined during the development of RFC 1122, I suspect that it readily would have been incorporated and recommended therein! Besides a small couple of textual flaws and improvement requests I already have communicated off-list to the author, there seems to be a double oversight in the second part of the algorithm in section 3: a) There's no "Otherwise, ..." clause. Fix: Copy the sibling clause literally from the end of the first part of the algorithm to the end of the second part! b) The following (potentially rare) corner case, in which it would have been possible according to the rules in RFC 1122 to establish a new connection notwithstanding a previous incarnation in the TIME-WAIT state, has not been considered: - old connection didn't use TSO, - new SYN segment with TSO, - local policy / socket options would lead to SYN-ACK without TSO, - new incoming Sequence Number > last corresponding old SN Including this case into the second alternative of the second part of the algorithm would therefore further improve the benefit of the algorithm. It might be preferable to make the answer to the question 'would the new connection be using timestamps?' the primary criterion for distinguishing between the first and the second alternative in the second part of the algorithm. Doing so would allow to simplify the text otherwise necessary to describe the preconditions in the second alternative. I have submitted ot the author some possible text variants to accommodate these considerations and discussed their mutual benefit. For the sake of brevity, I have omitted the details here, shortly ahead of a promised update to the draft. Best 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 From tcpm-bounces@ietf.org Tue Jan 13 23:50:52 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38CA228C1AF; Tue, 13 Jan 2009 23:50:52 -0800 (PST) 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 8C5FE28C1A5 for ; Tue, 13 Jan 2009 23:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 p6at03bA9zTO for ; Tue, 13 Jan 2009 23:50:44 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 596D028C1A2 for ; Tue, 13 Jan 2009 23:50:42 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so482889wfd.31 for ; Tue, 13 Jan 2009 23:50:27 -0800 (PST) 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=3+Zs+F/158pN5QEPS+eRicoO4TBr46emci+BZl5PJlA=; b=LpqMvhjjXT276rmTrVmZDV+d8qG+e2xB0+aUNq0+Kgb+e7U4Ppe3EoorR4jal3McXY smeCbDriiY44aeXbo23CBGe94kpb07RuVUY8cDHXKNOu4Dakoxc5Myd1MYqBHK3IPdra GSCEGUF2CsSuZHtLiT+iaB/KXrCswFjBe0sjs= 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=mH2md771HpVmJWGeDeHExD0lGjKzwjINfwjFZz8gjsyjK6rN1lCy6leMgdU5ocjPWZ lN1NjCzHENYbq+SQt2ZBRc2BZsXtdFy7UR2f0mEGGQrQh3Sn9PsKJedDtULYwS4JehrZ 5nfAtjKQhFS9uPvJ3Ccx1sqCnzeug5olsS9aM= Received: by 10.143.16.9 with SMTP id t9mr13263978wfi.329.1231919427482; Tue, 13 Jan 2009 23:50:27 -0800 (PST) Received: from Gregory-T60.gmail.com (c-71-202-141-8.hsd1.ca.comcast.net [71.202.141.8]) by mx.google.com with ESMTPS id 24sm17166443wfc.42.2009.01.13.23.50.22 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Jan 2009 23:50:25 -0800 (PST) Message-ID: <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Jan 2009 23:50:18 -0800 To: Joe Touch From: "Gregory M. Lebovitz" In-Reply-To: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> Mime-Version: 1.0 Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: multipart/mixed; boundary="===============1437275397==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1437275397== Content-Type: multipart/alternative; boundary="=====================_54915156==.ALT" --=====================_54915156==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Folks, resend... Neither I nor Joe have received ANY feedback on this New_Key process. Can people pls do a quick review and reply to me, Joe, and list with comments? Joe is trying to get a next version out. Many thanks, Gregory. At 01:18 AM 12/19/2008, Gregory M. Lebovitz wrote: >Hey Joe, and all. >Below is pasted my first crack at the text for the New_Key Process. >All input welcome. >Gregory > >==New_Key Process: > >[Suggest you place text about new_key at the end of section 6 in -02] > >One big difference between TCP-AO and TCP MD5 is that TCP-AO allows >for the change of a TSAD entry -- and thus the corresponding change >of a conn_key -- during a connection, without having to drop the >connection. This allows for an HMAC algorithm or TSAD_key change >without a connection loss. This behavior is very beneficial for the >optimal operation of applications with long lived connections, such >as BGP. The process of moving from one key to another is called "New_Key". > >X.1 New_Key Design Goals >The following are the design goals of the New_Key process: > > - Both sides will move to the new TSAD entry as fast as possible, > assuming both peers are configured with the new TSAD entry at > (almost) the same time. This provides the security benefit of being > able to move immediately off a key believed to be compromised to a > newly defined key. > > - Support a potentially long time lag between when each peer is > configured with the new TSAD entry. This time could be as long as > two or three weeks, depending on maintenance processes and change > windows for both sides. > > - Impact the operation and performance of the application using > TCP as little as possible. Cause zero, or very little, application > data loss or delay. > > - Modify the TCP stack itself as little as possible. > > - Ensure that neither side transitions completely to the new TSAD > entry prematurely, before the other peer has the new TSAD entry and > is ready to use the new TSAD entry. > > - Ensure that neither side erases an old TSAD entry prematurely. > Implementations will hold both the old and new TSAD entries in > memory long enough to employ the new TSAD entry as soon as > possible, while still being able to properly process any straggler, > out-of-order segments that might arrive having been processed with > the old TSAD entry, even after the new TSAD entry is already in use > by both sides. > > - Avoid moving to the use of a new TSAD entry prematurely, > i.e. before the other peer is prepared to use the new TSAD entry. > > >X.2 Use Cases Supported >There are two main cases that New_Key must address. The first is the >case where a new TSAD entry (KeyID, MAC type, key length, TSAD_key; >see section 6) is configured onto both peers during a connection's >life. The TSAD entry may have arrived into the peers' states either >by manual configuration, or by some automated key management >exchange. Regardless the method, a new TSAD entry is installed into >each peers' respective state while the previous TSAD entry is already in use. > >[NOTE: There is an assumption being made here that at some point in >the future, when a key management protocol has been defined for >TCP-AO, that mechanism will leverage the conn_key derivation >mechanism described here in TCP-AO. This means that instead of >negotiating ISN's and conn_keys directly, the key management >protocol will simply negotiate a TSAD entry, and TCP-AO will use >that TSAD entry according to this specification to derive its conn_keys.] > >The second use case involves a chain of pre-configured TSAD entries. >In this case, the two sides choose and exchange out-of-band a series >of TSAD entries to be used over time. Each TSAD entry will also have >the time at which the key will begin to be actually used to >authenticate segments, and how long the key is to be used. This >information is all exchanged out-of-band, and then configured into >each device respectively. The chains may be quite long, like 64 or >128 entries. The TSAD entries, the order of use, and start times, >must all match on both sides. The TSAD entries are then used in >sequential order. In this use case, the new TSAD entry is known on >both sides well ahead of the actual New_Key event. The key chain >mechanism provides a way to limit the lifetime of a particular key's >use on the wire. Limiting a key's lifetime protects against a >successful brute force guessing attack. The idea is that the >connection has already moved on to a new TSAD entry by the time the >attacker, who has been working offline to guess the key, succeeds. >Key chains do not protect against the termination of an employee who >had access to the TSAD entries. In such a case, the entire key chain >is assumed to be compromised, and a whole new key chain SHOULD be >put into use. The concept of key chains, their benefits and >limitations are discussed more thoroughly in the Security >Considerations section. > > >X.2 New_Key State Machine > >There are three states in the New_Key state machine: SINGLE-TSAD, >PROBING, and TSAD-OVERLAP. The states are shown below in Figure X. > >X.2.1 SINGLE-TSAD > >The SINGLE-TSAD state is the beginning and ending state of the >New_Key process. It is the state in which there is one and only one >TSAD entry actively in use for both sending and receiving segments. >When a new TCP connection using TCP-AO first begins, the New_Key >process is initialized to the SINGLE-TSAD state. > >For the purpose of this explanation, the starting TSAD used in >SINGLE-TSAD state will be called "TSAD-X". The new TSAD entry >activated will be referred to as TSAD-Y. > > From SINGLE-TSAD it is only possible to move to PROBING state. The > move from SINGLE-TSAD to PROBING occurs when a new TSAD entry, > TSAD-Y, becomes active. According to the use cases described above, > a TSAD-Y becomes active when one of the following events occurs: > > o It is manually entered and activated on the device for an > existing connection > o It is received into state as a result of a key management > protocol negotiation > o It is the next TSAD entry in a chain, and it's start time > equals the current > time > >It is most common to transition into SINGLE-TSAD state from either a >new connection initialization, or from the TSAD-OVERLAP state (as >described in section X.2.3). There also exists one condition under >which the state may transition to SINGLE-TSAD from PROBING. This is >described at the end of section X.2.2 PROBING. > > > +---------------+ > | | > | SINGLE-TSAD | > | | > +------/*-------+ > // \\ > New TSAD-Y // \\ > Entry Activated // \\ Deactivate > // \\ previous TSAD-X > // \\ entry > // \\ > // \\ > +-----//-----+ +----\-----------+ > | | | | > | PROBING +-------------------+ TSAD-OVERLAP | > | | | | > +------------+ +----------------+ > Receive Packet > Processed with > TSAD-Y entry > > > Figure X. > New_Key State Machine > > >X.2.2 PROBING > >The PROBING state is the second state. The goal of the PROBING state >is for a host A, "Alice", to signal to its peer, host B, "Bob", that >Alice has TSAD-Y installed and active, and is ready to use it. If >Bob does not have TSAD-Y then any segments sent by Alice with >TSAD-Y's KeyID will be discarded. Discarded segments may cause >retransmission and delays in the application processing. So Alice >wants to avoid sending application data with TSAD-Y before she is >certain Bob has TSAD-Y. Once Alice has TSAD-Y activated she cannot >yet be certain that Bob also has TSAD-Y installed and activated for >the following reasons: > > o Bob's administrator may not have gotten around to installing TSAD-Y yet > o If using a key chain, the clocks on the two devices may be out > of sync such > that start time for Alice is not the same absolute time as > start time for Bob > >Therefore, Alice will send a probe segment, processed using the >TSAD-Y, to signal to Bob that she is ready to begin using TSAD-Y. >She will repeat this probe periodically. (The specifics of this >probing mechanism are described below in Section X.3.) Before Bob >has TSAD-Y he will not be able to process these probes, and he will >discard them. > >Once Bob has installed and activated TSAD-Y, Bob will himself >transition from SINGLE-TSAD to PROBING state. Bob will then send a >probe processed with TSAD-Y to Alice. Further, Bob will be able to >successfully process Alice's next probe sent using TSAD-Y. > >Once Alice has successfully received and processed a segment from >Bob that was sent using TSAD-Y, she transitions immediately to >TSAD-OVERLAP state. The time spent in PROBING state may be very >short, especially if Bob has already activated TSAD-Y and has just >sent a probe. Alice may not have even sent a probe yet. That's okay. >Once Alice successfully processes a segment from Bob using TSAD-Y >she knows (a) that she has the correct TSAD-Y, that (b) Bob has the >correct TSAD-Y, and (c) they are both prepared to begin sending and >receiving all following segments with TSAD-Y. > >It is only possible to move into PROBING from the SINGLE-TSAD state, >as described above in X.2.1. PROBING is distinct from SINGLE-TSAD in >that now there exists a second active TSAD, TSAD-Y, along with >TSAD-X. In PROBING, only probe segments are sent using TSAD-Y. All >other segments are sent using TSAD-X. Most segments received will be >processed using TSAD-X. Once the first received segment is >successfully processed using TSAD-Y, the state transitions to TSAD-OVERLAP. > >TSAD-OVERLAP is the most probable state that will be entered when >exiting PROBING. > >However, under one unlikely condition the state will transition from >PROBING to SINGLE-TSAD. In the case where: > > o a life-time has been configured for TSAD-X, AND, > o that life-time expires while in PROBING state, AND, > o TSAD-Y is still active, AND, > o no other TSAD has yet been activated, THEN, > o the only active TSAD remaining is TSAD-Y. > >Even though Alice has not yet successfully received TSAD-Y segments >from Bob, if a life-time is exceeded, the expired TSAD MUST be >de-activated in order to follow the configured security policy. This >would force the state back to SINGLE-TSAD state, with TSAD-Y being >the only activated TSAD entry. This condition -- where TSAD-X >expired before segments were received processed by TSAD-Y -- SHOULD >be logged, and the administrator alerted. Assuming the security >policy mandates the use of TCP-AO on this connection, segments MUST >be sent processed with TSAD-Y. Received segments MAY continue to be >processed with TSAD-X. However, if Bob does not activate TSAD-Y, >then the TCP connection will soon timeout, because Bob will discard >the TSAD-Y processed segments he receives. > >X.2.3 TSAD-OVERLAP > >The TSAD-OVERLAP state is the third state. Like PROBING, both the >old TSAD-X and the new TSAD-Y are both activated. The main >distinction between PROBING and TSAD-OVERLAP is that in TSAD-OVERLAP >the new TSAD, TSAD-Y, is the only one used for sending all segments. >In this state, TSAD-X is used only for processing received segments >that may arrive with TSAD-X's KeyID. Such straggler segments may >arrive because they were sent out onto the wire before the >transition from PROBING to TSAD-OVERLAP occurred, and are just now arriving. > >Once the state transitions to TSAD-OVERLAP, a counter is initialized >to 512. The counter decrements once per second, so TSAD-X will >overlap TSAD-Y for just under nine minutes. Upon reaching zero, the >prior TSAD, TSAD-X is de-activated. At this point the entire TSAD-X >entry, including its conn_keys, MAY be deleted from state. The >TSAD-OVERLAP counter MAY be configurable on various implementations. > >[Author's Thought: I have no idea if this is the best way to do this >timer. I chose seconds because that is how TCP does it's exponential >back-off timer for retransmission, the max of which is ~9 minutes, >from what I read in Stevens, Ch 21. TCP gurus are welcome to refine >the overlap timer mechanism based on practical experience] > >Once TSAD-X is deactivated, the state transitions to SINGLE-TSAD. At >this point, TSAD-Y is the one and only active TSAD entry for both >sending and receiving segments. > > >X.3 Probe Mechanism > >This section specifies the probe mechanism used in PROBING state >(section X.2.2). > >The probe is a single TCP segment sent with: > > o the TCP-AO option using TSAD-Y, AND > o any other tcp options present (per section 3.2, point 4), AND > o with no TCP data, AND > o marked with a sequence number unmistakably smaller than the currently > appropriate sequence number. Precisely, where the current > sequence number that would otherwise be used is "S", and the probe > segment's sequence number is "P", P is 1024 less than S, or > > P = S - 1024 > > [Question 1: TCP guru's, is 1024 the best number?] > > [Question 2: given the empty TCP data, will we need to add > padding here to meet the minimum 64 byte IP packet size?] > >The probe is crafted so that no real application data will be lost >if the probe fails. This protects the performance of the application >being authenticated in TCP. The probe is transmitted with an old, >stale sequence number so that if the receiver, Bob, is unable to >process the probe, and discards it, there will be no perceived skip >in the proper sequence flow, and no retransmission required. > >Alice starts a standard exponential back-off timer for transmitting >the next probe(s). If no segment has been received with TSAD-Y, then >the next probe is sent 1.5 seconds later. After this the timeout >value is doubled for each following probe, with an upper limit of 64 >seconds; i.e. at 3, 6, 12, 24, 48, 64, 64, 64, etc. seconds apart. >If at any point a segment is received that was crafted using TSAD-Y, >then the timer is terminated, and state is transitioned to TSAD-OVERLAP. > >Bob receives the probe segment, and responds in one of two ways. > > (1) IF Bob has NOT activated TSAD-Y, THEN > > Bob will not recognize the KeyID in the probe segment, and > will silently discard the segment. Since the segment has a stale > sequence number, absolutely no interruption occurs to the application flow. > > (2) IF Bob HAS activated TSAD-Y, THEN > > Bob will recognize the KeyID in the probe, and process the > segment using TSAD-Y. Assume this is the first segment received > with TSAD-Y; when the authentication verification processes > correctly Bob will state transition to TSAD-OVERLAP state. > Henceforth Bob will transmit all segments using only TSAD-Y. Bob's > TCP stack then parses the segment and reads the stale sequence > number. TCP responds naturally with an ACK. That ACK will naturally > contain the sequence number of the last received data segment prior > to the segment with the stale sequence number, the probe. That ACK > is processed using TSAD-Y, and transmitted. Thus, zero interruption > to the normal application flow occurs as a result of the probe segment. > >Once Alice receives either (a) a TSAD-Y processed ACK to her probe, >or (b) a TSAD-Y processed probe from Bob, she transitions to TSAD-OVERLAP. > > >+++++++++++++++++++++++ >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 --=====================_54915156==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks,
resend...

Neither I nor Joe have received ANY feedback on this New_Key process. Can people pls do a quick review and reply to me, Joe, and list with comments? Joe is trying to get a next version out.

Many thanks,
Gregory.

At 01:18 AM 12/19/2008, Gregory M. Lebovitz wrote:
Hey Joe, and all.
Below is pasted my first crack at the text for the New_Key Process. All input welcome.
Gregory

=3D=3DNew_Key Process:

[Suggest you place text about new_key at the end of section 6 in -02]

One big difference between TCP-AO and TCP MD5 is that TCP-AO allows for the change of a TSAD entry -- and thus the corresponding change of a conn_key -- during a connection, without having to drop the connection. This allows for an HMAC algorithm or TSAD_key change without a connection loss. This behavior is very beneficial for the optimal operation of applications with long lived connections, such as BGP. The process of moving from one key to another is called "New_Key".

X.1  New_Key Design Goals
The following are the design goals of the New_Key process:

 - Both sides will move to the new TSAD entry as fast as possible, assuming both peers are configured with the new TSAD entry at (almost) the same time. This provides the security benefit of being able to move immediately off a key believed to be compromised to a newly defined key.
 
 - Support a potentially long time lag between when each peer is configured with the new TSAD entry. This time could be as long as two or three weeks, depending on maintenance processes and change windows for both sides.
 
 - Impact the operation and performance of the application using TCP as little as possible. Cause zero, or very little, application data loss or delay.
 
 - Modify the TCP stack itself as little as possible.
 
 - Ensure that neither side transitions completely to the new TSAD entry prematurely, before the other peer has the new TSAD entry and is ready to use the new TSAD entry.
 
 - Ensure that neither side erases an old TSAD entry prematurely. Implementations will hold both the old and new TSAD entries in memory long enough to employ the new TSAD entry as soon as possible, while still being able to properly process any straggler, out-of-order segments that might arrive having been processed with the old TSAD entry, even after the new TSAD entry is already in use by both sides.
 
 - Avoid moving to the use of a new TSAD entry prematurely, i.e.  before the other peer is prepared to use the new TSAD entry.
 

X.2 Use Cases Supported
There are two main cases that New_Key must address. The first is the case where a new TSAD entry (KeyID, MAC type, key length, TSAD_key; see section 6) is configured onto both peers during a connection's life. The TSAD entry may have arrived into the peers' states either by manual configuration, or by some automated key management exchange. Regardless the method, a new TSAD entry is installed into each peers' respective state while the previous TSAD entry is already in use.

[NOTE:  There is an assumption being made here that at some point in the future, when a key management protocol has been defined for TCP-AO, that mechanism will leverage the conn_key derivation mechanism described here in TCP-AO. This means that instead of negotiating ISN's and conn_keys directly, the key management protocol will simply negotiate a TSAD entry, and TCP-AO will use that TSAD entry according to this specification to derive its conn_keys.]

The second use case involves a chain of pre-configured TSAD entries. In this case, the two sides choose and exchange out-of-band a series of TSAD entries to be used over time. Each TSAD entry will also have the time at which the key will begin to be actually used to authenticate segments, and how long the key is to be used. This information is all exchanged out-of-band, and then configured into each device respectively. The chains may be quite long, like 64 or 128 entries. The TSAD entries, the order of use, and start times, must all match on both sides. The TSAD entries are then used in sequential order. In this use case, the new TSAD entry is known on both sides well ahead of the actual New_Key event. The key chain mechanism provides a way to limit the lifetime of a particular key's use on the wire. Limiting a key's lifetime protects against a successful brute force guessing attack. The idea is that the connection has already moved on to a new TSAD entry by the time the attacker, who has been working offline to guess the key, succeeds. Key chains do not protect against the termination of an employee who had access to the TSAD entries. In such a case, the entire key chain is assumed to be compromised, and a whole new key chain SHOULD be put into use. The concept of key chains, their benefits and limitations are discussed more thoroughly in the Security Considerations section.


X.2 New_Key State Machine

There are three states in the New_Key state machine: SINGLE-TSAD, PROBING, and TSAD-OVERLAP. The states are shown below in Figure X.

X.2.1 SINGLE-TSAD

The SINGLE-TSAD state is the beginning and ending state of the New_Key process. It is the state in which there is one and only one TSAD entry actively in use for both sending and receiving segments. When a new TCP connection using TCP-AO first begins, the New_Key process is initialized to the SINGLE-TSAD state.

For the purpose of this explanation, the starting TSAD used in SINGLE-TSAD state will be called "TSAD-X". The new TSAD entry activated will be referred to as TSAD-Y.

From SINGLE-TSAD it is only possible to move to PROBING state. The move from SINGLE-TSAD to PROBING occurs when a new TSAD entry, TSAD-Y, becomes active. According to the use cases described above, a TSAD-Y becomes active when one of the following events occurs:

  o  It is manually entered and activated on the device for an existing connection
  o  It is received into state as a result of a key management protocol negotiation
  o  It is the next TSAD entry in a chain, and it's start time equals the current
     time

It is most common to transition into SINGLE-TSAD state from either a new connection initialization, or from the TSAD-OVERLAP state (as described in section X.2.3). There also exists one condition under which the state may transition to SINGLE-TSAD from PROBING. This is described at the end of section X.2.2 PROBING.


            &nbs= p;       +---------------+
            &nbs= p;       |            &nb= sp;  |
            &nbs= p;       |  SINGLE-TSAD  |
            &nbs= p;       |            &nb= sp;  |
            &nbs= p;       +------/*-------+
            &nbs= p;            //  \\
     New TSAD-Y          //      \\
    Entry Activated  //          \\      Deactivate
            &nbs= p;      //            &n= bsp; \\    previous TSAD-X
            &nbs= p;    //            &n= bsp;     \\  entry
            &nbs= p;  //            &n= bsp;         \\
             //            &n= bsp;             \\
     +-----//-----+          &n= bsp;        +----\-----------+
     |            |            &nb= sp;      |            &nb= sp;   |
     |  PROBING   +-------------------+  TSAD-OVERLAP  |
     |            |            &nb= sp;      |            &nb= sp;   |
     +------------+          &n= bsp;        +----------------+
            &nbs= p;         Receive Packet
            &nbs= p;        Processed with
            &nbs= p;         TSAD-Y entry


            &nbs= p;         Figure X.
            &nbs= p;         New_Key State Machine


X.2.2 PROBING

The PROBING state is the second state. The goal of the PROBING state is for a host A, "Alice", to signal to its peer, host B, "Bob", that Alice has TSAD-Y installed and active, and is ready to use it. If Bob does not have TSAD-Y then any segments sent by Alice with TSAD-Y's KeyID will be discarded. Discarded segments may cause retransmission and delays in the application processing. So Alice wants to avoid sending application data with TSAD-Y before she is certain Bob has TSAD-Y. Once Alice has TSAD-Y activated she cannot yet be certain that Bob also has TSAD-Y installed and activated for the following reasons:

  o  Bob's administrator may not have gotten around to installing TSAD-Y yet
  o  If using a key chain, the clocks on the two devices may be out of sync such
     that start time for Alice is not the same absolute time as start time for Bob

Therefore, Alice will send a probe segment, processed using the TSAD-Y, to signal to Bob that she is ready to begin using TSAD-Y. She will repeat this probe periodically. (The specifics of this probing mechanism are described below in Section X.3.) Before Bob has TSAD-Y he will not be able to process these probes, and he will discard them.

Once Bob has installed and activated TSAD-Y, Bob will himself transition from SINGLE-TSAD to PROBING state. Bob will then send a probe processed with TSAD-Y to Alice. Further, Bob will be able to successfully process Alice's next probe sent using TSAD-Y.

Once Alice has successfully received and processed a segment from Bob that was sent using TSAD-Y, she transitions immediately to TSAD-OVERLAP state. The time spent in PROBING state may be very short, especially if Bob has already activated TSAD-Y and has just sent a probe. Alice may not have even sent a probe yet. That's okay. Once Alice successfully processes a segment from Bob using TSAD-Y she knows (a) that she has the correct TSAD-Y, that (b) Bob has the correct TSAD-Y, and (c) they are both prepared to begin sending and receiving all following segments with TSAD-Y.

It is only possible to move into PROBING from the SINGLE-TSAD state, as described above in X.2.1. PROBING is distinct from SINGLE-TSAD in that now there exists a second active TSAD, TSAD-Y, along with TSAD-X. In PROBING, only probe segments are sent using TSAD-Y. All other segments are sent using TSAD-X. Most segments received will be processed using TSAD-X. Once the first received segment is successfully processed using TSAD-Y, the state transitions to TSAD-OVERLAP.

TSAD-OVERLAP is the most probable state that will be entered when exiting PROBING.

However, under one unlikely condition the state will transition from PROBING to SINGLE-TSAD. In the case where:

  o  a life-time has been configured for TSAD-X, AND,
  o  that life-time expires while in PROBING state, AND,
  o  TSAD-Y is still active, AND,
  o  no other TSAD has yet been activated, THEN,
  o  the only active TSAD remaining is TSAD-Y.
 
Even though Alice has not yet successfully received TSAD-Y segments from Bob, if a life-time is exceeded, the expired TSAD MUST be de-activated in order to follow the configured security policy. This would force the state back to SINGLE-TSAD state, with TSAD-Y being the only activated TSAD entry. This condition -- where TSAD-X expired before segments were received processed by TSAD-Y -- SHOULD be logged, and the administrator alerted. Assuming the security policy mandates the use of TCP-AO on this connection, segments MUST be sent processed with TSAD-Y. Received segments MAY continue to be processed with TSAD-X. However, if Bob does not activate TSAD-Y, then the TCP connection will soon timeout, because Bob will discard the TSAD-Y processed segments he receives.

X.2.3 TSAD-OVERLAP

The TSAD-OVERLAP state is the third state. Like PROBING, both the old TSAD-X and the new TSAD-Y are both activated. The main distinction between PROBING and TSAD-OVERLAP is that in TSAD-OVERLAP the new TSAD, TSAD-Y, is the only one used for sending all segments. In this state, TSAD-X is used only for processing received segments that may arrive with TSAD-X's KeyID. Such straggler segments may arrive because they were sent out onto the wire before the transition from PROBING to TSAD-OVERLAP occurred, and are just now arriving.

Once the state transitions to TSAD-OVERLAP, a counter is initialized to 512. The counter decrements once per second, so TSAD-X will overlap TSAD-Y for just under nine minutes. Upon reaching zero, the prior TSAD, TSAD-X is de-activated. At this point the entire TSAD-X entry, including its conn_keys, MAY be deleted from state. The TSAD-OVERLAP counter MAY be configurable on various implementations.

[Author's Thought: I have no idea if this is the best way to do this timer. I chose seconds because that is how TCP does it's exponential back-off timer for retransmission, the max of which is ~9 minutes, from what I read in Stevens, Ch 21.  TCP gurus are welcome to refine the overlap timer mechanism based on practical experience]

Once TSAD-X is deactivated, the state transitions to SINGLE-TSAD. At this point, TSAD-Y is the one and only active TSAD entry for both sending and receiving segments.

            &nbs= p;      
X.3 Probe Mechanism

This section specifies the probe mechanism used in PROBING state (section X.2.2).

The probe is a single TCP segment sent with:

  o  the TCP-AO option using TSAD-Y, AND
  o  any other tcp options present (per section 3.2, point 4), AND
  o  with no TCP data, AND
  o  marked with a sequence number unmistakably smaller than the currently
     appropriate sequence number. Precisely, where the current sequence number that would otherwise be used is "S", and the probe segment's sequence number is "P", P is 1024 less than S, or

          P =3D S - 1024
         
  [Question 1: TCP guru's, is 1024 the best number?]
 
  [Question 2: given the empty TCP data, will we need to add padding here to meet the minimum 64 byte IP packet size?]

The probe is crafted so that no real application data will be lost if the probe fails. This protects the performance of the application being authenticated in TCP. The probe is transmitted with an old, stale sequence number so that if the receiver, Bob, is unable to process the probe, and discards it, there will be no perceived skip in the proper sequence flow, and no retransmission required.

Alice starts a standard exponential back-off timer for transmitting the next probe(s). If no segment has been received with TSAD-Y, then the next probe is sent 1.5 seconds later. After this the timeout value is doubled for each following probe, with an upper limit of 64 seconds; i.e. at 3, 6, 12, 24, 48, 64, 64, 64, etc. seconds apart. If at any point a segment is received that was crafted using TSAD-Y, then the timer is terminated, and state is transitioned to TSAD-OVERLAP.

Bob receives the probe segment, and responds in one of two ways.

  (1)  IF Bob has NOT activated TSAD-Y, THEN
 
       Bob will not recognize the KeyID in the probe segment, and will silently discard the segment. Since the segment has a stale sequence number, absolutely no interruption occurs to the application flow.
 
  (2)  IF Bob HAS activated TSAD-Y, THEN
 
       Bob will recognize the KeyID in the probe, and process the segment using TSAD-Y. Assume this is the first segment received with TSAD-Y; when the authentication verification processes correctly Bob will state transition to TSAD-OVERLAP state. Henceforth Bob will transmit all segments using only TSAD-Y. Bob's TCP stack then parses the segment and reads the stale sequence number. TCP responds naturally with an ACK. That ACK will naturally contain the sequence number of the last received data segment prior to the segment with the stale sequence number, the probe. That ACK is processed using TSAD-Y, and transmitted. Thus, zero interruption to the normal application flow occurs as a result of the probe segment.
      
Once Alice receives either (a) a TSAD-Y processed ACK to her probe, or (b) a TSAD-Y processed probe from Bob, she transitions to TSAD-OVERLAP.
      

+++++++++++++++++++++++
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
--=====================_54915156==.ALT-- --===============1437275397== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1437275397==-- From tcpm-bounces@ietf.org Wed Jan 14 10:30:02 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4218D3A6A15; Wed, 14 Jan 2009 10:30:02 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5A7593A69C2; Wed, 14 Jan 2009 10: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: <20090114183001.5A7593A69C2@core3.amsl.com> Date: Wed, 14 Jan 2009 10:30:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-early-rexmt-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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --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 : Early Retransmit for TCP and SCTP Author(s) : M. Allman, K. Avrachenkov, U. Ayesta, E. Blanton, P. Hurtig Filename : draft-ietf-tcpm-early-rexmt-01.txt Pages : 11 Date : 2009-1-14 This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover packet losses that would otherwise require a lengthy retransmission timeout. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-early-rexmt-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-early-rexmt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-1-14102338.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Wed Jan 14 13:32:59 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272073A6AAF; Wed, 14 Jan 2009 13:32:59 -0800 (PST) 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 8965D3A6822 for ; Wed, 14 Jan 2009 13:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, 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 Hlzx0Ah86gFs for ; Wed, 14 Jan 2009 13:32:57 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id D773A3A6AAF for ; Wed, 14 Jan 2009 13:32:56 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id E0BF478202 for ; Wed, 14 Jan 2009 15:32:41 -0600 (CST) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n0ELWjDQ023562 for ; Wed, 14 Jan 2009 15:32:45 -0600 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 15:32:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jan 2009 15:31:41 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem Thread-Index: Acl2ZHSJtO1XKW5KRc2nR1nIPUZBFAAKtb+w From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 14 Jan 2009 21:32:41.0546 (UTC) FILETIME=[A14EB2A0:01C9768F] Subject: [tcpm] FW: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org FYI - for document authors who aren't following the IETF discussion list, please be aware of the note below. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- >-----Original Message----- >From: wgchairs-bounces@ietf.org >[mailto:wgchairs-bounces@ietf.org] On Behalf Of Russ Housley >Sent: Wednesday, January 14, 2009 11:00 AM >To: wgchairs@ietf.org >Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your >review andcomments on a proposed Work-Around to the Pre-5378 Problem > >WG Chairs: > >Please make sure that your WG, and especially your document authors, >are aware of this situation. Please follow the discussion on the >IETF Discussion list, and keep the WG informed about the way forward >as it develops. > >Thanks, > Russ > > >>From: "Ed Juskevicius" >>To: "'IETF Discussion'" , , >> , , , >> >>Date: Thu, 8 Jan 2009 16:43:50 -0500 >>Cc: 'Trustees' >>Subject: [Trustees] ANNOUNCEMENT: The IETF Trustees invite >your review and >> comments on a proposed Work-Around to the Pre-5378 Problem >> >>The purpose of this message is twofold: >> >>1) To summarize the issues that some members of our community >> have experienced since the publication of RFC 5378 in >November 2008, >> and >>2) To invite community review and discussion on a potential >work-around >> being considered by the IETF Trustees. >> >>Some I-D authors are having difficulty implementing RFC 5378. An >>example of the difficulty is as follows: >> >> - an author wants to include pre-5378 content in a new submission >> or contribution to the IETF, but >> - s/he is not certain that all of the author(s) of the earlier >> material have agreed to license it to the IETF Trust according >> to RFC 5378. >> >>If an I-D author includes pre-5378 material in a new >document, then s/he >>must represent or warrant that all of the authors who created the >>pre-5378 material have granted rights for that material to >the IETF Trust. >>If s/he cannot make this assertion, then s/he has a problem. >> >>This situation has halted the progression of some Internet-Drafts and >>interrupted the publication of some RFCs. The Trustees of >the IETF Trust >>are investigating ways to implement a temporary work-around >so that IETF >>work can continue to progress. A permanent solution to this "pre-5378 >>problem" may require an update to RFC 5378, for example new >work by the >>community to create a 5378-bis document. >> >>The remainder of this message provides an outline of the >temporary work- >>around being considered by the Trustees. >> >>RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the >>authority to develop legend text for authors to use in >situations where >>they wish to limit the granting of rights to modify and prepare >>derivatives of the documents they submit. The Trustees used this >>authority in 2008 to develop and adopt the current "Legal Provisions >>Relating to IETF Documents" which are posted at: >>http://trustee.ietf.org/license-info/. >> >>The Trustees are now considering the creation of optional new >legend text >>which could be used by authors experiencing the "pre-5378 problem". >> >>The new legend text, if implemented, would do the following: >> >> a. Provide Authors and Contributors with a way to identify (to the >> IETF Trust) that their contributions contain material >from pre-5378 >> documents for which RFC 5378 rights to modify the >material outside >> the IETF standards process may not have been granted, and >> >> b. Provide the IETF Trust and the community with a clear indication >> of every document containing pre-5378 content and having the >> "pre-5378 problem". >> >>So, how could the creation and use of some new legend text help people >>work-around the pre-5378 problem? >> >>The proposed answer is as follows: >> >> 1. Anyone having a contribution with the "pre-5378" >problem should add >> new legend text to the contribution, to clearly flag >that it includes >> pre-5378 material for which all of the rights needed >under RFC 5378 >> may not have been granted, and >> >> 2. The IETF Trust will consider authors and contributors (with the >> pre-5378 problem) to have met their RFC 5378 obligations if the >> new legend text appears on their documents, and >> >> 3. Authors and contributors should only resort to adding the new >> legend text to their documents (per #1) if they cannot develop >> certainty that all of the author(s) of pre-5378 material in >> their documents have agreed to license the pre-5378 content to >> the IETF Trust according to RFC 5378. >> >>The proposed wording for the new legend text is now available for your >>review and comments in section 6.c.iii of a draft revision to the >>IETF Trust's "Legal Provisions Relating to IETF Documents" located at >>http://trustee.ietf.org/policyandprocedures.html. >> >>Please note that the above document also contains new text in >section 5.c >>dealing with "License Limitations". >> >>If your review and feedback on this proposed work-around is positive, >>then the new text may be adopted by the Trustees in early >February 2009, >>and then be published as an official revision to the Legal Provisions >>document. If so adopted, Internet-Drafts with pre-5378 material may >>advance within the Internet standards process and get >published as RFCs >>where otherwise qualified to do so. Unless covered by >sections 6.c.i or >>6.c.ii, authors of documents in which there is no pre-5378 >>material must provide a RFC 5378 license with no limitation on >>modifications outside the IETF standards process. >> >>The IETF Trust will not grant the right to modify or prepare >derivative >>works of any specific RFC or other IETF Contribution outside the IETF >>standards process until RFC 5378 rights pertaining to that >document have >>been obtained from all authors and after compliance by the IETF Trust >>with RFC 5377. The Trustees will establish one or more mechanisms by >>which authors of pre-5378 documents may grant RFC 5378 rights. >> >>The Trustees hereby invite your review, comments and >suggestions on this >>proposed work-around to the "pre-5378 problem". The period >for this review >>is 30 days. Microsoft WORD and PDF versions of the proposed >revisions are >>attached to this message. Copies are also available on the IETF Trust >>website under the heading "DRAFT Policy and Procedures Being >Developed" at: >>http://trustee.ietf.org/policyandprocedures.html >> >>All feedback submitted before the end of February 7th will be >considered by >>the Trustees. A decision on whether to move forward with >this proposal will >>be made and communicated to you before the end of February 15th. >> >>Please give this your attention. >> >>Regards and Happy New Year ! >> >>Ed Juskevicius, on behalf of the IETF Trustees >>edj.etc@gmail.com > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 15 02:30:41 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E333A685D; Thu, 15 Jan 2009 02:30:41 -0800 (PST) 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 BE95D3A685D for ; Thu, 15 Jan 2009 02:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.638 X-Spam-Level: * X-Spam-Status: No, score=1.638 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 yetZh5odHxGD for ; Thu, 15 Jan 2009 02:30:40 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 0BA8D3A67E6 for ; Thu, 15 Jan 2009 02:30:38 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA256795322; Thu, 15 Jan 2009 11:28:42 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA20246; Thu, 15 Jan 2009 11:28:37 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200901151028.LAA20246@TR-Sys.de> To: tcpm@ietf.org Date: Thu, 15 Jan 2009 11:28:36 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: Re: [tcpm] FW: ANNOUNCEMENT: The IETF Trustees invite your review and comments ... 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: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Rm9sa3MsCkZZSSwgdGhlIG9yaWdpbmFsIElFVEYgVHJ1c3QgYW5ub3VuY2VtZW50IHF1b3RlZCBp biBFZGR5J3MgbWVzc2FnZQppcyBhcmNoaXZlZCBhdDoKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2lldGYvY3VycmVudC9tc2c1NDgzOS5odG1sCgpNYXliZSB0aGF0IFVS TCBhbmQgdGhlIGJldHRlciByZWFkYWJsZSBmb3JtIG9mIHRoZSBvcmlnaW5hbAphbm5vdW5jZW1l bnQgYXJlIG9mIGJlbmVmaXQgZm9yIG1hbnkuCgpUaGUgZW5zdWluZyBkaXNjdXNzaW9uIGhhcyBp bnN0YW50YW5lb3VzbHkgc3RhcnRlZCBmbG9vZGluZyB0aGUKSUVURiBtYWluIGxpc3QsIGFuZCBp dCBzZWVtcyBpbnRyYWN0YWJsZSBmb3IgYW55Ym9keSB3YW50aW5nIHRvCnBlcmZvcm0gcHJhY3Rp Y2FsbHkgdXNlZnVsIHdvcmsgdG8gZm9sbG93IGFsbCB0aGF0IG9uZ29pbmcKZGlzY3Vzc2lvbiB0 aHJlYWRzLgoKSXQgbG9va3MgcHJldHR5IGxpa2Ugbm90aGluZyBpcyBmb3Igc3VyZSwgYXQgdGhl IG1vbWVudC4KCkhvd2V2ZXIsIGluIG9yZGVyIHRvIG5vdCBibG9jayBhbG1vc3QgYWxsIElFVEYg YWN0aXZpdGllcywKdGhlIElFVEYgVHJ1c3QgYXBwYXJlbnRseSBpcyB3aWxsaW5nIHRvIGFkbWl0 IGEgbGVzcyBmb3JtYWwKcHJvY2VkdXJlICh3aXRob3V0IHJlcXVpcmluZyBhbGwgcHJlc2VudCBh bmQgcGFzdCBjb250cmlidXRvcnMKc2lnbmluZyBhbmQgZmlsaW5nIGEgZm9ybWFsIGxpY2VuY2Ug YWdyZWVtZW50KSAtLSBhdCBsZWFzdAp0ZW1wb3JhcmlseSwgZm9yIGEgc2hvcnQgdHJhbnNpdCBw ZXJpb2QuCgpJbiBzdXBwb3J0IG9mIHRoaXMsIGFuZCBpbiB0aGUgaG9wZSB0aGF0IGl0IG1pZ2h0 IGFsbGV2aWF0ZQp0aGUgd29yayBvZiBhdXRob3JzIHdoaWNoIGFyZSBpbiB0aGUgcHJvY2VzcyBv ZiB1cGRhdGluZyBkcmFmdHMKYW5kIG1pZ2h0IG90aGVyd2lzZSBiZQotIGVpdGhlciBibG9ja2Vk IGJ5IHRoZSBwZW5kaW5nIGxlZ2FsIGlzc3VlcywKLSBvciBidXJkZW5lZCBieSBoYXZpbmcgdG8g Y29sbGVjdCBmb3JtYWwgY29uc2VudCBvZiBhbGwgSUVURgogIGNvbnRyaWJ1dG9ycyAodG8gcHJl dmlvdXMgd29yaywgcmV2aWV3cywgb24tIG9yIG9mZi1saXN0IGlucHV0CiAgaW50ZW5kZWQgdG8g YmUgcmVnYXJkZWQgYXMgSUVURiBjb250cmlidXRpb24pLAotIG9yIGVsc2UgcnVubmluZyB0aGUg cGVyc29uYWwgcmlzayBvZiBsaXRpZ2F0aW9ucyBieSB0aGlyZCBwYXJ0aWVzCiAgd2FpdGluZyBm b3Igb3Bwb3J0dW5pdGllcyB0byBtYWtlIG1vbmV5IG91dCBvZiBjb25zdHJ1ZWQKICB2aW9sYXRp b25zIG9mIGNvcHlyaWdodCBsYXcsCkkgd291bGQgbGlrZSB0byBmb2xsb3cgYSByZWxhdGVkIHBy ZWNlZGVudCBpbiBhbm90aGVyIFdHIGFuZCBtYWtlCm15IGdyYW50IHB1YmxpYyBvbiB0aGUgbGlz dC4KCiAgICBJIGhlcmVieSBncmFudCB0byB0aGUgSUVURiBUcnVzdCB0aGUgcmlnaHRzIGFjY29y ZGluZyB0bwogICAgUkZDIDUzNzggaW4gbXkgSUVURiBjb250cmlidXRpb25zLCBpbmNsdWRpbmcg aW4gcGFydGljdWxhcgogICAgcGFzdCBhbmQgcHJlc2VudCBwb3N0aW5ncyB0byBJRVRGIG1haWxp bmcgbGlzdHMsIGFuZAogICAgb2ZmLWxpc3QgY29tbXVuaWNhdGlvbnMgd2l0aCBhdXRob3JzIG9m IEludGVybmV0LURyYWZ0cwogICAgYW5kIFJGQ3MgcmVhc29uYWJseSBiZWluZyB1bmRlcnN0b29k IGFzIGNvbnRyaWJ1dGluZyB0bwogICAgdGhlaXIgd29yayBhbmQgbm90IGV4cGxpY2l0ZWx5IGNh bGxlZCBvdXQgYXMgcHJpdmF0ZS4KCgpCZXN0IHJlZ2FyZHMsCiAgQWxmcmVkIEjObmVzLgoKLS0g CgorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKwp8IFRSLVN5cyBBbGZyZWQgSG9lbmVzICAgfCAgQWxmcmVkIEhvZW5l cyAgIERpcGwuLU1hdGguLCBEaXBsLi1QaHlzLiAgfAp8IEdlcmxpbmdlciBTdHJhc3NlIDEyICAg fCAgUGhvbmU6ICgrNDkpNzE1Ni85NjM1LTAsIEZheDogLTE4ICAgICAgICAgfAp8IEQtNzEyNTQg IERpdHppbmdlbiAgICAgfCAgRS1NYWlsOiAgYWhAVFItU3lzLmRlICAgICAgICAgICAgICAgICAg ICAgfAorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KdGNwbSBtYWlsaW5nIGxpc3QKdGNwbUBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0K From tcpm-bounces@ietf.org Thu Jan 15 04:05:43 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C66F28C187; Thu, 15 Jan 2009 04:05:43 -0800 (PST) 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 D674B28C170 for ; Thu, 15 Jan 2009 04:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.626 X-Spam-Level: * X-Spam-Status: No, score=1.626 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 HCcN-mKkxDBu for ; Thu, 15 Jan 2009 04:05:41 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id C32A828C15D for ; Thu, 15 Jan 2009 04:05:39 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA257491024; Thu, 15 Jan 2009 13:03:44 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA20429 for tcpm@ietf.org; Thu, 15 Jan 2009 13:03:43 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200901151203.NAA20429@TR-Sys.de> To: tcpm@ietf.org Date: Thu, 15 Jan 2009 13:03:43 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org R3JlZ29yeSwgSm9lLCBhbGwsCgpJIGRpZG4ndCBzZWUgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgcmVn YXJkaW5nIHRoZSBOZXdfS2V5IHByb2Nlc3MKZm9yIFRDUC1BTy4gIEhhc24ndCBpdCBiZWVuIGNv cGllZCB0byB0aGUgdGNwbSBsaXN0PwoKVGhlIHRleHQgcHJvcG9zYWwgYXQgYSBoaWdoIGxldmVs IHNlZW1zIHRvIHJlZmxlY3QgdGhlIGN1cnJlbnQKd2lzZG9tIGFuZCBzdGF0ZSBvZiB0aGUgYXJ0 IG9mIGhvdyAncmVrZXlpbmcnIChzb3JyeSBmb3IgdGhlCnNpbXBsaWZ5aW5nIHRlcm0gY29tbW9u bHkgdXNlZCkgc2hvdWxkIGJlIHBlcmZvcm1lZCBpbiBhIHJlYXNvbmFibGUKIm1ha2UtYmVmb3Jl LWJyZWFrIiBtYW5uZXIuCgpGdXJ0aGVyLCBJIGFwcHJlY2lhdGUgeW91ciBpbnRlbnQgdG8gZ2V0 IGEgbmV3IHZlcnNpb24gb3V0ICpiZWZvcmUqCnRoZSAncnVzaCB3ZWVrcycgYmVmb3JlIElFVEYg ZHJhZnQgY3V0b2ZmLCB3aGVyZSBkcmFmdHMgYWx3YXlzIGFyZQppbiBkYW5nZXIgb2Ygbm90IGdl dHRpbmcgdGhlIGF0dGVudGlvbiBhbmQgdGltZSB0aGV5IG1pZ2h0IGRlc2VydmUuCihVbmZvcnR1 bmF0ZWx5LCB0aGlzIGhhcHBlbmVkIHdpdGggdGhlIHByZXZpb3VzIHZlcnNpb25zIG9mIFRDUC1B Ty4pCgpJIGRvIG5vdCBwcmV0ZW5kIHRvIGVpdGhlciBiZSBhICJUQ1AgZ3VydSIgbm9yIGhhdmlu ZyAibXVjaCBleHBlcmllbmNlIgp3aXRoIFJGQyAyMzg1LCBidXQgbXkgd29ya2luZyBrbm93bGVk Z2Ugd2l0aCBUQ1AgbWFrZXMgbWUgcmFpc2luZyBteQp2b2ljZSByZWdhcmRpbmcgdGhlIERJU0NV U1MgaXRlbXMgdy5yLnQuIFRDUCB1c2UgaW4geW91ciBwcm9wb3NhbC4KCgooQSkgIFNlY3Rpb24g WC4yLjMsIHtOZXdfS2V5IHN0YXRlfSBUU0FELU9WRVJMQVAKCkZpcnN0bHksIHRoZSBwcm9wb3Nl ZCB0aW1lciB2YWx1ZSBvZiA1MTIgc2VjIGFtb3VudHMgdG8gfjguNSBtaW51dGVzLAoifjkgbWlu dXRlcyIgaXMgYSBiaXQgdG9vIGNvYXJzZS4gICAgOi0pCgpIb3dldmVyLCBmcm9tIG15IHBvaW50 IG9mIHZpZXcsIHR3byBjb25zaWRlcmF0aW9ucyBhcHBseToKCmEpICBBZnRlciBhbiBhY3RpdmUg Y2xvc2Ugb2YgYSBUQ1AgY29ubmVjdGlvbiwgaWYgdGhlIEFDSwogICAgZm9yIHRoZSBGSU4gYXJy aXZlcywgdGhlIFRDUCBwZWVyIHRyYW5zaXRpb25zIGl0cyBUQ1AKICAgIHRvIHRoZSBUSU1FLVdB SVQgc3RhdGUgd2hpY2ggcmVndWxhcmx5IHBlcnNpc3RzIGZvciAyKk1TTAogICAgKHR3aWNlIHRo ZSBtYXhpbXVtIHNlZ21lbnQgbGlmZXRpbWUgaW4gdGhlIEludGVybmV0KQogICAgd2hpY2ggdGhl IElFVEYgaGFzIGRlZmluZWQgYXMgIDQgbWludXRlcy4KCiAgICBTaW5jZSB0aGlzIHNjZW5hcmlv IHJlc2VtYmxlcyB0aGUgYWJvdmUgLS0gaXQgYWxzbyBhaW1zCiAgICBhdCBkcmFpbmluZyBhbGwg VENQIHNlZ21lbnRzIHN0aWxsICdvbiB0aGUgcm9hZCcgYXQgdGhlCiAgICBhY3RpdmF0aW9uIG9m IHRoZSBuZXcgVFNBRCwgaXQgd291bGQgSU1ITyBtYWtlIHNlbnNlIHRvCiAgICBhZG9wdCB0aGUg c2FtZSB0aW1lb3V0IHZhbHVlLCA0IG1pbnV0ZXMuCgpiKSAgU2luY2UgdGhlIFRDUC1BTyBwcm9j ZXNzaW5nIHJ1bGVzIHRha2UgY2FyZSBvZiBzaWxlbnRseQogICAgZHJvcHBpbmcgcGFja2V0cyBu b3QgbWF0Y2hpbmcgYW4gYWN0aXZlIFRTQUQgZW50cnkgKGZvcgogICAgY29ubmVjdGlvbnMgdGhh dCBoYXZlIGF0IGxlYXN0IG9uZSBUU0FEIGVudHJ5LCBvZiBjb3Vyc2UpLAogICAgaXQgd291bGQg YmUgZWFzeSB0byBleHBlZGl0ZSB0aGUgYWdpbmcgb2YgdGhlIG9sZCBUU0FELVg6CiAgICBUaGUg VENQIHBlZXIgZW50ZXJpbmcgVFNBRC1PVkVSTEFQIGlzIGF3YXJlIG9mIHRoZSBjdXJyZW50CiAg ICBzZXF1ZW5jZSBhbmQgYWNrbm93bGVkZ21lbnQgbnVtYmVycyBhdCB0aGlzIGluc3RhbnQuCgog ICAgVGhlIHJlbW90ZSBwZWVyIGlzIG9ibGlnZWQgdG8gc2VuZCBhbGwgc3Vic2VxdWVudCBzZWdt ZW50cwogICAgdW5kZXIgdGhlIHByb3RlY3Rpb24gb2YgVFNBRC1ZIGFzIHdlbGwuICBUaGVyZWZv cmUsIGFzIHNvb24KICAgIGFzIHRoZSBjb25uZWN0aW9uIG1ha2VzIHByb2dyZXNzLCBpLmUuOgog ICAgLSAgYWxsIG91dGJvdW5kIHNlZ21lbnRzIHdpdGggc2VxdWVuY2UgbnVtYmVycwogICAgICAg bGVzcyB0aGFuIHRoZSBsb2NhbCAnc3dpdGNob3ZlciBwb2ludCcgdG8gVFNBRC1YIGhhdmUgYmVl bgogICAgICAgdHJhbnNtaXR0ZWQgKGRyYWluZWQgZnJvbSB0aGUgbG9jYWwgcmV0cmFuc21pc3Np b24gcXVldWUpCiAgICAgICBhbmQgYWNrbm93bGVkZ2VkIGJ5IHRoZSByZW1vdGUgcGVlciAgQU5E CiAgICAtICBhbGwgaW5ib3VuZCBzZWdtZW50cyB3aXRoIHNlcXVlbmNlIG51bWJlcnMgbGVzcyB0 aGFuIHRoZQogICAgICAgcGVlcidzIHN3aXRjaG92ZXIgcG9pbnQgaGF2ZSBiZWVuIHJlY2VpdmVk IGFuZCBjdW11bGF0aXZlbHkKICAgICAgIGFja25vd2xlZGdlZCwKICAgIGl0IGlzIHNhdmUgdG8g Y2FuY2VsIHRoZSBUU0FELU9WRVJMQVAgdGltZXIsIGRlYWN0aXZhdGUgVFNBRC1YLAogICAgYW5k IHRyYW5zaXRpb24gdG8gU0lOR0xFLVRTQUQgc3RhdGUuCiAgICBVbm5lY2Vzc2FyeSByZXRyYW5z bWlzc2lvbnMgYW5kIHBhY2tldHMgZHVwbGljYXRlZCBpbiB0aGUKICAgIG5ldHdvcmsgdGhhdCBh cmUgcHJvdGVjdGVkIGJ5IFRTQUQtWCBhYW5kc3RpbGwgYXJvdW5kIGF0IHRoaXMKICAgIG1vbWVu dCB3aWxsIHNpbXBseSBiZSBzaWxlbnRseSBkaXNjYXJkZWQgYXQgYXJyaXZhbC4KCiAgICBUaGlz IHdheSwgcmVzb3VyY2VzIChpbmNsdWRpbmcgc3RhbGUga2V5aW5nIG1hdGVyaWFsKSBjb3VsZCBi ZQogICAgY2xlYW5lZCB1cCBtb3JlIHF1aWNrbHkuICBUaGlzIG1pZ2h0IGJlIG9mIHBhcnRpY3Vs YXIgaW1wb3J0YW5jZQogICAgaWYgY3J5cHRvIGFjY2VsZXJhdGluZyBoYXJkd2FyZSB3aXRoIHJl c3RyaWN0ZWQgcmVzb3VyY2VzIGlzIHVzZWQuCgoKKEIpICBTZWN0aW9uIFguMywgUHJvYmUgTWVj aGFuaXNtCgpJdCBzZWVtcyBkYW5nZXJvdXMgdG8gaW50cm9kdWNlIG5ldywgJ3VudXN1YWwnIHBh Y2tldHMgZm9yIHRoaXMKc2lnbmFsaW5nIG1lY2hhbmlzbTsgaW50ZXJtZWRpYXRlIHN5c3RlbXMg YW5kIGZpcmV3YWxscyBtaWdodApub3QgbGV0IHRoZW0gdGhyb3VnaCwgYW5kIHRoZSBwcm9wb3Nh bCBzZWVtcyB0byBuZWVkIGEgZGV0YWlsZWQKc2VjdXJpdHkgYW5hbHlzaXMuICBBdCBmaXJzdCBn bGFuY2UsIGl0IGFsc28gc2VlbXMgdG8gdmlvbGF0ZQpydWxlcyBiZWluZyByZWNvbW1lbmRlZCBm b3IgbW9yZSBjbG9zZXIgcGFja2V0IGluc3BlY3Rpb24gaW4Kb3JkZXIgdG8gY291bnRlciB2YXJp b3VzIGtpbmRzIG9mIGF0dGFjayB2ZWN0b3JzIGFnYWluc3QgVENQLgoKVENQIGhhcyBhICdrZWVw IGFsaXZlJyBtZWNoYW5pc20gYmFzZWQgb24gQUNLIGV4Y2hhbmdlcywgYW5kCnZpcnR1YWxseSBh bGwgVENQIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0IHRoaXMgbWVjaGFuaXNtLgoKSXQgd291bGQg dGhlcmVmb3JlIG1ha2UgdmVyeSBtdWNoIHNlbnNlIHRvIHJlLXVzZSB0aGF0IG1lY2hhbmlzbQpm b3IgdGhlIFByb2Jlczogbm8gJ3N0cmFuZ2UgbG9va2luZycgc2VnbWVudHMsIGtub3duIHNlY3Vy aXR5CmNvbnNpZGVyYXRpb25zIGZvciB0aGUgc2VnbWVudHMsIGJldHRlciByZS11c2Ugb2YgZXhp c3RpbmcgY29kZSEKClRoZXJlZm9yZSwgcmVnYXJkaW5nIFF1ZXN0aW9uIDEsIEkgZXNzZW50aWFs bHkgc3VnZ2VzdDogIDEwMjQgLS0+IDAgICEKClJlZ2FyZGluZyBRdWVzdGlvbiAyOiAgSSBhc3N1 bWUgdGhlIFByb2JlIFRDUCBzZWdtZW50cyB3aWxsIGNvbWUKd2l0aCBhIFRDUCBoZWFkZXIgYW5k IGFuIElQIGhlYWRlciBhcyB3ZWxsLiAgOi0pClRoZXJlZm9yZSwgdGhlIHF1ZXN0aW9uIGlzIG1v b3QhCihFdmVyeSBUQ1AgcmVndWxhcmx5IHNlbmRzIG15cmlhZHMgb2YgZGF0YS1sZXNzIEFDS3Mg dy9vIHBhZGRpbmcsCmFuZCAoZGF0YSkgcGFkZGluZyBuZXZlciBoYXBwZW5zIGF0IHRoZSBUQ1Ag bGF5ZXIuKQoKCktpbmQgcmVnYXJkcywKICBBbGZyZWQgSM5uZXMuCgotLSAKCistLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rCnwgVFItU3lzIEFsZnJlZCBIb2VuZXMgICB8ICBBbGZyZWQgSG9lbmVzICAgRGlwbC4tTWF0 aC4sIERpcGwuLVBoeXMuICB8CnwgR2VybGluZ2VyIFN0cmFzc2UgMTIgICB8ICBQaG9uZTogKCs0 OSk3MTU2Lzk2MzUtMCwgRmF4OiAtMTggICAgICAgICB8CnwgRC03MTI1NCAgRGl0emluZ2VuICAg ICB8ICBFLU1haWw6ICBhaEBUUi1TeXMuZGUgICAgICAgICAgICAgICAgICAgICB8CistLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwp0 Y3BtIG1haWxpbmcgbGlzdAp0Y3BtQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGNwbQo= From tcpm-bounces@ietf.org Thu Jan 15 12:09:57 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284393A69F6; Thu, 15 Jan 2009 12:09:57 -0800 (PST) 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 0FB073A69F6 for ; Thu, 15 Jan 2009 12:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 z-KkCEHvtHqD for ; Thu, 15 Jan 2009 12:09:55 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id CA64A3A68B6 for ; Thu, 15 Jan 2009 12:09:53 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E15506B69C8; Thu, 15 Jan 2009 17:09:40 -0300 (ART) Received: from notebook.gont.com.ar (85-138-17-190.fibertel.com.ar [190.17.138.85]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n0FK9NrK024950; Thu, 15 Jan 2009 18:09:26 -0200 Message-Id: <200901152009.n0FK9NrK024950@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Jan 2009 15:30:59 -0300 To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" , From: Fernando Gont In-Reply-To: References: Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 15 Jan 2009 17:09:40 -0300 (ART) Subject: Re: [tcpm] FW: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 06:31 p.m. 14/01/2009, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >FYI - for document authors who aren't following the IETF >discussion list, please be aware of the note below. What's considered "content"? For example, are "quotes" of pre-5378 RFCs considered contents? Feedback by IETF'ers sent on-list, off-list, or on the microphone at IETF meetings, too? What a mess... 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 tcpm-bounces@ietf.org Tue Jan 20 07:24:42 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E686728C1EA; Tue, 20 Jan 2009 07:24:42 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5F1963A6A51; Tue, 20 Jan 2009 07:24:40 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090120152440.5F1963A6A51@core3.amsl.com> Date: Tue, 20 Jan 2009 07:24:40 -0800 (PST) Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Document Action: 'TCP's Reaction to Soft Errors' to Informational RFC 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The IESG has approved the following document: - 'TCP's Reaction to Soft Errors ' as an Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-09.txt Technical Summary The TCP specification calls for calls for ICMP soft errors to be treated as transient and therefore TCP connections will not abort in response to such messages. A widely implemented departure from the specification has TCP stacks treating such soft errors as hard errors and aborting connections during connection establishment. Working Group Summary The WG could not arrive at consensus for changing the TCP specification to allow ICMP soft errors to be treated as hard errors during connection establishment. However, this change is widely implemented. This document describes the change in an informational way. Document Quality The document was reviewed for quality by a large number of TCPM WG members. Personnel Mark Allman (mallman@icir.org) was the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 21 16:31:12 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9DD43A692D; Wed, 21 Jan 2009 16:31:12 -0800 (PST) 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 EE1BC3A692D for ; Wed, 21 Jan 2009 16:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.708 X-Spam-Level: * X-Spam-Status: No, score=1.708 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 x58SM7N+qcxx for ; Wed, 21 Jan 2009 16:31:10 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id EA4CA3A687A for ; Wed, 21 Jan 2009 16:31:09 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA295334150; Thu, 22 Jan 2009 01:29:10 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA02855 for tcpm@ietf.org; Thu, 22 Jan 2009 01:29:09 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200901220029.BAA02855@TR-Sys.de> To: tcpm@ietf.org Date: Thu, 22 Jan 2009 01:29:09 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: [tcpm] API related DISCUSS for draft-ietf-tcpm-tcp-uto (fwd) 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: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org LS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgZnJvbSBBbGZyZWQgSM5uZXMgLS0tLS0KCkZyb20gQS5I b2VuZXNAVFItU3lzLmRlIFdlZCBKYW4gMjEgMjA6NTc6NTcgTUVaIDIwMDkKUmVjZWl2ZWQ6IGZy b20gWkVVUy5UUi1TeXMuZGUgYnkgdy4gd2l0aCBFU01UUCAoJFJldmlzaW9uOiAxLjM3LjEwOS4y NiAkLzE2LjMpCiAgICAgIGlkIEFBMjk0NDI3ODc2OyBXZWQsIDIxIEphbiAyMDA5IDIwOjU3OjU2 ICswMTAwClJldHVybi1QYXRoOiA8QS5Ib2VuZXNAVFItU3lzLmRlPgpSZWNlaXZlZDogKGZyb20g YWhAbG9jYWxob3N0KSBieSB6LlRSLVN5cy5kZSAoOC45LjMgKFBITkVfMjUxODMpLzguNy4zKQog ICAgICBpZCBVQUEwMjU3MDsgV2VkLCAyMSBKYW4gMjAwOSAyMDo1Nzo1MSArMDEwMCAoTUVaKQpG cm9tOiBBbGZyZWQgSM5uZXMgPGFoQFRSLVN5cy5kZT4KVG86IGllc2dAaWV0Zi5vcmcKQ2M6IHRz dndnQGlldGYub3JnCk1lc3NhZ2UtSWQ6IDwyMDA5MDEyMTE5NTcuVUFBMDI1NzBAVFItU3lzLmRl PgpEYXRlOiBXZWQsIDIxIEphbiAyMDA5IDIwOjU3OjUxICswMTAwIChNRVopClN1YmplY3Q6IEFQ SSByZWxhdGVkIERJU0NVU1MgZm9yIGRyYWZ0LWlldGYtdGNwbS10Y3AtdXRvCgpIZWxsbywKCkkg c3R1bWJsZWQgb3ZlciB0aGUgbWlkLURlY2VtYmVyIElFU0cgZGVsaWJlcmF0aW9ucyByZWdhcmRp bmcgdGhlCkktRCBhZnRlciBMQywgZHJhZnQtaWV0Zi10Y3BtLXRjcC11dG8sIGFuZCBnb3Qgc3R1 Y2sgYXQgdGhlIERJU0NVU1MKcG9zaXRpb24gaW4gZmF2b3Igb2YgYW4gQVBJIHNwZWNpZmljYXRp b24gaW4gdGhlIGRyYWZ0LgoKSSBoYXZlIHNlcmlvdXMgY29uY2VybnMgd2l0aCB0aGF0IHBvc2l0 aW9uLgoKRm9yIHRoZSBtb3N0IHBhcnQsIHRoZSBJRVRGIGhhcyByZWZyYWluZWQgZnJvbSBkb2lu ZyB0aGF0IGVudGlyZWx5LAphbmQgd2hlbiBpdCBpbmRlZWQgZGVhbHQgd2l0aCBzcGVjaWZ5aW5n IEFQSXMsIGl0IHdhcyBiYXNlZCBvbgppbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlLgoKVGhlIHN0 aWxsIG5vdCBmaW5hbGl6ZWQgU0NUUCBzb2NrZXQgQVBJIHNwZWMgc3Rvcnkgc2VlbXMgdG8Kc3Vw cG9ydCBteSBvYnNlcnZhdGlvbiB0aGF0IHN0cm9uZyBmZWVkYmFjayBmcm9tIGltcGxlbWVudGF0 aW9ucwphbmQgdXNlIGNhc2VzIGNhbiBoYXZlIGFuIGltcG9ydGFudCBpbXBhY3Qgb24gdGhlIGRl dGFpbHMgb2YgYW4KQVBJIHNwZWNpZmljYXRpb24sIGl0cyByZXN1bHRpbmcgdmVyc2F0aWxpdHks IGFuZCBpdHMgYWNjZXB0YW5jZS4KCkV4dGVybmFsbHkgdmlzaWJsZSBiZWhhdmlvciBoYXMgdHJh ZGl0aW9uYWxseSBiZWVuIHNwZWNpZmllZCBmaXJzdCwKZ2l2aW5nIHRoZSBBUEkgdGltZSB0byBl dm9sdmUuICBUaGVyZWZvcmUsIEkgc3Ryb25nbHkgc3VnZ2VzdCB0byAqbm90KgphZGQgdGhlIHNw ZWNpZmljYXRpb24gb2YgYSBjb25jcmV0ZSBleHRlbnNpb24gb2YgdGhlIHNvY2tldHMgQVBJIChp bgpzdXBwb3J0IG9mIFRDUC1VVE8pIHRvIHRoZSBkcmFmdCB1bmRlciBjb25zaWRlcmF0aW9uLCBh dCB0aGlzIHN0YWdlLgoKVGhpcyB0b3BpYyBzaG91bGQgYmUgcmUtdmlzaXRlZCB3aGVuLCBhdCBz b21lIHRpbWUgaW4gdGhlIGZ1dHVyZSwKYSByZXZpc2VkIGRvY3VtZW50IHRhcmdldGluZyBhdCBE cmFmdCBTdGFuZGFyZCBmb3IgVENQLVVUTyBtaWdodApiZSBjb25zaWRlcmVkLgoKCktpbmQgcmVn YXJkcywKICBBbGZyZWQgSM5uZXMuCgotLQoKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCBUUi1TeXMgQWxmcmVk IEhvZW5lcyAgIHwgIEFsZnJlZCBIb2VuZXMgICBEaXBsLi1NYXRoLiwgRGlwbC4tUGh5cy4gIHwK fCBHZXJsaW5nZXIgU3RyYXNzZSAxMiAgIHwgIFBob25lOiAoKzQ5KTcxNTYvOTYzNS0wLCBGYXg6 IC0xOCAgICAgICAgIHwKfCBELTcxMjU0ICBEaXR6aW5nZW4gICAgIHwgIEUtTWFpbDogIGFoQFRS LVN5cy5kZSAgICAgICAgICAgICAgICAgICAgIHwKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCgotLS0tLSBFbmQg b2YgZm9yd2FyZGVkIG1lc3NhZ2UgZnJvbSBBbGZyZWQgSM5uZXMgLS0tLS0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdGNwbSBtYWlsaW5nIGxpc3QKdGNw bUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0K From tcpm-bounces@ietf.org Thu Jan 22 07:04:33 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31E83A68ED; Thu, 22 Jan 2009 07:04:33 -0800 (PST) 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 660903A6821 for ; Thu, 22 Jan 2009 07:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.697 X-Spam-Level: * X-Spam-Status: No, score=1.697 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 a43aRkg9I6cj for ; Thu, 22 Jan 2009 07:04:26 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id B5B2F3A6983 for ; Thu, 22 Jan 2009 07:04:25 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA000436542; Thu, 22 Jan 2009 16:02:22 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA03702 for tcpm@ietf.org; Thu, 22 Jan 2009 16:02:21 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200901221502.QAA03702@TR-Sys.de> To: tcpm@ietf.org Date: Thu, 22 Jan 2009 16:02:20 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: [tcpm] API related DISCUSS for draft-ietf-tcpm-tcp-uto 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: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org W1sgIEkgYXBvbG9naXplIGZvciB0aGUgcmVwZXRpdGlvbiwgYnV0IG11bHRpcGxlIHRoaW5ncyB3 ZW50IHdyb25nICBdXQpbWyAgd2l0aCBteSBvcmlnaW5hbCBwb3N0LCBsZXR0aW5nIGl0IGFwcGVh ciBlbXB0eSBpbiB0aGUgYXJjaGl2ZTsgIF1dCltbICBzbyBoZXJlIGlzIHRoZSBvcmlnaW5hbCB0 ZXh0IChhZ2FpbikgLiAgICA6LSkgICAgICAgICAgICAgICAgICAgXV0KCgpIZWxsbywKCkkgc3R1 bWJsZWQgb3ZlciB0aGUgbWlkLURlY2VtYmVyIElFU0cgZGVsaWJlcmF0aW9ucyByZWdhcmRpbmcg dGhlCkktRCBhZnRlciBMQywgZHJhZnQtaWV0Zi10Y3BtLXRjcC11dG8sIGFuZCBnb3Qgc3R1Y2sg YXQgdGhlIERJU0NVU1MKcG9zaXRpb24gaW4gZmF2b3Igb2YgYW4gQVBJIHNwZWNpZmljYXRpb24g aW4gdGhlIGRyYWZ0LgoKSSBoYXZlIHNlcmlvdXMgY29uY2VybnMgd2l0aCB0aGF0IHBvc2l0aW9u LgoKRm9yIHRoZSBtb3N0IHBhcnQsIHRoZSBJRVRGIGhhcyByZWZyYWluZWQgZnJvbSBkb2luZyB0 aGF0IGVudGlyZWx5LAphbmQgd2hlbiBpdCBpbmRlZWQgZGVhbHQgd2l0aCBzcGVjaWZ5aW5nIEFQ SXMsIGl0IHdhcyBiYXNlZCBvbgppbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlLgoKVGhlIHN0aWxs IG5vdCBmaW5hbGl6ZWQgU0NUUCBzb2NrZXQgQVBJIHNwZWMgc3Rvcnkgc2VlbXMgdG8Kc3VwcG9y dCBteSBvYnNlcnZhdGlvbiB0aGF0IHN0cm9uZyBmZWVkYmFjayBmcm9tIGltcGxlbWVudGF0aW9u cwphbmQgdXNlIGNhc2VzIGNhbiBoYXZlIGFuIGltcG9ydGFudCBpbXBhY3Qgb24gdGhlIGRldGFp bHMgb2YgYW4KQVBJIHNwZWNpZmljYXRpb24sIGl0cyByZXN1bHRpbmcgdmVyc2F0aWxpdHksIGFu ZCBpdHMgYWNjZXB0YW5jZS4KCkV4dGVybmFsbHkgdmlzaWJsZSBiZWhhdmlvciBoYXMgdHJhZGl0 aW9uYWxseSBiZWVuIHNwZWNpZmllZCBmaXJzdCwKZ2l2aW5nIHRoZSBBUEkgdGltZSB0byBldm9s dmUuICBUaGVyZWZvcmUsIEkgc3Ryb25nbHkgc3VnZ2VzdCB0byAqbm90KgphZGQgdGhlIHNwZWNp ZmljYXRpb24gb2YgYSBjb25jcmV0ZSBleHRlbnNpb24gb2YgdGhlIHNvY2tldHMgQVBJIChpbgpz dXBwb3J0IG9mIFRDUC1VVE8pIHRvIHRoZSBkcmFmdCB1bmRlciBjb25zaWRlcmF0aW9uLCBhdCB0 aGlzIHN0YWdlLgoKVGhpcyB0b3BpYyBzaG91bGQgYmUgcmUtdmlzaXRlZCB3aGVuLCBhdCBzb21l IHRpbWUgaW4gdGhlIGZ1dHVyZSwKYSByZXZpc2VkIGRvY3VtZW50IHRhcmdldGluZyBhdCBEcmFm dCBTdGFuZGFyZCBmb3IgVENQLVVUTyBtaWdodApiZSBjb25zaWRlcmVkLgoKCktpbmQgcmVnYXJk cywKICBBbGZyZWQgSM5uZXMuCgotLQoKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCBUUi1TeXMgQWxmcmVkIEhv ZW5lcyAgIHwgIEFsZnJlZCBIb2VuZXMgICBEaXBsLi1NYXRoLiwgRGlwbC4tUGh5cy4gIHwKfCBH ZXJsaW5nZXIgU3RyYXNzZSAxMiAgIHwgIFBob25lOiAoKzQ5KTcxNTYvOTYzNS0wLCBGYXg6IC0x OCAgICAgICAgIHwKfCBELTcxMjU0ICBEaXR6aW5nZW4gICAgIHwgIEUtTWFpbDogIGFoQFRSLVN5 cy5kZSAgICAgICAgICAgICAgICAgICAgIHwKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnRjcG0gbWFpbGluZyBsaXN0CnRjcG1A aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtCg== From tcpm-bounces@ietf.org Thu Jan 22 08:00:02 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819BA28C19C; Thu, 22 Jan 2009 08:00:02 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CCD6B28C17E; Thu, 22 Jan 2009 08:00: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: <20090122160001.CCD6B28C17E@core3.amsl.com> Date: Thu, 22 Jan 2009 08:00:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-uto-11.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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --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 User Timeout Option Author(s) : L. Eggert, F. Gont Filename : draft-ietf-tcpm-tcp-uto-11.txt Pages : 17 Date : 2009-01-22 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-11.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-uto-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-22075036.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Thu Jan 22 10:28:55 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B9628C268; Thu, 22 Jan 2009 10:28:55 -0800 (PST) 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 AA44828C25A for ; Thu, 22 Jan 2009 10:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.563 X-Spam-Level: X-Spam-Status: No, score=-4.563 tagged_above=-999 required=5 tests=[AWL=-1.964, 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 AOU+nods6Aed for ; Thu, 22 Jan 2009 10:28:54 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id E9D6828C25F for ; Thu, 22 Jan 2009 10:28:53 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 9EEF42D8215; Thu, 22 Jan 2009 12:28:36 -0600 (CST) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n0MISbFt019748; Thu, 22 Jan 2009 12:28:37 -0600 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 12:28:36 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 12:28:35 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECNSYN change review Thread-Index: Acl8vzx5+kFF4yuBS2eUQlXv01hFoQ== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 22 Jan 2009 18:28:36.0333 (UTC) FILETIME=[3D26F1D0:01C97CBF] Cc: akuzma@northwestern.edu, kkrama@research.att.com, Sally Floyd , a-mondal@northwestern.edu Subject: [tcpm] ECNSYN change 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org As discussed in Minneapolis, we need a couple of people to look again at the ECNSYN draft and sanity-check the changes: http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-07 The background is that this cleared WGLC some time ago, but the authors made some changes based on further simulation results. They felt the changes warranted the WG having a look at, so if a couple of people can coomment on them, it would be good. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 23 00:37:04 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B7228C152; Fri, 23 Jan 2009 00:37:04 -0800 (PST) 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 1CC3E3A6920; Fri, 23 Jan 2009 00:37:03 -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 gAPB4ZwfPdX9; Fri, 23 Jan 2009 00:37:02 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 877C43A67FB; Fri, 23 Jan 2009 00:37:01 -0800 (PST) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n0N8aeKL015203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Jan 2009 10:36:41 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <10C7DFB2-2F9A-4F6E-936A-FC76596BED9A@nokia.com> From: Lars Eggert To: Denis-Courmont Remi (Nokia-D/Helsinki) In-Reply-To: <200901231008.26443.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 23 Jan 2009 10:36:37 +0200 References: <200901211957.UAA02570@TR-Sys.de> <200901231008.26443.remi.denis-courmont@nokia.com> 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]); Fri, 23 Jan 2009 10:36:41 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/8894/Fri Jan 23 06:59:14 2009 on fit.nokia.com X-Virus-Status: Clean Cc: tcpm@ietf.org, tsvwg@ietf.org Subject: Re: [tcpm] [Tsvwg] API related DISCUSS for draft-ietf-tcpm-tcp-uto 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: , Content-Type: multipart/mixed; boundary="===============1433745284==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1433745284== Content-Type: multipart/signed; boundary=Apple-Mail-44-989527136; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-44-989527136 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-1-23, at 10:08, Denis-Courmont Remi (Nokia-D/Helsinki) wrote: > There are quite a bunch of otherwise good IETF technologies that would > probably have gained much wider acceptance, had they had an > Informational API, > rather than none. FYI, the option does have a high-level API (Section 3). Lars PS: Also, this discussion should be on the TCPM list. --Apple-Mail-44-989527136 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 MBwGCSqGSIb3DQEJBTEPFw0wOTAxMjMwODM2MzdaMCMGCSqGSIb3DQEJBDEWBBTtXGiLOPrRNn69 RWxFawB48E4z2DCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAcvygqM+h9PhfC1tmjluJRzAQHzPh2OZIv6Yx/qMef1vj6ny3HOAw E5hojujGfDF0VEe8awJ1HqcvW5MoJJSri2G3cCEHgd1f/ZUwTVBVSI9yb0+YwDXHkYGN1cb+1THy r2KqsokJjcePX6/cyW5TBpODX2qKspm1JoAD+MduohSD2gMfQooxrS13CNfm53vlLnjVemK19ePJ giKEJDW3vlum8jgtDTYETbBmNfj+5LPMagUVt4HAF8+p0L5HYOyGHOe9KLKlulCS7idGoIZYTFYx lRWz4MOoaZmi053s7QQLbahXO6cvMq5B3T2uD1MVLD4GJXfmThNcdnE8nuPjvAAAAAAAAA== --Apple-Mail-44-989527136-- --===============1433745284== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1433745284==-- From tcpm-bounces@ietf.org Fri Jan 23 15:31:43 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A373A6B56; Fri, 23 Jan 2009 15:31:43 -0800 (PST) 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 36B533A6B63 for ; Fri, 23 Jan 2009 15:31:43 -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 CplGT6m2k+Qo for ; Fri, 23 Jan 2009 15:31:42 -0800 (PST) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by core3.amsl.com (Postfix) with ESMTP id CAD9628C276 for ; Fri, 23 Jan 2009 15:31:08 -0800 (PST) MIME-version: 1.0 Received: from [192.168.1.85] ([70.132.11.80]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KDY00CTF6NE2I00@asmtp016.mac.com> for tcpm@ietf.org; Fri, 23 Jan 2009 15:30:52 -0800 (PST) Message-id: <20DE24B1-1A32-44DA-9730-07CE6E3D662A@mac.com> From: Sally Floyd To: Wesley Eddy , David Borman , tcpm Date: Fri, 23 Jan 2009 15:30:50 -0800 X-Mailer: Apple Mail (2.930.3) Cc: David Ros , =?ISO-8859-1?Q?Andr=E9s_Arcia?= , Janardhan Iyengar Subject: [tcpm] Adding Acknowledgement Congestion Control to TCP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org We have submitted a new version of our internet-draft on "Adding Acknowledgement Congestion Control to TCP", draft-floyd-tcpm-ackcc, available at "http://tools.ietf.org/html/draft-floyd-tcpm-ackcc". This draft is an individual submission, and was first presented at TCPM in July, 2007. ("http://www.icir.org/floyd/talks.html"). Because I am in the process of retiring, and have a number of unfinished documents still, I have changed this draft to have an intended status of Informational instead of Experimental, and would like to see what steps would be necessary to advance this document as Informational. (This document is at the moment an individual submission, not a working group document, and I would be happy to try for an Informational document either as an individual submission or as a working group document, whichever seems more appropriate.) Several of the co-authors of the draft intend to continue research in this area, and might submit a revised document to TCPM for Experimental or Proposed Standard some time in the future. The abstract and changes from the previous version are listed below. Any feedback would be appreciated. Many thanks, - Sally http://www.icir.org/floyd/ Abstract: This document describes a possible congestion control mechanism for acknowledgement traffic (ACKs) in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts, the TCP data sender and the TCP data receiver. The TCP data sender detects lost or ECN-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in DCCP's CCID 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. Changes from draft-floyd-tcpm-ackcc-04.txt: * Changed desired status of document from Experimental to Informational, with associated editing changes. * Specified that ACK packets are only sent as ECN-Capable if ECN-capability has been negotiated as specified in RFC 3168. * Added a section on "Possible Addition: Decreasing the ACK Ratio after a Congestion Window Decrease". * Minor editing. Feedback from Alfred Hoenes. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jan 24 13:43:21 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9DE3A6951; Sat, 24 Jan 2009 13:43:21 -0800 (PST) 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 2E4ED3A6951 for ; Sat, 24 Jan 2009 13:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 MzZAmYUJXnGK for ; Sat, 24 Jan 2009 13:43:20 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3B5E33A68A1 for ; Sat, 24 Jan 2009 13:43:20 -0800 (PST) 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 n0OLgioH009642; Sat, 24 Jan 2009 13:42:46 -0800 (PST) Message-ID: <497B8B54.5060409@isi.edu> Date: Sat, 24 Jan 2009 13:42:44 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Sally Floyd References: <20DE24B1-1A32-44DA-9730-07CE6E3D662A@mac.com> In-Reply-To: <20DE24B1-1A32-44DA-9730-07CE6E3D662A@mac.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm , David Borman , Janardhan Iyengar , Wesley Eddy , David Ros , =?ISO-8859-1?Q?Andr=E9s_Arcia?= Subject: Re: [tcpm] Adding Acknowledgement Congestion Control to TCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Sally, Sally Floyd wrote: > We have submitted a new version of our internet-draft on > "Adding Acknowledgement Congestion Control to TCP", > draft-floyd-tcpm-ackcc, available at > "http://tools.ietf.org/html/draft-floyd-tcpm-ackcc". > > This draft is an individual submission, and was first presented at > TCPM in July, 2007. ("http://www.icir.org/floyd/talks.html"). > Because I am in the process of retiring, and have a number of > unfinished documents still, I have changed this draft to have an > intended status of Informational instead of Experimental, and would > like to see what steps would be necessary to advance this document > as Informational. I would expect there would be higher hurdles for experimental than informational, no? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl7i1QACgkQE5f5cImnZrtYhgCcDz8BNofZFp2Qkb4VjOZWRcup UYgAoNAXqVunPKjPUEHCF2/VNdxp1bBh =oSm4 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Jan 25 11:04:22 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D803A67F6; Sun, 25 Jan 2009 11:04:22 -0800 (PST) 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 A4EA93A67F6 for ; Sun, 25 Jan 2009 11:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 L3+BvTpNFsNe for ; Sun, 25 Jan 2009 11:04:20 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D08C53A6774 for ; Sun, 25 Jan 2009 11:04:20 -0800 (PST) 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 n0PJ3kjx011132; Sun, 25 Jan 2009 11:03:49 -0800 (PST) Message-ID: <497CB792.60702@isi.edu> Date: Sun, 25 Jan 2009 11:03:46 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: janardhan.iyengar@fandm.edu References: <20DE24B1-1A32-44DA-9730-07CE6E3D662A@mac.com> <497B8B54.5060409@isi.edu> <497C9F88.4030605@fandm.edu> In-Reply-To: <497C9F88.4030605@fandm.edu> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm , David Borman , Wesley Eddy , David Ros , =?ISO-8859-1?Q?Andr=E9s_Arcia?= Subject: Re: [tcpm] Adding Acknowledgement Congestion Control to TCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Janardhan Iyengar wrote: > Hi Joe, > >>> This draft is an individual submission, and was first presented at >>> TCPM in July, 2007. ("http://www.icir.org/floyd/talks.html"). >>> Because I am in the process of retiring, and have a number of >>> unfinished documents still, I have changed this draft to have an >>> intended status of Informational instead of Experimental, and would >>> like to see what steps would be necessary to advance this document >>> as Informational. >> >> I would expect there would be higher hurdles for experimental than >> informational, no? > > Which is why we are going for Informational and *not* Experimental. > > (Am I missing something?) I'm suggesting that there aren't many steps necessary if this is going Informational. ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl8t5IACgkQE5f5cImnZrtgvwCcDVBsNi93EoASZCQ2/LA6U9UJ 55MAn3Cpf5MiyjPe3hads5rfENsb0dxe =ctOk -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 26 12:55:25 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C101428C1CC; Mon, 26 Jan 2009 12:55:25 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5AB293A69F1; Mon, 26 Jan 2009 12:55:21 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090126205522.5AB293A69F1@core3.amsl.com> Date: Mon, 26 Jan 2009 12:55:22 -0800 (PST) Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Protocol Action: 'TCP User Timeout Option' to Proposed Standard 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The IESG has approved the following document: - 'TCP User Timeout Option ' as a Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-11.txt Technical Summary: This document calls for an option to all TCP endpoints to request peers to set the user-timeout to a particular value. The motivation behind this option is hosts that understand that they will be unavailable for a lengthy period of time and can thus inform their peer of this phenomenon such that the peer can prevent the normal connection aborting procedures from reaping the connection. The information is advisory and therefore the peer is still able to abort the connection (e.g., in times of resource contention). Working Group Summary Given that the information exchanged is advisory, the TCPM WG has consensus that this option is perfectly reasonable. Document Quality The document was reviewed for quality by a large number of TCPM WG members. Personel Responsible AD was Magnus Westerlund. WG shepherd is Wesley Eddy. Note to RFC Editor New paragraph as the second paragraph in section 4.1: Implementations may want to exchange UTO options on the very first data segments after the three-way handshake to determine if such a middlebox exists on the path. When segments carrying UTO options are persistently lost, an implementation should turn off the use of UTO for the connection. When the connection itself is reset, an implementation may be able to transparently re-establish another connection instance that does not use UTO before any application data has been successfully exchanged. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jan 27 00:57:39 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47183A6A53; Tue, 27 Jan 2009 00:57:39 -0800 (PST) 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 2061F3A6A53 for ; Tue, 27 Jan 2009 00:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.026 X-Spam-Level: *** X-Spam-Status: No, score=3.026 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 6pK5oIe76hWs for ; Tue, 27 Jan 2009 00:57:37 -0800 (PST) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by core3.amsl.com (Postfix) with ESMTP id 0FA373A69A4 for ; Tue, 27 Jan 2009 00:57:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,331,1231113600"; d="scan'208,217";a="1410356" Received: from banpmailmx01.citrite.net ([10.103.128.73]) by SYDPIPO01.CITRIX.COM.AU with ESMTP; 27 Jan 2009 08:57:18 +0000 Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by BANPMAILMX01.citrite.net ([10.103.128.73]) with mapi; Tue, 27 Jan 2009 14:27:18 +0530 From: Mahesh M To: "'tcpm@ietf.org'" Date: Tue, 27 Jan 2009 14:27:17 +0530 Thread-Topic: keepalive probing in FIN_WAIT_2 state Thread-Index: AcmAXUGNu+s34SIdTOmQbxK+IzX37w== Message-ID: <2529883E7B666F4E8F21F85AADA43CA707E6EBBC23@BANPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [tcpm] keepalive probing in FIN_WAIT_2 state 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: , Content-Type: multipart/mixed; boundary="===============1159172053==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1159172053== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_2529883E7B666F4E8F21F85AADA43CA707E6EBBC23BANPMAILBOX01_" --_000_2529883E7B666F4E8F21F85AADA43CA707E6EBBC23BANPMAILBOX01_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, For keep alive probing last sequence will be retransmitted with len <=3D 1.= In FIN_WAIT_2 state, if we want to do keep alive probe, the last sequence = number is FIN sequence. In this kind of situation how should the receiver i= nterpret the packet, should it be treated as FIN retransmission or as keep = alive probe. Even though both the events results in ACK packet with latest = ACK number, it makes difference in the spliced connections. One of the spli= ced connections can be reused and FIN from one side is not mapped to the ot= her side. I would like to know if there is a way to distinguish between FIN retransmi= ssion and keep alive probe during CLOSE_WAIT state. Regards, Mahesh --_000_2529883E7B666F4E8F21F85AADA43CA707E6EBBC23BANPMAILBOX01_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

For keep alive probing last sequence will be retransmitt= ed with len <=3D 1. In FIN_WAIT_2 state, if we want to do keep alive probe,= the last sequence number is FIN sequence. In this kind of situation how should = the receiver interpret the packet, should it be treated as FIN retransmission o= r as keep alive probe. Even though both the events results in ACK packet with la= test ACK number, it makes difference in the spliced connections. One of the spli= ced connections can be reused and FIN from one side is not mapped to the other side.

I would like to know if there is a way to distinguish between FIN retransmission and keep alive probe during CLOSE_WAIT state.

 

Regards,

Mahesh

 

--_000_2529883E7B666F4E8F21F85AADA43CA707E6EBBC23BANPMAILBOX01_-- --===============1159172053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1159172053==-- From tcpm-bounces@ietf.org Tue Jan 27 07:52:12 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80763A6ABB; Tue, 27 Jan 2009 07:52:12 -0800 (PST) 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 C04973A6AD3 for ; Tue, 27 Jan 2009 07:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 Bwh-stV+blrb for ; Tue, 27 Jan 2009 07:52:11 -0800 (PST) Received: from frantic.weston.borman.com (frantic-dmz.weston.BORMAN.COM [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id D12EE3A6ABB for ; Tue, 27 Jan 2009 07:52:10 -0800 (PST) Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id n0RFpmud003821; Tue, 27 Jan 2009 09:51:50 -0600 (CST) Message-Id: From: David Borman To: Mahesh M In-Reply-To: <2529883E7B666F4E8F21F85AADA43CA707E6EBBC23@BANPMAILBOX01.citrite.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 27 Jan 2009 09:51:48 -0600 References: <2529883E7B666F4E8F21F85AADA43CA707E6EBBC23@BANPMAILBOX01.citrite.net> X-Mailer: Apple Mail (2.930.3) Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] keepalive probing in FIN_WAIT_2 state 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Mahesh, Keep-alives are not part of the TCP protocol. A keep-alive packet is a hand-crafted TCP packet, designed to guarantee an ACK response from the other side. So, if a retransmitted FIN and a keep-alive probe while in CLOSE-WAIT look identical, in the absence of any other information I would say treat it as a retransmitted FIN. Alternatively, if I am the receiver side and am continuing to send new data after I received the FIN, then since that data will contain a cumulative ACK including the FIN, if I receive an ACK for the new data, I will know that the other side has received my ACK for his FIN, and any additional FINs that I receive would probably be keep-alive probes. But if I haven't sent any data packets with a cumulative ACK that includes the FIN, then I can't be sure and should treat it as a retransmitted FIN. -David Borman On Jan 27, 2009, at 2:57 AM, Mahesh M wrote: > Hi, > > For keep alive probing last sequence will be retransmitted with len > <= 1. In FIN_WAIT_2 state, if we want to do keep alive probe, the > last sequence number is FIN sequence. In this kind of situation how > should the receiver interpret the packet, should it be treated as > FIN retransmission or as keep alive probe. Even though both the > events results in ACK packet with latest ACK number, it makes > difference in the spliced connections. One of the spliced > connections can be reused and FIN from one side is not mapped to the > other side. > I would like to know if there is a way to distinguish between FIN > retransmission and keep alive probe during CLOSE_WAIT state. > > Regards, > Mahesh > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jan 27 13:34:55 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44F23A6A57; Tue, 27 Jan 2009 13:34:55 -0800 (PST) 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 B0ECD3A6A57 for ; Tue, 27 Jan 2009 13:34:54 -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 YVXKGORJPVHl for ; Tue, 27 Jan 2009 13:34:52 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BB2613A6967 for ; Tue, 27 Jan 2009 13:34:52 -0800 (PST) Received: from [70.213.159.222] (222.sub-70-213-159.myvzw.com [70.213.159.222]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0RLYJGQ026125; Tue, 27 Jan 2009 13:34:21 -0800 (PST) Message-ID: <497F7DDC.70309@isi.edu> Date: Tue, 27 Jan 2009 13:34:20 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> In-Reply-To: <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, I'll kick off discussion on this point on the list. IMO, this mechanism is not viable for TCP-AO; it requires generating (and consuming) TCP segments that a native TCP would not generate. I was under the assumption that our design space was as close to TCP MD5 as possible, i.e., augment existing segments with a new option, but neither generate nor consume new segments. The goal appears to be synchronization of the use of new keys. It seems like this can be achieved operationally, e.g., as follows: both sides start with master key A both sides insert master key A with KeyID=5 both sides connect as expected To enable a rapid synchronization of the next key: both sides also reinsert master key A with KeyID=6 At this point, either KeyID=5 or KeyID=6 will work, but both sides use KeyID=5 (by configuration). Now let's assume we want to add a new key for that connection, but also to coordinate its use. both sides receive master key B (out-of-band) both sides insert master key B with KeyID=7 Either side, upon inserting master key B, starts using KeyID=6. Note that there is no loss of packets, because 6 was there back when 5 was. Both sides monitor the keys being received; when keyid=6 is received, then they can start using KeyID=7. I.e., this can be done entirely with an external KMS local to each endpoint, without requiring the KMS's to communicate. I.e., this is automated, but doesn't require a protocol. To some extent, this restores some of the intent of Bonica's "K" bit, but there's no need for an explicit bit, and there's no limit to how quickly the keyID changes happen (i.e., no need to sync when the bit needs to be cleared or for how long). We can put this into the doc, but IMO, it's not necessary at all. It's completely isolated to the KMS anyway. I had already updated the API to be able to return samples of the received KeyIDs, FWIW... Joe Gregory M. Lebovitz wrote: > Folks, > resend... > > Neither I nor Joe have received ANY feedback on this New_Key process. > Can people pls do a quick review and reply to me, Joe, and list with > comments? Joe is trying to get a next version out. > > Many thanks, > Gregory. > > At 01:18 AM 12/19/2008, Gregory M. Lebovitz wrote: >> Hey Joe, and all. >> Below is pasted my first crack at the text for the New_Key Process. >> All input welcome. >> Gregory >> >> ==New_Key Process: >> >> [Suggest you place text about new_key at the end of section 6 in -02] >> >> One big difference between TCP-AO and TCP MD5 is that TCP-AO allows >> for the change of a TSAD entry -- and thus the corresponding change of >> a conn_key -- during a connection, without having to drop the >> connection. This allows for an HMAC algorithm or TSAD_key change >> without a connection loss. This behavior is very beneficial for the >> optimal operation of applications with long lived connections, such as >> BGP. The process of moving from one key to another is called "New_Key". >> >> X.1 New_Key Design Goals >> The following are the design goals of the New_Key process: >> >> - Both sides will move to the new TSAD entry as fast as possible, >> assuming both peers are configured with the new TSAD entry at (almost) >> the same time. This provides the security benefit of being able to >> move immediately off a key believed to be compromised to a newly >> defined key. >> >> - Support a potentially long time lag between when each peer is >> configured with the new TSAD entry. This time could be as long as two >> or three weeks, depending on maintenance processes and change windows >> for both sides. >> >> - Impact the operation and performance of the application using TCP >> as little as possible. Cause zero, or very little, application data >> loss or delay. >> >> - Modify the TCP stack itself as little as possible. >> >> - Ensure that neither side transitions completely to the new TSAD >> entry prematurely, before the other peer has the new TSAD entry and is >> ready to use the new TSAD entry. >> >> - Ensure that neither side erases an old TSAD entry prematurely. >> Implementations will hold both the old and new TSAD entries in memory >> long enough to employ the new TSAD entry as soon as possible, while >> still being able to properly process any straggler, out-of-order >> segments that might arrive having been processed with the old TSAD >> entry, even after the new TSAD entry is already in use by both sides. >> >> - Avoid moving to the use of a new TSAD entry prematurely, i.e. >> before the other peer is prepared to use the new TSAD entry. >> >> >> X.2 Use Cases Supported >> There are two main cases that New_Key must address. The first is the >> case where a new TSAD entry (KeyID, MAC type, key length, TSAD_key; >> see section 6) is configured onto both peers during a connection's >> life. The TSAD entry may have arrived into the peers' states either by >> manual configuration, or by some automated key management exchange. >> Regardless the method, a new TSAD entry is installed into each peers' >> respective state while the previous TSAD entry is already in use. >> >> [NOTE: There is an assumption being made here that at some point in >> the future, when a key management protocol has been defined for >> TCP-AO, that mechanism will leverage the conn_key derivation mechanism >> described here in TCP-AO. This means that instead of negotiating ISN's >> and conn_keys directly, the key management protocol will simply >> negotiate a TSAD entry, and TCP-AO will use that TSAD entry according >> to this specification to derive its conn_keys.] >> >> The second use case involves a chain of pre-configured TSAD entries. >> In this case, the two sides choose and exchange out-of-band a series >> of TSAD entries to be used over time. Each TSAD entry will also have >> the time at which the key will begin to be actually used to >> authenticate segments, and how long the key is to be used. This >> information is all exchanged out-of-band, and then configured into >> each device respectively. The chains may be quite long, like 64 or 128 >> entries. The TSAD entries, the order of use, and start times, must all >> match on both sides. The TSAD entries are then used in sequential >> order. In this use case, the new TSAD entry is known on both sides >> well ahead of the actual New_Key event. The key chain mechanism >> provides a way to limit the lifetime of a particular key's use on the >> wire. Limiting a key's lifetime protects against a successful brute >> force guessing attack. The idea is that the connection has already >> moved on to a new TSAD entry by the time the attacker, who has been >> working offline to guess the key, succeeds. Key chains do not protect >> against the termination of an employee who had access to the TSAD >> entries. In such a case, the entire key chain is assumed to be >> compromised, and a whole new key chain SHOULD be put into use. The >> concept of key chains, their benefits and limitations are discussed >> more thoroughly in the Security Considerations section. >> >> >> X.2 New_Key State Machine >> >> There are three states in the New_Key state machine: SINGLE-TSAD, >> PROBING, and TSAD-OVERLAP. The states are shown below in Figure X. >> >> X.2.1 SINGLE-TSAD >> >> The SINGLE-TSAD state is the beginning and ending state of the New_Key >> process. It is the state in which there is one and only one TSAD entry >> actively in use for both sending and receiving segments. When a new >> TCP connection using TCP-AO first begins, the New_Key process is >> initialized to the SINGLE-TSAD state. >> >> For the purpose of this explanation, the starting TSAD used in >> SINGLE-TSAD state will be called "TSAD-X". The new TSAD entry >> activated will be referred to as TSAD-Y. >> >> From SINGLE-TSAD it is only possible to move to PROBING state. The >> move from SINGLE-TSAD to PROBING occurs when a new TSAD entry, TSAD-Y, >> becomes active. According to the use cases described above, a TSAD-Y >> becomes active when one of the following events occurs: >> >> o It is manually entered and activated on the device for an >> existing connection >> o It is received into state as a result of a key management >> protocol negotiation >> o It is the next TSAD entry in a chain, and it's start time equals >> the current >> time >> >> It is most common to transition into SINGLE-TSAD state from either a >> new connection initialization, or from the TSAD-OVERLAP state (as >> described in section X.2.3). There also exists one condition under >> which the state may transition to SINGLE-TSAD from PROBING. This is >> described at the end of section X.2.2 PROBING. >> >> >> +---------------+ >> | | >> | SINGLE-TSAD | >> | | >> +------/*-------+ >> // \\ >> New TSAD-Y // \\ >> Entry Activated // \\ Deactivate >> // \\ previous TSAD-X >> // \\ entry >> // \\ >> // \\ >> +-----//-----+ +----\-----------+ >> | | | | >> | PROBING +-------------------+ TSAD-OVERLAP | >> | | | | >> +------------+ +----------------+ >> Receive Packet >> Processed with >> TSAD-Y entry >> >> >> Figure X. >> New_Key State Machine >> >> >> X.2.2 PROBING >> >> The PROBING state is the second state. The goal of the PROBING state >> is for a host A, "Alice", to signal to its peer, host B, "Bob", that >> Alice has TSAD-Y installed and active, and is ready to use it. If Bob >> does not have TSAD-Y then any segments sent by Alice with TSAD-Y's >> KeyID will be discarded. Discarded segments may cause retransmission >> and delays in the application processing. So Alice wants to avoid >> sending application data with TSAD-Y before she is certain Bob has >> TSAD-Y. Once Alice has TSAD-Y activated she cannot yet be certain that >> Bob also has TSAD-Y installed and activated for the following reasons: >> >> o Bob's administrator may not have gotten around to installing >> TSAD-Y yet >> o If using a key chain, the clocks on the two devices may be out of >> sync such >> that start time for Alice is not the same absolute time as start >> time for Bob >> >> Therefore, Alice will send a probe segment, processed using the >> TSAD-Y, to signal to Bob that she is ready to begin using TSAD-Y. She >> will repeat this probe periodically. (The specifics of this probing >> mechanism are described below in Section X.3.) Before Bob has TSAD-Y >> he will not be able to process these probes, and he will discard them. >> >> Once Bob has installed and activated TSAD-Y, Bob will himself >> transition from SINGLE-TSAD to PROBING state. Bob will then send a >> probe processed with TSAD-Y to Alice. Further, Bob will be able to >> successfully process Alice's next probe sent using TSAD-Y. >> >> Once Alice has successfully received and processed a segment from Bob >> that was sent using TSAD-Y, she transitions immediately to >> TSAD-OVERLAP state. The time spent in PROBING state may be very short, >> especially if Bob has already activated TSAD-Y and has just sent a >> probe. Alice may not have even sent a probe yet. That's okay. Once >> Alice successfully processes a segment from Bob using TSAD-Y she knows >> (a) that she has the correct TSAD-Y, that (b) Bob has the correct >> TSAD-Y, and (c) they are both prepared to begin sending and receiving >> all following segments with TSAD-Y. >> >> It is only possible to move into PROBING from the SINGLE-TSAD state, >> as described above in X.2.1. PROBING is distinct from SINGLE-TSAD in >> that now there exists a second active TSAD, TSAD-Y, along with TSAD-X. >> In PROBING, only probe segments are sent using TSAD-Y. All other >> segments are sent using TSAD-X. Most segments received will be >> processed using TSAD-X. Once the first received segment is >> successfully processed using TSAD-Y, the state transitions to >> TSAD-OVERLAP. >> >> TSAD-OVERLAP is the most probable state that will be entered when >> exiting PROBING. >> >> However, under one unlikely condition the state will transition from >> PROBING to SINGLE-TSAD. In the case where: >> >> o a life-time has been configured for TSAD-X, AND, >> o that life-time expires while in PROBING state, AND, >> o TSAD-Y is still active, AND, >> o no other TSAD has yet been activated, THEN, >> o the only active TSAD remaining is TSAD-Y. >> >> Even though Alice has not yet successfully received TSAD-Y segments >> from Bob, if a life-time is exceeded, the expired TSAD MUST be >> de-activated in order to follow the configured security policy. This >> would force the state back to SINGLE-TSAD state, with TSAD-Y being the >> only activated TSAD entry. This condition -- where TSAD-X expired >> before segments were received processed by TSAD-Y -- SHOULD be logged, >> and the administrator alerted. Assuming the security policy mandates >> the use of TCP-AO on this connection, segments MUST be sent processed >> with TSAD-Y. Received segments MAY continue to be processed with >> TSAD-X. However, if Bob does not activate TSAD-Y, then the TCP >> connection will soon timeout, because Bob will discard the TSAD-Y >> processed segments he receives. >> >> X.2.3 TSAD-OVERLAP >> >> The TSAD-OVERLAP state is the third state. Like PROBING, both the old >> TSAD-X and the new TSAD-Y are both activated. The main distinction >> between PROBING and TSAD-OVERLAP is that in TSAD-OVERLAP the new TSAD, >> TSAD-Y, is the only one used for sending all segments. In this state, >> TSAD-X is used only for processing received segments that may arrive >> with TSAD-X's KeyID. Such straggler segments may arrive because they >> were sent out onto the wire before the transition from PROBING to >> TSAD-OVERLAP occurred, and are just now arriving. >> >> Once the state transitions to TSAD-OVERLAP, a counter is initialized >> to 512. The counter decrements once per second, so TSAD-X will overlap >> TSAD-Y for just under nine minutes. Upon reaching zero, the prior >> TSAD, TSAD-X is de-activated. At this point the entire TSAD-X entry, >> including its conn_keys, MAY be deleted from state. The TSAD-OVERLAP >> counter MAY be configurable on various implementations. >> >> [Author's Thought: I have no idea if this is the best way to do this >> timer. I chose seconds because that is how TCP does it's exponential >> back-off timer for retransmission, the max of which is ~9 minutes, >> from what I read in Stevens, Ch 21. TCP gurus are welcome to refine >> the overlap timer mechanism based on practical experience] >> >> Once TSAD-X is deactivated, the state transitions to SINGLE-TSAD. At >> this point, TSAD-Y is the one and only active TSAD entry for both >> sending and receiving segments. >> >> >> X.3 Probe Mechanism >> >> This section specifies the probe mechanism used in PROBING state >> (section X.2.2). >> >> The probe is a single TCP segment sent with: >> >> o the TCP-AO option using TSAD-Y, AND >> o any other tcp options present (per section 3.2, point 4), AND >> o with no TCP data, AND >> o marked with a sequence number unmistakably smaller than the currently >> appropriate sequence number. Precisely, where the current >> sequence number that would otherwise be used is "S", and the probe >> segment's sequence number is "P", P is 1024 less than S, or >> >> P = S - 1024 >> >> [Question 1: TCP guru's, is 1024 the best number?] >> >> [Question 2: given the empty TCP data, will we need to add padding >> here to meet the minimum 64 byte IP packet size?] >> >> The probe is crafted so that no real application data will be lost if >> the probe fails. This protects the performance of the application >> being authenticated in TCP. The probe is transmitted with an old, >> stale sequence number so that if the receiver, Bob, is unable to >> process the probe, and discards it, there will be no perceived skip in >> the proper sequence flow, and no retransmission required. >> >> Alice starts a standard exponential back-off timer for transmitting >> the next probe(s). If no segment has been received with TSAD-Y, then >> the next probe is sent 1.5 seconds later. After this the timeout value >> is doubled for each following probe, with an upper limit of 64 >> seconds; i.e. at 3, 6, 12, 24, 48, 64, 64, 64, etc. seconds apart. If >> at any point a segment is received that was crafted using TSAD-Y, then >> the timer is terminated, and state is transitioned to TSAD-OVERLAP. >> >> Bob receives the probe segment, and responds in one of two ways. >> >> (1) IF Bob has NOT activated TSAD-Y, THEN >> >> Bob will not recognize the KeyID in the probe segment, and will >> silently discard the segment. Since the segment has a stale sequence >> number, absolutely no interruption occurs to the application flow. >> >> (2) IF Bob HAS activated TSAD-Y, THEN >> >> Bob will recognize the KeyID in the probe, and process the >> segment using TSAD-Y. Assume this is the first segment received with >> TSAD-Y; when the authentication verification processes correctly Bob >> will state transition to TSAD-OVERLAP state. Henceforth Bob will >> transmit all segments using only TSAD-Y. Bob's TCP stack then parses >> the segment and reads the stale sequence number. TCP responds >> naturally with an ACK. That ACK will naturally contain the sequence >> number of the last received data segment prior to the segment with the >> stale sequence number, the probe. That ACK is processed using TSAD-Y, >> and transmitted. Thus, zero interruption to the normal application >> flow occurs as a result of the probe segment. >> >> Once Alice receives either (a) a TSAD-Y processed ACK to her probe, or >> (b) a TSAD-Y processed probe from Bob, she transitions to TSAD-OVERLAP. >> >> >> +++++++++++++++++++++++ >> 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 iEYEARECAAYFAkl/fdsACgkQE5f5cImnZrtW8wCgv7w7hbUsemoVuIMbUzjKqft8 h7gAoJd0qWqDxMceS+geMpxvMC4bbOjn =vRME -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 28 03:25:35 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA19428C112; Wed, 28 Jan 2009 03:25:35 -0800 (PST) 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 5EE6228C112 for ; Wed, 28 Jan 2009 03:25:34 -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 WciaDLEBHRFt for ; Wed, 28 Jan 2009 03:25:33 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 7BD0A3A68C7 for ; Wed, 28 Jan 2009 03:25:33 -0800 (PST) Received: from [10.180.41.23] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n0SBOxVg032062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Jan 2009 13:25:00 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <5E6CB562-0495-4D2B-924E-AB4650924151@nokia.com> From: Lars Eggert To: Joe Touch In-Reply-To: <497F7DDC.70309@isi.edu> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 28 Jan 2009 13:24:54 +0200 References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> 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, 28 Jan 2009 13:25:00 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/8914/Wed Jan 28 08:40:00 2009 on fit.nokia.com X-Virus-Status: Clean Cc: "tcpm@ietf.org" , Allison Mankin , "skonduru@juniper.net" Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On 2009-1-27, at 23:34, Joe Touch wrote: > I was under the assumption that our design space was as close to TCP > MD5 as > possible, i.e., augment existing segments with a new option, but > neither > generate nor consume new segments. That's my recollection as well, and hopefully it's in the minutes of the WG meeting where we adopted the work item. The idea was to be as lightweight (in terms of changes to TCP) as possible, and changes to the state machine, etc. seem rather heavyweight. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 28 04:14:39 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5D128C1C4; Wed, 28 Jan 2009 04:14:38 -0800 (PST) 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 C0DF828C1C3 for ; Wed, 28 Jan 2009 04:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[AWL=0.001, 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 k0RbF0l2bWwU for ; Wed, 28 Jan 2009 04:14:37 -0800 (PST) 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 D8EA928C1B6 for ; Wed, 28 Jan 2009 04:14:36 -0800 (PST) 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 <0KE600BYUKNTPQF0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 28 Jan 2009 13:14:17 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.37,338,1231110000"; d="sig'?scan'208";a="98218902" 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; Wed, 28 Jan 2009 13:14:17 +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 n0SCEHdl025383; Wed, 28 Jan 2009 13:14:17 +0100 (CET) Message-id: <48642A12-CF26-4ECC-8DD6-D40F18732297@nets.rwth-aachen.de> From: Alexander Zimmermann To: tcpm@ietf.org Date: Wed, 28 Jan 2009 13:14:13 +0100 X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.930.3) Cc: Arnd Hannemann Subject: [tcpm] New Internet Draft: draft-zimmermann-tcp-lcd-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: , Content-Type: multipart/mixed; boundary="===============0911893171==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0911893171== Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-20--712900188 Content-transfer-encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-20--712900188 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit A new version of an I-D has been posted on the IETF web site. http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-00.txt Filename: draft-zimmermann-tcp-lcd Revision: 00 Title: Make TCP more Robust to Long Connectivity Disruptions WG ID: Independent Submission Abstract: TCP was designed with fixed, wired networks in mind. As a result TCP performs suboptimal in networks where connectivity disruptions are frequent, e.g., in wireless (multi-hop) networks. One reason for the performance degradation is TCP's over-conservative behavior in face of long connectivity disruptions. This document describes how connectivity disruption indications provided by standard ICMP messages may be exploited to improve TCP's performance. An RTO revert strategy is proposed that enables earlier detection of whether connectivity to a previously disconnected peer node has been restored or not. The scheme is a sender only modification which fully respects the TCP congestion control principles. Comments are welcome. Alexander Zimmermann --Apple-Mail-20--712900188 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) iEYEARECAAYFAkmATBYACgkQdyiq39b9uS4RdwCfTD1B8LY5vIO+3tuxRmhNsey5 Os0AoJmaQrExIkKbD3itSyyP7hPkR6GF =cUmM -----END PGP SIGNATURE----- --Apple-Mail-20--712900188-- --===============0911893171== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0911893171==-- From tcpm-bounces@ietf.org Wed Jan 28 08:12:18 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0045528C176; Wed, 28 Jan 2009 08:12:18 -0800 (PST) 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 DC44028C17C for ; Wed, 28 Jan 2009 08:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 OMnnrfi1CiKz for ; Wed, 28 Jan 2009 08:12:15 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id DFEDD28C1E7 for ; Wed, 28 Jan 2009 08:11:36 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 3799450822; Wed, 28 Jan 2009 08:27:56 -0800 (PST) Date: Wed, 28 Jan 2009 08:27:56 -0800 From: Eric Rescorla To: Joe Touch In-Reply-To: <497F7DDC.70309@isi.edu> References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> 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") Message-Id: <20090128162756.3799450822@romeo.rtfm.com> Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Tue, 27 Jan 2009 13:34:20 -0800, Joe Touch wrote: > I'll kick off discussion on this point on the list. > > IMO, this mechanism is not viable for TCP-AO; it requires generating > (and consuming) TCP segments that a native TCP would not generate. I was > under the assumption that our design space was as close to TCP MD5 as > possible, i.e., augment existing segments with a new option, but neither > generate nor consume new segments. I think it's important to separate two issues: 1. How can an implementation decide when it's safe to use a newly installed key? 2. How can an implementation help a peer implementation make that decision. I think it's pretty clear that the most natural way to answer question (1) is "when you see a segment protected with that key". Unfortunately, this creates a deadlock problem since both sides are waiting for the other side to use the key. Thus, we need a combination of two methods: 1. If a node has two keys, OLD and NEW, as soon as it sees a segment from the peer protected with NEW, it starts sending with NEW. 2. If a node has two keys, OLD and NEW, and it's still using OLD it occasionally experimentally sends a segment with NEW (probing). Taken together, these rules allow a clean transition, since both nodes are in probing state until one node receives a packet with NEW, at which point it switches over and the peer soon follows. The question then becomes how the probing mechanism works. At a high level, there are two options: 1. Probe with packets that the TCP stack would already send. 2. Generate new segments to use explicitly as probes. The advantage of (1) is obviously minimal impact on the stack, but may mean that segments are lost and could unless cere is taken, exert false congestion feedback. The advantage of (2) is that it is less likely to create false congestion feedback, but it requires more changes to the stack and of course creates additional traffic on the wire. Greg's mechanism is of course of type (2). -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 28 08:58:52 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7521C3A69EB; Wed, 28 Jan 2009 08:58:52 -0800 (PST) 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 108623A69EB for ; Wed, 28 Jan 2009 08:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 rLy-zsNcOLO3 for ; Wed, 28 Jan 2009 08:58:50 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 12E783A67BD for ; Wed, 28 Jan 2009 08:58:50 -0800 (PST) Received: from [75.215.232.200] (200.sub-75-215-232.myvzw.com [75.215.232.200]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0SGvuux006284; Wed, 28 Jan 2009 08:57:58 -0800 (PST) Message-ID: <49808E94.8050107@isi.edu> Date: Wed, 28 Jan 2009 08:57:56 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Rescorla References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> In-Reply-To: <20090128162756.3799450822@romeo.rtfm.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: > At Tue, 27 Jan 2009 13:34:20 -0800, > Joe Touch wrote: >> I'll kick off discussion on this point on the list. >> >> IMO, this mechanism is not viable for TCP-AO; it requires generating >> (and consuming) TCP segments that a native TCP would not generate. I was >> under the assumption that our design space was as close to TCP MD5 as >> possible, i.e., augment existing segments with a new option, but neither >> generate nor consume new segments. > > I think it's important to separate two issues: > > 1. How can an implementation decide when it's safe to use a newly installed > key? > 2. How can an implementation help a peer implementation make that decision. > > I think it's pretty clear that the most natural way to answer question > (1) is "when you see a segment protected with that key". Unfortunately, > this creates a deadlock problem since both sides are waiting for the > other side to use the key. Thus, we need a combination of two > methods: > > 1. If a node has two keys, OLD and NEW, as soon as it sees a segment > from the peer protected with NEW, it starts sending with NEW. > 2. If a node has two keys, OLD and NEW, and it's still using OLD > it occasionally experimentally sends a segment with NEW (probing). I've already shown a way to achieve this without requiring the use of the NEW key, i.e., that used two KeyIDs with the OLD key, using the change in the KeyID to inform the endpoints. I've also described in that email a way to achieve this using the current API, without asking TCP-AO to generate new packets or to do anything conditional _inside_ TCP-AO; this can (and, IMO, should) all be accomplished with an external mechanism, with __no__ impact on the stack. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmAjpQACgkQE5f5cImnZrtftwCeKbn3TIHZFDbudbLbBVFkSvUv bBsAmwbhw+DBZp2lobyjiuVcR3aWyysR =pG9x -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 28 09:37:28 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661513A6A74; Wed, 28 Jan 2009 09:37:28 -0800 (PST) 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 89BE13A67DA for ; Wed, 28 Jan 2009 09:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 u-FNwn9O2nrb for ; Wed, 28 Jan 2009 09:37:26 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 691203A6A74 for ; Wed, 28 Jan 2009 09:37:26 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C434E50822; Wed, 28 Jan 2009 09:53:45 -0800 (PST) Date: Wed, 28 Jan 2009 09:53:45 -0800 From: Eric Rescorla To: Joe Touch In-Reply-To: <49808E94.8050107@isi.edu> References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <49808E94.8050107@isi.edu> 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") Message-Id: <20090128175345.C434E50822@romeo.rtfm.com> Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 28 Jan 2009 08:57:56 -0800, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Eric Rescorla wrote: > > At Tue, 27 Jan 2009 13:34:20 -0800, > > Joe Touch wrote: > >> I'll kick off discussion on this point on the list. > >> > >> IMO, this mechanism is not viable for TCP-AO; it requires generating > >> (and consuming) TCP segments that a native TCP would not generate. I was > >> under the assumption that our design space was as close to TCP MD5 as > >> possible, i.e., augment existing segments with a new option, but neither > >> generate nor consume new segments. > > > > I think it's important to separate two issues: > > > > 1. How can an implementation decide when it's safe to use a newly installed > > key? > > 2. How can an implementation help a peer implementation make that decision. > > > > I think it's pretty clear that the most natural way to answer question > > (1) is "when you see a segment protected with that key". Unfortunately, > > this creates a deadlock problem since both sides are waiting for the > > other side to use the key. Thus, we need a combination of two > > methods: > > > > 1. If a node has two keys, OLD and NEW, as soon as it sees a segment > > from the peer protected with NEW, it starts sending with NEW. > > 2. If a node has two keys, OLD and NEW, and it's still using OLD > > it occasionally experimentally sends a segment with NEW (probing). > > I've already shown a way to achieve this without requiring the use of > the NEW key, i.e., that used two KeyIDs with the OLD key, using the > change in the KeyID to inform the endpoints. I've also described in that > email a way to achieve this using the current API, without asking TCP-AO > to generate new packets or to do anything conditional _inside_ TCP-AO; > this can (and, IMO, should) all be accomplished with an external > mechanism, with __no__ impact on the stack. I read your mechanism, but I'm not sure it works. The basic unit of operation here isn't keys but key-ids. It's true that in your example key-id 6 refers to the same key as key-id 5, but that's not something that the stack should be observing. In other words, if you get a packet with key-id 6 and you only have key-id 5, you should reject it, not try the key corresponding to key-id 5, so we've reduced this to a previously unsolved problem. If your point is that at the time I install key-id 5 I also install a dummy key-id 6, and use that purely for signalling, I agree that that would work, but it strikes me as extremely kludgy. There's no natural connection between the switch from 5-6 and the switch from 5-7. So, no, I don't favor that approach. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 28 09:59:11 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4D828C17B; Wed, 28 Jan 2009 09:59:11 -0800 (PST) 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 7BBCD28C130 for ; Wed, 28 Jan 2009 09:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 G5g6twKawZTb for ; Wed, 28 Jan 2009 09:59:09 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6AFB228C17B for ; Wed, 28 Jan 2009 09:59:09 -0800 (PST) Received: from [75.215.232.200] (200.sub-75-215-232.myvzw.com [75.215.232.200]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0SHwKIp022961; Wed, 28 Jan 2009 09:58:22 -0800 (PST) Message-ID: <49809CBC.5080603@isi.edu> Date: Wed, 28 Jan 2009 09:58:20 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Rescorla References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <49808E94.8050107@isi.edu> <20090128175345.C434E50822@romeo.rtfm.com> In-Reply-To: <20090128175345.C434E50822@romeo.rtfm.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric (et al.), Eric Rescorla wrote: > At Wed, 28 Jan 2009 08:57:56 -0800, > Joe Touch wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> Eric Rescorla wrote: >>> At Tue, 27 Jan 2009 13:34:20 -0800, >>> Joe Touch wrote: >>>> I'll kick off discussion on this point on the list. >>>> >>>> IMO, this mechanism is not viable for TCP-AO; it requires generating >>>> (and consuming) TCP segments that a native TCP would not generate. I was >>>> under the assumption that our design space was as close to TCP MD5 as >>>> possible, i.e., augment existing segments with a new option, but neither >>>> generate nor consume new segments. >>> I think it's important to separate two issues: >>> >>> 1. How can an implementation decide when it's safe to use a newly installed >>> key? >>> 2. How can an implementation help a peer implementation make that decision. >>> >>> I think it's pretty clear that the most natural way to answer question >>> (1) is "when you see a segment protected with that key". Unfortunately, >>> this creates a deadlock problem since both sides are waiting for the >>> other side to use the key. Thus, we need a combination of two >>> methods: >>> >>> 1. If a node has two keys, OLD and NEW, as soon as it sees a segment >>> from the peer protected with NEW, it starts sending with NEW. >>> 2. If a node has two keys, OLD and NEW, and it's still using OLD >>> it occasionally experimentally sends a segment with NEW (probing). >> I've already shown a way to achieve this without requiring the use of >> the NEW key, i.e., that used two KeyIDs with the OLD key, using the >> change in the KeyID to inform the endpoints. I've also described in that >> email a way to achieve this using the current API, without asking TCP-AO >> to generate new packets or to do anything conditional _inside_ TCP-AO; >> this can (and, IMO, should) all be accomplished with an external >> mechanism, with __no__ impact on the stack. > > I read your mechanism, but I'm not sure it works. > > The basic unit of operation here isn't keys but key-ids. It's true that > in your example key-id 6 refers to the same key as key-id 5, but that's > not something that the stack should be observing. The stack doesn't observe it; the stack reports it if asked to an external process. > In other words, > if you get a packet with key-id 6 and you only have key-id 5, you should > reject it, not try the key corresponding to key-id 5, so we've reduced > this to a previously unsolved problem. I've reduced the problem to a configuration solution, not a TCP-level protocol mechanism. If you remove aspects of the solution (i.e., if you don't install a key with two keyIDs), then the solution obviously won't work. That doesn't reintroduce the unsolved problem; it reverts to the unsolved problem when not solved (which is a tautology). > If your point is that at the time I install key-id 5 I also install a > dummy key-id 6, and use that purely for signalling, I agree that that > would work, but it strikes me as extremely kludgy. It allows side A to tell side B when side A has a new key installed, without causing any packets to fall on the floor on side B (note that retransmissions, if received, could open the congestion window inappropriately). The mechanism I proposed achieved with no modifications to the TCP stack. The other mechanisms suggested all have the property of also using the KeyID value as a signal. The only downside of the mechanism I proposed is that is inefficient in the use of the KeyID space - however, the space is large enough that this isn't an issue. > There's no natural > connection between the switch from 5-6 and the switch from 5-7. Why should there be? IMO, it's up to the endpoints to decide how and when to switch keys; key change coordination needs to be _enabled_ by TCP-AO, but not provided by it. IMO, that's a KMS issue - whether automated at the endpoints, or via a protocol. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmAnLwACgkQE5f5cImnZrsDggCeLX8Sy6YORgG4D0kz+usylDep zDYAnR8EMoBNAtrXx90OJW1Z1O0lMljF =Kqm5 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 28 10:14:29 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9353A695B; Wed, 28 Jan 2009 10:14:29 -0800 (PST) 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 CC2543A6897 for ; Wed, 28 Jan 2009 10:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 W6+FxdbNn1f2 for ; Wed, 28 Jan 2009 10:14:24 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 47B663A695B for ; Wed, 28 Jan 2009 10:14:24 -0800 (PST) Received: from [75.215.232.200] (200.sub-75-215-232.myvzw.com [75.215.232.200]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0SIDg1B027065; Wed, 28 Jan 2009 10:13:44 -0800 (PST) Message-ID: <4980A055.8000501@isi.edu> Date: Wed, 28 Jan 2009 10:13:41 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Joe Touch References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <49808E94.8050107@isi.edu> In-Reply-To: <49808E94.8050107@isi.edu> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 PS - I can add the description of my suggestion below in "how to synchronize key rollover" if desired; IMO, it's outside the scope of the document except to demonstrate that the mechanisms in the document are sufficient to achieve key rollover sync. FYI, the only change to TCP-AO needed for the mechanism I described was to report a recently received KeyID (as a sample) when requested. That's a very low hurdle to enable key rollover, IMO, vs. in-mechanism probing systems. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmAoFUACgkQE5f5cImnZrsX5wCfT7Y+0ok5dHa1A9uPcjr6WhdS SxgAn0gDZg6a6S7wU3RzT2bmsJ56uPkG =Udco -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 28 22:38:48 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2AB3A6852; Wed, 28 Jan 2009 22:38:48 -0800 (PST) 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 E3B5C3A6852 for ; Wed, 28 Jan 2009 22:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 QcuWG97bGHXd for ; Wed, 28 Jan 2009 22:38:46 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id D700C3A67F7 for ; Wed, 28 Jan 2009 22:38:45 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 243E550822; Wed, 28 Jan 2009 22:55:00 -0800 (PST) Date: Wed, 28 Jan 2009 22:55:00 -0800 From: Eric Rescorla To: Joe Touch In-Reply-To: <49809CBC.5080603@isi.edu> References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <49808E94.8050107@isi.edu> <20090128175345.C434E50822@romeo.rtfm.com> <49809CBC.5080603@isi.edu> 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") Message-Id: <20090129065500.243E550822@romeo.rtfm.com> Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 28 Jan 2009 09:58:20 -0800, Joe Touch wrote: > Eric Rescorla wrote: > >> I've already shown a way to achieve this without requiring the use of > >> the NEW key, i.e., that used two KeyIDs with the OLD key, using the > >> change in the KeyID to inform the endpoints. I've also described in that > >> email a way to achieve this using the current API, without asking TCP-AO > >> to generate new packets or to do anything conditional _inside_ TCP-AO; > >> this can (and, IMO, should) all be accomplished with an external > >> mechanism, with __no__ impact on the stack. > > > > I read your mechanism, but I'm not sure it works. > > > > The basic unit of operation here isn't keys but key-ids. It's true that > > in your example key-id 6 refers to the same key as key-id 5, but that's > > not something that the stack should be observing. > > The stack doesn't observe it; the stack reports it if asked to an > external process. As I've indicated before, I think this whole external process thing is overcomplicating matters. Key management daemons are a bug, not a feature, and it would be much better if things could be constructed so the TCP-AO module would do everything. > > If your point is that at the time I install key-id 5 I also install a > > dummy key-id 6, and use that purely for signalling, I agree that that > > would work, but it strikes me as extremely kludgy. > > It allows side A to tell side B when side A has a new key installed, > without causing any packets to fall on the floor on side B (note that > retransmissions, if received, could open the congestion window > inappropriately). > The mechanism I proposed achieved with no modifications to the TCP stack. Yes, by laying the burden on some as yet nonexistent key management mechanism. > The other mechanisms suggested all have the property of also using the > KeyID value as a signal. The only downside of the mechanism I proposed > is that is inefficient in the use of the KeyID space - however, the > space is large enough that this isn't an issue. That's far from the only downside. For one, consider what happens if key 7 is misconfigured. In Greg's system, everything works fine, because packets with MAC failures are dropped. In your system, the 5-6 transition is used to signal the availability of 7, but if that transition fails the connection just falls over. > > There's no natural > > connection between the switch from 5-6 and the switch from 5-7. > > Why should there be? IMO, it's up to the endpoints to decide how and > when to switch keys; key change coordination needs to be _enabled_ by > TCP-AO, but not provided by it. IMO, that's a KMS issue - whether > automated at the endpoints, or via a protocol. Again, I don't agree. TCP-AO should work fine without some additional KMS, and that includes having unsynchronized key changes work correctly. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 29 07:16:16 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452353A68DF; Thu, 29 Jan 2009 07:16:16 -0800 (PST) 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 0216D3A68DF for ; Thu, 29 Jan 2009 07:16:15 -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 UYnFDCpqnVFT for ; Thu, 29 Jan 2009 07:16:13 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D0D0A3A68DB for ; Thu, 29 Jan 2009 07:16:13 -0800 (PST) Received: from [75.210.185.39] (39.sub-75-210-185.myvzw.com [75.210.185.39]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0TFFGpU020019; Thu, 29 Jan 2009 07:15:18 -0800 (PST) Message-ID: <4981C803.8040504@isi.edu> Date: Thu, 29 Jan 2009 07:15:15 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Rescorla References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <49808E94.8050107@isi.edu> <20090128175345.C434E50822@romeo.rtfm.com> <49809CBC.5080603@isi.edu> <20090129065500.243E550822@romeo.rtfm.com> In-Reply-To: <20090129065500.243E550822@romeo.rtfm.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: > At Wed, 28 Jan 2009 09:58:20 -0800, > Joe Touch wrote: >> Eric Rescorla wrote: >>>> I've already shown a way to achieve this without requiring the use of >>>> the NEW key, i.e., that used two KeyIDs with the OLD key, using the >>>> change in the KeyID to inform the endpoints. I've also described in that >>>> email a way to achieve this using the current API, without asking TCP-AO >>>> to generate new packets or to do anything conditional _inside_ TCP-AO; >>>> this can (and, IMO, should) all be accomplished with an external >>>> mechanism, with __no__ impact on the stack. >>> I read your mechanism, but I'm not sure it works. >>> >>> The basic unit of operation here isn't keys but key-ids. It's true that >>> in your example key-id 6 refers to the same key as key-id 5, but that's >>> not something that the stack should be observing. >> The stack doesn't observe it; the stack reports it if asked to an >> external process. > > As I've indicated before, I think this whole external process thing > is overcomplicating matters. Key management daemons are a bug, > not a feature, and it would be much better if things could > be constructed so the TCP-AO module would do everything. > > >>> If your point is that at the time I install key-id 5 I also install a >>> dummy key-id 6, and use that purely for signalling, I agree that that >>> would work, but it strikes me as extremely kludgy. >> It allows side A to tell side B when side A has a new key installed, >> without causing any packets to fall on the floor on side B (note that >> retransmissions, if received, could open the congestion window >> inappropriately). >> The mechanism I proposed achieved with no modifications to the TCP stack. > > Yes, by laying the burden on some as yet nonexistent key management > mechanism. We can bury the mechanism I suggest inside TCP-AO if desired, but I think that just ends up making it even more heavyweight. Automated key management is a mechanism that does not need to be inside TCP-AO - we were given that direction by the ADs from the start. >> The other mechanisms suggested all have the property of also using the >> KeyID value as a signal. The only downside of the mechanism I proposed >> is that is inefficient in the use of the KeyID space - however, the >> space is large enough that this isn't an issue. > > That's far from the only downside. > > For one, consider what happens if key 7 is misconfigured. In Greg's > system, everything works fine, because packets with MAC failures are > dropped. I cannot believe TCP-AO needs to handle misconfigured keys. This is supposed to be a lightweight mechanism. > In your system, the 5-6 transition is used to signal the > availability of 7, but if that transition fails the connection just > falls over. It's trivial to handle misconfigured keys in a similar fashion in the mechanism I proposed - when you get keyID6, you switch to using keyID7; if you don't get ACKs after some timeout, you revert back. Again, this can be done without burying the mechanism inside TCP (you can do it by sampling the keyIDs received). >>> There's no natural >>> connection between the switch from 5-6 and the switch from 5-7. >> Why should there be? IMO, it's up to the endpoints to decide how and >> when to switch keys; key change coordination needs to be _enabled_ by >> TCP-AO, but not provided by it. IMO, that's a KMS issue - whether >> automated at the endpoints, or via a protocol. > > Again, I don't agree. TCP-AO should work fine without some additional > KMS, and that includes having unsynchronized key changes work correctly. TCP-AO *supports* key management; it doesn't include it. Synchronizing key changes is key management. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmByAMACgkQE5f5cImnZruddwCg3ZkQCiYv/I7nhosYMvXVYCwL odoAoKUq3Fxsu0SN9crhAwC3di60GBJ1 =60My -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 29 07:36:36 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0285128C1E8; Thu, 29 Jan 2009 07:36:36 -0800 (PST) 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 485AB28C1E8 for ; Thu, 29 Jan 2009 07:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 4cuh3ZZaLxN5 for ; Thu, 29 Jan 2009 07:36:34 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3D6DF28C0ED for ; Thu, 29 Jan 2009 07:36:34 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2136150823; Thu, 29 Jan 2009 07:52:51 -0800 (PST) Date: Thu, 29 Jan 2009 07:52:51 -0800 From: Eric Rescorla To: Joe Touch In-Reply-To: <4981C803.8040504@isi.edu> References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <49808E94.8050107@isi.edu> <20090128175345.C434E50822@romeo.rtfm.com> <49809CBC.5080603@isi.edu> <20090129065500.243E550822@romeo.rtfm.com> <4981C803.8040504@isi.edu> 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") Message-Id: <20090129155251.2136150823@romeo.rtfm.com> Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 29 Jan 2009 07:15:15 -0800, Joe Touch wrote: > Eric Rescorla wrote: > > At Wed, 28 Jan 2009 09:58:20 -0800, > >> It allows side A to tell side B when side A has a new key installed, > >> without causing any packets to fall on the floor on side B (note that > >> retransmissions, if received, could open the congestion window > >> inappropriately). > >> The mechanism I proposed achieved with no modifications to the TCP stack. > > > > Yes, by laying the burden on some as yet nonexistent key management > > mechanism. > > We can bury the mechanism I suggest inside TCP-AO if desired, but I > think that just ends up making it even more heavyweight. Automated key > management is a mechanism that does not need to be inside TCP-AO - we > were given that direction by the ADs from the start. I don't consider this to be automated key management, and I don't think it's very productive to argue about the direction from the ADs gave us. My understanding from the discussion in MSP was that there was general WG consensus that the protocol ought to include some mechanism for automatic switchover of manually configured keys without real-time coordination. The minutes aren't as explicit as one might like but sort of reflect this when they say: "***ACTION*** GL will write the text up explaining all of this" That isn't to say you need to love Greg's mechanism, but if you think the WG shouldn't do this sort of thing at all, I think we need a more meta discussion, perhaps requiring more time in SFO. > >> The other mechanisms suggested all have the property of also using the > >> KeyID value as a signal. The only downside of the mechanism I proposed > >> is that is inefficient in the use of the KeyID space - however, the > >> space is large enough that this isn't an issue. > > > > That's far from the only downside. > > > > For one, consider what happens if key 7 is misconfigured. In Greg's > > system, everything works fine, because packets with MAC failures are > > dropped. > > I cannot believe TCP-AO needs to handle misconfigured keys. This is > supposed to be a lightweight mechanism. I agree it should be a lightweight mechanism, but as I took it your argument is that we don't need an in protocol switchover mechanism because it could be done with the external mechanism you propose. My point is that your external mechanism is inferior in this respect, which motivates an internal mechanism. This isn't the only downside, however. Your mechanism also entails significantly more user intervention in the switchover process to install these dummy keys. I don't consider that a feature. > > In your system, the 5-6 transition is used to signal the > > availability of 7, but if that transition fails the connection just > > falls over. > > It's trivial to handle misconfigured keys in a similar fashion in the > mechanism I proposed - when you get keyID6, you switch to using keyID7; > if you don't get ACKs after some timeout, you revert back. Again, this > can be done without burying the mechanism inside TCP (you can do it by > sampling the keyIDs received). Well, you've now sort of reinvented the mechanism I originally suggested and which is in Greg's message, but this is worse IMO because substantial numbers of packets may be lost at one time before you can switch over. Granted, this only happens with misconfiguration but it makes misconfiguration quite bad. And the logic around failure also becomes quite complicated. How long do I wait before I decide the other side has screwed up? > >>> There's no natural > >>> connection between the switch from 5-6 and the switch from 5-7. > >> Why should there be? IMO, it's up to the endpoints to decide how and > >> when to switch keys; key change coordination needs to be _enabled_ by > >> TCP-AO, but not provided by it. IMO, that's a KMS issue - whether > >> automated at the endpoints, or via a protocol. > > > > Again, I don't agree. TCP-AO should work fine without some additional > > KMS, and that includes having unsynchronized key changes work correctly. > > TCP-AO *supports* key management; it doesn't include it. Synchronizing > key changes is key management. This seems like a definitional argument. As I said at the beginning, it was my read of the discussion in MSP that the WG agreed there should be such a mechanism. I think that having one would be a good thing. If that's key management, then make the most of it. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 29 09:17:20 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521B13A6A45; Thu, 29 Jan 2009 09:17:20 -0800 (PST) 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 259EC3A6A3D for ; Thu, 29 Jan 2009 09:17:19 -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 HoNoMD3TtX1t for ; Thu, 29 Jan 2009 09:17:18 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 261BB3A6920 for ; Thu, 29 Jan 2009 09:17:18 -0800 (PST) Received: from [75.208.173.56] (56.sub-75-208-173.myvzw.com [75.208.173.56]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0THGaqS017691; Thu, 29 Jan 2009 09:16:38 -0800 (PST) Message-ID: <4981E474.6060402@isi.edu> Date: Thu, 29 Jan 2009 09:16:36 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Rescorla References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <49808E94.8050107@isi.edu> <20090128175345.C434E50822@romeo.rtfm.com> <49809CBC.5080603@isi.edu> <20090129065500.243E550822@romeo.rtfm.com> <4981C803.8040504@isi.edu> <20090129155251.2136150823@romeo.rtfm.com> In-Reply-To: <20090129155251.2136150823@romeo.rtfm.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric (et al.), To others - it might be useful to weigh in on this discussion... Eric Rescorla wrote: > At Thu, 29 Jan 2009 07:15:15 -0800, ... >> We can bury the mechanism I suggest inside TCP-AO if desired, but I >> think that just ends up making it even more heavyweight. Automated key >> management is a mechanism that does not need to be inside TCP-AO - we >> were given that direction by the ADs from the start. > > I don't consider this to be automated key management, and I don't > think it's very productive to argue about the direction from the ADs > gave us. My understanding from the discussion in MSP was that there > was general WG consensus that the protocol ought to include some > mechanism for automatic switchover of manually configured keys > without real-time coordination. The minutes aren't as explicit > as one might like but sort of reflect this when they say: > > "***ACTION*** GL will write the text up explaining all of this" Greg was a proponent of it, and we were all interested in hearing what he was thinking; I don't recall anything beyond interest in seeing the details. Upon examining it in detail, it involves coupling directly with TCP exchanges in a way I think is out of scope based on what I recall the ADs saying - they can certainly remind us of what they're thinking now... > That isn't to say you need to love Greg's mechanism, but if you > think the WG shouldn't do this sort of thing at all, I think we > need a more meta discussion, perhaps requiring more time > in SFO. My view is that TCP-AO MUST support a mechanism for key coordination - which I believe was consensus in the design team at least. I prefer TCP-AO not to include that mechanism internally, to keep things simple. That's just a preference, though. I do think that mechanisms that couple tightly to a particular segment exchange should be out of scope, however. ... >>> In your system, the 5-6 transition is used to signal the >>> availability of 7, but if that transition fails the connection just >>> falls over. >> It's trivial to handle misconfigured keys in a similar fashion in the >> mechanism I proposed - when you get keyID6, you switch to using keyID7; >> if you don't get ACKs after some timeout, you revert back. Again, this >> can be done without burying the mechanism inside TCP (you can do it by >> sampling the keyIDs received). > > Well, you've now sort of reinvented the mechanism I originally > suggested and which is in Greg's message, Not really; the difference is that in my example side A can tell side B it's ready to switch keys without ANY impact to side B; side B can switchover when its ready. Further, my mechanism does not require tight coupling with TCP segments being exchanged - it can be done through the API, with zero impact to the TCP implementation. > but this is worse IMO because > substantial numbers of packets may be lost at one time before you can > switch over. Yes, packets are lost when you switchover and the key is wrong in my mechanism. However, NO packets are lost when the key is right, vs. Greg's mechanism which loses all probe packets until the other side is ready. The impact of the lost probes depends on the variant used; if no new TCP segments are generated, then the lost probes impact TCP's congestion control. If new TCP segments are generated, the implementation needs to be tightly coupled with TCP (which, again, I was expecting we were trying to avoid). > Granted, this only happens with misconfiguration but it > makes misconfiguration quite bad. And the logic around failure also > becomes quite complicated. How long do I wait before I decide the > other side has screwed up? IMO, that's the benefit - it's up to the user, not the TCP-AO implementation to decide that. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmB5HQACgkQE5f5cImnZrtNvQCgnfJB1dfoGZErisfkDYxOASRu UiYAoPhhqqLDlBrSde0y7uSbBzrMhHCl =RxsO -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 29 16:17:27 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A383A68DC; Thu, 29 Jan 2009 16:17:27 -0800 (PST) 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 CE89228C185 for ; Thu, 29 Jan 2009 16:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SORTED_RECIPS=1.125] 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 gPeWgKE7cioy for ; Thu, 29 Jan 2009 16:17:25 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C0A1C3A69B6 for ; Thu, 29 Jan 2009 16:17:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,347,1231113600"; d="scan'208";a="135424793" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 30 Jan 2009 00:17:07 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0U0H7I3017651; Thu, 29 Jan 2009 16:17:07 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0U0H4YM004862; Fri, 30 Jan 2009 00:17:07 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jan 2009 16:17:07 -0800 Received: from [128.107.163.184] ([128.107.163.184]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jan 2009 16:17:07 -0800 In-Reply-To: <20090128162756.3799450822@romeo.rtfm.com> References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Weis Date: Thu, 29 Jan 2009 16:18:26 -0800 To: Eric Rescorla X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 30 Jan 2009 00:17:07.0115 (UTC) FILETIME=[15D74FB0:01C98270] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5770; t=1233274627; x=1234138627; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Re=3A=20TCP-AO=3A=20Text=20for=20New_Key=20Proc ess |Sender:=20; bh=LdJ69LZ5KswC/VEWMyH3Q2VEnjZquDmIYHcOk/oqBHg=; b=IJeOFapkTeI4X5sWBxeHfv+8BtWpIvYO87ULmSBO/LyuTVaXvl90++NcCD YOw+7C9QprVVl0BS4GFfErcvoUhYW1I6V1N5Yt9O6EBWnbJUORYtOBT5U1rf 1VS+ZnPxG0; Authentication-Results: sj-dkim-3; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: tcpm@ietf.org, Allison Mankin , Joe Touch , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The message below summarizes the problem nicely. On Jan 28, 2009, at 8:27 AM, Eric Rescorla wrote: > At Tue, 27 Jan 2009 13:34:20 -0800, > Joe Touch wrote: >> I'll kick off discussion on this point on the list. >> >> IMO, this mechanism is not viable for TCP-AO; it requires generating >> (and consuming) TCP segments that a native TCP would not generate. >> I was >> under the assumption that our design space was as close to TCP MD5 as >> possible, i.e., augment existing segments with a new option, but >> neither >> generate nor consume new segments. > > I think it's important to separate two issues: > > 1. How can an implementation decide when it's safe to use a newly > installed > key? > 2. How can an implementation help a peer implementation make that > decision. > > I think it's pretty clear that the most natural way to answer question > (1) is "when you see a segment protected with that key". > Unfortunately, > this creates a deadlock problem since both sides are waiting for the > other side to use the key. Thus, we need a combination of two > methods: > > 1. If a node has two keys, OLD and NEW, as soon as it sees a segment > from the peer protected with NEW, it starts sending with NEW. > 2. If a node has two keys, OLD and NEW, and it's still using OLD > it occasionally experimentally sends a segment with NEW (probing). > > Taken together, these rules allow a clean transition, since both > nodes are in probing state until one node receives a packet with > NEW, at which point it switches over and the peer soon follows. > > The question then becomes how the probing mechanism works. At a > high level, there are two options: > > 1. Probe with packets that the TCP stack would already send. > 2. Generate new segments to use explicitly as probes. > > The advantage of (1) is obviously minimal impact on the stack, > but may mean that segments are lost and could unless cere is taken, > exert false congestion feedback. The advantage of (2) is that it > is less likely to create false congestion feedback, but it requires > more changes to the stack and of course creates additional traffic > on the wire. Greg's mechanism is of course of type (2). > > -Ekr Probing implies "using a key optimistically", whereby the sender is taking a substantial risk that the peer does not yet have knowledge of that key. I don't particularly like either option above since they are both highly likely to result in significant change to the operation of the TCP session. Joe mentioned a third approach. Summarizing the discussion, rather than "probe" with segments that the TCP stack would already send, his approach would add a signal to TCP segments noting that a new master key was available. This helps a peer implementation make the decision to move to a new key (i.e., the problem we're trying to solve) without actually using the new key. This can break the deadlock without the actual use of the new key. I favor this approach, but not the mechanism. Joe's idea consumes one extra KeyID value for each real KeyID. The example given was to allocate both KeyID 5 and KeyID 6 when using KeyID 5. Signaling the presence of a new key comes by moving to KeyID 6. But overloading KeyIDs is not ideal -- in particular, recall that KeyID values are chosen by some external entity (e.g., a human or some automated key management system). I'm really not confident that a human will always appreciate that they can only configure "odd" KeyID values, for example. Furthermore, in order to guarantee interoperability I believe that this would have to be described in TCP-AO. We would want to avoid different implementations have different conventions, and not be able to set the same KeyIDs! This could be a fair amount of addition to TCP-AO. A better approach is to steal a bit from the KeyID field, and give it the meaning "I have a new KeyID". This is an explicit marking with a clear meaning. There's no reason the KeyID has to consume 8 bits -- KeyIDs should be associated with a single peer, and even 7 bits worth of simultaneous KeyIDs should be more than enough. A system configured with a new KeyID for that peer sets the "new KeyID bit"; a system which also has a new KeyID begins use of it when it sees that bit set. As far as I can tell, stealing this bit has a negligible effect on the current definition of TCP-AO. Some further comments addressing other discussion in this thread: - No external entity has to be present in this approach. - It's true that the two systems could have made an error in stalling a new set of policy, and automatically switching to a new KeyID could result in peers that cannot communicate. It is a plausible situation when the values are manually configured. I'm personally willing to make that tradeoff for a simpler TCP stack. This error should rarely occur in the presence of a future automated key management method. One more thought ... it seems to me that with probe-based approaches a man-in-the-middle can prevent the session ever moving to the new key. This would be done by dropping frames containing a new KeyID, forcing the TCP session continue with an old key. Continued use of the old key indefinitely may not be detected by operations staff. On the other hand, the presences of a "new KeyID bit" would requires a man-in-the-middle to disrupt the TCP session entirely, which is not a new attack on TCP, and also immediately visible to operations staff. Brian -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 29 16:19:46 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0728028C1F9; Thu, 29 Jan 2009 16:19:46 -0800 (PST) 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 5D7B73A689F; Thu, 29 Jan 2009 16:19:44 -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 zw2bSZk7PdPo; Thu, 29 Jan 2009 16:19:43 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id AE9F53A6859; Thu, 29 Jan 2009 16:19:43 -0800 (PST) Received: from [75.209.223.67] (67.sub-75-209-223.myvzw.com [75.209.223.67]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0U0JDnx005827; Thu, 29 Jan 2009 16:19:15 -0800 (PST) Message-ID: <49824780.9080808@isi.edu> Date: Thu, 29 Jan 2009 16:19:12 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Chris Newman References: <200901211957.UAA02570@TR-Sys.de> <1FFDE2586B687DAD64427796@446E7922C82D299DB29D899F> In-Reply-To: <1FFDE2586B687DAD64427796@446E7922C82D299DB29D899F> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Alfred H?nes , tcpm Extensions WG , iesg@ietf.org Subject: Re: [tcpm] [Tsvwg] API related DISCUSS for draft-ietf-tcpm-tcp-uto 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Newman wrote: > I absolutely agree with your position except the statement about the > IETF refraining from APIs (we have done APIs such as getaddrinfo, > advanced sockets, LDAP C API, GSSAPI, etc). If you read my discuss > position, I am not asking for inclusion of the API in this spec, but I > am asking for the specification to be revised to either: > > * Make it clear the intention is to have communication of this > information between > application protocol implementations and the TCP stack. IMO, this is OK since it's in the spirit of explaining the impact to the TCP API, as specified in RFC793. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmCR4AACgkQE5f5cImnZrvXxgCg61oYUAUexCK9FzXh25qBUwpB yokAn06iIlb6yl7O0yTNAHn/SSXpz8MS =TFoC -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 29 16:25:28 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84AAB28C239; Thu, 29 Jan 2009 16:25:28 -0800 (PST) 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 AFADC28C239 for ; Thu, 29 Jan 2009 16:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, SORTED_RECIPS=1.125] 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 Avdr3gfa7p4T for ; Thu, 29 Jan 2009 16:25:20 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8101628C227 for ; Thu, 29 Jan 2009 16:25:17 -0800 (PST) Received: from [75.209.223.67] (67.sub-75-209-223.myvzw.com [75.209.223.67]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0U0OMiJ006797; Thu, 29 Jan 2009 16:24:25 -0800 (PST) Message-ID: <498248B5.1080003@isi.edu> Date: Thu, 29 Jan 2009 16:24:21 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Brian Weis References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> In-Reply-To: X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Weis wrote: ... > Joe mentioned a third approach. Summarizing the discussion, rather than > "probe" with segments that the TCP stack would already send, his > approach would add a signal to TCP segments noting that a new master key > was available. This helps a peer implementation make the decision to > move to a new key (i.e., the problem we're trying to solve) without > actually using the new key. This can break the deadlock without the > actual use of the new key. > > I favor this approach, but not the mechanism. Joe's idea consumes one > extra KeyID value for each real KeyID. The example given was to allocate > both KeyID 5 and KeyID 6 when using KeyID 5. Signaling the presence of a > new key comes by moving to KeyID 6. But overloading KeyIDs is not ideal > -- in particular, recall that KeyID values are chosen by some external > entity (e.g., a human or some automated key management system). I'm > really not confident that a human will always appreciate that they can > only configure "odd" KeyID values, for example. Furthermore, in order to > guarantee interoperability I believe that this would have to be > described in TCP-AO. We would want to avoid different implementations > have different conventions, and not be able to set the same KeyIDs! This > could be a fair amount of addition to TCP-AO. > > A better approach is to steal a bit from the KeyID field, and give it > the meaning "I have a new KeyID". The problem with this sort of bit is that we would need to know when it is set and when it is clearable; this requires coordinating state between the endpoints. The flag has meaning only in the context of a particular keyID, which is why it is equivalent to using a new keyID value. Further, using keyIDs allows the user/KMS/etc to have a variety of ways to pick new keys. E.g., if there are one of two possible future keys: key A = keyID 9 key A = keyID 10 key A = keyID 11 keyB = keyID 12 keyB = keyID 13 Use keyID=9 for the 'old key' with no new changes pending. Use keyID=11 to signal use of key B, and use keyID=12 to signal use of keyID=13. There are other things that keyIDs can be used to coordinate - and this is exactly why it's not useful to carve bits out for specific meaning. The meaning should be determined by the user/KMS. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmCSLUACgkQE5f5cImnZrs4QwCfdOq2iH4mXHVxlTmQETSBdLQD leEAn0GNipkeF66Et5lmaswnZ3+fQPTs =yjNn -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 29 17:34:32 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2C228C185; Thu, 29 Jan 2009 17:34:32 -0800 (PST) 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 A52153A6ACD for ; Thu, 29 Jan 2009 17:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 ork8G2s0ipF0 for ; Thu, 29 Jan 2009 17:34:30 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7D8083A68DC for ; Thu, 29 Jan 2009 17:34:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,347,1231113600"; d="scan'208";a="239473770" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Jan 2009 01:34:12 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0U1YC7e017696; Thu, 29 Jan 2009 17:34:12 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0U1YCiQ011967; Fri, 30 Jan 2009 01:34:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jan 2009 17:34:12 -0800 Received: from [128.107.163.184] ([128.107.163.184]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jan 2009 17:34:11 -0800 In-Reply-To: <498248B5.1080003@isi.edu> References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <498248B5.1080003@isi.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Weis Date: Thu, 29 Jan 2009 17:35:31 -0800 To: Joe Touch X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 30 Jan 2009 01:34:11.0944 (UTC) FILETIME=[DA743680:01C9827A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4008; t=1233279252; x=1234143252; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Re=3A=20TCP-AO=3A=20Text=20for=20New_Key=20Proc ess |Sender:=20; bh=nee1SUiacjbscpFFLJmofAtkPkmzcmXwy+S35JMkhl4=; b=uO9VD8x9MeLlMfRXYtrTK10Lgd8Y5+mL7Lb3yLhYLoTEnaTxjMmpW8DHiu bGMHKWWij4Vg/0Vot3us/W4erVacb+LkcEHClsi8+4Oldl+CbqrpiHdkxuM2 nQUHvLSbAOAuQMn0py9Y8u7aRVeBSqnAqfop+pfy7guv3ha0YjuH8=; Authentication-Results: sj-dkim-1; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi Joe, On Jan 29, 2009, at 4:24 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Brian Weis wrote: > ... >> Joe mentioned a third approach. Summarizing the discussion, rather >> than >> "probe" with segments that the TCP stack would already send, his >> approach would add a signal to TCP segments noting that a new >> master key >> was available. This helps a peer implementation make the decision to >> move to a new key (i.e., the problem we're trying to solve) without >> actually using the new key. This can break the deadlock without the >> actual use of the new key. >> >> I favor this approach, but not the mechanism. Joe's idea consumes one >> extra KeyID value for each real KeyID. The example given was to >> allocate >> both KeyID 5 and KeyID 6 when using KeyID 5. Signaling the >> presence of a >> new key comes by moving to KeyID 6. But overloading KeyIDs is not >> ideal >> -- in particular, recall that KeyID values are chosen by some >> external >> entity (e.g., a human or some automated key management system). I'm >> really not confident that a human will always appreciate that they >> can >> only configure "odd" KeyID values, for example. Furthermore, in >> order to >> guarantee interoperability I believe that this would have to be >> described in TCP-AO. We would want to avoid different implementations >> have different conventions, and not be able to set the same >> KeyIDs! This >> could be a fair amount of addition to TCP-AO. >> >> A better approach is to steal a bit from the KeyID field, and give it >> the meaning "I have a new KeyID". > > The problem with this sort of bit is that we would need to know > when it > is set and when it is clearable; this requires coordinating state > between the endpoints. Each TCP peer sets the bit independently, at such time as a new KeyID is provided to the local system that matches policy for an existing TCP session. I.e., the manual key management logic or automated key management system. The station clears the bit when it begins transmitting with a new KeyID. It begins transmitting with the new KeyID because it observes the peer using the new KeyID (as described earlier in this thread). > The flag has meaning only in the context of a particular keyID, > which is > why it is equivalent to using a new keyID value. Further, using keyIDs > allows the user/KMS/etc to have a variety of ways to pick new keys. > E.g., if there are one of two possible future keys: > > key A = keyID 9 > key A = keyID 10 > key A = keyID 11 > > keyB = keyID 12 > keyB = keyID 13 > > Use keyID=9 for the 'old key' with no new changes pending. Use > keyID=11 > to signal use of key B, and use keyID=12 to signal use of keyID=13. > There are other things that keyIDs can be used to coordinate - and > this > is exactly why it's not useful to carve bits out for specific meaning. > The meaning should be determined by the user/KMS. Recall that TCP-AO is meant for BGP and LDP. Neither one needs much more than an "old key" and "new key" per peer. Going to the extent you describe here is way overkill. I know you don't like defining bits in a header, but sometimes they solve a simple problem in a straightforward way. If there's really an application that needs what you describe above, it will be complicated enough that it will need automated KMS, and that KMS can instruct TCP-AO exactly which key it wants to be used using a local mechanism. Brian > Joe > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkmCSLUACgkQE5f5cImnZrs4QwCfdOq2iH4mXHVxlTmQETSBdLQD > leEAn0GNipkeF66Et5lmaswnZ3+fQPTs > =yjNn > -----END PGP SIGNATURE----- -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 29 18:27:59 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96583A6AA4; Thu, 29 Jan 2009 18:27:59 -0800 (PST) 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 101953A6AA4 for ; Thu, 29 Jan 2009 18:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 UOZF9EElgsZv for ; Thu, 29 Jan 2009 18:27:58 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 0F21B3A6870 for ; Thu, 29 Jan 2009 18:27:58 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E094750822; Thu, 29 Jan 2009 18:44:17 -0800 (PST) Date: Thu, 29 Jan 2009 18:44:17 -0800 From: Eric Rescorla To: Joe Touch In-Reply-To: <4981E474.6060402@isi.edu> References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <49808E94.8050107@isi.edu> <20090128175345.C434E50822@romeo.rtfm.com> <49809CBC.5080603@isi.edu> <20090129065500.243E550822@romeo.rtfm.com> <4981C803.8040504@isi.edu> <20090129155251.2136150823@romeo.rtfm.com> <4981E474.6060402@isi.edu> 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") Message-Id: <20090130024417.E094750822@romeo.rtfm.com> Cc: tcpm@ietf.org, Allison Mankin , skonduru@juniper.net Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 29 Jan 2009 09:16:36 -0800, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Eric (et al.), > > To others - it might be useful to weigh in on this discussion... > > Eric Rescorla wrote: > > At Thu, 29 Jan 2009 07:15:15 -0800, > ... > >> We can bury the mechanism I suggest inside TCP-AO if desired, but I > >> think that just ends up making it even more heavyweight. Automated key > >> management is a mechanism that does not need to be inside TCP-AO - we > >> were given that direction by the ADs from the start. > > > > I don't consider this to be automated key management, and I don't > > think it's very productive to argue about the direction from the ADs > > gave us. My understanding from the discussion in MSP was that there > > was general WG consensus that the protocol ought to include some > > mechanism for automatic switchover of manually configured keys > > without real-time coordination. The minutes aren't as explicit > > as one might like but sort of reflect this when they say: > > > > "***ACTION*** GL will write the text up explaining all of this" > > Greg was a proponent of it, and we were all interested in hearing what > he was thinking; I don't recall anything beyond interest in seeing the > details. Upon examining it in detail, it involves coupling directly with > TCP exchanges in a way I think is out of scope based on what I recall > the ADs saying - they can certainly remind us of what they're thinking > now... Well, as I said earlier, there are ways to do this that don't couple to TCP. I.e., TCP-AO just chooses the occasional existing packet to probe with. > > Well, you've now sort of reinvented the mechanism I originally > > suggested and which is in Greg's message, > > Not really; the difference is that in my example side A can tell side B > it's ready to switch keys without ANY impact to side B; side B can > switchover when its ready. Yes, but you rely on correct receipt to confirm the switch. > > but this is worse IMO because > > substantial numbers of packets may be lost at one time before you can > > switch over. > > Yes, packets are lost when you switchover and the key is wrong in my > mechanism. However, NO packets are lost when the key is right, vs. > Greg's mechanism which loses all probe packets until the other side is > ready. The impact of the lost probes depends on the variant used; if no > new TCP segments are generated, then the lost probes impact TCP's > congestion control. Yeah, I'm having a really hard time getting worked up about the impact of losing one packet every hour or so. > > Granted, this only happens with misconfiguration but it > > makes misconfiguration quite bad. And the logic around failure also > > becomes quite complicated. How long do I wait before I decide the > > other side has screwed up? > > IMO, that's the benefit - it's up to the user, not the TCP-AO > implementation to decide that. I don't consider that a benefit in terms of either interop or user confusion. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 29 19:29:04 2009 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937CA3A6887; Thu, 29 Jan 2009 19:29:04 -0800 (PST) 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 DD1093A6887 for ; Thu, 29 Jan 2009 19:29:02 -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 mWDboaUGONVg for ; Thu, 29 Jan 2009 19:29:02 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id E67F03A687F for ; Thu, 29 Jan 2009 19:29:01 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id DAEEE2D8068; Thu, 29 Jan 2009 21:28:42 -0600 (CST) Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160] (may be forged)) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n0U3Skao016208; Thu, 29 Jan 2009 21:28:46 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Thu, 29 Jan 2009 21:28:42 -0600 From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: Joe Touch , Eric Rescorla Date: Thu, 29 Jan 2009 21:28:47 -0600 Thread-Topic: [tcpm] TCP-AO: Text for New_Key Process Thread-Index: AcmCNWxxPNoAe9//S5e4hnDkJYRohgAUa48g Message-ID: References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <20090128162756.3799450822@romeo.rtfm.com> <49808E94.8050107@isi.edu> <20090128175345.C434E50822@romeo.rtfm.com> <49809CBC.5080603@isi.edu> <20090129065500.243E550822@romeo.rtfm.com> <4981C803.8040504@isi.edu> <20090129155251.2136150823@romeo.rtfm.com> <4981E474.6060402@isi.edu> In-Reply-To: <4981E474.6060402@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "skonduru@juniper.net" , "tcpm@ietf.org" , Allison Mankin Subject: Re: [tcpm] TCP-AO: Text for New_Key Process 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I mostly agree with Joe, and have some brief comments below: >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >Behalf Of Joe Touch >Sent: Thursday, January 29, 2009 12:17 PM > >Greg was a proponent of it, and we were all interested in hearing what >he was thinking; I don't recall anything beyond interest in seeing the >details. Upon examining it in detail, it involves coupling >directly with >TCP exchanges in a way I think is out of scope based on what I recall >the ADs saying - they can certainly remind us of what they're thinking >now... > >> That isn't to say you need to love Greg's mechanism, but if you >> think the WG shouldn't do this sort of thing at all, I think we >> need a more meta discussion, perhaps requiring more time >> in SFO. > >My view is that TCP-AO MUST support a mechanism for key coordination - >which I believe was consensus in the design team at least. > >I prefer TCP-AO not to include that mechanism internally, to >keep things >simple. That's just a preference, though. > >I do think that mechanisms that couple tightly to a particular segment >exchange should be out of scope, however. > The direction that we were always heading in was that TCPM will make sure the spec for AO permits automated changes of keys and won't be breaking other parts of TCP in the meantime. We understood that "permiting" or "supporting" the changeover in AO didn't mean actually being responsible for doing it all inside the TCP connection, and that the SECDIR would define a separate mechanism (not inside TCP) for this. To be done timely and without bugs, AO has to stay as simple as the needed security properties permit, so I have to agree with Joe. >> >> Well, you've now sort of reinvented the mechanism I originally >> suggested and which is in Greg's message, > >Not really; the difference is that in my example side A can tell side B >it's ready to switch keys without ANY impact to side B; side B can >switchover when its ready. Further, my mechanism does not require tight >coupling with TCP segments being exchanged - it can be done through the >API, with zero impact to the TCP implementation. This is a very important property given the level of complexity that we already have in TCP implementations to be robust under all sorts of circumstances and with various combinations of options in play. >> but this is worse IMO because >> substantial numbers of packets may be lost at one time before you can >> switch over. > >Yes, packets are lost when you switchover and the key is wrong in my >mechanism. However, NO packets are lost when the key is right, vs. >Greg's mechanism which loses all probe packets until the other side is >ready. The impact of the lost probes depends on the variant used; if no >new TCP segments are generated, then the lost probes impact TCP's >congestion control. If new TCP segments are generated, the >implementation needs to be tightly coupled with TCP (which, >again, I was >expecting we were trying to avoid). I agree, this should definitely be avoided. It's easy to specify wrong, and even easier to implement wrong. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm