From tcpm-bounces@ietf.org Sun Nov 2 17:49:26 2008 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 751F83A6BED; Sun, 2 Nov 2008 17:49:26 -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 9A7C63A6BED for ; Sun, 2 Nov 2008 17:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808] 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-H8iSKZTbej for ; Sun, 2 Nov 2008 17:49:24 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 79F993A6B57 for ; Sun, 2 Nov 2008 17:49:23 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2DF786B65A7; Sun, 2 Nov 2008 22:49:26 -0300 (ART) Received: from notebook.gont.com.ar (201-254-57-122.speedy.com.ar [201.254.57.122] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mA31n6fe020648; Sun, 2 Nov 2008 23:49:07 -0200 Message-Id: <200811030149.mA31n6fe020648@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Nov 2008 22:43:32 -0300 To: Joe Touch , Fernando Gont From: Fernando Gont In-Reply-To: <49088156.6020305@isi.edu> References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> 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]); Sun, 02 Nov 2008 22:49:24 -0300 (ART) Cc: tcpm@ietf.org, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello, Joe, Comments in-line.... > > So we have to issues: > > > > * Deprecate recv(2)/MSG_OOB and encourage SO_OOBINLINE. (with which you > > seem to agree) > >That sounds like a Unix man page update, not an RFC. RFC 793 specifies a minimalistic/generic API for TCP. Most (if not all) systems have misunderstood that API. And that's what I think should be clarified. recv(2)/MSG_OOB is simply an example of how the TCP API was misunderstood. > > * Update RFC 793/RFC1122 wrt where the UP points to, to reflect what > > everybody does and has been doing. (with which I don't know whether you > > agree or not). > >Either this is an implementation error or it updates our definition of PUSH. Push? Why Push? And, well, you may take it as an "implementation error". But everybody has been ding this for... how long?... twenty years? If you were to push TCP implementations to implement the RFC1122-mandated semantics of the urgent pointer, that would simply break existing applciations, as that change is not backwards-compatible. After twenty years of doing so, and with every stack doing it, it's completely unrealistic to expect any real system to move to the RFC1122 semantics of the Urgent Pointer (i.e., "the UP points to the last byte of urgent data" instead of "the urgent pointer points to the byte following the last byte of urgent data). Keeping things "as they are" simply means that anybody trying to analyze real traffic and interpret it according to the existing specs, will be puzzled. (FWIW, the same day I posted the announcement of our I-D, a TCP implementor of one of the major free OSes sent me an off-list note mentioning that he found our draft just in time, as he was in trouble trying to figure out what everybody was doing wrt TCP urgent data) >If the former, it can be noted in the next version of the TCP >implementation errors doc. If the latter, it would update 1122 - NOT >793. As Dave noted, 1122 supercedes 793 on this issue. Agreed. It would update RFC1122. >I don't like the idea of continuing to document implementations that do >not comply with current specs without either stating > a) this is BAD and should be fixed > b) this is GOOD and we're changing our spec We are aiming at "b", if you want. It's not really that it is "good". It simply is. It's the real world. Ignoring the real world simply helps to have the specs become irrelevant. >FWIW, so far, this looks to me like an implementation error, not a >reason to change the spec. At some point, the specs (RFC 793) were ambiguous. So implementations simply picked one of the possible intrepretations. The IETF later mandated the other possible interpretation. But nobody changed their stacks. And nobody will. At some point it may have been an implementation error. Nowadays... who cares? it's the de-facto standard. What do others think about all this? 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 Sun Nov 2 20:15:05 2008 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 283C928C0E1; Sun, 2 Nov 2008 20:15:05 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D744C3A6B67; Sun, 2 Nov 2008 20:15: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: <20081103041501.D744C3A6B67@core3.amsl.com> Date: Sun, 2 Nov 2008 20:15:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-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 : Improving TCP's Robustness to Blind In-Window Attacks Author(s) : A. Ramaiah, et al. Filename : draft-ietf-tcpm-tcpsecure-11.txt Pages : 27 Date : 2008-11-02 TCP has historically been considered protected against spoofed off- path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in [RFC0793]) to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-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-tcpsecure-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-02201440.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 Sun Nov 2 21:08:24 2008 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 E332D3A688E; Sun, 2 Nov 2008 21:08:24 -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 5A30E3A688E for ; Sun, 2 Nov 2008 21:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808] 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 ib6rBMH0UrLO for ; Sun, 2 Nov 2008 21:08:23 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 72AED3A6866 for ; Sun, 2 Nov 2008 21:08:22 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E81DA6B6598 for ; Mon, 3 Nov 2008 02:08:23 -0300 (ART) Received: from notebook.gont.com.ar (201-254-57-122.speedy.com.ar [201.254.57.122] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mA3583sM005136 for ; Mon, 3 Nov 2008 03:08:04 -0200 Message-Id: <200811030508.mA3583sM005136@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Nov 2008 02:00:33 -0300 To: tcpm@ietf.org From: Fernando Gont In-Reply-To: <20081103041501.D744C3A6B67@core3.amsl.com> References: <20081103041501.D744C3A6B67@core3.amsl.com> 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]); Mon, 03 Nov 2008 02:08:22 -0300 (ART) Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-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: , 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 01:15 a.m. 03/11/2008, Internet-Drafts@ietf.org wrote: >TCP has historically been considered protected against spoofed off- >path packet injection attacks by relying on the fact that it is >difficult to guess the 4-tuple (the source and destination IP >addresses and the source and destination ports) in combination with >the 32 bit sequence number(s). A combination of increasing window >sizes and applications using longer term connections (e.g. H-323 or >Border Gateway Protocol [RFC4271]) have left modern TCP >implementations more vulnerable to these types of spoofed packet >injection attacks. It was pointed out by a number of us (e.g., Joe Touch and me) that this document should probably reference the ongoing work at tsvwg on port randomization (http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-02.txt). Considering that nowadays TCP implementations such as that FreeBSD, OpenBSD, Linux, and Cisco itself do implement some form of ephemeral port randomization, some statements in the document wrt port randomization seem inacurate. (e.g., do *current* TCP implementations used for servicing BGP not randomize their ephemeral ports). (FWIW, I don't care about our doc being referenced.... but talking about guessing the connection-id while ignoring what is currently being done about ephemeral port selection doesn't seem quite right to me). 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 Mon Nov 3 12:30:04 2008 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 F06B128C24F; Mon, 3 Nov 2008 12:30:03 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7694D3A6BB8; Mon, 3 Nov 2008 12: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: <20081103203001.7694D3A6BB8@core3.amsl.com> Date: Mon, 3 Nov 2008 12:30:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-07.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 : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Author(s) : S. Floyd, I. Property Filename : draft-ietf-tcpm-ecnsyn-07.txt Pages : 33 Date : 2008-11-03 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document specifies the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmit timer). This document updates RFC 3168. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-07.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-ecnsyn-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03122057.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 Mon Nov 3 14:00:05 2008 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 603D128C2B7; Mon, 3 Nov 2008 14:00:05 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4125E28C144; Mon, 3 Nov 2008 14: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: <20081103220001.4125E28C144@core3.amsl.com> Date: Mon, 3 Nov 2008 14:00:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-02.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 : The TCP Authentication Option Author(s) : J. Touch, et al. Filename : draft-ietf-tcpm-tcp-auth-opt-02.txt Pages : 36 Date : 2008-11-03 This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static keying or an external, out-of-band key management mechanism; in either case, TCP-AO also protects connections when using the same key across repeated instances of a connection. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses its own option identifier, even though used mutually exclusive of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is fully compatible with the requirements for the replacement of TCP MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-auth-opt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03135128.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 Tue Nov 4 06:36:55 2008 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 0069A28C119; Tue, 4 Nov 2008 06:36: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 D75BA28C119 for ; Tue, 4 Nov 2008 06:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x72h--1yJLDn for ; Tue, 4 Nov 2008 06:36:53 -0800 (PST) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 272843A67AA for ; Tue, 4 Nov 2008 06:36:53 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id D2C2E2D803A; Tue, 4 Nov 2008 08:36:48 -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 mA4EalNY017026; Tue, 4 Nov 2008 08:36:47 -0600 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 08:36:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Nov 2008 08:36:47 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: intended status of UTO Thread-Index: Ack+isRnejiC/BZmSpyO+TiWeCz6Wg== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 04 Nov 2008 14:36:48.0838 (UTC) FILETIME=[C5015E60:01C93E8A] Subject: [tcpm] intended status of 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 Although UTO has finished last-call and been submitted for publication, Magnus has noted that there seemed to be a question during last call about its intended status that wasn't conclusively resolved. Our ADs would like to make sure that there isn't going to be a problem with publishing this as proposed standard, and need the WG's feedback in order to advance the document. By my homework, the charter item for UTO was written for a proposed standard. When I checked the archives, it looked like Pasi was the only WGLC commenter that argued for experimental, and on the other hand, Joe, Mark, Caitlin, and Toby all seemed to support it as proposed standard. Versions 04 through 09 of the draft include "Intended status: Standards Track". However, in the IETF 68 minutes, I found this: * Lars and chairs did not remember if this is going for experimental or proposed. Tim Shepard has preference for experimental. - Tim Shepherd: in San Diego asked this explicitly from chairs during agenda bashing, they said the plan is for Experimental. - Lars: ok _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 4 06:50:02 2008 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 703493A6962; Tue, 4 Nov 2008 06:50:02 -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 B68A33A6962 for ; Tue, 4 Nov 2008 06:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=0.807, 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 cAzQoFkOUabG for ; Tue, 4 Nov 2008 06:49:59 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 90C303A68AC for ; Tue, 4 Nov 2008 06:49:59 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA4Enftp023920; Tue, 4 Nov 2008 16:49:54 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 16:49:40 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 16:49:40 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 16:49:40 +0200 Received: from esdhcp030110.research.nokia.com (esdhcp030110.research.nokia.com [172.21.30.110]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id mA4EncGq006026; Tue, 4 Nov 2008 16:49:38 +0200 Message-Id: <6C82605A-BCD4-4201-BCF5-7E7D29A18D35@nokia.com> From: Lars Eggert To: "ext Eddy, Wesley M. (GRC-RCN0)[VZ]" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 4 Nov 2008 16:49:37 +0200 References: X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 04 Nov 2008 14:49:40.0252 (UTC) FILETIME=[90CDCDC0:01C93E8C] X-Nokia-AV: Clean Cc: tcpm@ietf.org Subject: Re: [tcpm] intended status of 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="===============2010944488==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============2010944488== Content-Type: multipart/signed; boundary=Apple-Mail-8-542358454; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-8-542358454 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit For the record, I don't care whether it goes PS or Exp. Lars (as an author) On 2008-11-4, at 16:36, ext Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > Although UTO has finished last-call and been submitted > for publication, Magnus has noted that there seemed to > be a question during last call about its intended status > that wasn't conclusively resolved. > > Our ADs would like to make sure that there isn't going > to be a problem with publishing this as proposed standard, > and need the WG's feedback in order to advance the document. > > By my homework, the charter item for UTO was written for > a proposed standard. When I checked the archives, it > looked like Pasi was the only WGLC commenter that argued > for experimental, and on the other hand, Joe, Mark, > Caitlin, and Toby all seemed to support it as proposed > standard. Versions 04 through 09 of the draft include > "Intended status: Standards Track". > > However, in the IETF 68 minutes, I found this: > * Lars and chairs did not remember if this is going for experimental > or > proposed. Tim Shepard has preference for experimental. > - Tim Shepherd: in San Diego asked this explicitly from chairs > during > agenda bashing, they said the plan is for Experimental. > - Lars: ok > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-8-542358454 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTEwNDE0NDkzOFowIwYJKoZI hvcNAQkEMRYEFNejlpXm6srimTxFbTD4rw4wad1tMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQB+Frh6sd3ErXq85YJuu/VUcFXu gIRw0OwWpu86g1O1Q3ZFIhh6q+Gv+EHBu1gLt78yDLie/mB5DrIeYHJJaLZHart7xK8bJcmIxJN1 3IQuMf3E6Y3bFUjqJjueP0oicYEIa93ae9H8g+4agTlye+P/fLEviTbLG7vumpAPWJBU1rgOBwV6 DX+96BhEWjlfySSeCwzSOSr1GC+rZoKNU3M4vEAkr9RiSDRwQnHn1Y1CSBQhl9ISdQ30Nq+hXz6c N0Mp6RaH83jyu/HopNVCjZ6FlDbYFnb2M++LIAr+TiDp00dcDRZtq/UhD1RcI2a6lFbCWWOOvMgE 4dhh8T6gMUvOAAAAAAAA --Apple-Mail-8-542358454-- --===============2010944488== 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 --===============2010944488==-- From tcpm-bounces@ietf.org Wed Nov 5 04:52:56 2008 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 8FA173A67B5; Wed, 5 Nov 2008 04:52:56 -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 500FD3A67B5 for ; Wed, 5 Nov 2008 04:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.001 X-Spam-Level: ** X-Spam-Status: No, score=2.001 tagged_above=-999 required=5 tests=[AWL=0.750, 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 kJp0hJeS5Cxg for ; Wed, 5 Nov 2008 04:52:54 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 8809B3A677E for ; Wed, 5 Nov 2008 04:52:53 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA102969488; Wed, 5 Nov 2008 13:51:28 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA01027; Wed, 5 Nov 2008 13:51:23 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200811051251.NAA01027@TR-Sys.de> To: tcpm@ietf.org Date: Wed, 5 Nov 2008 13:51:22 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: Re: [tcpm] intended status of 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 Folks, Since all the draft versions included "Intended status: Standards Track" since more than 24 months without interruption, and this time span included the WGLC period -- without complaints coming even far close to WG consensus --, changing this aim *now* would not make sense for me, unless strong new arguments can be shown up. Don't forget: This WG is chartered to maintenance and minor extensions of TCP. As this draft closes a gap in existing specifications, it does precisely that, and it should aim at an appropriate level on the Standards Track. For all these reasons, I strongly support *not changing* the intended status now. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 5 06:14:44 2008 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 5B43F3A6AC2; Wed, 5 Nov 2008 06:14:44 -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 CC0C13A6B8A for ; Wed, 5 Nov 2008 06:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.06 X-Spam-Level: X-Spam-Status: No, score=-6.06 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew2ZLXGrACFq for ; Wed, 5 Nov 2008 06:14:42 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BBA903A6AAF for ; Wed, 5 Nov 2008 06:14:41 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8913D224A1; Wed, 5 Nov 2008 15:14:09 +0100 (CET) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-08-4911a93d0d2e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 46FD4210FD; Wed, 5 Nov 2008 15:10:05 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 14:11:06 +0100 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 14:11:04 +0100 Message-ID: <49119B68.4040607@ericsson.com> Date: Wed, 05 Nov 2008 14:11:04 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" References: In-Reply-To: X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 05 Nov 2008 13:11:04.0968 (UTC) FILETIME=[F56ED880:01C93F47] X-Brightmail-Tracker: AAAAAA== Cc: tcpm@ietf.org Subject: Re: [tcpm] intended status of 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Eddy, Wesley M. (GRC-RCN0)[VZ] skrev: > Although UTO has finished last-call and been submitted > for publication, Magnus has noted that there seemed to > be a question during last call about its intended status > that wasn't conclusively resolved. > = > Our ADs would like to make sure that there isn't going > to be a problem with publishing this as proposed standard, > and need the WG's feedback in order to advance the document. > = > By my homework, the charter item for UTO was written for > a proposed standard. When I checked the archives, it > looked like Pasi was the only WGLC commenter that argued > for experimental, and on the other hand, Joe, Mark, > Caitlin, and Toby all seemed to support it as proposed > standard. Versions 04 through 09 of the draft include > "Intended status: Standards Track". > = > However, in the IETF 68 minutes, I found this: > * Lars and chairs did not remember if this is going for experimental > or > proposed. Tim Shepard has preference for experimental. > - Tim Shepherd: in San Diego asked this explicitly from chairs > during > agenda bashing, they said the plan is for Experimental. > - Lars: ok > = Hi, I had hoped the WG chairs would simply declare that standards track was the consensus of the WG last call. To me it is quite clear that this is the case. The old IETF 68 minutes are far prior to the WG last call. Thus I will declare that UTO will be IETF last called intended for Standards Track. If anyone object about this they can send in a IETF last call comment on this. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 5 07:24:34 2008 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 8745D28C144; Wed, 5 Nov 2008 07:24:34 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E74B23A6900; Wed, 5 Nov 2008 07:24:32 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081105152432.E74B23A6900@core3.amsl.com> Date: Wed, 5 Nov 2008 07:24:32 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-uto (TCP User Timeout Option) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org 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 received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP User Timeout Option ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13162&rfc_flag=0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 5 10:20:28 2008 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 9B0B428C18C; Wed, 5 Nov 2008 10:20: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 0F6DC28C1BF for ; Wed, 5 Nov 2008 10:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTSbH+5o4vQS for ; Wed, 5 Nov 2008 10:20:26 -0800 (PST) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id A32C73A68F1 for ; Wed, 5 Nov 2008 10:20:23 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id mA5IJsxk014212; Wed, 5 Nov 2008 10:19:54 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 10:19:53 -0800 Received: from [172.25.34.36] ([172.25.34.36]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 10:19:53 -0800 Message-Id: <3A807B31-473A-45BD-ABDC-BEB0CFF954F7@windriver.com> From: David Borman To: Magnus Westerlund In-Reply-To: <49119B68.4040607@ericsson.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 5 Nov 2008 12:19:49 -0600 References: <49119B68.4040607@ericsson.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 05 Nov 2008 18:19:53.0677 (UTC) FILETIME=[196777D0:01C93F73] Cc: tcpm@ietf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] intended status of 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Ok, I'll clarify it. The UTO document went through WGLC without = changing it to experimental, so it is standards track. Wes' message = explicitly brought up this point, so that people could object if they = felt that wasn't true. So far, no one has objected, so it is still = standards track. As Magnus notes, any late-comers that want to object = will now have to do this during the IETF last call. -David Borman, TCPM WG co-chair On Nov 5, 2008, at 7:11 AM, Magnus Westerlund wrote: > Eddy, Wesley M. (GRC-RCN0)[VZ] skrev: >> Although UTO has finished last-call and been submitted >> for publication, Magnus has noted that there seemed to >> be a question during last call about its intended status >> that wasn't conclusively resolved. >> >> Our ADs would like to make sure that there isn't going >> to be a problem with publishing this as proposed standard, >> and need the WG's feedback in order to advance the document. >> >> By my homework, the charter item for UTO was written for >> a proposed standard. When I checked the archives, it >> looked like Pasi was the only WGLC commenter that argued >> for experimental, and on the other hand, Joe, Mark, >> Caitlin, and Toby all seemed to support it as proposed >> standard. Versions 04 through 09 of the draft include >> "Intended status: Standards Track". >> >> However, in the IETF 68 minutes, I found this: >> * Lars and chairs did not remember if this is going for experimental >> or >> proposed. Tim Shepard has preference for experimental. >> - Tim Shepherd: in San Diego asked this explicitly from chairs >> during >> agenda bashing, they said the plan is for Experimental. >> - Lars: ok >> > > Hi, > > I had hoped the WG chairs would simply declare that standards track = > was > the consensus of the WG last call. To me it is quite clear that this = > is > the case. The old IETF 68 minutes are far prior to the WG last call. > Thus I will declare that UTO will be IETF last called intended for > Standards Track. If anyone object about this they can send in a IETF > last call comment on this. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > F=E4r=F6gatan 6 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > 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 Wed Nov 5 16:05:54 2008 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 D69883A687D; Wed, 5 Nov 2008 16:05:54 -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 573BE3A68F9 for ; Wed, 5 Nov 2008 16:05:53 -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 Q3w+KOilN0+B for ; Wed, 5 Nov 2008 16:05:52 -0800 (PST) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by core3.amsl.com (Postfix) with ESMTP id 263303A6829 for ; Wed, 5 Nov 2008 16:05:52 -0800 (PST) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_ewzpjQ3hGKRwasoqGgCZpA)" Received: from [192.168.1.132] ([70.132.1.164]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K9V00KLWXK9A940@asmtp011.mac.com> for tcpm@ietf.org; Wed, 05 Nov 2008 16:04:59 -0800 (PST) Message-id: <36235E15-9019-476A-9CA7-519026635558@mac.com> From: Sally Floyd To: tcpm Date: Wed, 05 Nov 2008 16:04:56 -0800 X-Mailer: Apple Mail (2.929.2) Cc: "K. K. Ramakrishnan" , Amit Mondal , Aleksandar Kuzmanovic Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-07.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 --Boundary_(ID_ewzpjQ3hGKRwasoqGgCZpA) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT We have (finally) revised draft-ietf-tcpm-ecnsyn, on "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", and are finally ready for it to complete the standardization process. Here is the story: The draft had finished Working Group Last Call, and been forwarded to the IESG for review. As a final step in revising the draft after the AD Evaluation, we (the authors) reran the simulations with an updated version of the ns-2 simulator, and found that in some highly congested scenarios, ECN+ would significantly increase the packet drop rate even further. (I am appending the 5/26/08 email below.) In response to this, we have added a change to ECN+, which in the new draft we call "ECN+/TryOnce". With ECN+/TryOnce, when an ECN-Capable SYN/ACK packet is ECN-marked, the TCP responder sends another SYN/ACK packet that is not ECN-Capable, and also reduces the initial window to one packet. ECN+/TryOnce shows most of the performance benefit of ECN+, and avoids the problem of increasing the packet drop rate in times of high congestion. I think it makes sense to pass this through the working group before going back to the IESG. However, I won't be at IETF in Minnesota, and am hoping that this can be done by email. The new version of the draft is at: "http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-07", and that web page also gives the differences with earlier versions of the draft. Any feedback would be appreciated. Many thanks, - Sally http://www.icir.org/floyd/ Begin forwarded message: > From: Lars Eggert > Date: May 28, 2008 7:35:26 AM PDT > To: ext Sally Floyd > Cc: Mark Allman , Aleksandar Kuzmanovic >, "K. K. Ramakrishnan" , Ted Faber >, Amit Mondal > Subject: Re: AD review: draft-ietf-tcpm-ecnsyn-05 > > Hi, > > thanks for the update. I'll move it back to a WG document in the > tracker in this case, and Ted and Mark will figure out what to do > with the new version when it comes out. > > On 2008-5-27, at 1:45, ext Sally Floyd wrote: >> We need to modify the mechanism in ECN+ to deal with severely >> congested networks. (I fixed a bug in the simulator some time ago, >> and the result was to uncover a problem with ECN+, in a few cases, >> in highly congested networks.) We are rerunning the simulations, >> and I will let you know as soon as we have a revised version of the >> draft. I think we will have to report back to the working group >> before moving on to the IESG. > > Thanks, > Lars Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: November 3, 2008 12:30:01 PM PST > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-07.txt > > 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 : Adding Explicit Congestion Notification (ECN) > Capability to TCP's SYN/ACK Packets > Author(s) : S. Floyd, I. Property > Filename : draft-ietf-tcpm-ecnsyn-07.txt > Pages : 33 > Date : 2008-11-03 > > This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK > packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting > an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK > packets. However, because of the high cost to the TCP transfer of > having a SYN/ACK packet dropped, with the resulting retransmit > timeout, this document specifies the use of ECN for the SYN/ACK > packet itself, when sent in response to a SYN packet with the two ECN > flags set in the TCP header, indicating a willingness to use ECN. > Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great > benefit to the TCP connection, avoiding the severe penalty of a > retransmit timeout for a connection that has not yet started placing > a load on the network. The TCP responder (the sender of the SYN/ACK > packet) must reply to a report of an ECN-marked SYN/ACK packet by > resending a SYN/ACK packet that is not ECN-Capable. If the resent > SYN/ACK packet is acknowledged, then the TCP responder reduces its > initial congestion window from two, three, or four segments to one > segment, thereby reducing the subsequent load from that connection on > the network. If instead the SYN/ACK packet is dropped, or for some > other reason the TCP responder does not receive an acknowledgement in > the specified time, the TCP responder follows TCP standards for a > dropped SYN/ACK packet (setting the retransmit timer). This document > updates RFC 3168. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-07.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. --Boundary_(ID_ewzpjQ3hGKRwasoqGgCZpA) Content-type: message/external-body; x-unix-mode=0666; name=draft-ietf-tcpm-ecnsyn-07.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-ietf-tcpm-ecnsyn-07.txt Content-Type: text/plain
Content-ID: <2008-11-03122057.I-D@ietf.org>

--Boundary_(ID_ewzpjQ3hGKRwasoqGgCZpA) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Boundary_(ID_ewzpjQ3hGKRwasoqGgCZpA) 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 --Boundary_(ID_ewzpjQ3hGKRwasoqGgCZpA)-- From tcpm-bounces@ietf.org Thu Nov 6 00:01:09 2008 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 D263D3A6993; Thu, 6 Nov 2008 00:01:09 -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 3D0CD3A6993 for ; Thu, 6 Nov 2008 00:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.922 X-Spam-Level: X-Spam-Status: No, score=-5.922 tagged_above=-999 required=5 tests=[AWL=0.677, 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 BGTggNmU+MAF for ; Thu, 6 Nov 2008 00:01:08 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 831AE3A68B2 for ; Thu, 6 Nov 2008 00:01:08 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA6811n1018188; Thu, 6 Nov 2008 02:01:02 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 10:01:00 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 10:00:59 +0200 Received: from [10.180.41.20] (essapo-nirac25292.europe.nokia.com [10.162.252.92]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id mA680utK018651; Thu, 6 Nov 2008 10:00:56 +0200 Message-Id: <3E321D79-BDF5-4EDB-8943-8F99E230A185@nokia.com> From: Lars Eggert To: ext Sally Floyd In-Reply-To: <36235E15-9019-476A-9CA7-519026635558@mac.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 6 Nov 2008 10:00:56 +0200 References: <36235E15-9019-476A-9CA7-519026635558@mac.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 06 Nov 2008 08:00:59.0934 (UTC) FILETIME=[CE61B3E0:01C93FE5] X-Nokia-AV: Clean Cc: "K. K. Ramakrishnan" , tcpm , Amit Mondal , Aleksandar Kuzmanovic Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-07.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: , Content-Type: multipart/mixed; boundary="===============0976822119==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0976822119== Content-Type: multipart/signed; boundary=Apple-Mail-2-690637031; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-2-690637031 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2008-11-6, at 2:04, ext Sally Floyd wrote: > I think it makes sense to pass this through the working group > before going back to the IESG. I agree - the changes seem to be substantial. Lars --Apple-Mail-2-690637031 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTEwNjA4MDA1NlowIwYJKoZI hvcNAQkEMRYEFB0LnFl+l95pLkMXPMMJi8cWWe7DMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQCw6lpopmHXje8ONsqL2YoFUdqc 4hf+fEiYsdl672z3o3DiLb23gANBmywyBgbbyiHonm8acTQNNcJ3Ui5gZEM4F4R+ZD8sGTEvwcWc qxVzGmdWpA0bKddC21WlTJp+GldfY5AtvFbFjBrZ3q/nZ726HeksRG8aZc8dXhyASs5zUrxjMPTJ 9sSaFAQDgOTziOT8miuks72lcgMDC9wHZzpdkJFvnp4sHQautFdXgpSmIBTmaZWiPqZQEci7y+7D pCukDSKgb4iVGemj2x2nLfx5+HBzlXxy4KVctiOM+Y8tD3ISLWfEO10XJPHk1bFxH+MvIu2koUx2 KhL8Znc3sMzSAAAAAAAA --Apple-Mail-2-690637031-- --===============0976822119== 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 --===============0976822119==-- From tcpm-bounces@ietf.org Thu Nov 6 00:26:02 2008 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 C05513A697D; Thu, 6 Nov 2008 00:26:02 -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 E6BE23A6952 for ; Thu, 6 Nov 2008 00:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FS_REPLICA=0.994, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTBpVwxyHgcx for ; Thu, 6 Nov 2008 00:26:00 -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 BE1CB3A6903 for ; Thu, 6 Nov 2008 00:26:00 -0800 (PST) Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K9W00I9JKR9C190@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 06 Nov 2008 09:25:57 +0100 (CET) Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 06 Nov 2008 09:25:57 +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 mA68PugR004663; Thu, 06 Nov 2008 09:25:56 +0100 (CET) Date: Thu, 06 Nov 2008 09:25:55 +0100 From: Alexander Zimmermann To: tcpm@ietf.org Message-id: <5896054F-1A61-4BAC-94B0-F89660190A53@nets.rwth-aachen.de> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) X-IronPort-AV: E=Sophos;i="4.33,556,1220220000"; d="sig'?scan'208,217";a="89476742" X-Pgp-Agent: GPGMail d53 (v53, Leopard) Subject: [tcpm] RFC 2883 (D-SACK), Section 5.1 Replication by the network 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="===============2130511456==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2130511456== Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-23-692136267 Content-transfer-encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-23-692136267 Content-Type: multipart/alternative; boundary=Apple-Mail-22-692136219 --Apple-Mail-22-692136219 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi folks, RFC 2883, Section 5.1 states that without D-SACK a TCP sender would not know that a packet had been replicated in the network if the last ACK was piggybacked on a data packet. According 2581(bis) a TCP receiver should send immediately an DUPACK when an out-of-order segment arrives. Furthermore, 2581bis says that a DUPACK carries no data. So, according to the DUPACK definition of 2581bis it seems to me that we have no problem to detect a packet replication in case D-SACK is not present. Right? Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-22-692136219 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi folks,

RFC 2883, = Section 5.1 states that without D-SACK a TCP sender would
not know = that a packet had been replicated in the network if the last ACK
was = piggybacked on a data packet.

According 2581(bis) a TCP receiver = should send immediately an DUPACK
when an out-of-order segment = arrives. Furthermore, 2581bis says that a
DUPACK carries no = data.

So, according to the DUPACK definition of 2581bis it seems = to me that we
have no problem to detect a packet replication in case = D-SACK is not
present. Right?

Alex

//
// = Dipl.-Inform. Alexander Zimmermann
// Department of Computer = Science, Informatik 4
// RWTH Aachen University
// = Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: = (49-241) 80-22220
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 B07F03A6B96; Fri, 7 Nov 2008 13:38:06 -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 0F3693A6B96 for ; Fri, 7 Nov 2008 13:38:06 -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 7WHi+JTEG5yV for ; Fri, 7 Nov 2008 13:38:05 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4C0533A6B7E for ; Fri, 7 Nov 2008 13:38:05 -0800 (PST) Received: from [75.215.102.23] (23.sub-75-215-102.myvzw.com [75.215.102.23]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mA7Lbbsf014505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Nov 2008 13:37:39 -0800 (PST) Message-ID: <4914B521.3090509@isi.edu> Date: Fri, 07 Nov 2008 13:37:37 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Fernando Gont References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> In-Reply-To: <200811030149.mA31n6fe020648@venus.xmundo.net> 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, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Hello, Joe, ... > At some point, the specs (RFC 793) were ambiguous. So implementations > simply picked one of the possible intrepretations. The IETF later > mandated the other possible interpretation. But nobody changed their > stacks. And nobody will. At some point it may have been an > implementation error. Nowadays... who cares? it's the de-facto standard. FWIW, there was an errata in RFC961 in 1985, that indicates that page 17 of RFC793 is incorrect, and that the pointer is to the last octet of urgent data (not the first octet of non-urgent data). That information is reiterated in RFC1122 in 1989, and is very specific in overriding RFC793. There is no remaining ambiguity. There is only the difference between what is implemented and what the requirements state. That does NOT make it a 'de-facto standard'; it can also be a 'de-facto bug'. The key question is why RFC1122 chose the "points to last URG byte" interpretation, and why we think that should be changed. Simply describing it as "what has been deployed" is insufficient justification to call this anything other than a bug without further rationale. If that rationale exists, it would be useful to provide it. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkkUtSAACgkQE5f5cImnZru6qgCTB003RkSP8eJW50DdnbjYV1QX mACeMoe5RvIjmEMu52oSv8CjUejZvRk= =KKzy -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 7 17:41:25 2008 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 452E83A68C5; Fri, 7 Nov 2008 17:41:25 -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 8346B3A68C5 for ; Fri, 7 Nov 2008 17:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.864, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 xN98BKEzvUc6 for ; Fri, 7 Nov 2008 17:41:23 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 614C13A635F for ; Fri, 7 Nov 2008 17:41:22 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5E5296B656D; Fri, 7 Nov 2008 22:41:12 -0300 (ART) Received: from notebook.gont.com.ar (201-254-63-40.speedy.com.ar [201.254.63.40] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mA81eqGx025906; Fri, 7 Nov 2008 23:40:53 -0200 Message-Id: <200811080140.mA81eqGx025906@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 07 Nov 2008 22:32:10 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <4914B521.3090509@isi.edu> References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> 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]); Fri, 07 Nov 2008 22:41:11 -0300 (ART) Cc: tcpm@ietf.org, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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-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:37 p.m. 07/11/2008, Joe Touch wrote: > > At some point, the specs (RFC 793) were ambiguous. So implementations > > simply picked one of the possible intrepretations. The IETF later > > mandated the other possible interpretation. But nobody changed their > > stacks. And nobody will. At some point it may have been an > > implementation error. Nowadays... who cares? it's the de-facto standard. > >FWIW, there was an errata in RFC961 in 1985, that indicates that page 17 >of RFC793 is incorrect, and that the pointer is to the last octet of >urgent data (not the first octet of non-urgent data). Agreed. >That does NOT make it a 'de-facto standard'; it can also be a 'de-facto >bug'. Does this change anything? Do you expect anybody to change their implementations at this point in time? They would not even do it even if they wanted to (it would break existing apps) C'mon Joe...let's be realistic, please. >The key question is why RFC1122 chose the "points to last URG byte" >interpretation, and why we think that should be changed. Because nobody has ever implemented that, there's not benefit in the RFC1122 behavior vs. the deployed behavior, and nobody is going to change their stacks in this respect at this point in time. >Simply >describing it as "what has been deployed" is insufficient justification >to call this anything other than a bug without further rationale. And... what would that change? Okay, I can answer this one for you: More and more people would look somewhere else to find out how the protocols work in practice. P.S.: What was it called? "rough consensus and.... "? -- 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 Fri Nov 7 17:48:09 2008 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 4A6073A684E; Fri, 7 Nov 2008 17:48:09 -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 DFBBC3A684E for ; Fri, 7 Nov 2008 17:48:07 -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 9zYWFuMIfnBH for ; Fri, 7 Nov 2008 17:48:07 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3CB543A635F for ; Fri, 7 Nov 2008 17:48:07 -0800 (PST) Received: from [192.168.1.46] (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 mA81lrvE013726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Nov 2008 17:47:55 -0800 (PST) Message-ID: <4914EFC9.7060906@isi.edu> Date: Fri, 07 Nov 2008 17:47:53 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Fernando Gont References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> In-Reply-To: <200811080140.mA81eqGx025906@venus.xmundo.net> 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, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: ... >> Simply >> describing it as "what has been deployed" is insufficient justification >> to call this anything other than a bug without further rationale. > > And... what would that change? Okay, I can answer this one for you: More > and more people would look somewhere else to find out how the protocols > work in practice. > > P.S.: What was it called? "rough consensus and.... "? It's not "running code." either. We are not here to write documents that describe only what has been implemented. We need to decide what the target is. If you want merely to document "what is", that's a fine description for a man page, but it doesn't provide utility in a standards body. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkU78kACgkQE5f5cImnZrtL0wCfQUr5/WF5SzPyniyI39UdjV6i 7YgAoNQUPOZ/u4XseNRI3yTQsctZtiTk =vbff -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 7 17:58:27 2008 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 BB3713A684E; Fri, 7 Nov 2008 17:58: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 B02B93A684E for ; Fri, 7 Nov 2008 17:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.785, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 kx8jHiUcX2fV for ; Fri, 7 Nov 2008 17:58:26 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id CE2953A635F for ; Fri, 7 Nov 2008 17:58:24 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E4A5C6B6557; Fri, 7 Nov 2008 22:57:54 -0300 (ART) Received: from notebook.gont.com.ar (201-254-63-40.speedy.com.ar [201.254.63.40] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mA81vYQA032096; Fri, 7 Nov 2008 23:57:35 -0200 Message-Id: <200811080157.mA81vYQA032096@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 07 Nov 2008 22:51:53 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <4914EFC9.7060906@isi.edu> References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> 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]); Fri, 07 Nov 2008 22:57:54 -0300 (ART) Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 10:47 p.m. 07/11/2008, Joe Touch wrote: > > P.S.: What was it called? "rough consensus and.... "? > >It's not "running code." either. > >We are not here to write documents that describe only what has been >implemented. We need to decide what the target is. Again: Do you really expect anybody to change their stacks so that they become RFC1122-compliant in this respect??? >If you want merely to document "what is", that's a fine description for >a man page, but it doesn't provide utility in a standards body. Well, I guess that depends whether you want the specs to be useful for implementers, or not. I just hope that some of the kernel hackers that send comments off-list post something in this respect on-list. FWIW, I guess we have to agree to disagree.... 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 Sat Nov 8 09:51:48 2008 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 E011D28C192; Sat, 8 Nov 2008 09:51: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 38CB628C192 for ; Sat, 8 Nov 2008 09:51:47 -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 3rbYa0USS7Qb for ; Sat, 8 Nov 2008 09:51:46 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 54E5F3A68A2 for ; Sat, 8 Nov 2008 09:51:46 -0800 (PST) Received: from [192.168.1.46] (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 mA8HpLA6005608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 8 Nov 2008 09:51:23 -0800 (PST) Message-ID: <4915D19A.4070404@isi.edu> Date: Sat, 08 Nov 2008 09:51:22 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Fernando Gont References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> In-Reply-To: <200811080157.mA81vYQA032096@venus.xmundo.net> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Note to the chairs: This is an important topic for this WG, and I hope we will have time to discuss it in Minneapolis. Fernando Gont wrote: > At 10:47 p.m. 07/11/2008, Joe Touch wrote: > >> > P.S.: What was it called? "rough consensus and.... "? >> >> It's not "running code." either. >> >> We are not here to write documents that describe only what has been >> implemented. We need to decide what the target is. > > Again: Do you really expect anybody to change their stacks so that they > become RFC1122-compliant in this respect??? I expect that, even if the IETF had a compliance process, the specs are always out of sync with what is deployed, and represent what implementations should try to achieve. >> If you want merely to document "what is", that's a fine description for >> a man page, but it doesn't provide utility in a standards body. > > Well, I guess that depends whether you want the specs to be useful for > implementers, or not. I just hope that some of the kernel hackers that > send comments off-list post something in this respect on-list. Implementers should design protocols to specs; they should design applications to specs together with man pages and errata that discuss where the two diverge. IMO, the specs cannot constantly be downgraded to represent what is implemented solely for that reason; downgrading can - and should - occur if we, as a community, decide to change what we *want* the protocol to do. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkkV0ZkACgkQE5f5cImnZrtSKACgm9/OzQjGg0Wq51JSEtMmPhi2 lw8Al2iGit2ki5MvW/fLjRaq9LdWWts= =RO/n -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Nov 8 12:12:48 2008 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 C18903A6A4A; Sat, 8 Nov 2008 12:12: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 4BC3528C0D0 for ; Sat, 8 Nov 2008 11:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FS_REPLICA=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 MZhd4KPG2pen for ; Sat, 8 Nov 2008 11:59:29 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82FCA3A6822 for ; Sat, 8 Nov 2008 11:59:29 -0800 (PST) Received: from [67.59.52.214] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kytxr-000PNI-9c for tcpm@ietf.org; Sat, 08 Nov 2008 19:59:25 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id E02DF2BE23 for ; Sat, 8 Nov 2008 14:59:20 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 0E8A227F1E; Sat, 8 Nov 2008 14:59:19 -0500 (EST) Date: Sat, 8 Nov 2008 14:59:19 -0500 From: Ethan Blanton To: tcpm@ietf.org Message-ID: <20081108195919.GA13079@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <5896054F-1A61-4BAC-94B0-F89660190A53@nets.rwth-aachen.de> MIME-Version: 1.0 In-Reply-To: <5896054F-1A61-4BAC-94B0-F89660190A53@nets.rwth-aachen.de> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Subject: Re: [tcpm] RFC 2883 (D-SACK), Section 5.1 Replication by the network 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="===============0175498213==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0175498213== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alexander Zimmermann spake unto us the following wisdom: > RFC 2883, Section 5.1 states that without D-SACK a TCP sender would > not know that a packet had been replicated in the network if the last =20 > ACK was piggybacked on a data packet. > > According 2581(bis) a TCP receiver should send immediately an DUPACK > when an out-of-order segment arrives. Furthermore, 2581bis says that a > DUPACK carries no data. > > So, according to the DUPACK definition of 2581bis it seems to me that we > have no problem to detect a packet replication in case D-SACK is not > present. Right? The problem here is that you have no idea whether the dupack was generated by a packet already received (entirely below RCV.NXT), or a packet following a lost or as yet un-received packet (entirely beyond RCV.NXT). Both of these conditions generate a duplicate acknowledgment. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --wac7ysb48OaltWcw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJFe+Xr9kA9Ig8HBQRArqUAKClYFM9nUSwteRceev6rBkXtj5UzQCgv+sS AaCqHSquXoXD00J9FCcVu9k= =ZtWD -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- --===============0175498213== 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 --===============0175498213==-- From tcpm-bounces@ietf.org Sat Nov 8 15:00:37 2008 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 3DC043A681A; Sat, 8 Nov 2008 15:00:37 -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 C9C183A6407 for ; Sat, 8 Nov 2008 15:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 SHfTIz0L3Rr6 for ; Sat, 8 Nov 2008 15:00:35 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 908B53A63D2 for ; Sat, 8 Nov 2008 15:00:33 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id F1D776B6559; Sat, 8 Nov 2008 20:00:33 -0300 (ART) Received: from notebook.gont.com.ar (201-254-63-40.speedy.com.ar [201.254.63.40] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mA8N0FPj001169; Sat, 8 Nov 2008 21:00:16 -0200 Message-Id: <200811082300.mA8N0FPj001169@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 08 Nov 2008 19:54:31 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <4915D19A.4070404@isi.edu> References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> 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]); Sat, 08 Nov 2008 20:00:32 -0300 (ART) Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:51 p.m. 08/11/2008, Joe Touch wrote: > > Again: Do you really expect anybody to change their stacks so that they > > become RFC1122-compliant in this respect??? > >I expect that, even if the IETF had a compliance process, the specs are >always out of sync with what is deployed, and represent what >implementations should try to achieve. I understand what you mean, but I believe that there's a difference between simply being out of sync (i.e., the specs simply being ahead of time), and the specs specifying stuff that the implementations will never even try to implement. > >> If you want merely to document "what is", that's a fine description for > >> a man page, but it doesn't provide utility in a standards body. > > > > Well, I guess that depends whether you want the specs to be useful for > > implementers, or not. I just hope that some of the kernel hackers that > > send comments off-list post something in this respect on-list. > >Implementers should design protocols to specs; they should design >applications to specs together with man pages and errata that discuss >where the two diverge. Man pages? We are talking about what is sent on the wire. We're talking about the semantics of the urgent pointer. Why should, e.g. a UNIX man page state whether the urgent pointer points to the last byte of urgent data vs. the byte following the last byte of urgent data?? >IMO, the specs cannot constantly be downgraded to represent what is >implemented solely for that reason; downgrading can - and should - occur >if we, as a community, decide to change what we *want* the protocol to do. Joe, why do you imply that simply updating RFC1122 such that it states that the UP points to "the byte following the last byte of urgent data" is a downgrade? Could you please elaborate a little bit on why you think it would be a downgrade? 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 Sat Nov 8 16:11:27 2008 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 0868228C18E; Sat, 8 Nov 2008 16:11: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 0CE3428C18E for ; Sat, 8 Nov 2008 16:11:26 -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 KNBoXp40Cc43 for ; Sat, 8 Nov 2008 16:11:25 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3437528C18A for ; Sat, 8 Nov 2008 16:11:25 -0800 (PST) Received: from [192.168.1.46] (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 mA90AvnM001185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 8 Nov 2008 16:11:00 -0800 (PST) Message-ID: <49162A91.30403@isi.edu> Date: Sat, 08 Nov 2008 16:10:57 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Fernando Gont References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> <200811082300.mA8N0FPj001169@venus.xmundo.net> In-Reply-To: <200811082300.mA8N0FPj001169@venus.xmundo.net> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > At 02:51 p.m. 08/11/2008, Joe Touch wrote: > >> > Again: Do you really expect anybody to change their stacks so that they >> > become RFC1122-compliant in this respect??? >> >> I expect that, even if the IETF had a compliance process, the specs are >> always out of sync with what is deployed, and represent what >> implementations should try to achieve. > > I understand what you mean, but I believe that there's a difference > between simply being out of sync (i.e., the specs simply being ahead of > time), and the specs specifying stuff that the implementations will > never even try to implement. > > > >> >> If you want merely to document "what is", that's a fine description >> for >> >> a man page, but it doesn't provide utility in a standards body. >> > >> > Well, I guess that depends whether you want the specs to be useful for >> > implementers, or not. I just hope that some of the kernel hackers that >> > send comments off-list post something in this respect on-list. >> >> Implementers should design protocols to specs; they should design >> applications to specs together with man pages and errata that discuss >> where the two diverge. > > Man pages? We are talking about what is sent on the wire. We're talking > about the semantics of the urgent pointer. Why should, e.g. a UNIX man > page state whether the urgent pointer points to the last byte of urgent > data vs. the byte following the last byte of urgent data?? The UNIX man page should explain where its implementation differs from the spec. The BSD source code does, FWIW. >> IMO, the specs cannot constantly be downgraded to represent what is >> implemented solely for that reason; downgrading can - and should - occur >> if we, as a community, decide to change what we *want* the protocol to >> do. > > Joe, why do you imply that simply updating RFC1122 such that it states > that the UP points to "the byte following the last byte of urgent data" > is a downgrade? Could you please elaborate a little bit on why you think > it would be a downgrade? I'm trying to have a general discussion about a series of I-Ds that you have generated along these lines. In this case, we're talking about downgrading from 1122 (and some earlier RFCs) to allow the ambiguity from 793. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkWKpEACgkQE5f5cImnZrvZSwCffyqyx5U/Q26xI7SSL0zn2oHM iv8AoKvATo3iDP40Wv5xALwmI3JQkVhk =rwM+ -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Nov 8 16:24:38 2008 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 664FD3A68F2; Sat, 8 Nov 2008 16:24: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 0779F3A68F2 for ; Sat, 8 Nov 2008 16:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 OWBR+6yXwRQl for ; Sat, 8 Nov 2008 16:24:36 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id D7F8B3A687B for ; Sat, 8 Nov 2008 16:24:35 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E89A66B6567; Sat, 8 Nov 2008 21:24:33 -0300 (ART) Received: from notebook.gont.com.ar (201-254-63-40.speedy.com.ar [201.254.63.40] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mA90OGDs025064; Sat, 8 Nov 2008 22:24:17 -0200 Message-Id: <200811090024.mA90OGDs025064@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 08 Nov 2008 21:18:35 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <49162A91.30403@isi.edu> References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> <200811082300.mA8N0FPj001169@venus.xmundo.net> <49162A91.30403@isi.edu> 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]); Sat, 08 Nov 2008 21:24:32 -0300 (ART) Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 09:10 p.m. 08/11/2008, Joe Touch wrote: > > Joe, why do you imply that simply updating RFC1122 such that it states > > that the UP points to "the byte following the last byte of urgent data" > > is a downgrade? Could you please elaborate a little bit on why you think > > it would be a downgrade? > >I'm trying to have a general discussion about a series of I-Ds that you >have generated along these lines. I don't understand what you mean by "along these lines". I don't think this document is in line with any other document I have published. FWIW, I had not even planned to publish this "urgent data" draft. But while analyzing some stuff (including packet traces) with Andrew, we realized that the specs had nothing to do with what has actually been implemented. It's a pain for implementers to find out that in many areas the specifications have nothing to do with what current impementations do (and, in this case, I'd say "with what implementations have always done, and still do"). >In this case, we're talking about >downgrading from 1122 (and some earlier RFCs) to allow the ambiguity >from 793. No. We are talking about updating RFC 1122 so that the semantics of the UP are officially updated so that the specs (theory) agree with implementations (practice). We're not "downgrading" anything. FWIW, I have already asked you to clarify why you think this is a "downgrade". 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 Sun Nov 9 05:29:33 2008 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 19E423A6977; Sun, 9 Nov 2008 05:29: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 11C7B3A6977 for ; Sun, 9 Nov 2008 05:29:32 -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 5bcIvJ60WLCR for ; Sun, 9 Nov 2008 05:29:31 -0800 (PST) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id E7D523A6971 for ; Sun, 9 Nov 2008 05:29:30 -0800 (PST) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id mA9DTPXU022762; Sun, 9 Nov 2008 15:29:25 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id mA9DTPA8021464; Sun, 9 Nov 2008 15:29:25 +0200 Received: from hell.hell.gr (adsl61-198.lsf.forthnet.gr [79.103.188.198]) by MX-IN-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id mA9DTKeZ010274; Sun, 9 Nov 2008 15:29:22 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-05.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org Date: Sun, 9 Nov 2008 15:29:20 +0200 User-Agent: KMail/1.9.9 References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200811082300.mA8N0FPj001169@venus.xmundo.net> <49162A91.30403@isi.edu> In-Reply-To: <49162A91.30403@isi.edu> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200811091529.20537.v13@v13.gr> Cc: ah@tr-sys.de, ayourtch@cisco.com, David Borman , Fernando Gont , Joe Touch Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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 On Sunday 09 November 2008, Joe Touch wrote: > > Man pages? We are talking about what is sent on the wire. We're talking > > about the semantics of the urgent pointer. Why should, e.g. a UNIX man > > page state whether the urgent pointer points to the last byte of urgent > > data vs. the byte following the last byte of urgent data?? > > The UNIX man page should explain where its implementation differs from > the spec. The BSD source code does, FWIW. What Fernando says (as far as i understand) is that we have a reality here where everyone does the X thing (where X may be "wrong"). This is a reality and we have to accept it. After accepting that this actually happens, we must either (a) persuade everyone to change their implementation or (b) update the RFC. It seems that (a) isn't possible since it will introduce a backward incompatibility and practically invalidate the urgent pointer as a whole. Since everyone does the X thing we can easily update the RFC without practically changing the actual meaning (or interpretation since everyone does it already the other way) of UP. RFCs MUST be at sync with the real world. Having RFCs that don't represent reality makes RFCs as a whole (or at least TCP related) less valuable and less respectable. This will also save time and pain from all current and future TCP implementors. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Nov 9 05:46:49 2008 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 1F2893A69A2; Sun, 9 Nov 2008 05:46:49 -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 48CF83A69A2 for ; Sun, 9 Nov 2008 05:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 xMMDoqujFg42 for ; Sun, 9 Nov 2008 05:46:47 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 61B8A3A6931 for ; Sun, 9 Nov 2008 05:46:46 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id BC1DD6B654F; Sun, 9 Nov 2008 10:46:43 -0300 (ART) Received: from notebook.gont.com.ar (201-254-63-40.speedy.com.ar [201.254.63.40] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mA9DkYmo011693; Sun, 9 Nov 2008 11:46:35 -0200 Message-Id: <200811091346.mA9DkYmo011693@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 09 Nov 2008 10:36:10 -0300 To: Stefanos Harhalakis , tcpm@ietf.org From: Fernando Gont In-Reply-To: <200811091529.20537.v13@v13.gr> References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200811082300.mA8N0FPj001169@venus.xmundo.net> <49162A91.30403@isi.edu> <200811091529.20537.v13@v13.gr> 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]); Sun, 09 Nov 2008 10:46:42 -0300 (ART) Cc: ah@tr-sys.de, ayourtch@cisco.com, David Borman , Joe Touch Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 10:29 a.m. 09/11/2008, Stefanos Harhalakis wrote: >What Fernando says (as far as i understand) is that we have a reality here >where everyone does the X thing (where X may be "wrong"). This is a reality >and we have to accept it. > >After accepting that this actually happens, we must either (a) persuade >everyone to change their implementation or (b) update the RFC. > >It seems that (a) isn't possible since it will introduce a backward >incompatibility and practically invalidate the urgent pointer as a whole. > >Since everyone does the X thing we can easily update the RFC without >practically changing the actual meaning (or interpretation since everyone >does it already the other way) of UP. > >RFCs MUST be at sync with the real world. Having RFCs that don't represent >reality makes RFCs as a whole (or at least TCP related) less valuable and >less respectable. This will also save time and pain from all current and >future TCP implementors. Exactly! 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 Sun Nov 9 16:47:54 2008 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 63A7C3A69B3; Sun, 9 Nov 2008 16:47:54 -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 8DBE53A69B3 for ; Sun, 9 Nov 2008 16:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=1.994, 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 T9niClIz7UnC for ; Sun, 9 Nov 2008 16:47:52 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 4CB093A6813 for ; Sun, 9 Nov 2008 16:47:52 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAA0lgu00636; Mon, 10 Nov 2008 01:47:42 +0100 (CET) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAA0lOG00607; Mon, 10 Nov 2008 01:47:24 +0100 (CET) Date: Mon, 10 Nov 2008 01:47:28 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Joe Touch In-Reply-To: <4915D19A.4070404@isi.edu> Message-ID: References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> MIME-Version: 1.0 Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman , Fernando Gont Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Sat, 8 Nov 2008, Joe Touch wrote: > I expect that, even if the IETF had a compliance process, the specs are > always out of sync with what is deployed, and represent what > implementations should try to achieve. I think you did not mention one step before that - that the creation of the specs in the first place is to ensure the interoperability, not just for the sake of the specs themselves. If the interoperability is already achieved by other means ("the running code" deployed everywhere), the specs become irrelevant. If then complying to the specs breaks that interoperability, they become outright harmful. > Implementers should design protocols to specs; they should design > applications to specs together with man pages and errata that discuss > where the two diverge. After reading the set of what I could find - the only conclusion regarding TCP Urgent that I could come to if I was designing an application - "Don't use it. At all." On a related note, my understanding from reading the http://msdn.microsoft.com/en-us/library/ms740102(VS.85).aspx is that when the callers use SO_OOBINLINE in an attempt to be the "RFC-compliant", the urgent flag and pointer are pretty much a no-op altogether - maybe someone could correct me if I missed something: "Note When the SO_OOBINLINE socket option is set, the SIOCATMARK IOCTL always returns TRUE, and OOB data is returned to the user as normal data." > > IMO, the specs cannot constantly be downgraded to represent what is > implemented solely for that reason; downgrading can - and should - occur > if we, as a community, decide to change what we *want* the protocol to do. > This is a good point - so I will take a risk of being burned in-place for heresy :) - and will put a few open questions of a broader scope to the community: 1) Given the state of the matters and practical experience, are the OOB notifications (which TCP Urgent boils down to?) utilised enough in the today's (and tomorrow's) world to have them as part of the "core" protocol header as opposed to being an option ? (searching suggests this has already been on the table back in '94 as one of the "small changes" within the tcpng bounds - but I was not able to find any discussions on the topic - I presume they happened offline - so would very much appreciate an enlightenment from someone who happened to be part of those discussions). 2) Would we want to more effectively utilise these 16 bits in the TCP header (assuming the URG flag rests at "0"), rather than transmitting two zero bytes for 99.99% of the cases ? thanks, andrew _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Nov 9 20:11:25 2008 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 62F173A69D6; Sun, 9 Nov 2008 20:11:25 -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 43C933A69DA for ; Sun, 9 Nov 2008 20:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy+gFQOyCMdF for ; Sun, 9 Nov 2008 20:11:23 -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 77F923A69D6 for ; Sun, 9 Nov 2008 20:11:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,572,1220227200"; d="scan'208";a="191529263" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Nov 2008 04:11:20 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAA4BKt0025590; Sun, 9 Nov 2008 20:11:20 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAA4BKeb006631; Mon, 10 Nov 2008 04:11:20 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Nov 2008 20:11:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Nov 2008 20:11:19 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58061E8C1C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4914EFC9.7060906@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-urgent-data-00 Thread-Index: AclBRAy7P4tNt26kRO+8kCay9Wc2ugBoQYVw References: <200810280000.m9S00h4E029878@venus.xmundo.net><200810280203.m9S23foZ023071@venus.xmundo.net><523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com><200810290227.m9T2RAHQ001594@venus.xmundo.net><49088156.6020305@isi.edu><200811030149.mA31n6fe020648@venus.xmundo.net><4914B521.3090509@isi.edu><200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Fernando Gont" X-OriginalArrivalTime: 10 Nov 2008 04:11:20.0462 (UTC) FILETIME=[62D422E0:01C942EA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=967; t=1226290280; x=1227154280; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20Fwd=3A=20New=20Version=20Notif ication=20fordraft-gont-tcpm-urgent-data-00 |Sender:=20; bh=luEjlEhsEo2ZkNNO7ZvCEGZ5yZ53rqXrNt8tE9mTZRU=; b=viykXVEFCFtAn6e0MjZpIBUKf5XDZBlYPJAqbunD37Hcim2ltGEb7pDyaj 4PTmEDi4e18h+mSYWCdKJv+Pshf3NGoCbaMbKhfeK9pzn/TsqDFzotA5W1Kp 7uPaDX/hFy; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: tcpm@ietf.org, David Borman , "Andrew Yourtchenko \(ayourtch\)" Subject: Re: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-urgent-data-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 > Fernando Gont wrote: > ... > >> Simply > >> describing it as "what has been deployed" is insufficient > >> justification to call this anything other than a bug > without further rationale. > > > > And... what would that change? Okay, I can answer this one for you: > > More and more people would look somewhere else to find out how the > > protocols work in practice. > > > > P.S.: What was it called? "rough consensus and.... "? > > It's not "running code." either. > > We are not here to write documents that describe only what > has been implemented. We need to decide what the target is. > > If you want merely to document "what is", that's a fine > description for a man page, but it doesn't provide utility in > a standards body. Why wouldn't BCP help in this case ? Esp. if you are trying to document what is widely being done and also has agreement with the standards. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Nov 9 20:47:26 2008 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 8B1E73A69E7; Sun, 9 Nov 2008 20:47:26 -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 7EBDA3A69E9 for ; Sun, 9 Nov 2008 20:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 tQJ1ekeRqiwW for ; Sun, 9 Nov 2008 20:47:24 -0800 (PST) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 92CD93A69D6 for ; Sun, 9 Nov 2008 20:47:24 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 7AFF42D8069; Sun, 9 Nov 2008 22:47:20 -0600 (CST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id mAA4lMxa028711; Sun, 9 Nov 2008 22:47:22 -0600 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Nov 2008 22:47:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Nov 2008 22:47:19 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-urgent-data-00 Thread-Index: AclByqzj9Fz6Q4cRRt+p5KSi4EGPUwBI6Y0+ References: <200810280000.m9S00h4E029878@venus.xmundo.net><200810280203.m9S23foZ023071@venus.xmundo.net><523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com><200810290227.m9T2RAHQ001594@venus.xmundo.net><49088156.6020305@isi.edu><200811030149.mA31n6fe020648@venus.xmundo.net><4914B521.3090509@isi.edu><200811080140.mA81eqGx025906@venus.xmundo.net><4914EFC9.7060906@isi.edu><200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Joe Touch" , "Fernando Gont" X-OriginalArrivalTime: 10 Nov 2008 04:47:20.0346 (UTC) FILETIME=[6A3847A0:01C942EF] Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-urgent-data-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="===============1560110100==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1560110100== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C942EF.69FC9757" This is a multi-part message in MIME format. ------_=_NextPart_001_01C942EF.69FC9757 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, it's on the meeting agenda, currently at the very end. =20 I have a question for the authors. The survey you did of different OSes and how they handle urgent data is good; did you do any similar study of applications and which ones attempt to use urgent data? =20 =20 ________________________________ From: tcpm-bounces@ietf.org on behalf of Joe Touch Sent: Sat 11/8/2008 11:51 AM To: Fernando Gont Cc: ah@tr-sys.de; tcpm@ietf.org; David Borman; ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification = fordraft-gont-tcpm-urgent-data-00 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Note to the chairs: This is an important topic for this WG, and I hope we will have time to discuss it in Minneapolis. ------_=_NextPart_001_01C942EF.69FC9757 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [tcpm] Fwd: New Version Notification = fordraft-gont-tcpm-urgent-data-00=0A= =0A= =0A= =0A=
=0A=
Yes, it's on = the meeting agenda, currently at the very end.
=0A=
 
=0A=
I have a question for the = authors.  The survey you did of different OSes
=0A=
and how they handle urgent = data is good; did you do any similar study
=0A=
of applications and which = ones attempt to use urgent data?
=0A=
 
=0A=
 
=0A=

=0A=
=0A= From: tcpm-bounces@ietf.org on = behalf of Joe Touch
Sent: Sat 11/8/2008 11:51 AM
To: = Fernando Gont
Cc: ah@tr-sys.de; tcpm@ietf.org; David Borman; = ayourtch@cisco.com
Subject: Re: [tcpm] Fwd: New Version = Notification fordraft-gont-tcpm-urgent-data-00

=0A=
=0A=

-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

Note to the chairs:
This is an important topic for this = WG, and I hope we will have time to
discuss it in = Minneapolis.

------_=_NextPart_001_01C942EF.69FC9757-- --===============1560110100== 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 --===============1560110100==-- From tcpm-bounces@ietf.org Sun Nov 9 21:07:10 2008 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 9CBD73A69F5; Sun, 9 Nov 2008 21:07:10 -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 E0A6B3A69F5 for ; Sun, 9 Nov 2008 21:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] 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 u4-ZLkDUUAGv for ; Sun, 9 Nov 2008 21:07:09 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 050B23A69F2 for ; Sun, 9 Nov 2008 21:07:08 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 8B44F6B6592; Mon, 10 Nov 2008 02:07:10 -0300 (ART) Received: from notebook.gont.com.ar (201-254-54-89.speedy.com.ar [201.254.54.89] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mAA56lfX011855; Mon, 10 Nov 2008 03:06:48 -0200 Message-Id: <200811100506.mAA56lfX011855@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Nov 2008 01:57:07 -0300 To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" , "Joe Touch" From: Fernando Gont In-Reply-To: References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> 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]); Mon, 10 Nov 2008 02:07:09 -0300 (ART) Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-urgent-data-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 01:47 a.m. 10/11/2008, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >I have a question for the authors. The survey you did of different OSes >and how they handle urgent data is good; did you do any similar study >of applications and which ones attempt to use urgent data? Not yet. For open source ones I guess we could simply grep lots and lots of source files. For others it might be a little bit more difficult. I recall being told that e.g., MS SQL uses urgent data... and there may be many others... 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 Sun Nov 9 21:40:32 2008 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 742013A69DD; Sun, 9 Nov 2008 21:40: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 1C8FA3A69DD for ; Sun, 9 Nov 2008 21:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.997, 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 OuHG9lmIFZcz for ; Sun, 9 Nov 2008 21:40:30 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id A099B3A63EB for ; Sun, 9 Nov 2008 21:40:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAA5dnU19531; Mon, 10 Nov 2008 06:39:49 +0100 (CET) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAA5dNG19381; Mon, 10 Nov 2008 06:39:23 +0100 (CET) Date: Mon, 10 Nov 2008 06:39:27 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Fernando Gont In-Reply-To: <200811100506.mAA56lfX011855@venus.xmundo.net> Message-ID: References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> <200811100506.mAA56lfX011855@venus.xmundo.net> MIME-Version: 1.0 Cc: tcpm@ietf.org, ah@tr-sys.de, Joe Touch , David Borman , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-urgent-data-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, 10 Nov 2008, Fernando Gont wrote: > At 01:47 a.m. 10/11/2008, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > >> I have a question for the authors. The survey you did of different OSes >> and how they handle urgent data is good; did you do any similar study >> of applications and which ones attempt to use urgent data? > > Not yet. > > For open source ones I guess we could simply grep lots and lots of source > files. For others it might be a little bit more difficult. I recall being > told that e.g., MS SQL uses urgent data... and there may be many others... I think it was oracle SQL*Net: http://www.stanford.edu/dept/itss/docs/oracle/10g/network.101/b10776/sqlnet.htm Default is to "use urgent data". I'll try to find an oracle install to see what the "urgent data" constitutes there. One other possible candidate (to be verified) might include Citrix terminal server traffic (the anecdotal evidence taken from snort-users archive, e.g.: http://archives.neohapsis.com/archives/snort/2001-08/0787.html) However, both are "closed domain" applications - i.e., usually both ends of them are under single administrative domain, so regardless of which behaviour they use, standards compliant or not, it can be solved with configuration. The bigger problem is for internet-wide applications, e.g. for FTP, whose ABOR command appears to utilise the TCP Urgent as well. Ironically, the standard command-line ftp client on linux is BSD, so all the "standards-compliant" servers are effectively "broken" by default. There could be some more proprietary apps as well, since the searchable discussion forums on the internet include quite a lot of discussions on this topic from the puzzled application programmers. thanks, andrew _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 11 09:20:13 2008 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 B7C4028C1C1; Tue, 11 Nov 2008 09:20:13 -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 87C013A6A1F for ; Tue, 11 Nov 2008 09:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.806 X-Spam-Level: X-Spam-Status: No, score=-3.806 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FS_REPLICA=0.994, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-LzD3T+rAJ6 for ; Tue, 11 Nov 2008 09:20:11 -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 477263A698D for ; Tue, 11 Nov 2008 09:20:10 -0800 (PST) Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0KA600H48ITL4QD0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 11 Nov 2008 18:20:09 +0100 (CET) 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; Tue, 11 Nov 2008 18:20:09 +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 mABHK98w028899; Tue, 11 Nov 2008 18:20:09 +0100 (CET) Date: Tue, 11 Nov 2008 18:20:00 +0100 From: Alexander Zimmermann In-reply-to: <20081108195919.GA13079@elb.elitists.net> To: tcpm@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) X-IronPort-AV: E=Sophos;i="4.33,584,1220220000"; d="sig'?scan'208,217";a="90085028" X-Pgp-Agent: GPGMail d53 (v53, Leopard) References: <5896054F-1A61-4BAC-94B0-F89660190A53@nets.rwth-aachen.de> <20081108195919.GA13079@elb.elitists.net> Cc: Ethan Blanton Subject: Re: [tcpm] RFC 2883 (D-SACK), Section 5.1 Replication by the network 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="===============0421063184==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0421063184== Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-12--991302028 Content-transfer-encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-12--991302028 Content-Type: multipart/alternative; boundary=Apple-Mail-11--991302090 --Apple-Mail-11--991302090 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Am 08.11.2008 um 20:59 schrieb Ethan Blanton: > Alexander Zimmermann spake unto us the following wisdom: >> RFC 2883, Section 5.1 states that without D-SACK a TCP sender would >> not know that a packet had been replicated in the network if the last >> ACK was piggybacked on a data packet. >> >> According 2581(bis) a TCP receiver should send immediately an DUPACK >> when an out-of-order segment arrives. Furthermore, 2581bis says >> that a >> DUPACK carries no data. >> >> So, according to the DUPACK definition of 2581bis it seems to me >> that we >> have no problem to detect a packet replication in case D-SACK is not >> present. Right? > > The problem here is that you have no idea whether the dupack was > generated by a packet already received (entirely below RCV.NXT), or a > packet following a lost or as yet un-received packet (entirely beyond > RCV.NXT). Both of these conditions generate a duplicate > acknowledgment. > > Ethan Hi Ethan, you are completely right. However, in the example of section 5.1 it is assumed that no segment is lost. IMHO the example is not correct (anymore) since it is assumed that a DUPACK can be piggyback on a data packet. According to 2581bis a DUPACK carries no data. Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-11--991302090 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Am = 08.11.2008 um 20:59 schrieb Ethan = Blanton:

Alexander = Zimmermann spake unto us the following wisdom:
RFC 2883, Section 5.1 states that without D-SACK a TCP = sender would
not know that a = packet had been replicated in the network if the = last
ACK was piggybacked on a = data packet.

According = 2581(bis) a TCP receiver should send immediately an = DUPACK
when an out-of-order = segment arrives. Furthermore, 2581bis says that = a
DUPACK carries no = data.

So, according = to the DUPACK definition of 2581bis it seems to me that = we
have no problem to detect a = packet replication in case D-SACK is not
present. Right?

The problem here is = that you have no idea whether the dupack was
generated by a packet = already received (entirely below RCV.NXT), or a
packet following a = lost or as yet un-received packet (entirely beyond
RCV.NXT). =  Both of these conditions generate a = duplicate
acknowledgment.

Ethan

Hi Ethan,

you are completely = right. However, in the example of section 5.1 it is assumed that = no segment is lost.
IMHO the example is not correct = (anymore) since it is assumed that a DUPACK can be piggyback on a data = packet.
According to 2581bis a DUPACK carries no = data.

Alex

//
// = Dipl.-Inform. Alexander Zimmermann
// Department of Computer = Science, Informatik 4
// RWTH Aachen University
// = Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: = (49-241) 80-22220
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 84DC13A6925; Tue, 11 Nov 2008 12:41: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 A23693A6925 for ; Tue, 11 Nov 2008 12:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FS_REPLICA=0.994, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxB9Ai9lyqZU for ; Tue, 11 Nov 2008 12:41:19 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C6B5A3A6822 for ; Tue, 11 Nov 2008 12:41:18 -0800 (PST) Received: from [67.59.52.214] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L0030-000AIA-Ki; Tue, 11 Nov 2008 20:41:17 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 7CACB2BE23; Tue, 11 Nov 2008 15:41:12 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id AEF1E27F1E; Tue, 11 Nov 2008 15:41:11 -0500 (EST) Date: Tue, 11 Nov 2008 15:41:11 -0500 From: Ethan Blanton To: Alexander Zimmermann Message-ID: <20081111204111.GA13466@elb.elitists.net> Mail-Followup-To: Alexander Zimmermann , tcpm@ietf.org References: <5896054F-1A61-4BAC-94B0-F89660190A53@nets.rwth-aachen.de> <20081108195919.GA13079@elb.elitists.net> MIME-Version: 1.0 In-Reply-To: X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: tcpm@ietf.org Subject: Re: [tcpm] RFC 2883 (D-SACK), Section 5.1 Replication by the network 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="===============2101553309==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============2101553309== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alexander Zimmermann spake unto us the following wisdom: > Am 08.11.2008 um 20:59 schrieb Ethan Blanton: >> Alexander Zimmermann spake unto us the following wisdom: >>> >>> According 2581(bis) a TCP receiver should send immediately an DUPACK >>> when an out-of-order segment arrives. Furthermore, 2581bis says that=20 >>> a DUPACK carries no data. >>> >>> So, according to the DUPACK definition of 2581bis it seems to me that >>> we have no problem to detect a packet replication in case D-SACK is >>> not present. Right? >> >> The problem here is that you have no idea whether the dupack was >> generated by a packet already received (entirely below RCV.NXT), or a >> packet following a lost or as yet un-received packet (entirely beyond >> RCV.NXT). Both of these conditions generate a duplicate >> acknowledgment. > > you are completely right. However, in the example of section 5.1 it is = =20 > assumed that no segment is lost. > IMHO the example is not correct (anymore) since it is assumed that a =20 > DUPACK can be piggyback on a data packet. > According to 2581bis a DUPACK carries no data. You lost me, somewhere. In the example you quote there is indeed no loss, but the example does not need to show loss to model the utility of DSACK. The point is, that without the DSACK block, the sending TCP would have no way to know that in fact there *wasn't* loss, and would have to assume that the dupack coming back indicated that a segment above RCV.NXT had arrived out of order. Perhaps you should show an example timeline of packet events which you believe unambiguously indicates that a segment was received in duplicate. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --FCuugMFkClbJLl1L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJGe3nr9kA9Ig8HBQRAuUVAJ9W+Wpmp8E8pzaSyENSfQlngJpSNwCgyp0M CpwQve70Q9SvsFRfwk1Vkk0= =aKXH -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- --===============2101553309== 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 --===============2101553309==-- From tcpm-bounces@ietf.org Wed Nov 12 00:55:13 2008 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 3462B3A688E; Wed, 12 Nov 2008 00:55:13 -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 894BE3A688E for ; Wed, 12 Nov 2008 00:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FS_REPLICA=0.994, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64xUlgpjepJW for ; Wed, 12 Nov 2008 00:55:11 -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 03A013A6836 for ; Wed, 12 Nov 2008 00:55:10 -0800 (PST) Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0KA700JKWQ3YVWD0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 12 Nov 2008 09:55:10 +0100 (CET) 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, 12 Nov 2008 09:55:10 +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 mAC8t91I015173; Wed, 12 Nov 2008 09:55:09 +0100 (CET) Date: Wed, 12 Nov 2008 09:55:08 +0100 From: Alexander Zimmermann In-reply-to: <20081111204111.GA13466@elb.elitists.net> To: Ethan Blanton Message-id: <65DDF4F1-4A29-40F4-80A3-80C2A9D0D429@nets.rwth-aachen.de> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) X-IronPort-AV: E=Sophos;i="4.33,589,1220220000"; d="sig'?scan'208,217";a="90146433" X-Pgp-Agent: GPGMail d53 (v53, Leopard) References: <5896054F-1A61-4BAC-94B0-F89660190A53@nets.rwth-aachen.de> <20081108195919.GA13079@elb.elitists.net> <20081111204111.GA13466@elb.elitists.net> Cc: tcpm@ietf.org Subject: Re: [tcpm] RFC 2883 (D-SACK), Section 5.1 Replication by the network 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="===============0947394966==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0947394966== Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-15--935194893 Content-transfer-encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-15--935194893 Content-Type: multipart/alternative; boundary=Apple-Mail-14--935194926 --Apple-Mail-14--935194926 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Ethan, sorry that I confused you :-) For the moment, please forget the example I quoted. The problem that I have is maybe only a phrasing problem in RFC 2883. Read this (RFC 2883, page 13, last paragraph): "If D-SACK was not used and one of the ***duplicate ACKs was piggybacked on a data packet***, the sender would not know how many duplicate packets had been received." and now read this (Draft 2581bis, page 3): "DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a "duplicate" in the following algorithms when (a) the receiver of the ACK has outstanding data, (b) ***the incoming acknowledgment carries no data,*** ..." Do you see my problem? Alex Am 11.11.2008 um 21:41 schrieb Ethan Blanton: > Alexander Zimmermann spake unto us the following wisdom: >> Am 08.11.2008 um 20:59 schrieb Ethan Blanton: >>> Alexander Zimmermann spake unto us the following wisdom: >>>> >>>> According 2581(bis) a TCP receiver should send immediately an >>>> DUPACK >>>> when an out-of-order segment arrives. Furthermore, 2581bis says >>>> that >>>> a DUPACK carries no data. >>>> >>>> So, according to the DUPACK definition of 2581bis it seems to me >>>> that >>>> we have no problem to detect a packet replication in case D-SACK is >>>> not present. Right? >>> >>> The problem here is that you have no idea whether the dupack was >>> generated by a packet already received (entirely below RCV.NXT), >>> or a >>> packet following a lost or as yet un-received packet (entirely >>> beyond >>> RCV.NXT). Both of these conditions generate a duplicate >>> acknowledgment. >> >> you are completely right. However, in the example of section 5.1 it >> is >> assumed that no segment is lost. >> IMHO the example is not correct (anymore) since it is assumed that a >> DUPACK can be piggyback on a data packet. >> According to 2581bis a DUPACK carries no data. > > You lost me, somewhere. > > In the example you quote there is indeed no loss, but the example does > not need to show loss to model the utility of DSACK. The point is, > that without the DSACK block, the sending TCP would have no way to > know that in fact there *wasn't* loss, and would have to assume that > the dupack coming back indicated that a segment above RCV.NXT had > arrived out of order. > > Perhaps you should show an example timeline of packet events which you > believe unambiguously indicates that a segment was received in > duplicate. > > Ethan > > -- > The laws that forbid the carrying of arms are laws [that have no > remedy > for evils]. They disarm only those who are neither inclined nor > determined to commit crimes. > -- Cesare Beccaria, "On Crimes and Punishments", 1764 // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-14--935194926 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
on a data packet***, the sender would not know how = many duplicate packets
had been received."

and = now read this (Draft 2581bis, page = 3):

"DUPLICATE ACKNOWLEDGMENT:
An = acknowledgment is considered a "duplicate" in the following = algorithms when
(a) the receiver of the ACK has = outstanding data,
(b) ***the incoming = acknowledgment carries no = data,***
..."

Do you see my = problem?

Alex

Am = 11.11.2008 um 21:41 schrieb Ethan Blanton:

Alexander Zimmermann spake unto us the following = wisdom:
Am 08.11.2008 um 20:59 schrieb = Ethan Blanton:
Alexander Zimmermann spake unto us the following = wisdom:

According 2581(bis) a TCP receiver should send immediately = an DUPACK
when = an out-of-order segment arrives. Furthermore, 2581bis says that =
a = DUPACK carries no = data.

So, = according to the DUPACK definition of 2581bis it seems to me = that
we = have no problem to detect a packet replication in case D-SACK = is
not = present. Right?

The problem here is that you = have no idea whether the dupack = was
generated by a packet already received (entirely below = RCV.NXT), or a
packet following a lost or as = yet un-received packet (entirely = beyond
RCV.NXT).  Both of these conditions generate a = duplicate
acknowledgment.

you are = completely right. However, in the example of section 5.1 it is =  
assumed that no segment = is lost.
IMHO the example is = not correct (anymore) since it is assumed that a =  
DUPACK can be piggyback = on a data packet.
According to = 2581bis a DUPACK carries no data.

You lost me, = somewhere.

In the example you quote there is indeed no loss, but = the example does
not need to show loss to model the utility of DSACK. =  The point is,
that without the DSACK block, the sending TCP = would have no way to
know that in fact there *wasn't* loss, and would = have to assume that
the dupack coming back indicated that a segment = above RCV.NXT had
arrived out of order.

Perhaps you should = show an example timeline of packet events which you
believe = unambiguously indicates that a segment was received = in
duplicate.

Ethan

--
The laws that forbid the = carrying of arms are laws [that have no remedy
for evils].  They = disarm only those who are neither inclined nor
determined to commit = crimes.
= = -- Cesare Beccaria, "On Crimes and Punishments", = 1764

=
//
// = Dipl.-Inform. Alexander Zimmermann
// Department of Computer = Science, Informatik 4
// RWTH Aachen University
// = Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: = (49-241) 80-22220
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 510AF3A67F5; Wed, 12 Nov 2008 08:38:58 -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 6EE893A67D0 for ; Wed, 12 Nov 2008 08:38:56 -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 3Zooq2r-dsLv for ; Wed, 12 Nov 2008 08:38:55 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7A18228C193 for ; Wed, 12 Nov 2008 08:38:55 -0800 (PST) Received: from [75.217.243.45] (45.sub-75-217-243.myvzw.com [75.217.243.45]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mACGcWRx028629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Nov 2008 08:38:35 -0800 (PST) Message-ID: <491B0688.5000401@isi.edu> Date: Wed, 12 Nov 2008 08:38:32 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ayourtch@cisco.com References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> 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: ah@tr-sys.de, tcpm@ietf.org, David Borman , Fernando Gont Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Yourtchenko wrote: ... > After reading the set of what I could find - the only conclusion > regarding TCP Urgent that I could come to if I was designing an > application - "Don't use it. At all." I'm wondering what the current uses are; if they misuse urgent, then fixing the specs won't help. Maybe we should instead deprecate the function altogether? > 1) Given the state of the matters and practical experience, are the OOB > notifications (which TCP Urgent boils down to?) utilised enough in the > today's (and tomorrow's) world to have them as part of the "core" > protocol header as opposed to being an option ? > > (searching suggests this has already been on the table back in '94 as > one of the "small changes" within the tcpng bounds - but I was not able > to find any discussions on the topic - I presume they happened offline - > so would very much appreciate an enlightenment from someone who happened > to be part of those discussions). > > 2) Would we want to more effectively utilise these 16 bits in the TCP > header (assuming the URG flag rests at "0"), rather than transmitting > two zero bytes for 99.99% of the cases ? If we can't get the community to implement Urgent as per spec, we probably can't reassign those bits either. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkbBogACgkQE5f5cImnZrvuIQCdFVkPnRwmANRKD3QmY7Y5eJ3p Y5EAnjklUlDH/zscaHedZF0LTOImVvMt =53As -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 12 10:14:04 2008 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 96C3C3A6808; Wed, 12 Nov 2008 10:14: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 264B43A67F5 for ; Wed, 12 Nov 2008 10:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FS_REPLICA=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 lVWywSPNx+6T for ; Wed, 12 Nov 2008 10:14:02 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46D7C3A6407 for ; Wed, 12 Nov 2008 10:14:02 -0800 (PST) Received: from [67.59.52.214] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L0KE3-000Nj2-3d for tcpm@ietf.org; Wed, 12 Nov 2008 18:14:01 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 160D32BE23 for ; Wed, 12 Nov 2008 13:13:56 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 4582C27F1E; Wed, 12 Nov 2008 13:13:55 -0500 (EST) Date: Wed, 12 Nov 2008 13:13:56 -0500 From: Ethan Blanton To: tcpm@ietf.org Message-ID: <20081112181356.GB13466@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <5896054F-1A61-4BAC-94B0-F89660190A53@nets.rwth-aachen.de> <20081108195919.GA13079@elb.elitists.net> <20081111204111.GA13466@elb.elitists.net> <65DDF4F1-4A29-40F4-80A3-80C2A9D0D429@nets.rwth-aachen.de> MIME-Version: 1.0 In-Reply-To: <65DDF4F1-4A29-40F4-80A3-80C2A9D0D429@nets.rwth-aachen.de> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Subject: Re: [tcpm] RFC 2883 (D-SACK), Section 5.1 Replication by the network 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="===============0359775282==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0359775282== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alexander Zimmermann spake unto us the following wisdom: > For the moment, please forget the example I quoted. n> > The problem that I have is maybe only a phrasing problem in RFC 2883. > > Read this (RFC 2883, page 13, last paragraph): > > "If D-SACK was not used and one of the ***duplicate ACKs was > piggybacked on a data packet***, the sender would not know how many > duplicate packets had been received." OK, so this is unlikely to happen -- but note that the following sentence covers exactly the situation where it does not. > and now read this (Draft 2581bis, page 3): > > "DUPLICATE ACKNOWLEDGMENT: > An acknowledgment is considered a "duplicate" in the following =20 > algorithms when > (a) the receiver of the ACK has outstanding data, > (b) ***the incoming acknowledgment carries no data,*** > ..." > > Do you see my problem? Yes and no -- I see that 2883 describes, in part of one example, a situation which is unlikely, and which requires that a duplicate acknowledgment is defined in a broader sense than 2581bis. (However, note that 2581bis says that "Out-of-order data segments SHOULD be acknowledged immediately, in order to accelerate loss recovery." It seems to me that a TCP stack which is choosing not to implement SACK/DSACK might reasonably interpret this SHOULD in such a way that suppresses immediate dupacks specifically for already-received-and-acknowledged data, allowing the normal delayed ACK timer to handle that case. I'm not going to make an argument either way, but I do point out that the requirement you are citing is only a SHOULD. I say "yes and no" because I don't see why this is an issue, or why we should care. So there's an example in 2883, part of which describes an unlikely situation; the conclusion drawn from the example is still valid. Where is the problem? Again, I suggest that you provide a sequence of events which you believe indicates that DSACKs (or some alternate explicit mechanism, such as Reiner Ludwig's clever Eifel bits) are not required to disambiguate duplicate segment reception =66rom general out-of-order packet reception. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQFJGxzkr9kA9Ig8HBQRAuj9AJ4vkMNloQjQvAZ//UqupZu/53o2IgCY/xrw nqd0jNqM3zTJMQhUCRuBhA== =y5Sj -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- --===============0359775282== 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 --===============0359775282==-- From tcpm-bounces@ietf.org Wed Nov 12 15:11:55 2008 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 AD0C93A6988; Wed, 12 Nov 2008 15:11: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 6551B3A6988 for ; Wed, 12 Nov 2008 15:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.013 X-Spam-Level: X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg1wJFJGWNbo for ; Wed, 12 Nov 2008 15:11:53 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 377BE3A63D2 for ; Wed, 12 Nov 2008 15:11:52 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AC9B06B673B; Wed, 12 Nov 2008 20:11:56 -0300 (ART) Received: from notebook.gont.com.ar (host21.190-139-184.telecom.net.ar [190.139.184.21]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mACNBaPj028065; Wed, 12 Nov 2008 21:11:40 -0200 Message-Id: <200811122311.mACNBaPj028065@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Nov 2008 19:06:15 -0300 To: Joe Touch , ayourtch@cisco.com From: Fernando Gont In-Reply-To: <491B0688.5000401@isi.edu> References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> <491B0688.5000401@isi.edu> 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]); Wed, 12 Nov 2008 20:11:56 -0300 (ART) Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 01:38 p.m. 12/11/2008, Joe Touch wrote: > > After reading the set of what I could find - the only conclusion > > regarding TCP Urgent that I could come to if I was designing an > > application - "Don't use it. At all." > >I'm wondering what the current uses are; As far as I have been able to check (not that much), "urgent data" is used in what you'd call legacy applications (telnet, login, ftp) and some databases (I had been told MS SQL used it). >if they misuse urgent, then >fixing the specs won't help. FWIW, one could argue that they do misuses urgent. Basically, there are two things every app does wrt "urgent data" 1) They interpret the semantics of the UP incorrectly. (they interpret the UP as pointing to the byte following the last byte of urgent data, rather than pointing to the last byte of urgent data). 2) They read urgent data OOB. #1 can be easily "accommodated" by updating RFC1122. It's not that I "really love the idea", but I'm being pragmatic: it doesn't hurt, doesn't break anything, and keeps the specs relevant. While one could argue that #2 is simply broken, after all the end-result is the same: you discard everything up to the urgent mark. Also, as there are not that many applications using urgent data, it would not be crazy to expect/pretend that they get fixed (by having hem set SO_OOBINLINE). >Maybe we should instead deprecate the function altogether? Honestly speaking, this is what Andrew and me really and in mind, but we thought the proposal would sound controversial to many. :-) So we decided to trigger discussion on these issues, and propose (in the very first version of the draft) just to "fix" (for some meaning of "fix) urgent data, rather than deprecating it. I'll be putting on-line a rev of the urgent data soon, that better reflects the options we have on the table, the feedback we have got so far, etc., and probably even some survey of the apps that use urgent data. I guess that might help to decide which specific path to pursue. How does this sound? > > 2) Would we want to more effectively utilise these 16 bits in the TCP > > header (assuming the URG flag rests at "0"), rather than transmitting > > two zero bytes for 99.99% of the cases ? > >If we can't get the community to implement Urgent as per spec, we >probably can't reassign those bits either. I guess we could find some backwards-compatible approach to reassign the URG bits and the UP..... 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 Wed Nov 12 15:16:08 2008 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 DDE3B3A6964; Wed, 12 Nov 2008 15:16:08 -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 2AC3B3A6947 for ; Wed, 12 Nov 2008 15:16:07 -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 8+WJ0dpcymp2 for ; Wed, 12 Nov 2008 15:16:05 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C91563A63D2 for ; Wed, 12 Nov 2008 15:16:05 -0800 (PST) Received: from [75.214.39.252] (252.sub-75-214-39.myvzw.com [75.214.39.252]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mACNFai8028089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Nov 2008 15:15:39 -0800 (PST) Message-ID: <491B6397.6090308@isi.edu> Date: Wed, 12 Nov 2008 15:15:35 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Fernando Gont References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> <491B0688.5000401@isi.edu> <200811122311.mACNBaPj028065@venus.xmundo.net> In-Reply-To: <200811122311.mACNBaPj028065@venus.xmundo.net> 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, ah@tr-sys.de, ayourtch@cisco.com, David Borman Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: ... > I'll be putting on-line a rev of the urgent data soon, that better > reflects the options we have on the table, the feedback we have got so > far, etc., and probably even some survey of the apps that use urgent > data. I guess that might help to decide which specific path to pursue. > > How does this sound? Good idea... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkbY5cACgkQE5f5cImnZrt6vACfZKAH3zFKgphN1h4Gi/YXYLCr soEAn3tvHfFPD0OzBplYRZjmP86QHDRI =mfom -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Nov 15 14:03:20 2008 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 1BDF33A680F; Sat, 15 Nov 2008 14:03: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 3D4B03A680F for ; Sat, 15 Nov 2008 14:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx6LPeIkNAfZ for ; Sat, 15 Nov 2008 14:03:17 -0800 (PST) Received: from s-utl01-dcpop.stsn.net (s-utl01-dcpop.stsn.net [72.255.0.201]) by core3.amsl.com (Postfix) with SMTP id 94A4C3A67F5 for ; Sat, 15 Nov 2008 14:03:17 -0800 (PST) Received: from s-utl01-dcpop.stsn.net ([127.0.0.1]) by s-utl01-dcpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2008111517031722929 for ; Sat, 15 Nov 2008 17:03:17 -0500 Received: from kilo.rtfm.com ([10.11.23.51]) by s-utl01-dcpop.stsn.net for tcpm@ietf.org; Sat, 15 Nov 2008 17:03:05 -0500 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id DD4F57575BD for ; Sat, 15 Nov 2008 13:33:38 -0800 (PST) Date: Sat, 15 Nov 2008 13:33:28 -0800 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081115213338.DD4F57575BD@kilo.rtfm.com> Subject: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05 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 $Id: draft-ietf-tcpm-tcp-auth-opt-05-rev.txt,v 1.1 2008/11/15 20:50:05 ekr Exp $ Overall, this document is substantially improved. However, a number of the issues I raised in previous reviews remain: OLD ISSUES In particular, I wrote: I don't think this API, specification of the TSAD, etc., is particularly helpful. IPsec needed the concept of an association database because packets corresponding to multiple associations got similar treatment. However, TCP has an explicit notion of connection so it would be far more convenient to simply refer to keys as tied to connections, and then have a set of rules for mapping which connections get which keys. Even if some TSAD-type abstraction is useful, I don't think it's appropriate to define things like the size of each parameter in the TSAD as opposed to on the wire, or to describe the default values of various parameters as in S 3. For instance: iii. Key length. A byte indicating the length of the connection key in bytes. Those are internal implementation issues. Certainly, I might want to use a native int in my implementation. Why should this document tell me otherwise? In response to my previous review, Joe indicated that: The TSAD API needs to be specified in detail because the key management solution needs to rely on that information. I don't agree that it's necessary to define *any* API. What's necessary is to define clear boundaries between the packet processing system and the key management system (if any). I don't see that it's necessary to be specified at the level of "this parameter is a byte". If you want enough specificity that uncooperating implementors could independently develop these components and have them work together out of the box, then you need to explicitly define much more material, i.e., argument order, struct packing, error formats, calling sequences etc. In other words, you should either be defining language bindings or a formal language like IDL. Absent that, I don't agree that defining the length of the fields containing these parameters is of any value. It's particularly odd to focus on the length of the parameters and not specify (for instance) the signedness or the bit order. WRT to S 3 (now in S 6) I wrote: >> At least one direction (inbound/outbound) SHOULD have a non-"NONE" MAC in practice, but this MUST NOT be strictly required by an implementation. 1. This seems like a bad idea. It's very hard to analyze the security properties of a connection when only one side is protected. To take one case that is obviously bad, if you're worried about DoS attacks and you use TCP-AO, then forging packets in either direction can bring it down. I would reverse this and require MACs in both directions. 2. Even if we stipulate that this might be an OK idea, it's not appropriate to require implementations to support it. No good reason has ever been offered for this feature. Given the above reasoning, I propose it be removed. S 1.1. o TCP-AO replaces MD5's single MAC algorithm with two prespecified MACs (TBD-WG-MACS), and allows extension to include other MACs. I remain unconvinced that defining two MACs as MTI does anything but add complexity. NEW TECHNICAL ISSUES Overall I'm wondering if we should specify heuristics or algorithms for key changeover. Here's what I mean: Alice and Bob are currently using Key 1 and they want to change over to Key 2. At time T0, Alice installs Key 2, but she can't start transmitting with it until she knows that Bob has installed it. At time T1, Bob installs Key 2. Now, if he knows that Alice installed first, he can start using it, but if he does and Alice hasn't, then packets start getting dropped. Finally, once Bob has installed Key 2, he needs to tell Alice that he has installed Key 2 so he can switch over. This is a lot of manual coordination. Lebovitz and I spent some time the other day trying to make this problem easier and here's what we came up with. 1. As soon as a node receives a segment protected with Key X (and verifies it, of course) it can conclude that the peer knows Key X and start using Key X to transmit with. 2. Once a peer has had a new key installed, it should periodically send a segment protected with that key. Note that the interval here should be low enough that if the verification fails it doesn't cause TCP to back off really far. But other than that, it doesn't matter how it's set. [Maybe there's some TCP wizardry here to decrease the effect, like you only treat ACKs this way or something...] I'm assuming there's some concept of ordering or priority where key X is assumed to be better (newer) than Y. That seems easy to have. Anyway, the point of this algorithm is that Alice and Bob can independently configure new keys and then the system will automatically detect when they both have them configured and start using them without any explicit coordination over when the keys are installed. S 4. I found this ESN management algorithm extremely hard to follow. For starters, no initial values are provided for {SND,RCV}.PREV_SEQ, which makes it hard to see even where to start. Aside from that, let's look at the first line: ROLL = (RCV.PREV_SEQ > 0xffff) && (SEG.SEQ < 0xffff); Why is 0xffff magic? I'm inferring that no TCP datagram can ever exceed 2^16 bytes of data, but actually the maximum is somewhat less because it's bounded by the maximum length of an IP datagram minus the various headers, so it's more like 2^16 - 40 plus options, and of course this option consumes space. Anyway, this algorithm needs much more documentation about why it's supposed to work. I would also note that despite the statement that hte algorithm is "written in C", this is not valid C source code, because you're using # as a comment character. S 5. Conn_key = TALG(TSAD_key, connblock) This is not a good method of generating traffic keys: 1. There is no guarantee that the TALG will generate a value as long as the required key. Indeed, it's easy to design a MAC where this is not true. For instance, AES-256-CMAC. 2. What you want to generate a key is a pseudorandom function (PRF) Not all MACs are PRFs. This is easy to forget because HMAC is both. However, this is not always the case. For example, consider the following MAC, which is designed for the rapid detection of errored packets: MAC(Key, Data) = CRC32(Data) || HMAC(Key, Data) This is a perfectly fine MAC because forging it is intractable. However, it is a lousy PRF because the first 32 bits are extremely predictable. Note that this isn't at all a hypothetical example. Indeed, S 7.5 considers a MAC that is an even weaker PRF, with the initial values fixed! Additional reductions in MAC validation can be supported by using a MAC algorithm that partitions the MAC field into fixed and computed portions, where the fixed value is validated before investing in the computed portion. This optimization would be contained in the MAC algorithm specification. Note that the KeyID cannot be used for connection validation per se, because it is not assumed random. The use of the term "connection key" and "connection block" are confusing here because the keys are different in each direction, so there is no single conn key. I suggest using the term "traffic key". S 8. >> TCP-AO SHOULD be deployed in conjunction with support for selective acknowledgement (SACK), including support for multiple lost segments in the same round trip [RFC2018][RFC3517]. I get that SACK would be nice, but this should work fine without it, so why recommend it here. S 8.3 o TCP connection identifier (ID) (The socket pair, sent as 4 byte IP source address, 4 byte IP destination address, 2 byte TCP source port, 2 byte TCP destination port). This is incompatible with IPv6--a result of overspecification here. S 9. >> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for connections unless not supported by its peer, at which point it MAY use TCP MD5 instead. This seems like a restriction on operators and thus seems inappropriate to me. EDITORIAL S 3.2. The ESN for transmitted segments is locally maintained from a locally maintained SND.ESN value, for received segments, a local This repetition of "locally maintained" is clumsy. S 5 Once a connection is established, a connection key would typically be cached to avoid recomputing it on a per-segment basis. The use of both ISNs in the connection key computation ensures that segments cannot be replayed across repeated connections reusing the same socket pair (provided the ISN pair does not repeat, which is extremely unlikely). This is only true if strong ISN generation algorithms are used. This document should come with a SHOULD for using a strong PRNG for ISN generation. S 8.1. Keys reused across different socket pairs cannot enable replay attacks because the TCP socket pair is included in the MAC, as well as in the generation of the connection key. Keys reused across I would use "connnection id" instead of socket pair here. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Nov 15 14:48:27 2008 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 32A983A680F; Sat, 15 Nov 2008 14:48: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 4D1783A680F for ; Sat, 15 Nov 2008 14:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNBSFjEUFSLE for ; Sat, 15 Nov 2008 14:48:24 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D7F1E3A6805 for ; Sat, 15 Nov 2008 14:48:24 -0800 (PST) Received: from [192.168.1.46] (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 mAFMmFLB024660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 Nov 2008 14:48:17 -0800 (PST) Message-ID: <491F51AF.9090902@isi.edu> Date: Sat, 15 Nov 2008 14:48:15 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Eric Rescorla References: <20081115213338.DD4F57575BD@kilo.rtfm.com> In-Reply-To: <20081115213338.DD4F57575BD@kilo.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 Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05 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, Some clarifying questions below. I think most of these are easy to fix... Joe Eric Rescorla wrote: > $Id: draft-ietf-tcpm-tcp-auth-opt-05-rev.txt,v 1.1 2008/11/15 20:50:05 ekr Exp $ > > Overall, this document is substantially improved. However, > a number of the issues I raised in previous reviews remain: > > OLD ISSUES > In particular, I wrote: > > I don't think this API, specification of the TSAD, etc., is > particularly helpful. IPsec needed the concept of an association > database because packets corresponding to multiple associations > got similar treatment. However, TCP has an explicit notion > of connection so it would be far more convenient to simply > refer to keys as tied to connections, and then have a set > of rules for mapping which connections get which keys. > > Even if some TSAD-type abstraction is useful, I don't think > it's appropriate to define things like the size of each > parameter in the TSAD as opposed to on the wire, or to > describe the default values of various parameters as in > S 3. For instance: > > iii. Key length. A byte indicating the length of the > connection key in bytes. > > Those are internal implementation issues. Certainly, I might > want to use a native int in my implementation. Why should > this document tell me otherwise? > > In response to my previous review, Joe indicated that: > > The TSAD API needs to be specified in detail because the key management > solution needs to rely on that information. > > I don't agree that it's necessary to define *any* API. What's > necessary is to define clear boundaries between the packet processing > system and the key management system (if any). I don't see that it's > necessary to be specified at the level of "this parameter is a byte". > If you want enough specificity that uncooperating implementors could > independently develop these components and have them work together out > of the box, then you need to explicitly define much more material, > i.e., argument order, struct packing, error formats, calling sequences > etc. In other words, you should either be defining language bindings > or a formal language like IDL. Absent that, I don't agree that > defining the length of the fields containing these parameters is of > any value. It's particularly odd to focus on the length of the > parameters and not specify (for instance) the signedness or the > bit order. These would be good reasons to include the signedness (all are unsigned) and byte order (network standard). I don't see a reason to indicate bit order. > WRT to S 3 (now in S 6) I wrote: > > >> At least one direction (inbound/outbound) SHOULD have > a non-"NONE" MAC in practice, but this MUST NOT be > strictly required by an implementation. > > 1. This seems like a bad idea. It's very hard to analyze the security > properties of a connection when only one side is protected. To take > one case that is obviously bad, if you're worried about DoS attacks > and you use TCP-AO, then forging packets in either direction can > bring it down. I would reverse this and require MACs in both directions. > > 2. Even if we stipulate that this might be an OK idea, it's not > appropriate to require implementations to support it. > > No good reason has ever been offered for this feature. Given the above > reasoning, I propose it be removed. We covered this in detail in an extended discussion in Philadelphia; it is needed to support channel binding. We can't turn on TCP AO after a connection has started (because TCP has no option handshake after connection establishment), but we can go from using a null algorithm to using a real one. > S 1.1. > o TCP-AO replaces MD5's single MAC algorithm with two prespecified > MACs (TBD-WG-MACS), and allows extension to include other MACs. > > I remain unconvinced that defining two MACs as MTI does anything but > add complexity. You noted this before; I'll raise this to both TCPM and SAAG to confirm that a single algorithm is sufficient. > NEW TECHNICAL ISSUES > Overall > I'm wondering if we should specify heuristics or algorithms for > key changeover. Here's what I mean: Alice and Bob are currently > using Key 1 and they want to change over to Key 2. At time > T0, Alice installs Key 2, but she can't start transmitting with > it until she knows that Bob has installed it. At time T1, > Bob installs Key 2. Now, if he knows that Alice installed first, > he can start using it, but if he does and Alice hasn't, then > packets start getting dropped. Finally, once Bob has installed > Key 2, he needs to tell Alice that he has installed Key 2 > so he can switch over. This is a lot of manual coordination. Agreed; IMO, this is the responsibility of the key management system, not TCP-AO. > Lebovitz and I spent some time the other day trying to make this > problem easier and here's what we came up with. > > 1. As soon as a node receives a segment protected with Key X > (and verifies it, of course) it can conclude that the peer > knows Key X and start using Key X to transmit with. We do not require symmetric key changeover. Side A can use key X while side B uses key Y; there is no requirement that the senders use the same index. > 2. Once a peer has had a new key installed, it should periodically > send a segment protected with that key. Note that the interval > here should be low enough that if the verification fails it > doesn't cause TCP to back off really far. But other than that, > it doesn't matter how it's set. [Maybe there's some TCP wizardry > here to decrease the effect, like you only treat ACKs this way > or something...] This sounds like a protocol on top of TCP; we're trying to avoid that. TCP segments have other meanings, and sending such segments just for a key management reason would impact other TCP properties we're trying to leave alone. > I'm assuming there's some concept of ordering or priority where key > X is assumed to be better (newer) than Y. That seems easy to have. > > Anyway, the point of this algorithm is that Alice and Bob can > independently configure new keys and then the system will automatically > detect when they both have them configured and start using them > without any explicit coordination over when the keys are installed. The common algorithm is: a) install key at receiver b) install key at sender Since our keys are directional, (b) is taken as implicit permission to use that key. I don't see a reason for further key coordination. > S 4. > I found this ESN management algorithm extremely hard to follow. > For starters, no initial values are provided for {SND,RCV}.PREV_SEQ, > which makes it hard to see even where to start. We can initialize those as ISN-1. > Aside from that, let's look at the first line: > > ROLL = (RCV.PREV_SEQ > 0xffff) && (SEG.SEQ < 0xffff); > > Why is 0xffff magic? Sorry - that's a bug. It had been 0x7fff; I had changed it incorrectly in this version. I need to debug that code... ... > Anyway, this algorithm needs much more documentation about why > it's supposed to work. Agreed. > S 5. > Conn_key = TALG(TSAD_key, connblock) > > This is not a good method of generating traffic keys: > > 1. There is no guarantee that the TALG will generate a value as > long as the required key. Indeed, it's easy to design a MAC > where this is not true. For instance, AES-256-CMAC. That point was already raised and needs to be addressed. > 2. What you want to generate a key is a pseudorandom function (PRF) > Not all MACs are PRFs. This is easy to forget because HMAC is > both. However, this is not always the case. Understood; the question is whether we should be specifying separate PRFs, or a PRF that can be based on a MAC. I'd prefer the latter, to allow the PRF to track the addition of new MAC algorithms. Is there a way to do this? ... > Additional reductions in MAC validation can be supported by using a > MAC algorithm that partitions the MAC field into fixed and computed > portions, where the fixed value is validated before investing in the > computed portion. This optimization would be contained in the MAC > algorithm specification. Note that the KeyID cannot be used for > connection validation per se, because it is not assumed random. > > > The use of the term "connection key" and "connection block" are > confusing here because the keys are different in each direction, so > there is no single conn key. I suggest using the term "traffic > key". We don't use those terms in the above paragraph. We might use connection receive key and connection transmit key, but I don't think 'traffic' key is appropriate in a TCP document. > S 8. > >> TCP-AO SHOULD be deployed in conjunction with support for > selective acknowledgement (SACK), including support for multiple lost > segments in the same round trip [RFC2018][RFC3517]. > > I get that SACK would be nice, but this should work fine without > it, so why recommend it here. It helps reduce the overhead of rekeying lost segments. That might be worth mentioning, and we should determine whether this needs to be a SHOULD. > S 8.3 > o TCP connection identifier (ID) (The socket pair, sent as 4 byte IP > source address, 4 byte IP destination address, 2 byte TCP source > port, 2 byte TCP destination port). > > This is incompatible with IPv6--a result of overspecification here. Agreed. > S 9. > >> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for > connections unless not supported by its peer, at which point it MAY > use TCP MD5 instead. > > This seems like a restriction on operators and thus seems inappropriate > to me. That's an artifact of trying to include deprecation of TCP MD5 in this doc; operator guidance seemed needed. If that's not the case, we can remove it... > EDITORIAL > S 3.2. > > The ESN for transmitted segments is locally maintained from a > locally maintained SND.ESN value, for received segments, a local > > This repetition of "locally maintained" is clumsy. Agreed. Will fix. > S 5 > Once a connection is established, a connection key would typically be > cached to avoid recomputing it on a per-segment basis. The use of > both ISNs in the connection key computation ensures that segments > cannot be replayed across repeated connections reusing the same > socket pair (provided the ISN pair does not repeat, which is > extremely unlikely). > > This is only true if strong ISN generation algorithms are used. > This document should come with a SHOULD for using a strong PRNG > for ISN generation. Agreed. > S 8.1. > Keys reused across different socket pairs cannot enable replay > attacks because the TCP socket pair is included in the MAC, as well > as in the generation of the connection key. Keys reused across > > I would use "connnection id" instead of socket pair here. Agreed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkkfUa4ACgkQE5f5cImnZrueBQCYwPODKKQNntnZsZColaK6xCKD EACgmu7LC4ETj56d4wbpyQtu9m2AiEo= =p8bm -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Nov 15 15:51:34 2008 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 C0AC13A6943; Sat, 15 Nov 2008 15:51: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 736C43A6943 for ; Sat, 15 Nov 2008 15:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 iDHGeBkh9dGw for ; Sat, 15 Nov 2008 15:51:33 -0800 (PST) Received: from s-utl02-dcpop.stsn.net (s-utl02-dcpop.stsn.net [72.255.0.202]) by core3.amsl.com (Postfix) with SMTP id A53683A693D for ; Sat, 15 Nov 2008 15:51:33 -0800 (PST) Received: from s-utl02-dcpop.stsn.net ([127.0.0.1]) by s-utl02-dcpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2008111518513317629 for ; Sat, 15 Nov 2008 18:51:33 -0500 Received: from kilo.rtfm.com ([10.11.23.51]) by s-utl02-dcpop.stsn.net for tcpm@ietf.org; Sat, 15 Nov 2008 18:51:22 -0500 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id B57AB757BD0; Sat, 15 Nov 2008 17:38:19 -0600 (CST) Date: Sat, 15 Nov 2008 17:38:19 -0600 From: Eric Rescorla To: tcpm@ietf.org, draft-gont-tcpm-tcp-timestamps@tools.ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081115233819.B57AB757BD0@kilo.rtfm.com> Subject: [tcpm] Comment on 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 In Section 2, you write: the requirements of Section 4.2.2 of RFC 1323 [RFC1323], and F() is a function that should not be computable from the outside. Therefore, we suggest F() to be a cryptographic hash function of the connection-id and some secret data. Sorry to sound like nitpicky cryptographer guy here, but you want a PRF, not a hash function. A hash function might or might not be good enough depending on the function... -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Nov 16 12:33:26 2008 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 B8A543A699C; Sun, 16 Nov 2008 12:33:26 -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 BE02F3A699C for ; Sun, 16 Nov 2008 12:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnA4EIrNoMn8 for ; Sun, 16 Nov 2008 12:33:24 -0800 (PST) Received: from kilo.rtfm.com (unknown [130.129.95.170]) by core3.amsl.com (Postfix) with ESMTP id 4779C3A67AA for ; Sun, 16 Nov 2008 12:33:24 -0800 (PST) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 79E27757B07; Sat, 15 Nov 2008 17:31:46 -0600 (CST) Date: Sat, 15 Nov 2008 17:31:46 -0600 From: Eric Rescorla To: Joe Touch In-Reply-To: <491F51AF.9090902@isi.edu> References: <20081115213338.DD4F57575BD@kilo.rtfm.com> <491F51AF.9090902@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081115233146.79E27757B07@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05 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 Sat, 15 Nov 2008 14:48:15 -0800, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Eric, > > Some clarifying questions below. I think most of these are easy to fix... > > Joe > > Eric Rescorla wrote: > > $Id: draft-ietf-tcpm-tcp-auth-opt-05-rev.txt,v 1.1 2008/11/15 20:50:05 ekr Exp $ > > > > Overall, this document is substantially improved. However, > > a number of the issues I raised in previous reviews remain: > > > > OLD ISSUES > > In particular, I wrote: > > > > I don't think this API, specification of the TSAD, etc., is > > particularly helpful. IPsec needed the concept of an association > > database because packets corresponding to multiple associations > > got similar treatment. However, TCP has an explicit notion > > of connection so it would be far more convenient to simply > > refer to keys as tied to connections, and then have a set > > of rules for mapping which connections get which keys. > > > > Even if some TSAD-type abstraction is useful, I don't think > > it's appropriate to define things like the size of each > > parameter in the TSAD as opposed to on the wire, or to > > describe the default values of various parameters as in > > S 3. For instance: > > > > iii. Key length. A byte indicating the length of the > > connection key in bytes. > > > > Those are internal implementation issues. Certainly, I might > > want to use a native int in my implementation. Why should > > this document tell me otherwise? > > > > In response to my previous review, Joe indicated that: > > > > The TSAD API needs to be specified in detail because the key management > > solution needs to rely on that information. > > > > I don't agree that it's necessary to define *any* API. What's > > necessary is to define clear boundaries between the packet processing > > system and the key management system (if any). I don't see that it's > > necessary to be specified at the level of "this parameter is a byte". > > If you want enough specificity that uncooperating implementors could > > independently develop these components and have them work together out > > of the box, then you need to explicitly define much more material, > > i.e., argument order, struct packing, error formats, calling sequences > > etc. In other words, you should either be defining language bindings > > or a formal language like IDL. Absent that, I don't agree that > > defining the length of the fields containing these parameters is of > > any value. It's particularly odd to focus on the length of the > > parameters and not specify (for instance) the signedness or the > > bit order. > > These would be good reasons to include the signedness (all are unsigned) > and byte order (network standard). I don't see a reason to indicate bit > order. I want to remove the entire feature, not finish it. I only mention the fact that it's insufficient in passing. > > WRT to S 3 (now in S 6) I wrote: > > > > >> At least one direction (inbound/outbound) SHOULD have > > a non-"NONE" MAC in practice, but this MUST NOT be > > strictly required by an implementation. > > > > 1. This seems like a bad idea. It's very hard to analyze the security > > properties of a connection when only one side is protected. To take > > one case that is obviously bad, if you're worried about DoS attacks > > and you use TCP-AO, then forging packets in either direction can > > bring it down. I would reverse this and require MACs in both directions. > > > > 2. Even if we stipulate that this might be an OK idea, it's not > > appropriate to require implementations to support it. > > > > No good reason has ever been offered for this feature. Given the above > > reasoning, I propose it be removed. > > We covered this in detail in an extended discussion in Philadelphia; it > is needed to support channel binding. We can't turn on TCP AO after a > connection has started (because TCP has no option handshake after > connection establishment), but we can go from using a null algorithm to > using a real one. Well, I wasn't in Philadelphia, but I don't find this to be enough information to convince me--I can certainly think of ways to make channel binding work that don't require asymmetric protection. Perhaps you can point me to something someone has written that describes the issue? > > NEW TECHNICAL ISSUES > > Overall > > I'm wondering if we should specify heuristics or algorithms for > > key changeover. Here's what I mean: Alice and Bob are currently > > using Key 1 and they want to change over to Key 2. At time > > T0, Alice installs Key 2, but she can't start transmitting with > > it until she knows that Bob has installed it. At time T1, > > Bob installs Key 2. Now, if he knows that Alice installed first, > > he can start using it, but if he does and Alice hasn't, then > > packets start getting dropped. Finally, once Bob has installed > > Key 2, he needs to tell Alice that he has installed Key 2 > > so he can switch over. This is a lot of manual coordination. > > Agreed; IMO, this is the responsibility of the key management system, > not TCP-AO. The key management system is two people at either end of a cell phone. I'm trying to make their lives easier. > > Lebovitz and I spent some time the other day trying to make this > > problem easier and here's what we came up with. > > > > 1. As soon as a node receives a segment protected with Key X > > (and verifies it, of course) it can conclude that the peer > > knows Key X and start using Key X to transmit with. > > We do not require symmetric key changeover. Side A can use key X while > side B uses key Y; there is no requirement that the senders use the same > index. Nor did I say otherwise. I'm saying that receiving index X from the peer is permission to respond with it. It doesn't require you to do so. > > 2. Once a peer has had a new key installed, it should periodically > > send a segment protected with that key. Note that the interval > > here should be low enough that if the verification fails it > > doesn't cause TCP to back off really far. But other than that, > > it doesn't matter how it's set. [Maybe there's some TCP wizardry > > here to decrease the effect, like you only treat ACKs this way > > or something...] > > This sounds like a protocol on top of TCP; we're trying to avoid that. > TCP segments have other meanings, and sending such segments just for a > key management reason would impact other TCP properties we're trying to > leave alone. I'm sorry if I gave the impression you would send extra segments. That's not what I meant. I merely meant that every so often instead of using key X, you use key Y as a probe instead. > > I'm assuming there's some concept of ordering or priority where key > > X is assumed to be better (newer) than Y. That seems easy to have. > > > > Anyway, the point of this algorithm is that Alice and Bob can > > independently configure new keys and then the system will automatically > > detect when they both have them configured and start using them > > without any explicit coordination over when the keys are installed. > > The common algorithm is: > > a) install key at receiver > b) install key at sender > > Since our keys are directional, The traffic keys are directional. It wasn't my impression from the document that the master keys were directional. If so, I think that should be changed. > (b) is taken as implicit permission to > use that key. I don't see a reason for further key coordination. Well, as it is you effectively need a two phase commit protocol. I'm trying to remove that. > > S 4. > > I found this ESN management algorithm extremely hard to follow. > > For starters, no initial values are provided for {SND,RCV}.PREV_SEQ, > > which makes it hard to see even where to start. > > We can initialize those as ISN-1. > > > Aside from that, let's look at the first line: > > > > ROLL = (RCV.PREV_SEQ > 0xffff) && (SEG.SEQ < 0xffff); > > > > Why is 0xffff magic? > > Sorry - that's a bug. It had been 0x7fff; I had changed it incorrectly > in this version. I need to debug that code... Now I'm even more puzzled. Why should it be 0x7fff? > > 2. What you want to generate a key is a pseudorandom function (PRF) > > Not all MACs are PRFs. This is easy to forget because HMAC is > > both. However, this is not always the case. > > Understood; the question is whether we should be specifying separate > PRFs, or a PRF that can be based on a MAC. I'd prefer the latter, to > allow the PRF to track the addition of new MAC algorithms. > > Is there a way to do this? Well, clearly one can do what TLS does and require each algorithm to specify a PRF. I'm not sure if there is a general transformation from MACs to PRFs. My intuition is no, however, because you somehow need to extract the random versus non-random components of the MAC output. > > Additional reductions in MAC validation can be supported by using a > > MAC algorithm that partitions the MAC field into fixed and computed > > portions, where the fixed value is validated before investing in the > > computed portion. This optimization would be contained in the MAC > > algorithm specification. Note that the KeyID cannot be used for > > connection validation per se, because it is not assumed random. > > > > > > The use of the term "connection key" and "connection block" are > > confusing here because the keys are different in each direction, so > > there is no single conn key. I suggest using the term "traffic > > key". > > We don't use those terms in the above paragraph. We might use connection > receive key and connection transmit key, but I don't think 'traffic' key > is appropriate in a TCP document. Well, traffic key is the standard comsec terminology. However, I'm fine with connection receive key and conneciton transmit ke. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 17 10:51:20 2008 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 A276C3A6A04; Mon, 17 Nov 2008 10:51: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 3828F3A6A04 for ; Mon, 17 Nov 2008 10:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGYu+MKe8aCk for ; Mon, 17 Nov 2008 10:51:17 -0800 (PST) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id 0A3113A67A6 for ; Mon, 17 Nov 2008 10:51:16 -0800 (PST) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id mAHIpGvf004518 for ; Mon, 17 Nov 2008 12:51:16 -0600 Received: from USDALSMBS02.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 17 Nov 2008 12:51:15 -0600 Received: from USDALSMBS05.ad3.ad.alcatel.com ([172.22.216.34]) by USDALSMBS02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 17 Nov 2008 12:51:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 12:51:15 -0600 Message-ID: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on TCP-AO Draft Thread-Index: AclI5XgHf+wZoobzTouVULb4S/pTOQ== From: "LANGE Andrew" To: X-OriginalArrivalTime: 17 Nov 2008 18:51:15.0632 (UTC) FILETIME=[78180300:01C948E5] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Subject: [tcpm] Comments on TCP-AO Draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0534397114==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0534397114== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C948E5.7809C84C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C948E5.7809C84C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Here are some comments on this draft. Since this is the last full draft = I have, I've focused the comments on this iteration. The short = version: This document needs significant work. Abstract: The draft begins to contextualize the place where TCP-AO is = operating. However, it does not pay any attention to draft-bonica, or = the 3+ years of deployment experience with draft-bonica. Proper = contextualization is important to evaluate the draft and its changes.=20 Abstract: Update to TCP MD5 needs a reference at the end of the Abstract = section. Abstract: Define "MACs" - this is the first time it's used, and although = we can hope that people know which ones we're talking about, it wouldn't = hurt to write "Message Authentication Codes (MACs)" out. General Comment: There is no security policy explained in the draft: = What are we protecting against? From whom are we protecting? For how = long? It is critical to know who the threat(s) are. General Comment: This draft badly needs a "Deployment Considerations" = section, that shows how to operationalize the techniques, and situates = things such as migration from older techniques to newer ones. = Especially important are transition mechanisms.=20 Introduction: we should defined "cryptographic key management" as in = "...not the framework for cryptographic key management." And explain why = the draft makes this recommendation. Introduction: End of 2nd paragraph, reference to Be07 should be = normative - if the draft is to fulfill the requirements, those = requirements should be not subject to a moving target. Introduction: The draft is very blithe about recommending IPSec and = IKE, without providing any context why this is a good idea, or why it = has never been deployed. There are significant issues with using IPSec = for routing (complexity, reduced convergence times, relying on security = layers for routing functions, etc.) These issues need to be documented, = and discussed, before as the IETF, a recommendation should be made.=20 Introduction: Last paragraph - "TCP MD5 does not support any changes to = the connection's security..." Well, the draft may not consider this, = however, if you get the keychange timing done correctly, in fact, you = can roll the keys. It's a kludge, but it would be inaccurate to state = otherwise. Exec Summary: "Allows TCP-MD5 to be used..." - Why is this here?=20 "TBD-WG-MACS" - MACs MUST be specified, in the draft.=20 Ends of "Allows rekeying" section - TCP MD5 rolling comment is at odds = with the end of the introduction, it should be explained how this works. = Also, why MD5 could lose packets also needs to be explained, and why = new techniques do not suffer from this limitation. "Provides more detail in how this option interacts with TCP's states, = event processing, and user interface" - more detail that what? Much of = this is implementation specific. Especially the user interface parts. = This draft tends to munge what is necessary for interoperation (the = standard), and the way one might implement that internally = (implementation details.) Providing a reference state machine or = details are useful, but shouldn't be conflated with the standard spec. "Provides automatic key rollover" - is this section referring to key = rollover via keychains? key diversification techniques?=20 "Proposed option is 3 bytes shorter than" - why should we care? What do = those 3 bytes buy us? "Does not authenticate ICMP messages (some may be authenticated in = IPsec..." - is it also lighter weight, and better suited to router = protocol operation and deployment.=20 1.4.1: " IETF-72 topic" sections "No current consensus was reached on = this topic, so no change was made." This is a real problem -- the logic = is deeply flawed. Allow me to restate: One author of this document has = appointed themselves the arbiter of consensus. This author disagrees = with other people, and therefore no "consensus" can ever be reached, so = the default case this author has chosen is to keep things they way they = like it. 3.2 - "in the sprit of SP4" - why is this relevant to the document?=20 3.2 - The whole of ESN gets introduced without much prelude or = contextualization. Since this is something new for this draft (correct = me if I'm wrong.) It really needs to be better contextualized. In fact, = since this is something that may have utility outside of TCP-AO, it = ought to be documented in a separate draft, probably as a separate = option. It has an impact on the TCP state machine that goes beyond a = bigger value to prevent replay. "TCP Data in Network Byte Order" - We really do need to specify which = MAC's were going to use. Otherwise, the draft isn't very useful. "When options are excluded, all options..." - How is this indicated on = the wire? I'm guessing that the plan is to do this with configuration = on each end. This is a recipe for misconfiguration and confusion. = Putting a bit in the option makes this much easier to troubleshoot, = especially for sessions between providers.=20 "The implementation of ESN is not specified in this document..." - Does = this mean that there is a forthcoming draft that specifies how ESN is to = be used? =20 "Computing connection keys from TSAD key entries" - This section is a = non sequitur , there needs to be framing and introduction, as well as = some sort of segue from the section partly documenting ESN. "Conn_key =3D MD5(TSAD_key, connblock)" - why is MD5 used here? "For SYN segments..." - Implicit special cases are bad, as a matter of = design. "... extremely unlikely" - how unlikely? We can put the number in there, = since the definition of "extremely" tends to change over time.=20 Section 6 - Security Association Management - Define a TSAD: What does = it do? Why does the draft propose this construct? =20 "A TSAD implementation MUST support at least two keyIDs per connection = per direction, and MAY support up to 256." - why only two? wouldn't we = imagine most TSAD's supporting 256? It's not much of a burden, and = making a recommendation for two in an example implementation may lead to = some bad designs. Somewhere we need to explicitly state that 0 is a valid keyID. IKEv2 Transform Type -- why are we putting a dependency on IKE for this? = The protocols can and should be completely orthogonal to each other. = Putting change-dependencies in on updating IKEv2 registries will limit = the protocols utility and agility. =20 "...single host there should only be a single database..." - this seems = at odds with sections later in the document. It also excludes = virtualization and multi-level secure systems. "..omit an explicit algorithm ID..." -- I've said this before, this is a = BAD IDEA^tm. The protocol utility of doing this is minimal (1-bit = increase in search space), and the operational complexity goes up. Not = to mention, it makes it operationally incompatible with existing = implementations.=20 "It is presumed that a TSAD entry affecting a particular connection..." = - this section is at odds with what id done elsewhere. If the document = is going to provide implementation advice, then it needs a state machine = here to show how one might handle key destruction, process conflict, = race conditions, etc. "Users are advised to not inappropriately reuse keys" - Why is there = this throwaway line in here? If we look at 3562, we see there are three = recommendations: o Key lengths SHOULD be between 12 and 24 bytes, with larger keys having = effectively zero additional computational costs when compared to shorter = keys.=20 o Key sharing SHOULD be limited so that keys aren't shared among = multiple BGP peering arrangements.=20 o Keys SHOULD be changed at least every 90 days. What are the recommendations for each of these? Why are we continuing = to use them here? With key diversification, perhaps the same root key = can be used (assuming we document that a peer sharing that key could = potentially create an attack on reboot). Also, with stronger MACs do we = need to change keys every 90 days? Are 12-24 byte keys appropriate for = HMAC-SHA1-96 and AES-CMAC-96? "TCP segments with TCP-AO but not matching TSAD entries MUST be silently = accepted." - Accepted? Does this have to do with the proposed = order-of-match logic internal to the end systems? "Additional reductions in MAC validation can be supported by using a MAC = algorithm that partitions the MAC field into fixed and computed = portions." - Do we have examples of these MAC algorithms? Wouldn't = adding a "fixed" portion to a MAC algorithm rather defeat one of the MAC = algorithm design goals? Perhaps one of the security experts could = comment on this. "In the default case, where only a single key is used at a time..." - = The document should elaborate on what it means here. Is this a = recommendation that the TSAD only support a single key? Why would there = be invalid keys used? "... benefits from congestion control support for temporary path = outages." - References? SACK recommendation - Why? Is there something special about TCP-AO, and = not regular TCP sessions? Or is this a recommendation to use SACK for = all TCP segments? "Implementations are encouraged to keep keys in a suitably private = area." I agree, but what does this mean? What is suitable for this = protocol? What is private? "Keys should not be shared across different hosts, because this could = compromise the keying material itself." - Doesn't this defeat the = purpose? This is a shared-key cryptosystem. "Note that when TCP MD5 is required for a connection, it must be used = [RFC2385]" - This is rather confusing. This was written in one time and = place, and there is real-life versus standards-life. We need to make = recommendations for the former. Is the advice that only MD5 or AO be = used based on a line in a standard published 10 years ago, that = documented an even older implementation?? Section 10 - The option to calculate options or not should be in the = packet. If not, there will be a lot of broken connections out there, = and people who have no idea why they are broken. Section 12 - reference to Be07 should be Normative.=20 Section 13 - this section shows a limited knowledge of deployed routing = protocols, especially in the comparison to what the document believes is = the preferred solution of using IPSec. In deployment, there is both the = TCP TTL hack, and the extensive use of edge and system ACL's to provide = multilayer security. =20 "TCP-AO does not expose the MAC algorithm used to authenticate a..." - = Again, this is a BAD IDEA^tm. It offers minimal expanded search space = for the algorithm (1-bit). It also violates fundamental security = design: The security should be in the key, not in the obscurity of the = algorithm. Not carrying algorithm ID results in more downtime due to = opaque system operation. =20 "ICMP messages of Type 3, Codes 2-4" - This needs to be expanded. = People do not have ICMP type codes memorized. "To specify MAC algorithms, TCP-AO uses the 4-byte namespace of IKEv2" - = Again, bad idea. This creates an unnecessary protocol linkage between = the spaces. Not to mention a development, test and operational headache = -- "This protocol supports 2 MAC types, and yet the codes are "17" and = "153" - WTF??" Andrew ------_=_NextPart_001_01C948E5.7809C84C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on TCP-AO Draft

Hi All,

Here are some comments on this draft.  Since this is the last full = draft I have, I've focused the comments on this iteration.   = The short version:  This document needs significant work.

Abstract:  The draft begins to contextualize the place where TCP-AO = is operating.   However, it does not pay any attention to = draft-bonica, or the 3+ years of deployment experience with = draft-bonica.  Proper contextualization is important to evaluate = the draft and its changes.

Abstract: Update to TCP MD5 needs a reference at the end of the Abstract = section.

Abstract: Define "MACs" - this is the first time it's used, = and although we can hope that people know which ones we're talking = about, it wouldn't hurt to write "Message Authentication Codes = (MACs)" out.

General Comment: There is no security policy explained in the draft: = What are we protecting against?  From whom are we protecting? For = how long?  It is critical to know who the threat(s) are.

General Comment: This draft badly needs a "Deployment = Considerations" section, that shows how to operationalize the = techniques, and situates things such as migration from older techniques = to newer ones.  Especially important are transition mechanisms.

Introduction: we should defined "cryptographic key management" = as in "...not the framework for cryptographic key management." = And explain why the draft makes this recommendation.

Introduction: End of 2nd paragraph, reference to Be07 should be = normative - if the draft is to fulfill the requirements, those = requirements should be not subject to a moving target.

Introduction:  The draft is very blithe about recommending IPSec = and IKE, without providing any context why this is a good idea, or why = it has never been deployed.  There are significant issues with = using IPSec for routing (complexity, reduced convergence times, relying = on security layers for routing functions, etc.)  These issues need = to be documented, and discussed, before as the IETF, a recommendation = should be made.

Introduction: Last paragraph - "TCP MD5 does not support any = changes to the connection's security..." Well, the draft may not = consider this, however, if you get the keychange timing done correctly, = in fact, you can roll the keys.  It's a kludge, but it would be = inaccurate to state otherwise.

Exec Summary:

"Allows TCP-MD5 to be used..."  - Why is this here?

"TBD-WG-MACS" - MACs MUST be specified, in the draft.

Ends of "Allows rekeying" section - TCP MD5 rolling comment is = at odds with the end of the introduction, it should be explained how = this works.  Also, why MD5 could lose packets also needs to be = explained, and why new techniques do not suffer from this = limitation.

"Provides more detail in how this option interacts with TCP's = states, event processing, and user interface" - more detail that = what?  Much of this is implementation specific.  Especially = the user interface parts.  This draft tends to munge what is = necessary for interoperation (the standard), and the way one might = implement that internally (implementation details.)  Providing a = reference state machine or details are useful, but shouldn't be = conflated with the standard spec.

"Provides automatic key rollover" - is this section referring = to key rollover via keychains?  key diversification techniques?

"Proposed option is 3 bytes shorter than" - why should we = care?  What do those 3 bytes buy us?

"Does not authenticate ICMP messages (some may be authenticated in = IPsec..." - is it also lighter weight, and better suited to router = protocol operation and deployment.

1.4.1: " IETF-72 topic" sections "No current consensus = was reached on this topic, so no change was made."  This is a = real problem -- the logic is deeply flawed.  Allow me to restate: = One author of this document has appointed themselves the arbiter of = consensus.  This author disagrees with other people, and therefore = no "consensus" can ever be reached, so the default case this = author has chosen is to keep things they way they like it.

3.2 - "in the sprit of SP4" - why is this relevant to the = document?

3.2 - The whole of ESN gets introduced without much prelude or = contextualization.  Since this is something new for this draft = (correct me if I'm wrong.) It really needs to be better = contextualized.  In fact, since this is something that may have = utility outside of TCP-AO, it ought to be documented in a separate = draft, probably as a separate option.  It has an impact on the TCP = state machine that goes beyond a bigger value to prevent replay.

"TCP Data in Network Byte Order" - We really do need to = specify which MAC's were going to use.  Otherwise, the draft isn't = very useful.

"When options are excluded, all options..." - How is this = indicated on the wire?  I'm guessing that the plan is to do this = with configuration on each end.  This is a recipe for = misconfiguration and confusion.  Putting a bit in the option makes = this much easier to troubleshoot, especially for sessions between = providers.

"The implementation of ESN is not specified in this = document..." - Does this mean that there is a forthcoming draft = that specifies how ESN is to be used? 

"Computing connection keys from TSAD key entries" - This = section is a non sequitur , there needs to be framing and introduction, = as well as some sort of segue from the section partly documenting = ESN.

"Conn_key =3D MD5(TSAD_key, connblock)" - why is MD5 used = here?

"For SYN segments..." - Implicit special cases are bad, as a = matter of design.

"... extremely unlikely" - how unlikely? We can put the number = in there, since the definition of "extremely" tends to change = over time.

Section 6 - Security Association Management - Define a TSAD: What does = it do?  Why does the draft propose this construct? 

"A TSAD implementation MUST support at least two keyIDs per = connection per direction, and MAY support up to 256." - why only = two?  wouldn't we imagine most TSAD's supporting 256?  It's = not much of a burden, and making a recommendation for two in an example = implementation may lead to some bad designs.

Somewhere we need to explicitly state that 0 is a valid keyID.

IKEv2 Transform Type -- why are we putting a dependency on IKE for = this?  The protocols can and should be completely orthogonal to = each other.  Putting change-dependencies in on updating IKEv2 = registries will limit the protocols utility and agility. 

"...single host there should only be a single = database..."  - this seems at odds with sections later in the = document.  It also excludes virtualization and multi-level secure = systems.

"..omit an explicit algorithm ID..." -- I've said this before, = this is a BAD IDEA^tm. The protocol utility of doing this is minimal = (1-bit increase in search space), and the operational complexity goes = up.  Not to mention, it makes it operationally incompatible with = existing implementations.

"It is presumed that a TSAD entry affecting a particular = connection..." - this section is at odds with what id done = elsewhere.  If the document is going to provide implementation = advice, then it needs a state machine here to show how one might handle = key destruction, process conflict, race conditions, etc.

"Users are advised to not inappropriately reuse keys" - Why is = there this throwaway line in here?  If we look at 3562, we see = there are three recommendations:
o Key lengths SHOULD be between 12 and 24 bytes, with larger keys having = effectively zero additional computational costs when compared to shorter = keys.
o Key sharing SHOULD be limited so that keys aren't shared among = multiple BGP peering arrangements.
o Keys SHOULD be changed at least every 90 days.
What are the recommendations for each of these?  Why are we = continuing to use them here?  With key diversification, perhaps the = same root key can be used (assuming we document that a peer sharing that = key could potentially create an attack on reboot).  Also, with = stronger MACs do we need to change keys every 90 days?  Are 12-24 = byte keys appropriate for HMAC-SHA1-96 and AES-CMAC-96?

"TCP segments with TCP-AO but not matching TSAD entries MUST be = silently accepted." - Accepted?  Does this have to do with the = proposed order-of-match logic internal to the end systems?

"Additional reductions in MAC validation can be supported by using = a MAC algorithm that partitions the MAC field into fixed and computed = portions."  - Do we have examples of these MAC = algorithms?  Wouldn't adding a "fixed" portion to a MAC = algorithm rather defeat one of the MAC algorithm design goals?  = Perhaps one of the security experts could comment on this.

"In the default case, where only a single key is used at a = time..." - The document should elaborate on what it means = here.  Is this a recommendation that the TSAD only support a single = key?  Why would there be invalid keys used?

"... benefits from congestion control support for temporary path = outages." - References?

SACK recommendation - Why?  Is there something special about = TCP-AO, and not regular TCP sessions? Or is this a recommendation to use = SACK for all TCP segments?

"Implementations are encouraged to keep keys in a suitably private = area."  I agree, but what does this mean? What is suitable for = this protocol?  What is private?

"Keys should not be shared across different hosts, because this = could compromise the keying material itself." - Doesn't this defeat = the purpose?  This is a shared-key cryptosystem.

"Note that when TCP MD5 is required for a connection, it must be = used [RFC2385]" - This is rather confusing.  This was written = in one time and place, and there is real-life versus = standards-life.  We need to make recommendations for the = former.  Is the advice that only MD5 or AO be used based on a line = in a standard published 10 years ago, that documented an even older = implementation??

Section 10 - The option to calculate options or not should be in the = packet.  If not, there will be a lot of broken connections out = there, and people who have no idea why they are broken.

Section 12 - reference to Be07 should be Normative.

Section 13 - this section shows a limited knowledge of deployed routing = protocols, especially in the comparison to what the document believes is = the preferred solution of using IPSec.  In deployment, there is = both the TCP TTL hack, and the extensive use of edge and system ACL's to = provide multilayer security. 

"TCP-AO does not expose the MAC algorithm used to authenticate = a..." - Again, this is a BAD IDEA^tm. It offers minimal expanded = search space for the algorithm (1-bit).   It also violates = fundamental security design:  The security should be in the key, = not in the obscurity of the algorithm.   Not carrying = algorithm ID results in more downtime due to opaque system = operation. 

"ICMP messages of Type 3, Codes 2-4" - This needs to be = expanded.  People do not have ICMP type codes memorized.

"To specify MAC algorithms, TCP-AO uses the 4-byte namespace of = IKEv2" - Again, bad idea.  This creates an unnecessary = protocol linkage between the spaces.  Not to mention a development, = test and operational headache -- "This protocol supports 2 MAC = types, and yet the codes are "17" and "153" - = WTF??"

Andrew

------_=_NextPart_001_01C948E5.7809C84C-- --===============0534397114== 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 --===============0534397114==-- From tcpm-bounces@ietf.org Mon Nov 17 12:06:14 2008 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 1EDF33A6A3C; Mon, 17 Nov 2008 12:06: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 7DEC83A68F6 for ; Mon, 17 Nov 2008 12:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKSIarspnsPH for ; Mon, 17 Nov 2008 12:06:11 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 8934F3A6939 for ; Mon, 17 Nov 2008 12:06:11 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id D08BC7AB0D; Mon, 17 Nov 2008 14:06:09 -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 mAHK66G9004372; Mon, 17 Nov 2008 14:06:10 -0600 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 14:06:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 14:06:10 -0600 Message-ID: In-Reply-To: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Comments on TCP-AO Draft Thread-Index: AclI5XgHf+wZoobzTouVULb4S/pTOQACBnxQ References: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "LANGE Andrew" , X-OriginalArrivalTime: 17 Nov 2008 20:06:06.0573 (UTC) FILETIME=[ECE739D0:01C948EF] Subject: Re: [tcpm] Comments on TCP-AO Draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >Behalf Of LANGE Andrew >Sent: Monday, November 17, 2008 1:51 PM >To: tcpm@ietf.org >Subject: [tcpm] Comments on TCP-AO Draft > > There are a lot of good comments here that will strengthen the document. One of them that concerns the wire-format rather than text additions, clarifications, and changes that are needed, which we should address quickly is: >1.4.1: " IETF-72 topic" sections "No current consensus was >reached on this topic, so no change was made." This is a real >problem -- the logic is deeply flawed. Allow me to restate: >One author of this document has appointed themselves the >arbiter of consensus. This author disagrees with other >people, and therefore no "consensus" can ever be reached, so >the default case this author has chosen is to keep things they >way they like it. > > ... > >"..omit an explicit algorithm ID..." -- I've said this before, >this is a BAD IDEA^tm. The protocol utility of doing this is >minimal (1-bit increase in search space), and the operational >complexity goes up. Not to mention, it makes it operationally >incompatible with existing implementations. There was logic given to support each side of the argument. My understanding of the summary for each position is: (position 1 - "include") Including information like algorithm ID and k-bit is BAD because it aids in debugging of implementations and of configurations. (position 2 - "don't include") Including this information is BAD because it can expose information about the security parameters. It doesn't aid in debugging of configuration because operators still have to call each other in order to read off and verify keys. There seemed to be more people around position 2 than position 1, but we should flag this and ask during the meeting, as well as open this up on the mailing list to see what people prefer. We need to pick one and move on. As an individual, and not a co-chair, I'm in the position 2 "don't include" camp. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 17 15:21:05 2008 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 C96DD28C1B6; Mon, 17 Nov 2008 15:21:05 -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 27C2328C1B6 for ; Mon, 17 Nov 2008 15:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzs7hp3HcRKc for ; Mon, 17 Nov 2008 15:21:03 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BB64628C1B2 for ; Mon, 17 Nov 2008 15:21:02 -0800 (PST) Received: from [130.129.78.28] ([130.129.78.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAHNKkrX010859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Nov 2008 15:20:48 -0800 (PST) Message-ID: <4921FC4D.1080206@isi.edu> Date: Mon, 17 Nov 2008 15:20:45 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: LANGE Andrew References: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.com> In-Reply-To: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.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 Subject: Re: [tcpm] Comments on TCP-AO Draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, Andrew, LANGE Andrew wrote: > Hi All, > > Here are some comments on this draft. Since this is the last full > draft I have, I've focused the comments on this iteration. FWIW, this note apparently addresses a preview draft between -01 and - -02. The -02 update has been available since the cutoff date, two weeks ago. Some further notes below... Joe > The short version: This document needs significant work. The list below suggests a number of changes which should be able to be incorporated in a week or two. > Abstract: The draft begins to contextualize the place where TCP-AO is > operating. However, it does not pay any attention to draft-bonica, > or the 3+ years of deployment experience with draft-bonica. Proper > contextualization is important to evaluate the draft and its changes. That can be addressed in the intro. > Abstract: Update to TCP MD5 needs a reference at the end of the > Abstract section. My understanding is that abstracts don't have references in them; I can confirm this with the RFC Editor on this point > Abstract: Define "MACs" - this is the first time it's used, and > although we can hope that people know which ones we're talking about, > it wouldn't hurt to write "Message Authentication Codes (MACs)" out. Will do. > General Comment: There is no security policy explained in the draft: > What are we protecting against? From whom are we protecting? For how > long? It is critical to know who the threat(s) are. Will do. > General Comment: This draft badly needs a "Deployment Considerations" > section, that shows how to operationalize the techniques, and > situates things such as migration from older techniques to newer > ones. Especially important are transition mechanisms. The draft does have some of these issues already described, but it would probably be useful to have a separate discussion that summarizes the issues and expands on them. > Introduction: we should defined "cryptographic key management" as in > "...not the framework for cryptographic key management." And explain > why the draft makes this recommendation. Will do. > Introduction: End of 2nd paragraph, reference to Be07 should be > normative - if the draft is to fulfill the requirements, those > requirements should be not subject to a moving target. My understanding is that normative references must be standards track or equivalent (e.g., from IEEE), whereas Be07 would be informational if published. We haven't updated Be07 because it may be sufficient to cite it (for due credit) and just point down to the later section that contains most of it's info anyway. > Introduction: The draft is very blithe about recommending IPSec and > IKE, without providing any context why this is a good idea, or why it > has never been deployed. There are significant issues with using > IPSec for routing (complexity, reduced convergence times, relying on > security layers for routing functions, etc.) These issues need to be > documented, and discussed, before as the IETF, a recommendation > should be made. Will do. > Introduction: Last paragraph - "TCP MD5 does not support any changes > to the connection's security..." Well, the draft may not consider > this, however, if you get the keychange timing done correctly, in > fact, you can roll the keys. It's a kludge, but it would be > inaccurate to state otherwise. Will do. > Exec Summary: > > "Allows TCP-MD5 to be used..." - Why is this here? It addresses the transition issue you note above. > "TBD-WG-MACS" - MACs MUST be specified, in the draft. That's clearly noted as needing to be fixed; we're still waiting for the specific algorithm. We may be able to determine that this week. > Ends of "Allows rekeying" section - TCP MD5 rolling comment is at odds > with the end of the introduction, it should be explained how this > works. Will fix. > Also, why MD5 could lose packets also needs to be explained, and > why new techniques do not suffer from this limitation. Will address. > "Provides more detail in how this option interacts with TCP's states, > event processing, and user interface" - more detail that what? Than TCP MD5; that is the section in which the comment appears. > Much of this is implementation specific. Especially the user > interface parts. Agree that the user interface part needs revision to avoid focusing on implementation issues. > This draft tends to munge what is necessary for interoperation (the > standard), and the way one might implement that internally > (implementation details.) Providing a reference state machine or > details are useful, but shouldn't be conflated with the standard spec. The event processing and state issues, however, have been noted numerous times as relating directly to RFC793, not to an implementation. > "Provides automatic key rollover" - is this section referring to key > rollover via keychains? key diversification techniques? Will fix; it should say that we use extended sequence numbers, not key rollover (which was originally added to address sequence number rollover). > "Proposed option is 3 bytes shorter than" - why should we care? What > do those 3 bytes buy us? That is addressed in Section 7.6. Depending on the options and padding used, it could buy us another option or another SACK block. > "Does not authenticate ICMP messages (some may be authenticated in > IPsec..." - is it also lighter weight, and better suited to router > protocol operation and deployment. Will add as a benefit. > 1.4.1: " IETF-72 topic" sections "No current consensus was reached on > this topic, so no change was made." This is a real problem -- the > logic is deeply flawed. Allow me to restate: One author of this > document has appointed themselves the arbiter of consensus. This > author disagrees with other people, and therefore no "consensus" can > ever be reached, so the default case this author has chosen is to > keep things they way they like it. See Wes' post on this issue. A draft of this document was circulated to the off-list group - yourself included - Oct 10. The text on these issues was coordinated with the WG chairs, and we received no feedback on this until your note today. I appreciate your concern with the text, but not with your concerns about the process by which it appeared in the current draft. > 3.2 - "in the sprit of SP4" - why is this relevant to the document? This issue was raised by others; I can find out who if you're interested. > 3.2 - The whole of ESN gets introduced without much prelude or > contextualization. Since this is something new for this draft > (correct me if I'm wrong.) It really needs to be better > contextualized. In fact, since this is something that may have > utility outside of TCP-AO, it ought to be documented in a separate > draft, probably as a separate option. It has an impact on the TCP > state machine that goes beyond a bigger value to prevent replay. It is designed in such a way as to be interpreted from the incoming/outgoing packet; there is no direct interaction with TCP's state machine required. I agree this may be of larger utility, and I'll prepare something for the next IETF on this. Thanks for noting that. > "TCP Data in Network Byte Order" - We really do need to specify which > MAC's were going to use. Otherwise, the draft isn't very useful. Already noted above. > "When options are excluded, all options..." - How is this indicated on > the wire? I'm guessing that the plan is to do this with configuration > on each end. This is a recipe for misconfiguration and confusion. > Putting a bit in the option makes this much easier to troubleshoot, > especially for sessions between providers. It is not indicated on the wire for the same reason the algorithm isn't indicated - it is already required to be coordinated at the endpoints. Wes sent a separate note on this to the list, and this will be discussed in public at the meeting. > "The implementation of ESN is not specified in this document..." - > Does this mean that there is a forthcoming draft that specifies how > ESN is to be used? You noted above that we should avoid implementation issues; that's all this statement reiterates. As you noted above, a separate document can be developed to discuss the more general utility of ESNs. > "Computing connection keys from TSAD key entries" - This section is a > non sequitur , there needs to be framing and introduction, as well as > some sort of segue from the section partly documenting ESN. Will fix. > "Conn_key = MD5(TSAD_key, connblock)" - why is MD5 used here? Being fixed this week. > "For SYN segments..." - Implicit special cases are bad, as a matter of > design. This is explicit, not implicit. It is required because a SYN indicates the source's ISN but the receiver's ISN cannot be known at that point; we're just recognizing the existing handling of ISN values by SYNs, not creating anything new. > "... extremely unlikely" - how unlikely? We can put the number in > there, since the definition of "extremely" tends to change over > time. Will do. > Section 6 - Security Association Management - Define a TSAD: What does > it do? Why does the draft propose this construct? This can be explained further in the document. > "A TSAD implementation MUST support at least two keyIDs per > connection per direction, and MAY support up to 256." - why only two? > wouldn't we imagine most TSAD's supporting 256? It's not much of a > burden, and making a recommendation for two in an example > implementation may lead to some bad designs. It was a conservative assumption of a MUST; if the WG feels that it should be increased, it can be changed. > Somewhere we need to explicitly state that 0 is a valid keyID. See Section 6: >> A KeyID MUST support any value, 0-255 inclusive. There are no reserved KeyID values. > IKEv2 Transform Type -- why are we putting a dependency on IKE for > this? The protocols can and should be completely orthogonal to each > other. Putting change-dependencies in on updating IKEv2 registries > will limit the protocols utility and agility. We're not depending on IKE; we're depending only on its registry, because we don't see a reason to ask IANA to create a new one. We can instead ask IANA to create a new one. > "...single host there should only be a single database..." - this > seems at odds with sections later in the document. It also excludes > virtualization and multi-level secure systems. Will fix. The point is that there is a single database for a given IP address; a database can cover multiple IP addresses. There can't be two databases for a single IP address. > "..omit an explicit algorithm ID..." -- I've said this before, this > is a BAD IDEA. The protocol utility of doing this is minimal (1-bit > increase in search space), and the operational complexity goes up. > Not to mention, it makes it operationally incompatible with existing > implementations. TCP AO has no existing implementations since it has not been completed. We have already been reminded in various off-list discussions that we are not required to be compatible with the draft-bonica solution, and there are numerous other ways in which this draft is not compatible with that solution anyway. > "It is presumed that a TSAD entry affecting a particular > connection..." - this section is at odds with what id done elsewhere. > If the document is going to provide implementation advice, then it > needs a state machine here to show how one might handle key > destruction, process conflict, race conditions, etc. We're updating this to avoid implementation information, but need to retain information that defines the behavior of the TSAD, e.g., as above. > "Users are advised to not inappropriately reuse keys" - Why is there > this throwaway line in here? If we look at 3562, we see there are > three recommendations: > o Key lengths SHOULD be between 12 and 24 bytes, with larger keys > having effectively zero additional computational costs when compared to > shorter keys. > o Key sharing SHOULD be limited so that keys aren't shared among > multiple BGP peering arrangements. > o Keys SHOULD be changed at least every 90 days. > What are the recommendations for each of these? Why are we continuing > to use them here? We can reuse them here. > With key diversification, perhaps the same root key can be used > (assuming we document that a peer sharing that key could potentially > create an attack on reboot). Also, with stronger MACs do we need to > change keys every 90 days? Are 12-24 byte keys appropriate for > HMAC-SHA1-96 and AES-CMAC-96? Will resolve. > "TCP segments with TCP-AO but not matching TSAD entries MUST be > silently accepted." - Accepted? Does this have to do with the > proposed order-of-match logic internal to the end systems? This means that gratuitous signing of segments will not cause them to be dropped. We could change the requirement to 'drop if no key known', but it seems like if you care about a source you would put in a key. > "Additional reductions in MAC validation can be supported by using a > MAC algorithm that partitions the MAC field into fixed and computed > portions." - Do we have examples of these MAC algorithms? Wouldn't > adding a "fixed" portion to a MAC algorithm rather defeat one of the > MAC algorithm design goals? Perhaps one of the security experts could > comment on this. This was in response to an issue raised by Ran Atkinson, and he agreed to the response. Such a MAC algorithm would be to overwrite the lowest byte of an HMAC (e.g., from HMAC-SHA256) with a fixed byte. It does not weaken the HMAC any more than would truncating the HMAC - e.g., if you truncate to 80 bits, then add another 16 of nonce, then the nonce can be used for fast triage. I can add that example if it seems useful. > "In the default case, where only a single key is used at a time..." - > The document should elaborate on what it means here. Is this a > recommendation that the TSAD only support a single key? Why would > there be invalid keys used? Will fix. > "... benefits from congestion control support for temporary path > outages." - References? Will add (it's just TCP congestion control). > SACK recommendation - Why? Is there something special about TCP-AO, > and not regular TCP sessions? Or is this a recommendation to use SACK > for all TCP segments? There's already a recommendation to use SACK in general. SACK helps here to avoid reMAC'ing segments already received; given the overhead of the MAC algorithms, this seems useful. Others already noted we should explain this. In summary, we'll fix this to basically say "this is no different from existing TCP recommendations, and the benefit from SACK helps even more here". > "Implementations are encouraged to keep keys in a suitably private > area." I agree, but what does this mean? What is suitable for this > protocol? What is private? That's implementation advice. We can omit it. > "Keys should not be shared across different hosts, because this could > compromise the keying material itself." - Doesn't this defeat the > purpose? This is a shared-key cryptosystem. This will be clarified to say "across hosts not directly communicating". It's general key reuse info. We can omit it if preferred. > "Note that when TCP MD5 is required for a connection, it must be used > [RFC2385]" - This is rather confusing. This was written in one time > and place, and there is real-life versus standards-life. We need to > make recommendations for the former. Is the advice that only MD5 or > AO be used based on a line in a standard published 10 years ago, that > documented an even older implementation?? Yes, we're quoting existing requirements. It can be clarified; all it means is that if you install a key for a socket pair in TCP MD5, you don't accept segments that aren't signed. > Section 10 - The option to calculate options or not should be in the > packet. If not, there will be a lot of broken connections out there, > and people who have no idea why they are broken. We've already explained several times that the reason a connection breaks is determined by information at the endpoints already - the key, the option inclusion info, etc. That already has to be confirmed; having any of that info in the packet does not help. > Section 12 - reference to Be07 should be Normative. See note above. > Section 13 - this section shows a limited knowledge of deployed > routing protocols, especially in the comparison to what the document > believes is the preferred solution of using IPSec. In deployment, > there is both the TCP TTL hack, and the extensive use of edge and > system ACL's to provide multilayer security. That section can be clarified to explain that we're talking about authentication of TCP segments and protection from spoofers that could be on or off-path. The TCP TTL hack can be added. Can you clarify the issue of ACLs? How do those protect TCP connections? > "TCP-AO does not expose the MAC algorithm used to authenticate a..." > - Again, this is a BAD IDEA^tm. It offers minimal expanded search > space for the algorithm (1-bit). It also violates fundamental > security design: The security should be in the key, not in the > obscurity of the algorithm. Not carrying algorithm ID results in more > downtime due to opaque system operation. I can reword this throughout as "does not indicate" rather than implying a benefit by using the word "exposed". > "ICMP messages of Type 3, Codes 2-4" - This needs to be expanded. > People do not have ICMP type codes memorized. Will do. > "To specify MAC algorithms, TCP-AO uses the 4-byte namespace of > IKEv2" - Again, bad idea. This creates an unnecessary protocol > linkage between the spaces. Not to mention a development, test and > operational headache -- "This protocol supports 2 MAC types, and yet > the codes are "17" and "153" - WTF??" Already addressed above. - ------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkh/E0ACgkQE5f5cImnZru8NwCffaCIxSsbJIgBEqST3HKyZ0Nu WFcAoIpV6clUYqM95MPKTWNR/gNsZtFM =WFpA -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 17 17:28:15 2008 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 82C0E3A6922; Mon, 17 Nov 2008 17:28:15 -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 CF9B53A69AF for ; Mon, 17 Nov 2008 17:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UboJIvtT3jXS for ; Mon, 17 Nov 2008 17:28:13 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id EACB03A6922 for ; Mon, 17 Nov 2008 17:28:12 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2663860rvf.49 for ; Mon, 17 Nov 2008 17:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-mailer:date:to:from:subject :in-reply-to:references:mime-version:content-type:message-id; bh=664eyGx3jHRLcHVgNAkN0cPk/KtL6zNJRBIZZpEJ7FY=; b=hyh/dRhbDcYAgSy7exzdJXL3NLCCszn+X029rLlKUNaBvwHy+Pm7EDlpkeOohvYvt7 qWk6WBLVN8mjYBEZbrdBp9U8rHK0zQ3gTYB0qOovRD6ER1ui+T81xJFe9nlgGGX8DKIl MjdTqNpQW1pT485E5S2gnoKdTEicvq2UVbm/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-mailer:date:to:from:subject:in-reply-to:references:mime-version :content-type:message-id; b=pxOaBgL8VOg1DZe35oGrUZoty89egLNOObKi0tupUmSBOoglhhkDaB7hJoTpR64tnZ gdamU3wxg05FmuaPB/8QG/emcnJjk7TtJMlXagBPqTdVC1e6o+KKz2YVd0G5UuDGx4Ug J2/88YCIvRM7FbnaS+E9IqTPSBTf9y0z0plvU= Received: by 10.141.197.21 with SMTP id z21mr2602301rvp.75.1226971692308; Mon, 17 Nov 2008 17:28:12 -0800 (PST) Received: from Gregory-T60.gmail.com ([130.129.95.186]) by mx.google.com with ESMTPS id b39sm7540577rvf.0.2008.11.17.17.28.09 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 17:28:11 -0800 (PST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Nov 2008 17:28:04 -0800 To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" , "LANGE Andrew" , From: "Gregory M. Lebovitz" In-Reply-To: References: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.com> Mime-Version: 1.0 Message-ID: <49221a2b.27b38c0a.57ac.771b@mx.google.com> Subject: Re: [tcpm] Comments on TCP-AO Draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org inline... At 12:06 PM 11/17/2008, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > >-----Original Message----- > >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > >Behalf Of LANGE Andrew > >Sent: Monday, November 17, 2008 1:51 PM > >To: tcpm@ietf.org > >Subject: [tcpm] Comments on TCP-AO Draft > > > > > > >There are a lot of good comments here that will strengthen >the document. One of them that concerns the wire-format rather >than text additions, clarifications, and changes that are >needed, which we should address quickly is: > > > >1.4.1: " IETF-72 topic" sections "No current consensus was > >reached on this topic, so no change was made." This is a real > >problem -- the logic is deeply flawed. Allow me to restate: > >One author of this document has appointed themselves the > >arbiter of consensus. This author disagrees with other > >people, and therefore no "consensus" can ever be reached, so > >the default case this author has chosen is to keep things they > >way they like it. > > > > ... > > > >"..omit an explicit algorithm ID..." -- I've said this before, > >this is a BAD IDEA^tm. The protocol utility of doing this is > >minimal (1-bit increase in search space), and the operational > >complexity goes up. Not to mention, it makes it operationally > >incompatible with existing implementations. > > >There was logic given to support each side of the argument. My >understanding of the summary for each position is: > >(position 1 - "include") Including information like algorithm ID >and k-bit is BAD because it aids in debugging of implementations >and of configurations. Wes, did you mean to say "GOOD" instead of "BAD" in this paragraph? I'll assume yes. >(position 2 - "don't include") Including this information is BAD >because it can expose information about the security parameters. >It doesn't aid in debugging of configuration because operators still >have to call each other in order to read off and verify keys. > >There seemed to be more people around position 2 than position 1, >but we should flag this and ask during the meeting, as well as >open this up on the mailing list to see what people prefer. We >need to pick one and move on. I concur with your recollection about the two positions above. I also concur with your recollection that there was more people (not 100% consensus, but more) around Position 2 than 1. The argument I made went something like this, and was based on lots of years of debugging interop issues in both IKEv1/ESP and IKEv2/ESP: - there is only the case where the connection will be discussed out of band by system admins before a first connection is made. At that point, there will be some agreement about config choices. - if the connection doesn't work, you double check your config matches your agreement of config choices. - if the config matches the agreement, then you can try the other algo, just in case you misheard that part. - if it doesn't work, then you have to pick up the phone and call the other guy to double check config parameters. Conclusion: having the bits on the wire about the config elements doesn't help practically, and contradicts the basic security principle of hiding as much about the SA as possible. So I am also support Position 2. Gregory. >As an individual, and not a co-chair, I'm in the position 2 "don't >include" camp. > > >_______________________________________________ >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 Mon Nov 17 17:33:54 2008 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 2FE7F3A6922; Mon, 17 Nov 2008 17:33:54 -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 BDB9D3A6922 for ; Mon, 17 Nov 2008 17:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAqW4sgluXV4 for ; Mon, 17 Nov 2008 17:33:51 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 9B3323A67E1 for ; Mon, 17 Nov 2008 17:33:51 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2665629rvf.49 for ; Mon, 17 Nov 2008 17:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-mailer:date:to:from:subject :in-reply-to:references:mime-version:content-type:message-id; bh=G63zKzr/jUMwTNlgFM9qcBGiMa5+2/q7+xzILEffcmM=; b=vW7Ud7tMO62s07/ayXF8sU58zbnYNk8iH2qwSrZqSab4n0mAUjsRc3+pgh3KEWvJZg +FH5qTMgVFawgAV0Xjw8WVojlPP2tj0S0b5ZbMVa0PAf+fevY8n8Xkvo+ctgpxt87zsm Jnh48IT4C35VpU9YuFTy2Ai1NpSwFIC3jgZYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-mailer:date:to:from:subject:in-reply-to:references:mime-version :content-type:message-id; b=MGT5lENvhmE4ZgV6asc94ZXkg6Sg0NKBmrdJMd6VLNgodO9H80zLGr9FEqXQvIT+LQ 33+FR1NrnKiRtoOVCobmkWCR6i1YjPq0QHNo4QE6sK0q3idzIl0zno0dE7hfE4RngFNG wn37LXU+SobZlo4ztn1juAWDvIdxzzuyWTeyU= Received: by 10.140.174.11 with SMTP id w11mr73635rve.280.1226972031121; Mon, 17 Nov 2008 17:33:51 -0800 (PST) Received: from Gregory-T60.gmail.com ([130.129.95.186]) by mx.google.com with ESMTPS id l31sm11281033rvb.2.2008.11.17.17.33.47 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 17:33:49 -0800 (PST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Nov 2008 17:33:43 -0800 To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" , "LANGE Andrew" , From: "Gregory M. Lebovitz" In-Reply-To: <7.1.0.9.2.20081117170325.05214da8@gmail.com> References: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.com> <7.1.0.9.2.20081117170325.05214da8@gmail.com> Mime-Version: 1.0 Message-ID: <49221b7d.1f588c0a.477a.580b@mx.google.com> Subject: Re: [tcpm] Comments on TCP-AO Draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1995258273==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1995258273== Content-Type: multipart/alternative; boundary="=====================_32805343==.ALT" --=====================_32805343==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed inline again... At 05:28 PM 11/17/2008, Gregory M. Lebovitz wrote: >inline... > >At 12:06 PM 11/17/2008, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >> >-----Original Message----- >> >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> >Behalf Of LANGE Andrew >> >Sent: Monday, November 17, 2008 1:51 PM >> >To: tcpm@ietf.org >> >Subject: [tcpm] Comments on TCP-AO Draft >> > >> > >> >> >>There are a lot of good comments here that will strengthen >>the document. One of them that concerns the wire-format rather >>than text additions, clarifications, and changes that are >>needed, which we should address quickly is: >> >> >> >1.4.1: " IETF-72 topic" sections "No current consensus was >> >reached on this topic, so no change was made." This is a real >> >problem -- the logic is deeply flawed. Allow me to restate: >> >One author of this document has appointed themselves the >> >arbiter of consensus. This author disagrees with other >> >people, and therefore no "consensus" can ever be reached, so >> >the default case this author has chosen is to keep things they >> >way they like it. >> > >> > ... >> > >> >"..omit an explicit algorithm ID..." -- I've said this before, >> >this is a BAD IDEA^tm. The protocol utility of doing this is >> >minimal (1-bit increase in search space), and the operational >> >complexity goes up. Not to mention, it makes it operationally >> >incompatible with existing implementations. BTW, in the reference above, in the newly posted draft-ietf-tcp-auth-opt-02 this comment regards section 1.3.1, not 1.4.1. Hope it helps, Gregory. >>There was logic given to support each side of the argument. My >>understanding of the summary for each position is: >> >>(position 1 - "include") Including information like algorithm ID >>and k-bit is BAD because it aids in debugging of implementations >>and of configurations. > >Wes, did you mean to say "GOOD" instead of "BAD" in this paragraph? >I'll assume yes. > > >>(position 2 - "don't include") Including this information is BAD >>because it can expose information about the security parameters. >>It doesn't aid in debugging of configuration because operators still >>have to call each other in order to read off and verify keys. >> >>There seemed to be more people around position 2 than position 1, >>but we should flag this and ask during the meeting, as well as >>open this up on the mailing list to see what people prefer. We >>need to pick one and move on. > >I concur with your recollection about the two positions above. I >also concur with your recollection that there was more people (not >100% consensus, but more) around Position 2 than 1. The argument I >made went something like this, and was based on lots of years of >debugging interop issues in both IKEv1/ESP and IKEv2/ESP: > - there is only the case where the connection will be discussed > out of band by system admins before a first connection is made. At > that point, there will be some agreement about config choices. > - if the connection doesn't work, you double check your config > matches your agreement of config choices. > - if the config matches the agreement, then you can try the other > algo, just in case you misheard that part. > - if it doesn't work, then you have to pick up the phone and call > the other guy to double check config parameters. > Conclusion: having the bits on the wire about the config elements > doesn't help practically, and contradicts the basic security > principle of hiding as much about the SA as possible. > >So I am also support Position 2. > >Gregory. > > >>As an individual, and not a co-chair, I'm in the position 2 "don't >>include" camp. >> >> >>_______________________________________________ >>tcpm mailing list >>tcpm@ietf.org >>https://www.ietf.org/mailman/listinfo/tcpm --=====================_32805343==.ALT Content-Type: text/html; charset="us-ascii" inline again...

At 05:28 PM 11/17/2008, Gregory M. Lebovitz wrote:
inline...

At 12:06 PM 11/17/2008, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
>-----Original Message-----
>From: tcpm-bounces@ietf.org [ mailto:tcpm-bounces@ietf.org] On
>Behalf Of LANGE Andrew
>Sent: Monday, November 17, 2008 1:51 PM
>To: tcpm@ietf.org
>Subject: [tcpm] Comments on TCP-AO Draft
>
>


There are a lot of good comments here that will strengthen
the document.  One of them that concerns the wire-format rather
than text additions, clarifications, and changes that are
needed, which we should address quickly is:


>1.4.1: " IETF-72 topic" sections "No current consensus was
>reached on this topic, so no change was made."  This is a real
>problem -- the logic is deeply flawed.  Allow me to restate:
>One author of this document has appointed themselves the
>arbiter of consensus.  This author disagrees with other
>people, and therefore no "consensus" can ever be reached, so
>the default case this author has chosen is to keep things they
>way they like it.
>
> ...
>
>"..omit an explicit algorithm ID..." -- I've said this before,
>this is a BAD IDEA^tm. The protocol utility of doing this is
>minimal (1-bit increase in search space), and the operational
>complexity goes up.  Not to mention, it makes it operationally
>incompatible with existing implementations.

BTW, in the reference above, in the newly posted    
   

draft-ietf-tcp-auth-opt-02
this comment regards section 1.3.1, not 1.4.1.
Hope it helps,
Gregory.



There was logic given to support each side of the argument.  My
understanding of the summary for each position is:

(position 1 - "include") Including information like algorithm ID
and k-bit is BAD because it aids in debugging of implementations
and of configurations.

Wes, did you mean to say "GOOD" instead of "BAD" in this paragraph? I'll assume yes.


(position 2 - "don't include") Including this information is BAD
because it can expose information about the security parameters.
It doesn't aid in debugging of configuration because operators still
have to call each other in order to read off and verify keys.

There seemed to be more people around position 2 than position 1,
but we should flag this and ask during the meeting, as well as
open this up on the mailing list to see what people prefer.  We
need to pick one and move on.

I concur with your recollection about the two positions above. I also concur with your recollection that there was more people (not 100% consensus, but more) around Position 2 than 1. The argument I made went something like this, and was based on lots of years of debugging interop issues in both IKEv1/ESP and IKEv2/ESP:
 - there is only the case where the connection will be discussed out of band by system admins before a first connection is made. At that point, there will be some agreement about config choices.
 - if the connection doesn't work, you double check your config matches your agreement of config choices.
 - if the config matches the agreement, then you can try the other algo, just in case you misheard that part.
 - if it doesn't work, then you have to pick up the phone and call the other guy to double check config parameters.
 Conclusion: having the bits on the wire about the config elements doesn't help practically, and contradicts the basic security principle of hiding as much about the SA as possible.

So I am also support Position 2.

Gregory.


As an individual, and not a co-chair, I'm in the position 2 "don't
include" camp.


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--=====================_32805343==.ALT-- --===============1995258273== 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 --===============1995258273==-- From tcpm-bounces@ietf.org Mon Nov 17 17:40:15 2008 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 B483C3A6922; Mon, 17 Nov 2008 17:40:15 -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 311D63A6922 for ; Mon, 17 Nov 2008 17:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erJK-vHxl6RN for ; Mon, 17 Nov 2008 17:40:13 -0800 (PST) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 707323A6909 for ; Mon, 17 Nov 2008 17:40:13 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id A0A5FA7F6; Mon, 17 Nov 2008 19:40:11 -0600 (CST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id mAI1eBM7014972; Mon, 17 Nov 2008 19:40:11 -0600 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 19:40:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 19:40:15 -0600 Message-ID: In-Reply-To: <49221a2b.27b38c0a.57ac.771b@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Comments on TCP-AO Draft Thread-Index: AclJHOwzJhH0YVUJQJmpUsF7g1SeIAAAZUiw References: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.com> <49221a2b.27b38c0a.57ac.771b@mx.google.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Gregory M. Lebovitz" , "LANGE Andrew" , X-OriginalArrivalTime: 18 Nov 2008 01:40:11.0435 (UTC) FILETIME=[98926FB0:01C9491E] Subject: Re: [tcpm] Comments on TCP-AO Draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >-----Original Message----- >From: Gregory M. Lebovitz [mailto:gregory.ietf@gmail.com] >Sent: Monday, November 17, 2008 8:28 PM >To: Eddy, Wesley M. (GRC-RCN0)[VZ]; LANGE Andrew; tcpm@ietf.org >Subject: Re: [tcpm] Comments on TCP-AO Draft > >> > ... >> > >> >"..omit an explicit algorithm ID..." -- I've said this before, >> >this is a BAD IDEA^tm. The protocol utility of doing this is >> >minimal (1-bit increase in search space), and the operational >> >complexity goes up. Not to mention, it makes it operationally >> >incompatible with existing implementations. >> >> >>There was logic given to support each side of the argument. My >>understanding of the summary for each position is: >> >>(position 1 - "include") Including information like algorithm ID >>and k-bit is BAD because it aids in debugging of implementations >>and of configurations. > >Wes, did you mean to say "GOOD" instead of "BAD" in this paragraph? >I'll assume yes. Yes; thanks for catching that ... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 18 11:32:58 2008 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 0757E3A6809; Tue, 18 Nov 2008 11:32:58 -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 0166D3A6809 for ; Tue, 18 Nov 2008 11:32:57 -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 q6q5mDssCa7j for ; Tue, 18 Nov 2008 11:32:55 -0800 (PST) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by core3.amsl.com (Postfix) with ESMTP id DA7BF3A67F4 for ; Tue, 18 Nov 2008 11:32:55 -0800 (PST) MIME-version: 1.0 Received: from [192.168.1.132] ([70.231.247.191]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KAJ0073ANMRTV30@asmtp016.mac.com> for tcpm@ietf.org; Tue, 18 Nov 2008 11:32:53 -0800 (PST) Message-id: From: Sally Floyd To: tcpm Date: Tue, 18 Nov 2008 11:32:51 -0800 References: <36235E15-9019-476A-9CA7-519026635558@mac.com> X-Mailer: Apple Mail (2.929.2) Subject: [tcpm] Fwd: I-D Action:draft-ietf-tcpm-ecnsyn-07.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: , 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 This is just a reminder that, though I won't be at the tcpm meeting today, we have made a revision to the draft-ietf-tcpm-ecnsyn draft, and it needs another round of working group review before moving back to the IESG for the final stages. "http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-07" Many thanks, - Sally Begin forwarded message: > From: Sally Floyd > Date: November 5, 2008 4:04:56 PM PST > To: tcpm > Cc: "K. K. Ramakrishnan" , Amit Mondal >, Aleksandar Kuzmanovic > Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-07.txt > > We have (finally) revised draft-ietf-tcpm-ecnsyn, on "Adding Explicit > Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", > and are finally ready for it to complete the standardization process. > > Here is the story: > > The draft had finished Working Group Last Call, and been forwarded > to the IESG for review. As a final step in revising the draft > after the AD Evaluation, we (the authors) reran the simulations > with an updated version of the ns-2 simulator, and found that in > some highly congested scenarios, ECN+ would significantly increase > the packet drop rate even further. (I am appending the 5/26/08 > email below.) > > In response to this, we have added a change to ECN+, which in > the new draft we call "ECN+/TryOnce". With ECN+/TryOnce, when > an ECN-Capable SYN/ACK packet is ECN-marked, the TCP responder > sends another SYN/ACK packet that is not ECN-Capable, and also > reduces the initial window to one packet. ECN+/TryOnce > shows most of the performance benefit of ECN+, and avoids the > problem of increasing the packet drop rate in times of high > congestion. > > I think it makes sense to pass this through the working group > before going back to the IESG. However, I won't be at IETF > in Minnesota, and am hoping that this can be done by email. > > The new version of the draft is at: > "http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-07", > and that web page also gives the differences with earlier > versions of the draft. Any feedback would be appreciated. > > Many thanks, > - Sally > http://www.icir.org/floyd/ ... >> From: Internet-Drafts@ietf.org >> Date: November 3, 2008 12:30:01 PM PST >> To: i-d-announce@ietf.org >> Cc: tcpm@ietf.org >> Subject: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-07.txt >> >> 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 : Adding Explicit Congestion Notification (ECN) >> Capability to TCP's SYN/ACK Packets >> Author(s) : S. Floyd, I. Property >> Filename : draft-ietf-tcpm-ecnsyn-07.txt >> Pages : 33 >> Date : 2008-11-03 >> >> This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK >> packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting >> an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK >> packets. However, because of the high cost to the TCP transfer of >> having a SYN/ACK packet dropped, with the resulting retransmit >> timeout, this document specifies the use of ECN for the SYN/ACK >> packet itself, when sent in response to a SYN packet with the two ECN >> flags set in the TCP header, indicating a willingness to use ECN. >> Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great >> benefit to the TCP connection, avoiding the severe penalty of a >> retransmit timeout for a connection that has not yet started placing >> a load on the network. The TCP responder (the sender of the SYN/ACK >> packet) must reply to a report of an ECN-marked SYN/ACK packet by >> resending a SYN/ACK packet that is not ECN-Capable. If the resent >> SYN/ACK packet is acknowledged, then the TCP responder reduces its >> initial congestion window from two, three, or four segments to one >> segment, thereby reducing the subsequent load from that connection on >> the network. If instead the SYN/ACK packet is dropped, or for some >> other reason the TCP responder does not receive an acknowledgement in >> the specified time, the TCP responder follows TCP standards for a >> dropped SYN/ACK packet (setting the retransmit timer). This document >> updates RFC 3168. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-07.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. > Content-Type: text/plain
Content-ID: <2008-11-03122057.I-D@ietf.org > >

> >> _______________________________________________ >> 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 Nov 18 11:48:50 2008 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 BD8473A6B17; Tue, 18 Nov 2008 11:48:50 -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 9ABF928C115 for ; Tue, 18 Nov 2008 11:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 ieUITsYcctEf for ; Tue, 18 Nov 2008 11:48:48 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 873C028C0D8 for ; Tue, 18 Nov 2008 11:48:48 -0800 (PST) Received: from [130.129.78.28] ([130.129.78.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAIJmZCE024574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Nov 2008 11:48:38 -0800 (PST) Message-ID: <49231C13.10303@isi.edu> Date: Tue, 18 Nov 2008 11:48:35 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: tcpm Extensions WG X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: pasi.eronen@nokia.com, Russ Housley , Tim Polk Subject: [tcpm] Guidance on selection of MAC algorithms for TCP-AO 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 The following is posted on behalf of Tim Polk since it did not appear on the list as intended (he may not be a subscriber). Please CC this message in replies to include Tim, Russ, and Pasi on any discussion. Joe - ---- From: Tim Polk Date: Tue, 18 Nov 2008 17:13:07 -0000 To: Cc: Russ Housley , Pasi Eronen , Lars Eggert Subject: Guidance on selection of MAC algorithms for TCP-AO TCP-AO needs to make two decisions with respect to MAC algorithms: select algorithms for the current specification; and establish criteria for specification of MAC algorithms in the future. To be honest, there are numerous MAC algorithms that could satisfy TCP-AO's security requirements. Pragmatic issues like performance and current code bases need to be factored in as well. The two most attractive options for generating the MAC are AES 128 in the cipher-based message authentication code (CMAC) mode and the SHA-1 Hash-based Message Authentication Code (HMAC). Both options provide a high level of security and efficiency. The AES 128 CMAC is potentially more efficient, particularly in hardware, but SHA-1 HMAC is more widely used in Internet protocols and in most cases could be supported with little or no additional code. Another aspect of the algorithm selection is whether the tags should be truncated. CMAC-AES-128 produces a 128 bit MAC, and HMAC SHA-1 produces a 160 bit result. The MAC can be truncated to 96 bits provide a reasonable tradeoff between security and message size. So, the algorithms that were in draft-bonica are entirely reasonable choices: AES-128-CMAC-96 and HMAC-SHA-1-96. For interoperability, the working group needs to either specify one MAC algorithm as a MUST and the other as a SHOULD, or specify MUST implement for both algorithms. Note that the security issues driving the migration from SHA-1 to SHA-256 for digital signatures do not apply here. The security strength of SHA-1 HMACs should be sufficient for the foreseeable future. In addition, when the tags are truncated to 96 bits it is debatable if there is any increase in the security. Since this document provides cryptographic agility, it is also important to establish requirements for future MAC algorithms. The TCPM WG should restrict any future MAC algorithms for this specification to ones that can protect at least 2**48 messages with a probability that a collision will occur of less than one in a billion. Tim Polk, Pasi Eronen, and Russ Housley -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkjHBMACgkQE5f5cImnZrs7AwCgs6e//srfWiAaBGdwLUXFG5S3 ri8AoJkDthfhZwMngLNdScOLfcN8hPne =ItkS -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 18 12:06:33 2008 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 6CF4E28C253; Tue, 18 Nov 2008 12:06: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 797A83A69E5 for ; Tue, 18 Nov 2008 12:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3intzbcg2vdq for ; Tue, 18 Nov 2008 12:06:31 -0800 (PST) Received: from kilo.rtfm.com (unknown [130.129.95.170]) by core3.amsl.com (Postfix) with ESMTP id 0C62E3A6ACE for ; Tue, 18 Nov 2008 12:06:11 -0800 (PST) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id EEB0B75D184 for ; Tue, 18 Nov 2008 14:06:08 -0600 (CST) Date: Tue, 18 Nov 2008 14:06:08 -0600 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081118200608.EEB0B75D184@kilo.rtfm.com> Subject: [tcpm] PRFs 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 We had a little discussion on the list about PRFs earlier, and when I talked to Joe I said I would generate some text. Here it is: Given a TSAD key, the TCP socket pair, and the connection ISNs, the connection key used in the MAC algorithm is computed using a pseudorandom function (PRF), which is assumed to be able to produce an arbitrary number of random bits. The directional connection keys are computed as: Conn_Key = PRF(Key, connblock) Where enough bytes are generated to match the required key length for the algorithm. We also discussed PRF definitions. As I mentioned, while many MACs can double as PRFs, there's no easy transformation from a MAC to a PRF. Luckly, I think it's clear we can rip off PRFs from some existing registry, e.g., the IPsec registry defined in RFC 4306 (http://www.iana.org/assignments/ikev2-parameters), which has all the PRFs we would most likely want, including those which rely on functions which roughly match the likely MAC transforms. The high level question seems to me that we need to decide whether to tie PRFs to MACs, with the natural approach to use the corresponding PRF (e.g., you use HMAC-SHA-256 with PRF_HMAC_SHA2_256) or to allow mix-and-match. We can discuss the pluses and minuses of these options (which seem kind of obvious) at the meeting. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 18 12:16:59 2008 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 01C9F3A67D6; Tue, 18 Nov 2008 12:16: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 7FCD53A68BF for ; Tue, 18 Nov 2008 12:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcXYvfGPqkdU for ; Tue, 18 Nov 2008 12:16:53 -0800 (PST) Received: from kilo.rtfm.com (unknown [130.129.95.170]) by core3.amsl.com (Postfix) with ESMTP id 100543A67D0 for ; Tue, 18 Nov 2008 12:16:53 -0800 (PST) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 0D9DE75D25F; Tue, 18 Nov 2008 14:16:52 -0600 (CST) Date: Tue, 18 Nov 2008 14:16:51 -0600 From: Eric Rescorla To: Joe Touch In-Reply-To: <49231C13.10303@isi.edu> References: <49231C13.10303@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081118201652.0D9DE75D25F@kilo.rtfm.com> Cc: Russ Housley , tcpm Extensions WG , pasi.eronen@nokia.com, Tim Polk Subject: Re: [tcpm] Guidance on selection of MAC algorithms for TCP-AO 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, 18 Nov 2008 11:48:35 -0800, Joe Touch wrote: > TCP-AO needs to make two decisions with respect to MAC algorithms: > select algorithms for the current specification; and establish > criteria for specification of MAC algorithms in the future. To be > honest, there are numerous MAC algorithms that could satisfy TCP-AO's > security requirements. Pragmatic issues like performance and current > code bases need to be factored in as well. > > The two most attractive options for generating the MAC are AES 128 in > the cipher-based message authentication code (CMAC) mode and the > SHA-1 Hash-based Message Authentication Code (HMAC). Both options > provide a high level of security and efficiency. The AES 128 CMAC is > potentially more efficient, particularly in hardware, but SHA-1 HMAC > is more widely used in Internet protocols and in most cases could be > supported with little or no additional code. > > Another aspect of the algorithm selection is whether the tags should > be truncated. CMAC-AES-128 produces a 128 bit MAC, and HMAC SHA-1 > produces a 160 bit result. The MAC can be truncated to 96 bits > provide a reasonable tradeoff between security and message size. So, > the algorithms that were in draft-bonica are entirely reasonable > choices: AES-128-CMAC-96 and HMAC-SHA-1-96. For interoperability, > the working group needs to either specify one MAC algorithm as a MUST > and the other as a SHOULD, or specify MUST implement for both > algorithms. > > Note that the security issues driving the migration from SHA-1 to > SHA-256 for digital signatures do not apply here. The security > strength of SHA-1 HMACs should be sufficient for the foreseeable > future. I'm sorry to be difficult, but I don't think that this is quite so clear. The relevant cite here is: Jongsung Kim and Alex Biryukov and Bart Preneel and Seokhie Hong, "On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1", SCN 2006. http://eprint.iacr.org/2006/187 http://www.springerlink.com/content/00w4v62651001303/ While it's clear that the attacks aren't practical on SHA-1, or probably MD5, it's not like the types of analysis people are mounting don't potentially pose a concern for HMAC forgery if they were significantly improved, so I don't think that it's fair to say that the "security issues driving the migration... don't apply here" -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 18 12:29:31 2008 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 C954D3A6895; Tue, 18 Nov 2008 12:29:31 -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 AB7023A6895 for ; Tue, 18 Nov 2008 12:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 lS3dPc3QgL03 for ; Tue, 18 Nov 2008 12:29:29 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 7D0C83A6885 for ; Tue, 18 Nov 2008 12:29:29 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so3042663rvf.49 for ; Tue, 18 Nov 2008 12:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-mailer:date:to:from:subject :cc:in-reply-to:references:mime-version:content-type:message-id; bh=jQKjj5fSiWmkRdLsonsDs8mPdVYZZ2+Tz2KxfOEBi8A=; b=ic9eEBCPQwU9Msba65eCoxQvVOS9IIxPI+COMpBGVdTkMWCxu0CPnOfsKENmAauZux ORU4qGltm2dLQ5KPWQ+L3sgDxC2ThrCXs52SKvTEo+F5v2CPhtjE+fYDicK18p0hZlJs 5F+QDGT4K+7WWeUJdum0CjXX+B5AQO1bnz60A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type:message-id; b=nfcX8FTsDUU5YclQMb22ZK3aMChT+nG7DXBlejgGt3jnm1TDaTeNTTwXNI2ByWW898 ZwYDKD3/jTx7F2/R883Gv3L7vShn86KVtMIDFocv0BZ+tBOXGnfvxF1ypCXrvn5kTS/l oWdXKBui9v+J5OiBm9hMKYezP0ah9czPd/1Go= Received: by 10.140.202.12 with SMTP id z12mr126169rvf.183.1227040168470; Tue, 18 Nov 2008 12:29:28 -0800 (PST) Received: from Gregory-T60.gmail.com ([130.129.95.186]) by mx.google.com with ESMTPS id k41sm9109114rvb.4.2008.11.18.12.29.24 (version=SSLv3 cipher=RC4-MD5); Tue, 18 Nov 2008 12:29:27 -0800 (PST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Nov 2008 12:29:13 -0800 To: Eric Rescorla ,Joe Touch From: "Gregory M. Lebovitz" In-Reply-To: <20081118201652.0D9DE75D25F@kilo.rtfm.com> References: <49231C13.10303@isi.edu> <20081118201652.0D9DE75D25F@kilo.rtfm.com> Mime-Version: 1.0 Message-ID: <492325a7.29578c0a.7edf.7e39@mx.google.com> Cc: pasi.eronen@nokia.com, tcpm Extensions WG , Russ Housley , Tim Polk Subject: Re: [tcpm] Guidance on selection of MAC algorithms for TCP-AO 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 Ekr, Point of process order: since we've decide that the TCPM/TCP-AO effort team will simply receive a decision on MACs from SAAG, may I suggest that we take this dicussion to the SAAG list, or do it privately between the SAAG folks in the TCP-AO effort, rather than pelting the rest of TCPM folks with it? Would you be okay with that? Gregory. At 12:16 PM 11/18/2008, Eric Rescorla wrote: >At Tue, 18 Nov 2008 11:48:35 -0800, >Joe Touch wrote: > > TCP-AO needs to make two decisions with respect to MAC algorithms: > > select algorithms for the current specification; and establish > > criteria for specification of MAC algorithms in the future. To be > > honest, there are numerous MAC algorithms that could satisfy TCP-AO's > > security requirements. Pragmatic issues like performance and current > > code bases need to be factored in as well. > > > > The two most attractive options for generating the MAC are AES 128 in > > the cipher-based message authentication code (CMAC) mode and the > > SHA-1 Hash-based Message Authentication Code (HMAC). Both options > > provide a high level of security and efficiency. The AES 128 CMAC is > > potentially more efficient, particularly in hardware, but SHA-1 HMAC > > is more widely used in Internet protocols and in most cases could be > > supported with little or no additional code. > > > > Another aspect of the algorithm selection is whether the tags should > > be truncated. CMAC-AES-128 produces a 128 bit MAC, and HMAC SHA-1 > > produces a 160 bit result. The MAC can be truncated to 96 bits > > provide a reasonable tradeoff between security and message size. So, > > the algorithms that were in draft-bonica are entirely reasonable > > choices: AES-128-CMAC-96 and HMAC-SHA-1-96. For interoperability, > > the working group needs to either specify one MAC algorithm as a MUST > > and the other as a SHOULD, or specify MUST implement for both > > algorithms. > > > > Note that the security issues driving the migration from SHA-1 to > > SHA-256 for digital signatures do not apply here. The security > > strength of SHA-1 HMACs should be sufficient for the foreseeable > > future. > >I'm sorry to be difficult, but I don't think that this is quite so >clear. The relevant cite here is: > >Jongsung Kim and Alex Biryukov and Bart Preneel and Seokhie Hong, >"On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1", >SCN 2006. > >http://eprint.iacr.org/2006/187 >http://www.springerlink.com/content/00w4v62651001303/ > >While it's clear that the attacks aren't practical on SHA-1, or probably >MD5, it's not like the types of analysis people are mounting don't >potentially pose a concern for HMAC forgery if they were significantly >improved, so I don't think that it's fair to say that the "security issues >driving the migration... don't apply here" > >-Ekr >_______________________________________________ >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 Nov 18 13:23:37 2008 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 A5C3028C22E; Tue, 18 Nov 2008 13:23:37 -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 66A2C28C22E for ; Tue, 18 Nov 2008 13:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 ZS0aBSRgr+Vo for ; Tue, 18 Nov 2008 13:23:35 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 922E628C1F5 for ; Tue, 18 Nov 2008 13:23:35 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAILNPeW017471; Tue, 18 Nov 2008 15:23:31 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:23:28 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:23:27 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:23:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.11.137]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id mAILNKPa030259; Tue, 18 Nov 2008 23:23:21 +0200 Received: from nok-db1mmbr-01.mgdnok.nokia.com ([65.54.11.136]) by NOK-DB1MHUB-01.mgdnok.nokia.com ([65.54.11.137]) with mapi; Tue, 18 Nov 2008 21:23:17 +0000 From: To: , , Date: Tue, 18 Nov 2008 21:23:15 +0000 Thread-Topic: [tcpm] Guidance on selection of MAC algorithms for TCP-AO Thread-Index: AclJvF+cm3b+81raROCJkiGbKxYagwAB351I Message-ID: In-Reply-To: <492325a7.29578c0a.7edf.7e39@mx.google.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 18 Nov 2008 21:23:23.0174 (UTC) FILETIME=[E2F22460:01C949C3] X-Nokia-AV: Clean Cc: housley@vigilsec.com, tcpm@ietf.org, Pasi.Eronen@nokia.com, tim.polk@nist.gov Subject: Re: [tcpm] Guidance on selection of MAC algorithms for TCP-AO 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="===============0034810626==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0034810626== Content-Language: en Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3309866596_7945750" --B_3309866596_7945750 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 08-11-18 14:29, "ext Gregory M. Lebovitz" wrote: > Point of process order: since we've decide that the TCPM/TCP-AO > effort team will simply receive a decision on MACs from SAAG, may I > suggest that we take this dicussion to the SAAG list, or do it > privately between the SAAG folks in the TCP-AO effort, rather than > pelting the rest of TCPM folks with it? Would you be okay with that? I'd be OK with that, if we're going to get a response this time. (The last time we tried, we didn't...) Lars --B_3309866596_7945750 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIIdAYJKoZIhvcNAQcCoIIIZTCCCGECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BkAwggL5MIICYqADAgECAhBIu1mzDCmthiyhaUA2jgUBMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODA4MjMxNzQz MzlaFw0wOTA4MjMxNzQzMzlaMFwxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEU MBIGA1UEAxMLTGFycyBFZ2dlcnQxJDAiBgkqhkiG9w0BCQEWFWxhcnMuZWdnZXJ0QG5va2lh LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJcEFZLSWQmPPYlOo3FtV52U DfmjIBdrrQlE9x92SgeSW3rdUg1rdJnf1ue9Wx48bZ/QnxCXaHITS95fX9VoiTXVWydfNuee y7cfUqI6rYaarQNIyhKqNoKq3/q2lI9XXppqNOqHLC6r9OOgq8InTqepNEQH75Cjy4Q+Dw/T ZN6Gmbsagc9cGOLvEPN4ljAKw3l4kMXzWZzgc+XA7Fb1Y044rZt1QDZGw9NrTZMJeQB8O4bX XuMh/ISMJX86rALRwRGodx8jr7PW/oB4NqRc/Xkvh7qLWGSsnAsHkbPDSl6AoPswJFWIt872 RB9lTrj5aTEDKwffny1oNlAbE3mfOuMCAwEAAaMyMDAwIAYDVR0RBBkwF4EVbGFycy5lZ2dl cnRAbm9raWEuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEATHVdlPq8lebd 57gRR9fVyn5aHTegXOtBgWBx2P2dPgpdPEO+as07dNiCCwYPv2FYf38oG+qRazptbBbSze3x DQX2ztlbaRYz9pRlIG101U+cRjOvjLamYgSOi6nsQHmOoLHf7WqFH8vX2RuNnXIgQPYEhpUI 41kMhvJm+R0fC/YwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQG EwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNV BAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAw WhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBly YLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJo dHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNV HQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3 h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIB/DCCAfgCAQEwdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFp QDaOBQEwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTUYKyqvUiKXGayYPcZJkeyHxaq CTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODExMTgyMTIz MTVaMA0GCSqGSIb3DQEBAQUABIIBAG2C5ZnELxzqnofwTcvTm7sZFdxjOG2/VygjnI01zCYz zkxZPQ1ItVgbS8qnKOybXYan3Qx+r3Kl3rf4ol0kpZA3bEG6J+suJmPHjusm1C3Fzn5463bJ y3711oVU2p3arLU1ttQqdgYjT5vKUVpTJ+/yHCJrcmKX0c6vU81H4HYGENGo7G1PjIFKbdGX 5+VMdKlnbYvbRb/UOyOjTzbx550UbZuG8/8HS5P19twhQC2HAyb1PaGkLpJQBc/vUYpKqoNU l6TN8qqOc5dII9LtVnUsTQPzeNRK91rpAxMSS7+3/+rpsVKZx6x5zjxr0IAApxp8D5aQbDwj ndfKHgz9xHg= --B_3309866596_7945750-- --===============0034810626== 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 --===============0034810626==-- From tcpm-bounces@ietf.org Tue Nov 18 13:34:15 2008 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 629FB3A6B19; Tue, 18 Nov 2008 13:34:15 -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 B25CF3A6B19 for ; Tue, 18 Nov 2008 13:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5tzyultzj6Z for ; Tue, 18 Nov 2008 13:34:13 -0800 (PST) Received: from audl952.usa.alcatel.com (audl952.usa.alcatel.com [143.209.238.159]) by core3.amsl.com (Postfix) with ESMTP id 4DFAB3A6885 for ; Tue, 18 Nov 2008 13:34:13 -0800 (PST) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id mAILYBRg012904; Tue, 18 Nov 2008 15:34:12 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Nov 2008 15:34:11 -0600 Received: from USDALSMBS05.ad3.ad.alcatel.com ([172.22.216.34]) by USDALSMBS03.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Nov 2008 15:34:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 15:34:10 -0600 Message-ID: <66F9363AB70F764C96547BD8A0A3679E154CB9@USDALSMBS05.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Comments on TCP-AO Draft Thread-Index: AclI5XgHf+wZoobzTouVULb4S/pTOQACBnxQADVd9To= References: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.com> From: "LANGE Andrew" To: "Eddy, Wesley M. \(GRC-RCN0\)[VZ]" , X-OriginalArrivalTime: 18 Nov 2008 21:34:11.0324 (UTC) FILETIME=[6545FBC0:01C949C5] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Subject: Re: [tcpm] Comments on TCP-AO Draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1397201686==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1397201686== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C949C5.64E7CA8F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C949C5.64E7CA8F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Wesley, We can certainly discuss the issue. Although there seems to be a typo = below. Shouldn't the include option say that it is GOOD to include the = data? I've also includes some elaboration of the arguments inline. Perhaps an = explanation of where this requirement is coming from would help.=20 << elided >> >1.4.1: " IETF-72 topic" sections "No current consensus was=20 >reached on this topic, so no change was made." This is a real=20 >problem -- the logic is deeply flawed. Allow me to restate:=20 >One author of this document has appointed themselves the=20 >arbiter of consensus. This author disagrees with other=20 >people, and therefore no "consensus" can ever be reached, so=20 >the default case this author has chosen is to keep things they=20 >way they like it. > > ... > >"..omit an explicit algorithm ID..." -- I've said this before,=20 >this is a BAD IDEA^tm. The protocol utility of doing this is=20 >minimal (1-bit increase in search space), and the operational=20 >complexity goes up. Not to mention, it makes it operationally=20 >incompatible with existing implementations. There was logic given to support each side of the argument. My understanding of the summary for each position is: (position 1 - "include") Including information like algorithm ID and k-bit is BAD because it aids in debugging of implementations and of configurations. Elaboration: Including this information allows debugging, and = significantly aids in drilling down to the real problem. I have had a = direct hand in operating, engineering or architecting five major ISP = networks, before working for a vendor. Since then, I've been involved = in a number of others. The simple truth is that any additional = information is very helpful, especially at 4am, when you've rebooted a = peering router, and cannot explain why some of the peering sessions are = up, and others aren't. Misconfigurations take many forms, and being = able to look, and see immediately that, during the reboot the local = system failed back to a saved config with "ignore TCP options" or "use = HMAC-SHA-1-96", and the other side is sending "use AES-128-CMAC-96" = clears up the need for a phone call. Also, in reality, it is rarely a = simple as a phone call. Tickets are created, phone calls are made, = escalations happen, all the while traffic is misrouted, or not flowing = at all. The longer the outage, the bigger the bottom line impact. = Having this information around reduces the impact, and shortens or = eliminates the phone call. Having been there at 4am, troubleshooting = these sorts of things in the past, I know this. And it hold true across = operators.=20 (position 2 - "don't include") Including this information is BAD because it can expose information about the security parameters. It doesn't aid in debugging of configuration because operators still have to call each other in order to read off and verify keys. Elaboration: Originally I was also of this position. However, I came = around when I considered the operational impacts. We need to make this = protocol as operator-friendly as possible. That is why it is being = created to begin with. We shouldn't lose sight of deployability and = maintainability in the quest to shorten an option by a byte (especially = when we gain 3 from MD5 to start with.) Also, we have had many strong = security experts, such as ekr and Brian Weis (gentlemen, correct me if = I'm misquoting you) say that putting algorithm ID in the packet does = very little to make it harder for a bad guy to attack the session. To = be specific, the attacker has to be a man-in-the-middle to see the ALG = ID to start with (whereas blind attacks are probably more likely). In = addition, the search space would be extended by a single bit. We're = already using very strong algorithms, and have the agility to add more. = Search is already infeasible with known state, and if that changes the = right approach, and the secure approach is to introduce another = algorithm.=20 There seemed to be more people around position 2 than position 1, but we should flag this and ask during the meeting, as well as open this up on the mailing list to see what people prefer. We need to pick one and move on. Elaboration: I haven't taken a poll, but we do need to keep in mind, = that operators tend to be poorly represented, and they are the people = who are going to be using this. As an individual, and not a co-chair, I'm in the position 2 "don't include" camp. ------_=_NextPart_001_01C949C5.64E7CA8F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [tcpm] Comments on TCP-AO Draft

Hi Wesley,

We can certainly discuss the issue.  Although there seems to be a = typo below. Shouldn't the include option say that it is GOOD to include = the data?

I've also includes some elaboration of the arguments inline.  = Perhaps an explanation of where this requirement is coming from would = help.

<< elided >>


>1.4.1: " IETF-72 topic" sections "No current = consensus was
>reached on this topic, so no change was made."  This is a = real
>problem -- the logic is deeply flawed.  Allow me to = restate:
>One author of this document has appointed themselves the
>arbiter of consensus.  This author disagrees with other
>people, and therefore no "consensus" can ever be reached, = so
>the default case this author has chosen is to keep things they
>way they like it.
>
> ...
>
>"..omit an explicit algorithm ID..." -- I've said this = before,
>this is a BAD IDEA^tm. The protocol utility of doing this is
>minimal (1-bit increase in search space), and the operational
>complexity goes up.  Not to mention, it makes it = operationally
>incompatible with existing implementations.


There was logic given to support each side of the argument.  My
understanding of the summary for each position is:

(position 1 - "include") Including information like algorithm = ID
and k-bit is BAD because it aids in debugging of implementations
and of configurations.

Elaboration: Including this information allows debugging, and = significantly aids in drilling down to the real problem.  I have = had a direct hand in operating, engineering or architecting five major = ISP networks, before working for a vendor.  Since then, I've been = involved in a number of others.  The simple truth is that any = additional information is very helpful, especially at 4am, when you've = rebooted a peering router, and cannot explain why some of the peering = sessions are up, and others aren't.  Misconfigurations take many = forms, and being able to look, and see immediately that, during the = reboot the local system failed back to a saved config with "ignore = TCP options" or "use HMAC-SHA-1-96", and the other side = is sending "use AES-128-CMAC-96" clears up the need for a = phone call.  Also, in reality, it is rarely a simple as a phone = call.  Tickets are created, phone calls are made, escalations = happen, all the while traffic is misrouted, or not flowing at all.  = The longer the outage, the bigger the bottom line impact. Having this = information around reduces the impact, and shortens or eliminates the = phone call.  Having been there at 4am, troubleshooting these sorts = of things in the past, I know this.  And it hold true across = operators.

(position 2 - "don't include") Including this information is = BAD
because it can expose information about the security parameters.
It doesn't aid in debugging of configuration because operators still
have to call each other in order to read off and verify keys.

Elaboration: Originally I was also of this position.   = However, I came around when I considered the operational impacts.  = We need to make this protocol as operator-friendly as possible.  = That is why it is being created to begin with.  We shouldn't lose = sight of deployability and maintainability in the quest to shorten an = option by a byte (especially when we gain 3 from MD5 to start = with.)  Also, we have had many strong security experts, such as ekr = and Brian Weis (gentlemen, correct me if I'm misquoting you) say that = putting algorithm ID in the packet does very little to make it harder = for a bad guy to attack the session.  To be specific, the attacker = has to be a man-in-the-middle to see the ALG ID to start with (whereas = blind attacks are probably more likely).  In addition, the search = space would be extended by a single bit.  We're already using very = strong algorithms, and have the agility to add more.  Search is = already infeasible with known state, and if that changes the right = approach, and the secure approach is to introduce another algorithm.

There seemed to be more people around position 2 than position 1,
but we should flag this and ask during the meeting, as well as
open this up on the mailing list to see what people prefer.  We
need to pick one and move on.

Elaboration: I haven't taken a poll, but we do need to keep in mind, = that operators tend to be poorly represented, and they are the people = who are going to be using this.

As an individual, and not a co-chair, I'm in the position 2 = "don't
include" camp.

------_=_NextPart_001_01C949C5.64E7CA8F-- --===============1397201686== 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 --===============1397201686==-- From tcpm-bounces@ietf.org Tue Nov 18 13:40:10 2008 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 75FA53A6923; Tue, 18 Nov 2008 13:40:10 -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 876AD3A6923 for ; Tue, 18 Nov 2008 13:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj-+Z1AlpTB1 for ; Tue, 18 Nov 2008 13:40:07 -0800 (PST) Received: from kilo.rtfm.com (unknown [130.129.95.170]) by core3.amsl.com (Postfix) with ESMTP id 687C23A6885 for ; Tue, 18 Nov 2008 13:40:07 -0800 (PST) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 769F775D4A8; Tue, 18 Nov 2008 15:40:03 -0600 (CST) Date: Tue, 18 Nov 2008 15:40:03 -0600 From: Eric Rescorla To: "LANGE Andrew" In-Reply-To: <66F9363AB70F764C96547BD8A0A3679E154CB9@USDALSMBS05.ad3.ad.alcatel.com> References: <66F9363AB70F764C96547BD8A0A3679E154CB4@USDALSMBS05.ad3.ad.alcatel.com> <66F9363AB70F764C96547BD8A0A3679E154CB9@USDALSMBS05.ad3.ad.alcatel.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081118214003.769F775D4A8@kilo.rtfm.com> Cc: tcpm@ietf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] Comments on TCP-AO Draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Tue, 18 Nov 2008 15:34:10 -0600, LANGE Andrew wrote: > (position 2 - "don't include") Including this information is BAD > because it can expose information about the security parameters. It > doesn't aid in debugging of configuration because operators still > have to call each other in order to read off and verify keys. > > Elaboration: Originally I was also of this position. However, I > came around when I considered the operational impacts. We need to > make this protocol as operator-friendly as possible. That is why it > is being created to begin with. We shouldn't lose sight of > deployability and maintainability in the quest to shorten an option > by a byte (especially when we gain 3 from MD5 to start with.) Also, > we have had many strong security experts, such as ekr and Brian Weis > (gentlemen, correct me if I'm misquoting you) say that putting > algorithm ID in the packet does very little to make it harder for a > bad guy to attack the session. To be specific, the attacker has to > be a man-in-the-middle to see the ALG ID to start with (whereas > blind attacks are probably more likely). In addition, the search > space would be extended by a single bit. We're already using very > strong algorithms, and have the agility to add more. Search is > already infeasible with known state, and if that changes the right > approach, and the secure approach is to introduce another algorithm. I don't think there's any real security value to hiding the identity of the MAC algorithm. I leave the question of whether shaving the byte is worth doing to the TCP experts. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 20 23:33:44 2008 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 B1C6C3A67D8; Thu, 20 Nov 2008 23:33:44 -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 CF1913A67D8 for ; Thu, 20 Nov 2008 23:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdqKS7etu+Dd for ; Thu, 20 Nov 2008 23:33:42 -0800 (PST) Received: from mail.ocarinanetworks.com (h-69-3-29-18.snvacaid.covad.net [69.3.29.18]) by core3.amsl.com (Postfix) with ESMTP id E4F573A67B4 for ; Thu, 20 Nov 2008 23:33:41 -0800 (PST) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Thu, 20 Nov 2008 23:33:40 -0800 From: Murali Bashyam To: Murali Bashyam , David Borman , Murali Bashyam Date: Thu, 20 Nov 2008 23:33:35 -0800 Thread-Topic: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document Thread-Index: AcklnA2e2MXArg1GSAaMUO85RtQh+AAHXndQCXxc9OA= Message-ID: References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> <20081003183726.GD27519@zod.isi.edu> <9c8209a10810031237y470b9cd3ha8ad6cbc3e17e422@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Ted Faber , "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document 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 Wes/David What are the next steps for this document to be considered a WG item? Can we get some closure on this draft? Thx, Murali > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Murali Bashyam > Sent: Saturday, October 04, 2008 9:49 PM > To: David Borman; Murali Bashyam > Cc: Anantha Ramaiah (ananth); tcpm@ietf.org; Ted Faber > Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document > > > > > -----Original Message----- > > From: David Borman [mailto:david.borman@windriver.com] > > Sent: Friday, October 03, 2008 2:05 PM > > To: Murali Bashyam > > Cc: Ted Faber; tcpm@ietf.org; Anantha Ramaiah (ananth); Murali > Bashyam > > Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document > > > > > > On Oct 3, 2008, at 2:37 PM, Murali Bashyam wrote: > > > > > > My intent was that even where TCP implementations have a scheme for > > > dropping connections in the event > > > of resource exhaustion (such as the Linux one does), they have > > > excluded connections in this state. > > > The point i am trying to convey is that the 1122 portion has > > > (mis)guided them in that direction. > > > > If this is true, it should be clarified. 1122 does not in any way > say > > that ABORT does not apply to connections in persist state (probing a > > zero window). > > > > ... > > >> In light of that I think that the sentence about "TCP itself > SHOULD > > >> not[sic] take any action..." is more confusing than the 1122 > > section. > > >> It seems to imply that TCP might react differently to an abort > than > > >> the single paragraph in 793, and I don't think that's the case. > > > > > > What's meant here is that it's okay for the connection to get > > > aborted in this state, whatever the mechanism for doing > > > so maybe: TCP can abort the connection and inform the application, > > > similar to the retransmit/persist timeout mechanisms > > > already in place, or the application can choose to abort the > > > connection based policy, or the OS can do so based > > > on resource management criteria. We can re-word that sentence and > > > paragraph to reflect this. > > > > Just to be clear: TCP DOES NOT ABORT THE CONNECTION! The OS or the > > application can choose to ABORT the connection, but TCP does not make > > this decision. TCP does have retransmit timers, and it is allowed to > > terminate unresponsive connections, but it does not abort connections > > just because they are in persist state for long periods of time. > > Until you are running out of resources there is no good reason to > > terminate connections in persist state, and when you are running out > > of resources, it is the OS that is deciding whether or not to ABORT > > any TCP connections. > > I agree that the retransmit/persist timeout analogy doesn't apply to > this situation. > It is ONLY the OS or resource manager or the application that can > terminate the connection > In this state. > > > > > > > >> Now, a strictly defined abort command seems to somewhat contradict > > my > > >> earlier comments about allowing implementers some freedom. This > is > > a > > >> spot where the standards body has required a specific tool to be > > >> available to applications (and OSes and resource managers): there > > >> must > > >> be a way to annihilate a TCP connection from outside without > regard > > >> to > > >> its state or anything else. The standard is silent about how the > > >> command is used; that's the flexibility here. > > > > > > The abort semantics as specified by 793 are clear, they are not > > > specific to a particular state, it's the opinion > > > of the authors that 1122 excludes it from being applied in this > > state. > > > > Yes, that is an opinion, but it is wrong. In no way does 1122 say > > that connections in persist state cannot be ABORTed. What 1122 does > > say is that a connection being in persist state for a long time is > not > > sufficient reason *by itself* to terminate a TCP connection, i.e., > > don't time it out like you would a connection to a non-responsive > host. > > Just so that we are all clear, i want to summarize the goals of the > draft here once again: > > 1. Clarify the 1122 ambiguity/stance on the sender behavior in persist > state. > 2. Document (for informational purpose) the consequence of this > behavior leading to > the DoS possibility. > 3. Specify that the OS/application can terminate the connection in this > state using the 793 ABORT interface. > > We are NOT documenting the various memory management > considerations/issues surrounding the DoS scenario, that's left to the > implementers discretion. > > We will change the section that's ambiguous regarding the sentence that > goes "TCP itself should not take any action...". > > > _______________________________________________ > 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 Nov 25 08:28:08 2008 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 29FC63A682B; Tue, 25 Nov 2008 08:28:08 -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 7A28B3A682B for ; Tue, 25 Nov 2008 08:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyJqy-4u75RB for ; Tue, 25 Nov 2008 08:28:05 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 85A403A682A for ; Tue, 25 Nov 2008 08:28:05 -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 25C722D812C; Tue, 25 Nov 2008 10:28:03 -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 mAPGS2pa015100; Tue, 25 Nov 2008 10:28:02 -0600 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 10:28:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 10:25:41 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document Thread-Index: AcklnA2e2MXArg1GSAaMUO85RtQh+AAHXndQCXxc9OAA28N6IA== References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com><1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com><20081003183726.GD27519@zod.isi.edu><9c8209a10810031237y470b9cd3ha8ad6cbc3e17e422@mail.gmail.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Murali Bashyam" , "David Borman" , "Murali Bashyam" X-OriginalArrivalTime: 25 Nov 2008 16:28:02.0890 (UTC) FILETIME=[C9B9A2A0:01C94F1A] Cc: "Anantha Ramaiah \(ananth\)" , tcpm@ietf.org, Ted Faber Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document 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 >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >Behalf Of Murali Bashyam >Sent: Friday, November 21, 2008 2:34 AM >To: Murali Bashyam; David Borman; Murali Bashyam >Cc: Ted Faber; tcpm@ietf.org; Anantha Ramaiah (ananth) >Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document > >Wes/David > >What are the next steps for this document to be considered a >WG item? Can we get some closure on this draft? In the email thread proposing to adopt this, there were several people who expressed resistance. Most seemed to agree that it's not a pressing matter for TCPM and we'd only be providing implementation guidance. There was only fairly weak support for adopting this expressed by anyone but the authors, from what I saw. To me, it doesn't look like the WG is expressing sufficient interest to carry this through the process, even if it's mostly technically accurate and has some small utility in aiding implementers. Unless people start flooding forward to express interest in this as being important to them and commit to doing reviews, etc., I don't think it can be adopted as a WG item. If anyone does strongly support the document as a WG item, please speak up. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 26 02:39:09 2008 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 97C2E3A691A; Wed, 26 Nov 2008 02:39:09 -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 95FC428C0ED for ; Wed, 26 Nov 2008 02:39:08 -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 V1cZ+7JLES6K for ; Wed, 26 Nov 2008 02:39:07 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 573A43A68D1 for ; Wed, 26 Nov 2008 02:39:06 -0800 (PST) Received: from Gorry-Fairhursts-Laptop.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id mAQAcU5H024892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Nov 2008 10:38:31 GMT Message-ID: <492D2726.3060505@erg.abdn.ac.uk> Date: Wed, 26 Nov 2008 10:38:30 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: tcpm@ietf.org X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: Gorry , fernando@gont.com.ar Subject: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk 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 I volunteered to review this I-D in the TCPM meeting in MPLS. I'd like to make the following observations, and explore whether these are issues: * It was interesting to read the issues presented in the I-D. The I-D is mainly documentation of algorithms and current practice. If published, this seems like an informational document - I can not determine whether this is needed, and whether the material could already be covered by other documentation. * One section of the document (6) describes issues with Source-Quench, however this is not a credible issue - it has long been known that Source-Quench is not of value. I think this section could safely be omitted, reduced or combined with earlier sections to provide more rationale for the main part of the I-D. * The main part of the document is about PMTUD vulnerabilities to ICMP attacks and some deployed countermeasures. In my opinion, this discussion should be set against the framework defined by the IETF standards-track "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. This is not currently mentioned, which I find very confusing. I'd suggest that if the document is to be published as a useful output of the transport area it must compare the non-ICMP methods to those in RFC 4821. * Appendix A concludes with an interpretation of the meaning of several RFCs. If this is the result of an IETF WG consensus call, this needs to be made clear and more effort needs to be made to determine the correct advice. If this is the editor's own view, then it should be omitted from a working group draft. * Finally, I do not see a detailed discussion of ICMP issues in general as the title suggests, but more of a focus on PMTUD attacks. A change to the title and abstract would help attract the right people to read this and better reflect the actual content. I will separately send some comments on the document itself to the list, but have decided to postpone the final stage of the review until I hear more about the relationship to PLPMTUD, since this may require some reworking of the document. It may be that there has been discussion on this topic before, if so please let me know. Best wishes, Gorry _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 26 02:39:45 2008 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 CFC6828C1C8; Wed, 26 Nov 2008 02:39:45 -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 5705528C1C8 for ; Wed, 26 Nov 2008 02:39:45 -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 FKH7mRDMXLuX for ; Wed, 26 Nov 2008 02:39:44 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id E92913A691A for ; Wed, 26 Nov 2008 02:39:43 -0800 (PST) Received: from Gorry-Fairhursts-Laptop.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id mAQAcWda024894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Nov 2008 10:38:33 GMT Message-ID: <492D2728.2070309@erg.abdn.ac.uk> Date: Wed, 26 Nov 2008 10:38:32 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: fernando@gont.com.ar, Gorry X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: tcpm@ietf.org Subject: [tcpm] Comments on the text in draft-ietf-tcpm-icmp-attacks-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk 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 I volunteered to review this I-D in the TCPM meeting in MPLS, this email contains detailed comments on the text (but not the pseudocode). I may have more comments, depending on whether the answers to my other email also change my understanding of the draft. Best wishes, Gorry --- Detailed notes/comments These notes detail some of the document issues. A separate email highlights some issues that I feel are more significant. Abstract, line 4: /describes a/ - Insert /this also/ before the above clause. Abstract The abstract seems to match the title, but the majority of text describes the use or non-use of ICMP for selecting path MTU. If this is a major feature of the I-D, it should be reflected in the abstract. Section 1, para 1 /allowing variety of/ ^ - please insert 'a' Section 2.1.1 does not review the guidance on PLPMTUD provided in RFC 4821. Section 2.1.1 talks about source-quench. Is it possible to say this is historic in some way? Section 2.1.1 also needs a ref to RFC4821 besides that of RFC1191. Section 2.1.2 also needs to mention RFC 4821 (see previous note) Section 2.3 has an unclear introduction to IPsec, I think it is missing a few sentences that define the basic terminology used later in the draft. Section 3, para 1 - Identifies the small minimum payload of IPv4 ICXMP messages. In the light of extensive use of tunnels, it would be good to comment on the issues in receiving ICMP messages from routers on a tunnel path. Section 3, para 3 - I do not understand how a portion of a signed segment actually helps more than any other valid packet header sent from the sending host. Section 3, final para /with every existing intermediate system/ - this seems extreme. Is it /the set of routers along the path to the destination/ Section 4.1 /so makes TCP react only/ - this would be better written as: /that makes a sender TCP only react/ Section 4.2 /increasing the port number range for outgoing/ - This needs more detail: what does this mean? - is this a practice endorsed by the IETF, a new procedure, or one that goes against an IETF recommendation? /connection/ - spelling needs to be corrected. Section 4.3 /can help to prevent users of the network being protected/ - This seems odd. Is this sentence correct? Section 5.1, bullet 2 /and repeatedly retransmit its data/ - This needs clarification, is this a special procedure, or a standard TCP retransmit? Section 5.1 /It is important to note that even if/ - please delete //It is important to note that/ Section 5.2 /It is interesting to note that as/ - please delete. Section 5.2 / USER TIMEOUT/ - should this be upper case? Paragraph starting /In scenarios such that.../ reads curiously, please clarify the English. Section 6.1/6.2 - The level of detail in the section ICMP Source Quench seems rather odd, given that networks have been discouraged to deploy this for many years and RFC1812 already in 1995 has stated "A router SHOULD NOT originate ICMP Source Quench messages." Do we need to pick-apart the vulnerability of a mechanism that is not recommended for use in the general internet? - I'd prefer a more concise description. Section 7.1 /When one IP system has a large amount of data to send to another system, the data will be transmitted as a series of IP datagrams. / - I think it's not necessarily so large! - I think it would be bette to say the Internet architecture allows the sender to break data into a series of IP datagrams for transmission across the Internet - or something like that. Section 7.1 /The basic idea behind the PMTUD mechanism is that a source system assumes that the MTU of the path is that of the first hop,/ - It's probably better language to say it sets upper bound to the interface MTU (is there really an assumption here, this seems like a search algorithm). Section 7.1 /"fragmentation neeed and DF/ ^ - insert 'd' Section 7.1 - This section discusses an increase in IRQ with packet rate. I do not believe this is necessarily so. Many Ethernet drivers are able to cope with rising packet rates without a corresponding increase in IRQ rate, but of course there will still be packet processing overhead as the I-D states. The last two paragraphs appear to focus on IPv4-related issues, This would be clearer if the two paragraphs were reversed in their order. Section 7.2 /The described mechanism basically disregards ICMP messages when a connection makes progress./ - This seems like the place to introduce PLPMTUD, and to relate subsequent sections to this framework. Section 7.3 /SECTION/ should be /section/ Section 7.3 - This section talks about a proposed counter measure. Is this the same one that the I-D is seeking to document, or a different one? Section 7.3 /simplicity sake/ ^^^^ - please omit 'sake' Appendix A, Type 3 - What is a valid action if the host has only sent packets with a DF=0, and receives this message - ignore? Appendix A, final para - The last paragraph seems a little odd in a working group draft. Does this actually reflect the consensus of the working group - can that consensus be clarified? - I do not know, see other email (or Chairs may comment). Appendix B Is the IETF happy with the advice in appendix B? - I have no comment on this. The I-D talks about /intermediate systems/ but I think in this case we simply mean internet "routers" - was there a reason for this choice of words, or can we use router throughout? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 26 21:25:54 2008 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 8AC393A6820; Wed, 26 Nov 2008 21:25:54 -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 88BDD3A6820 for ; Wed, 26 Nov 2008 21:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.479 X-Spam-Level: X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808] 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 1uNghiwEYKDx for ; Wed, 26 Nov 2008 21:25:52 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 4EB2A3A6806 for ; Wed, 26 Nov 2008 21:25:51 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 44A3A6B6655; Thu, 27 Nov 2008 02:25:55 -0300 (ART) Received: from notebook.gont.com.ar (201-254-58-247.speedy.com.ar [201.254.58.247] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id mAR5PWGK018547; Thu, 27 Nov 2008 03:25:33 -0200 Message-Id: <200811270525.mAR5PWGK018547@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 27 Nov 2008 02:19:07 -0300 To: gorry@erg.abdn.ac.uk, tcpm@ietf.org From: Fernando Gont In-Reply-To: <492D2726.3060505@erg.abdn.ac.uk> References: <492D2726.3060505@erg.abdn.ac.uk> 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, 27 Nov 2008 02:25:54 -0300 (ART) Cc: fernando@gont.com.ar Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello, Gorry, Thanks so much for your thorough and timely review. You'll find my comments in-line.... >* It was interesting to read the issues presented in the I-D. The >I-D is mainly documentation of algorithms and current practice. If >published, this seems like an informational document - I can not >determine whether this is needed, and whether the material could >already be covered by other documentation. It is not covered by other documentation. For instance, this Internet-Draft is the document that has been referenced in a number of vulnerability advisories published on these issues (e.g. by CERT/CC and UK NISCC), and has also been referenced by a number of vulnerability advisories published by vendors when they addressed these issues. >* One section of the document (6) describes issues with >Source-Quench, however this is not a credible issue - it has long >been known that Source-Quench is not of value. I think this section >could safely be omitted, reduced or combined with earlier sections >to provide more rationale for the main part of the I-D. I'm not sure what you mean. It may have been known that SQ was not of value... yet all implementations were responding to SQ as specified by the IETF. And it was in response to this I-D that many implementations removed support for SQ (e.g., I did the corresponding patch for OpenBSD). >* The main part of the document is about PMTUD vulnerabilities to >ICMP attacks and some deployed countermeasures. In my opinion, this >discussion should be set against the framework defined by the IETF >standards-track "Packetization Layer Path MTU Discovery", RFC 4821, >March 2007. This is not currently mentioned, which I find very >confusing. I'd suggest that if the document is to be published as a >useful output of the transport area it must compare the non-ICMP >methods to those in RFC 4821. I belive that RFC 4821 does not necessarily obsolete traditional PMTUD. They may be orthogonal. That is, as stated in RFC 4821, you could implement PLPMTUD just for black-hole detection. I agree that additional discussion of PLPMTUD might be included, though. >* Appendix A concludes with an interpretation of the meaning of >several RFCs. If this is the result of an IETF WG consensus call, >this needs to be made clear and more effort needs to be made to >determine the correct advice. If this is the editor's own view, then >it should be omitted from a working group draft. This text was included in the document even before it was accepted as a wg document. (BTW, I do not recall when or why I moved that text out of the main body of the doc to an appendix). I don't seem to recall people arguing again this particular text. However, I'm open to remove this text if the wg feels this is a show-stopper. >* Finally, I do not see a detailed discussion of ICMP issues in >general as the title suggests, but more of a focus on PMTUD attacks. >A change to the title and abstract would help attract the right >people to read this and better reflect the actual content. The document discusses ICMP attacks against TCP. There are basically three of them: connection.reset (hard errors), throughput reduction (Source Quench), and the PMTUD ones. It's not that it focuses on the PMTUD ones, but rather that the full counter-measure for the PMTUD attack is more complex, so it requires more analysys, test-case scenarios, etc. That's it. >I will separately send some comments on the document itself to the >list, but have decided to postpone the final stage of the review >until I hear more about the relationship to PLPMTUD, since this may >require some reworking of the document. It may be that there has >been discussion on this topic before, if so please let me know. Please let me know if the above answer your questions.... Thanks so much for your review! 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 Fri Nov 28 05:08:49 2008 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 578C128C0D9; Fri, 28 Nov 2008 05:08:49 -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 7B0753A6AAE; Fri, 28 Nov 2008 05:08:48 -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 EopL5F4SsHYG; Fri, 28 Nov 2008 05:08:47 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 577383A6809; Fri, 28 Nov 2008 05:08:47 -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 mASD8DYm000775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 28 Nov 2008 15:08:14 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <2F5BD485-E44D-4346-8D21-762C0F42602D@nokia.com> From: Lars Eggert To: ext Scott Brim In-Reply-To: <20081124164002.GD45553@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 28 Nov 2008 15:08:13 +0200 References: <20081124164002.GD45553@cisco.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8691/Fri Nov 28 02:09:03 2008 on fit.nokia.com X-Virus-Status: Clean 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, 28 Nov 2008 15:08:17 +0200 (EET) Cc: General Area Review Team , tcpm@ietf.org, fernando@gont.com.ar, mallman@icir.org Subject: Re: [tcpm] gen-art review of draft-ietf-tcmp-tcp-uto-09.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: , Content-Type: multipart/mixed; boundary="===============0297495912==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0297495912== Content-Type: multipart/signed; boundary=Apple-Mail-23-462390427; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-23-462390427 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, Scott, thanks for the comments. On 2008-11-24, at 18:40, ext Scott Brim wrote: > - Since a UTO can apparently be sent at any time, what happens if a > UTO is received that shortens the timeout and there are > unacknowledged packets that are already beyond the new timeout > value? Good point. There are basically two choices: Apply the new UTO already to the current timeout event, or start using the new UTO for future timeout events. I believe that simply starting to use the new value immediately is easiest for implementors, but because reaction to UTOs is purely a local thing, I'm not sure if the draft should require any specific behavior. We can mention the two choices, if folks think that would be useful - tell us. > - Is it intended that the ENABLED flag applies to both sending and > receiving the UTO? It seems to be, but I want to be sure. If > that is the intention, could you make it clearer? > > It certainly applies to a received UTO: > > "This adaptation only happens if the other end of the connection > has explicitly allowed it (both ENABLED and CHANGEABLE are > true)." > > but it seems to apply to sending a UTO as well: > > "Before opening a connection, an application that wishes to use > the UTO option enables its use by setting ENABLED to true." Correct, it applies for both sending and receiving. Can we make this clearer in the text somehow? > (2) Editorial: I applied all of these in my working copy. Thanks, Lars --Apple-Mail-23-462390427 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 MBwGCSqGSIb3DQEJBTEPFw0wODExMjgxMzA4MTNaMCMGCSqGSIb3DQEJBDEWBBSbmhJpRME0IVB2 8qWWnFiOmNmVZjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAd7bizS5RUFSKt7GFJvCy8l6vhLzFTSXJMuYdqkOdIYPCli6RXDEe G8EOAnIo8oi43nMdHdTEKcTQw1gShIXwwiemQ4hRYcipLhfUBTS9AjqKt0E/U+iVDaCizmPd3Xdj TOoGpEalAwDXthPjLKK23FeOA7ngm4uU6vmAA1QdIVAdG6xI7eQ/yVEfHoVjkv4JVeh065ZWPBwv J7eGkgB9/FH4o789g1cI5Pc8wh0U4r8SHJhDmu8Ph2OMPgdi/st/+w9Bu5Z9EaZ1M9Pwe/rB+E6U hwRyYD2rEixxi8HafqOyTyh0o3OlD62e9APBxMWbq1DsmBoemU/lL4uXNVd8EgAAAAAAAA== --Apple-Mail-23-462390427-- --===============0297495912== 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 --===============0297495912==-- From tcpm-bounces@ietf.org Sun Nov 30 11:15:04 2008 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 51EA33A6BDA; Sun, 30 Nov 2008 11:15:04 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6061A3A6BA2; Sun, 30 Nov 2008 11:15:00 -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: <20081130191501.6061A3A6BA2@core3.amsl.com> Date: Sun, 30 Nov 2008 11:15:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-soft-errors-09.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's Reaction to Soft Errors Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-soft-errors-09.txt Pages : 17 Date : 2008-11-30 This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages, that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-09.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-soft-errors-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-30111138.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--