From hakim.adhari@uni-due.de Sat Oct 1 01:48:01 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0635521F8B1E for ; Sat, 1 Oct 2011 01:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44TksThHo1aC for ; Sat, 1 Oct 2011 01:48:00 -0700 (PDT) Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) by ietfa.amsl.com (Postfix) with ESMTP id 063FA21F8B1D for ; Sat, 1 Oct 2011 01:47:59 -0700 (PDT) Received: from EXCHANGE01.win.uni-due.de (ex02.win.uni-due.de [132.252.180.21]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id p918otlL021216 for ; Sat, 1 Oct 2011 10:50:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Deadline Extension: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support Date: Sat, 1 Oct 2011 10:51:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Deadline Extension: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support Thread-Index: AcyAFz9k+WCBJWBOSuS7ZugNtmA8vg== From: "Adhari, Hakim" To: X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 08:48:01 -0000 (Our apologies if you receive multiple copies of this CfP) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please consider to contribute to and/or forward to the appropriate = groups the following opportunity to submit and publish original = scientific results to PAMS 2012. =20 The submission deadline has been extended to October 16, 2011. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CALL FOR PAPERS = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2nd International Workshop on Protocols and Applications with = Multi-Homing Support (PAMS 2012) In conjunction with the 26th IEEE = International Conference on Advanced Information Networkingand = Applications (AINA 2012) Fukuoka, Japan, March 26-29, 2012 = http://tdrwww.iem.uni-due.de/pams2012.html The intent of our workshop is to bring together people from research and = industry, in order to provide a discussion forum for state-of-the-art = topics related to multi-homing on Network, Transport, Session and = Application Layers. The PAMS workshop will include full-paper sessions as well as a poster = session (with short presentations) to introduce preliminary ideas as = well as work in progress. Workshops proceedings will be published by the IEEE CS Conference = Publishing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimization for Multi-Homed Systems * Multi-Homing in the Context of Future Internet GENERAL CHAIRS: * Thomas Dreibholz, University of Duisburg-Essen, Germany * Martin Becke, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Michael T=FCxen, M=FCnster University of Applied Sciences, Germany * Erwin P. Rathgeb, University of Duisburg-Essen, Germany PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, Cetekom, Germany * Paul Amer, University of Delaware, U.S.A. * Holger Bleul, DB Systel, Germany * Anna Brunstr=F6m, Karlstad University, Sweden * Glenford Mapp, Middlesex University, United Kingdom * Michio Honda, Keio University, Japan * Seok J. Koh, Kyungpook National University, Korea * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, University of British Columbia, Canada * Irene R=FCngeler, M=FCnster University of Applied Sciences, = Germany * Robin Seggelmann, M=FCnster University of Applied Sciences, = Germany * Esbold Unurkhaan, Mongolian University of Science and Technology, = Mongolia * Alan Wagner, University of British Columbia, Canada * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: October 16, 2011 * Author Notification: December 01, 2011 * Camera-Ready Paper Submission: January 06, 2012 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh AT iem.uni-due.de) * Martin Becke (martin.becke AT uni-due.de) WEBSITE http://tdrwww.iem.uni-due.de/pams2012.html=20 From gorry@erg.abdn.ac.uk Thu Oct 6 05:39:47 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8D621F8B84 for ; Thu, 6 Oct 2011 05:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq7kK4yG3F0T for ; Thu, 6 Oct 2011 05:39:46 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 5AACC21F8B7D for ; Thu, 6 Oct 2011 05:39:46 -0700 (PDT) Received: from Gorry-Fairhurst-PC.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p96Cghbx013298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Oct 2011 13:42:43 +0100 (BST) Message-ID: <4E8DA243.4050002@erg.abdn.ac.uk> Date: Thu, 06 Oct 2011 13:42:43 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: tsvwg WG Subject: New TSVWG draft: Generic Aggregation of RSVP Reservations over PCN domains Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 12:39:47 -0000 The following draft is approved as a TSVWG work item: "Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains" http://tools.ietf.org/html/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01 Authors, please upload a new revision of this draft as: draft-ietf-tsvwg-rsvp-pcn-00 This draft has the support of the PCN working group and was discussed in TSVWG at IETF-81. Since this meeting, the Transport Area ADs have added the following milestone to our charter: "May 2012 - Submit Encoding and Transport of (Pre-) Congestion Information from the Domain Egress to the Ingress to the IESG for consideration as a Proposed Standard RFC." Best wishes, Gorry & James. From internet-drafts@ietf.org Sat Oct 8 01:16:34 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D6721F8B0C; Sat, 8 Oct 2011 01:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vby3CGyvTGBa; Sat, 8 Oct 2011 01:16:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8FD21F8AEA; Sat, 8 Oct 2011 01:16:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-rsvp-pcn-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111008081634.8601.19771.idtracker@ietfa.amsl.com> Date: Sat, 08 Oct 2011 01:16:34 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 08:16:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Generic Aggregation of Resource ReSerVation Protocol (RS= VP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-00.txt Pages : 22 Date : 2011-10-08 This document specifies the extensions to the Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-00.txt From karagian@cs.utwente.nl Sat Oct 8 01:19:24 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4590221F8AEC for ; Sat, 8 Oct 2011 01:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AM4pxGpWv13 for ; Sat, 8 Oct 2011 01:19:23 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7BA21F8B0C for ; Sat, 8 Oct 2011 01:19:22 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p988J6oZ017968; Sat, 8 Oct 2011 10:19:06 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 08 Oct 2011 08:22:54 +0000 To: tsvwg@ietf.org Subject: Re: New TSVWG draft: Generic Aggregation of RSVP Reservations over PCN domains Date: Sat, 08 Oct 2011 08:22:54 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4E8DA243.4050002@erg.abdn.ac.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sat, 08 Oct 2011 10:19:16 +0200 (MEST) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 08:19:24 -0000 Hi Gorry, Hi James, Thanks, I have just submitted the draft: draft-ietf-tsvwg-rsvp-pcn-00 Best regards, Georgios On 10/6/2011, "Gorry Fairhurst" wrote: > >The following draft is approved as a TSVWG work item: > >"Generic Aggregation of Resource ReSerVation Protocol (RSVP) >for IPv4 And IPv6 Reservations over PCN domains" >http://tools.ietf.org/html/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01 > >Authors, please upload a new revision of this draft as: >draft-ietf-tsvwg-rsvp-pcn-00 > >This draft has the support of the PCN working group and was discussed in >TSVWG at IETF-81. Since this meeting, the Transport Area ADs have added >the following milestone to our charter: > >"May 2012 - Submit Encoding and Transport of (Pre-) Congestion >Information from the Domain Egress to the Ingress to the IESG for >consideration as a Proposed Standard RFC." > >Best wishes, > >Gorry & James. > > > From internet-drafts@ietf.org Mon Oct 10 23:11:36 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B7321F8CFC; Mon, 10 Oct 2011 23:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO1rzNAMWb3D; Mon, 10 Oct 2011 23:11:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B683D21F8CE7; Mon, 10 Oct 2011 23:11:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-sctpsocket-32.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111011061135.4184.36253.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2011 23:11:35 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 06:11:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Sockets API Extensions for Stream Control Transmission P= rotocol (SCTP) Author(s) : Randall R. Stewart Michael Tuexen Kacheong Poon Peter Lei Vladislav Yasevich Filename : draft-ietf-tsvwg-sctpsocket-32.txt Pages : 113 Date : 2011-10-10 This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-32.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-32.txt From Michael.Tuexen@lurchi.franken.de Mon Oct 10 23:32:44 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0559321F8CD4; Mon, 10 Oct 2011 23:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGEC7KUKHzwR; Mon, 10 Oct 2011 23:32:43 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 3F30D21F8CC3; Mon, 10 Oct 2011 23:32:43 -0700 (PDT) Received: from [192.168.1.124] (p508F9F9D.dip.t-dialin.net [80.143.159.157]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D3E131C0C0BCE; Tue, 11 Oct 2011 08:32:40 +0200 (CEST) Subject: Re: I-D Action: draft-ietf-tsvwg-sctpsocket-32.txt Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20111011061135.4184.36253.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2011 08:32:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <522CDD5D-5DD3-4192-B3CF-CDD2AF18DAD9@lurchi.franken.de> References: <20111011061135.4184.36253.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.1244.3) Cc: tsvwg@ietf.org, i-d-announce@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 06:32:44 -0000 On Oct 11, 2011, at 8:11 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Transport Area Working = Group Working Group of the IETF. >=20 > Title : Sockets API Extensions for Stream Control = Transmission Protocol (SCTP) > Author(s) : Randall R. Stewart > Michael Tuexen > Kacheong Poon > Peter Lei > Vladislav Yasevich > Filename : draft-ietf-tsvwg-sctpsocket-32.txt > Pages : 113 > Date : 2011-10-10 >=20 > This document describes a mapping of the Stream Control Transmission > Protocol (SCTP) into a sockets API. The benefits of this mapping > include compatibility for TCP applications, access to new SCTP > features and a consolidated error and event notification scheme. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-32.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-32.txt >=20 Dear all, the changes are: * a statement regarding deprecated socket API elements. This addresses a Discuss of Adrian Farrel and a comment of Robert = Sparks. * a normative reference to the most recent POSIX document has been = added. This addresses a Comment of Peter Saint-Andre and Stephen Farrell. * a note has been added that DTLS/SCTP can be implemented using this = API. This addresses a Comment of Stephen Farrell. * a copyright note has been added to the source code. This addresses a Discuss of Sean Turner. * editorial fixes: - setsockopts last argument has the type socklen_t, not size_t. - the DSCP field uses the 6 most significant bits, not the least ones. - names in the Acks section are now in alphabetical order. Not addressed: * Change reference from RFC 1644 to RFC 6247. (Discuss of Adrian Farrel) Reason: We want to specifically refer to T/TCP, whereas RFC 6247 moves a bunch of documents to the historic state, RFC 1644 being one of = them. * Add a generic sentence about implementation security (buffer overruns, CVE). (Discuss of Stephen Farrell) Reason: This seems to be very generic and we can't provide a pointer = for a list of SCTP implementation bugs. On the other hand it is clear that implementations contain bugs... I hope this addresses the issues brought up during the IESG discussion = in an appropriate way. If not, please let me know. Thanks a lot to the IESG for reviewing the document and providing comments. Best regards Michael= From gorry@erg.abdn.ac.uk Tue Oct 18 04:22:43 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552EC21F8B88 for ; Tue, 18 Oct 2011 04:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+uj2Ujh6nUL for ; Tue, 18 Oct 2011 04:22:43 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id A5EF321F8B7E for ; Tue, 18 Oct 2011 04:22:42 -0700 (PDT) Received: from Gorry-Fairhurst-PC.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p9IBMcXo012973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Oct 2011 12:22:39 +0100 (BST) Message-ID: <4E9D617F.9080305@erg.abdn.ac.uk> Date: Tue, 18 Oct 2011 12:22:39 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: tsvwg list Subject: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011 References: <4CCBD067.60206@erg.abdn.ac.uk> In-Reply-To: <4CCBD067.60206@erg.abdn.ac.uk> X-Forwarded-Message-Id: <4CCBD067.60206@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: "tsvwg-chairs@tools.ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 11:22:43 -0000 This email announces the start of a working group last call for draft-ietf-tsvwg-source-quench-02.txt, "Deprecation of ICMP Source Quench messages". This document is now thought to be ready to proceed to be published as a PS. Please send any comments to the TSVWG list. The draft is available at: http://www.ietf.org/id/draft-ietf-tsvwg-source-quench-02.txt The last call will run for TWO weeks, ending Wednesday 9th October 2011 2011. Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. Please let us know if this draft is useful and seems to provide the correct advice. James and Gorry (TSVWG Chairs) From sob@harvard.edu Tue Oct 18 05:05:10 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC6721F8B8A for ; Tue, 18 Oct 2011 05:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PplHM-FsJ6L for ; Tue, 18 Oct 2011 05:05:09 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id A0D8E21F8B88 for ; Tue, 18 Oct 2011 05:05:09 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id A1537FED737; Tue, 18 Oct 2011 08:05:05 -0400 (EDT) To: tsvwg@ietf.org Subject: Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011, Message-Id: <20111018120505.A1537FED737@newdev.eecs.harvard.edu> Date: Tue, 18 Oct 2011 08:05:05 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 12:05:10 -0000 why does section 6 use SHOULD rather than MUST? seems to me that there are no known cases where any transport protocol should ever respond to a Source Quench Scott From touch@isi.edu Tue Oct 18 14:22:17 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732951F0C3B for ; Tue, 18 Oct 2011 14:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.203 X-Spam-Level: X-Spam-Status: No, score=-105.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVbe+eY3FH9G for ; Tue, 18 Oct 2011 14:22:16 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5F91F0C38 for ; Tue, 18 Oct 2011 14:22:16 -0700 (PDT) Received: from [10.103.185.165] (mobile-166-205-137-226.mycingular.net [166.205.137.226]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p9ILLV40023389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Oct 2011 14:21:44 -0700 (PDT) References: <20111018120505.A1537FED737@newdev.eecs.harvard.edu> In-Reply-To: <20111018120505.A1537FED737@newdev.eecs.harvard.edu> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <9C0A8082-9E2E-4A7A-BC94-805341AAF293@isi.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9A334) From: Joe Touch Subject: Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011, Date: Tue, 18 Oct 2011 14:20:52 -0700 To: "Scott O. Bradner" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:22:17 -0000 I had suggested: MUST ignore SHOULD NOT send The latter is weaker because there is no impact if a message is sent. Howeve= r, I do prefer use of SHOULD only with at least one known exception provided= , or at least a clear metric to know when the exception is appropriate.=20 In this case SHOULD should not be driven by legacy cases.=20 Joe On Oct 18, 2011, at 5:05 AM, sob@harvard.edu (Scott O. Bradner) wrote: >=20 > why does section 6 use SHOULD rather than MUST? >=20 > seems to me that there are no known cases where any transport protocol > should ever respond to a Source Quench >=20 > Scott From fernando.gont.netbook.win@gmail.com Thu Oct 20 08:09:21 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6C021F8C10 for ; Thu, 20 Oct 2011 08:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZWrSbsCg1JM for ; Thu, 20 Oct 2011 08:09:21 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7ACF21F8C0E for ; Thu, 20 Oct 2011 08:09:20 -0700 (PDT) Received: by yxj19 with SMTP id 19so3489367yxj.31 for ; Thu, 20 Oct 2011 08:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=t4ItESksdtl+gou8CLuMKpnW4/FaYSbxREShSLuBFbs=; b=nqn9pooybzNW5NJEpQ1+L8XYkuVjc0ZFc42bUBXPMHh6NTcepU5fBnMSusO2/c34he 1VVk2UNX7E1hNUQn6XaPRTl8yVzKfUu63BUJm8TevWTPUnPuGktFXLWZCgVZxX6VqzUr gaysXsAboiDC0fmJLZncyDlhmXCQ6aSea7+zY= Received: by 10.236.180.101 with SMTP id i65mr16601710yhm.21.1319123360554; Thu, 20 Oct 2011 08:09:20 -0700 (PDT) Received: from [192.168.123.103] ([190.48.225.169]) by mx.google.com with ESMTPS id d32sm12183364yhj.17.2011.10.20.08.09.17 (version=SSLv3 cipher=OTHER); Thu, 20 Oct 2011 08:09:19 -0700 (PDT) Sender: Fernando Gont Message-ID: <4EA03997.2080707@gont.com.ar> Date: Thu, 20 Oct 2011 12:09:11 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Joe Touch Subject: Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011, References: <20111018120505.A1537FED737@newdev.eecs.harvard.edu> <9C0A8082-9E2E-4A7A-BC94-805341AAF293@isi.edu> In-Reply-To: <9C0A8082-9E2E-4A7A-BC94-805341AAF293@isi.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Scott O. Bradner" , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:09:21 -0000 Hi, Joe, Thanks for your input! Please find my comments inline... On 10/18/2011 06:20 PM, Joe Touch wrote: > I had suggested: > > MUST ignore > > SHOULD NOT send > > The latter is weaker because there is no impact if a message is sent. Is there any valid reason *for* sending SQs? My understanding of Scott's point is that the motivation for a "SHOULD NOT" rather than "MUST NOT" should be that there are exceptions under which it could make sense to behave in a different way (rather than whether there may be a negative impact if the advise is not followed). So I'd agree with Scott that this should be "MUST NOT send, MUST ignore if received". Thoughts? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Thu Oct 20 10:25:42 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84A121F8486 for ; Thu, 20 Oct 2011 10:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.066 X-Spam-Level: X-Spam-Status: No, score=-103.066 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDUfJwtHxjT8 for ; Thu, 20 Oct 2011 10:25:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id C503521F8C36 for ; Thu, 20 Oct 2011 10:25:38 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p9KHPLv7014861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2011 10:25:24 -0700 (PDT) Message-ID: <4EA05981.9040709@isi.edu> Date: Thu, 20 Oct 2011 10:25:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Fernando Gont Subject: Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011, References: <20111018120505.A1537FED737@newdev.eecs.harvard.edu> <9C0A8082-9E2E-4A7A-BC94-805341AAF293@isi.edu> <4EA03997.2080707@gont.com.ar> In-Reply-To: <4EA03997.2080707@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Scott O. Bradner" , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:25:43 -0000 Hi, Fernando, My view: - the doc needs MUST ignore on receipt Anything beyond that isn't needed. If it's ignored, there's no point in sending it, but it does no harm. I would prefer to not even make a statement about whether to send it. A MUST NOT send could be (mis)interpreted as an opportunity for (yet another) needless suggestion that it should be interpreted as either an attack or a formal error worth reporting. Joe On 10/20/2011 8:09 AM, Fernando Gont wrote: > Hi, Joe, > > Thanks for your input! Please find my comments inline... > > On 10/18/2011 06:20 PM, Joe Touch wrote: >> I had suggested: >> >> MUST ignore >> >> SHOULD NOT send >> >> The latter is weaker because there is no impact if a message is sent. > > Is there any valid reason *for* sending SQs? > > My understanding of Scott's point is that the motivation for a "SHOULD > NOT" rather than "MUST NOT" should be that there are exceptions under > which it could make sense to behave in a different way (rather than > whether there may be a negative impact if the advise is not followed). > > So I'd agree with Scott that this should be "MUST NOT send, MUST ignore > if received". > > Thoughts? > > Thanks! > > Best regards, From gorry@erg.abdn.ac.uk Thu Oct 20 12:51:55 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6017C1F0C4A for ; Thu, 20 Oct 2011 12:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBaduliD7zvU for ; Thu, 20 Oct 2011 12:51:54 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 843691F0C43 for ; Thu, 20 Oct 2011 12:51:54 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p9KJpnO2001815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 20 Oct 2011 20:51:51 +0100 (BST) Message-ID: <4EA07BD5.7090701@erg.abdn.ac.uk> Date: Thu, 20 Oct 2011 20:51:49 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: tsvwg WG Subject: Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011, References: <20111018120505.A1537FED737@newdev.eecs.harvard.edu> <9C0A8082-9E2E-4A7A-BC94-805341AAF293@isi.edu> <4EA03997.2080707@gont.com.ar> <4EA05981.9040709@isi.edu> In-Reply-To: <4EA05981.9040709@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:51:55 -0000 On 20/10/2011 18:25, Joe Touch wrote: > Hi, Fernando, > > My view: > > - the doc needs MUST ignore on receipt > > Anything beyond that isn't needed. If it's ignored, there's no point in > sending it, but it does no harm. > > I would prefer to not even make a statement about whether to send it. > > A MUST NOT send could be (mis)interpreted as an opportunity for (yet > another) needless suggestion that it should be interpreted as either an > attack or a formal error worth reporting. > > Joe > > On 10/20/2011 8:09 AM, Fernando Gont wrote: >> Hi, Joe, >> >> Thanks for your input! Please find my comments inline... >> >> On 10/18/2011 06:20 PM, Joe Touch wrote: >>> I had suggested: >>> >>> MUST ignore >>> >>> SHOULD NOT send >>> >>> The latter is weaker because there is no impact if a message is sent. >> >> Is there any valid reason *for* sending SQs? >> >> My understanding of Scott's point is that the motivation for a "SHOULD >> NOT" rather than "MUST NOT" should be that there are exceptions under >> which it could make sense to behave in a different way (rather than >> whether there may be a negative impact if the advise is not followed). >> >> So I'd agree with Scott that this should be "MUST NOT send, MUST ignore >> if received". >> >> Thoughts? >> >> Thanks! >> >> Best regards, > > I wondered on this bit: " If a Source Quench message is received by any other transport- protocol instance (e.g., a UDP-based protocol), it SHOULD be silently ignored." While I agree it's fair to say such behavior is inappropriate for TCP and SCTP, I'm finding it harder to say that a UDP app MUST never respond to a SQ. In the end, I think that from my point of view (no chair hat, etc) there were no good reasons why an arbitrary UDP application program could decide not decide to react to SQ messages. Such an application would need to not care about optimising transmission rate (since a SQ does not really help in choosing a suitable rate, it just provides an indication that it may be good to reduce at this time). However, this could be good enough in a few cases, i.e. an application that really fears it may be hurting others *could* decide abort to abort. That would not really hurt the Internet. It would be good for the application's own safety of course that it checks the conditions under which these messages were received. It would also be reasonable to expect not to receive these from a modern Internet router, if this document does obsolete this. On the other hand, there may be better ways to detect congestion:-). Is this inconsistent or not? Someone help me think. I note Joe's comment on being silent on router sends, or laternatively saying that routers "SHOULD NOT" send. Gorry From hagen@jauu.net Thu Oct 20 13:11:26 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8E011E809D for ; Thu, 20 Oct 2011 13:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSd3HeCCu5jc for ; Thu, 20 Oct 2011 13:11:25 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id C3C0611E8097 for ; Thu, 20 Oct 2011 13:11:25 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 8327EF44129; Thu, 20 Oct 2011 22:11:23 +0200 (CEST) Date: Thu, 20 Oct 2011 22:11:22 +0200 From: Hagen Paul Pfeifer To: Gorry Fairhurst Subject: Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011, Message-ID: <20111020201121.GB3179@nuttenaction> References: <20111018120505.A1537FED737@newdev.eecs.harvard.edu> <9C0A8082-9E2E-4A7A-BC94-805341AAF293@isi.edu> <4EA03997.2080707@gont.com.ar> <4EA05981.9040709@isi.edu> <4EA07BD5.7090701@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA07BD5.7090701@erg.abdn.ac.uk> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:11:26 -0000 * Gorry Fairhurst | 2011-10-20 20:51:49 [+0100]: >While I agree it's fair to say such behavior is inappropriate for TCP >and SCTP, I'm finding it harder to say that a UDP app MUST never >respond to a SQ. > >In the end, I think that from my point of view (no chair hat, etc) >there were no good reasons why an arbitrary UDP application program >could decide not decide to react to SQ messages. Mhh, right. But on the other hand: there is no (suitable) protection for UDP to detect forged SQ messages (e.g. no sequence field). Every instance can forge malicious SQ messages and send to any UDP instance. From a security point of view UDP/UDPLite SHOULD ignore SQ messages too. After consensus on that (I hope that the security aspect is a legitimate aspect too) I am not aware of any transport protocol where SQ makes sense. Hagen From touch@isi.edu Thu Oct 20 14:10:22 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0861F0C3D for ; Thu, 20 Oct 2011 14:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.755 X-Spam-Level: X-Spam-Status: No, score=-102.755 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrsYSajIy1aO for ; Thu, 20 Oct 2011 14:10:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9701F0C43 for ; Thu, 20 Oct 2011 14:10:22 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p9KL9bpL027331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2011 14:09:37 -0700 (PDT) Message-ID: <4EA08E11.7070707@isi.edu> Date: Thu, 20 Oct 2011 14:09:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hagen Paul Pfeifer Subject: Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011, References: <20111018120505.A1537FED737@newdev.eecs.harvard.edu> <9C0A8082-9E2E-4A7A-BC94-805341AAF293@isi.edu> <4EA03997.2080707@gont.com.ar> <4EA05981.9040709@isi.edu> <4EA07BD5.7090701@erg.abdn.ac.uk> <20111020201121.GB3179@nuttenaction> In-Reply-To: <20111020201121.GB3179@nuttenaction> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Gorry Fairhurst , tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 21:10:22 -0000 On 10/20/2011 1:11 PM, Hagen Paul Pfeifer wrote: > * Gorry Fairhurst | 2011-10-20 20:51:49 [+0100]: > >> While I agree it's fair to say such behavior is inappropriate for TCP >> and SCTP, I'm finding it harder to say that a UDP app MUST never >> respond to a SQ. >> >> In the end, I think that from my point of view (no chair hat, etc) >> there were no good reasons why an arbitrary UDP application program >> could decide not decide to react to SQ messages. > > Mhh, right. But on the other hand: there is no (suitable) protection for UDP > to detect forged SQ messages (e.g. no sequence field). That won't help anyway. As with any router messages, there's no rule for how timely the message is, so the sequence number could easily be out of range (or even roll-over) by the time the message is sent. Sequence numbers in ICMP messages communicate NOTHING. > Every instance can > forge malicious SQ messages and send to any UDP instance. From a security > point of view UDP/UDPLite SHOULD ignore SQ messages too. AFAICT, this is the only sensible response. I.e., although SQ-like messages might be more useful to UDP than to other protocols, SQ itself as currently defined is not. > After consensus on that (I hope that the security aspect is a legitimate > aspect too) I am not aware of any transport protocol where SQ makes sense. With the caveat that "SQ as currently spec'd", +1 Joe From hagen@jauu.net Thu Oct 20 14:30:43 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFD421F848A for ; Thu, 20 Oct 2011 14:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zERcjTVfBuM for ; Thu, 20 Oct 2011 14:30:42 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id A714421F8487 for ; Thu, 20 Oct 2011 14:30:42 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id D8577F44129; Thu, 20 Oct 2011 23:30:41 +0200 (CEST) Date: Thu, 20 Oct 2011 23:30:41 +0200 From: Hagen Paul Pfeifer To: Joe Touch Subject: Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011, Message-ID: <20111020213041.GD3179@nuttenaction> References: <20111018120505.A1537FED737@newdev.eecs.harvard.edu> <9C0A8082-9E2E-4A7A-BC94-805341AAF293@isi.edu> <4EA03997.2080707@gont.com.ar> <4EA05981.9040709@isi.edu> <4EA07BD5.7090701@erg.abdn.ac.uk> <20111020201121.GB3179@nuttenaction> <4EA08E11.7070707@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA08E11.7070707@isi.edu> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Gorry Fairhurst , tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 21:30:43 -0000 * Joe Touch | 2011-10-20 14:09:37 [-0700]: >That won't help anyway. As with any router messages, there's no rule >for how timely the message is, so the sequence number could easily be >out of range (or even roll-over) by the time the message is sent. Right Joe, maybe too late ... :) >>Every instance can >>forge malicious SQ messages and send to any UDP instance. From a security >>point of view UDP/UDPLite SHOULD ignore SQ messages too. > >AFAICT, this is the only sensible response. > >I.e., although SQ-like messages might be more useful to UDP than to >other protocols, SQ itself as currently defined is not. > >>After consensus on that (I hope that the security aspect is a legitimate >>aspect too) I am not aware of any transport protocol where SQ makes sense. > >With the caveat that "SQ as currently spec'd", +1 +1 (for the ID) Hagen From jeff.morriss.ws@gmail.com Mon Oct 24 11:39:36 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6D51F0C6B for ; Mon, 24 Oct 2011 11:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGez6NNIZlnh for ; Mon, 24 Oct 2011 11:39:36 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C47A1F0C5B for ; Mon, 24 Oct 2011 11:39:36 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so6195985vcb.31 for ; Mon, 24 Oct 2011 11:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=wG8ieW2No7yIpkViDt2tNznBcytVv3QxHZBwkJbsDnM=; b=or2ahaFjCXGog8HpjABachHe3Ve6n9DIt+qPh5Rf+X/5Mces92ZDGlLQOJ1jE8sMbP x3vs5ixfkjKgvR+rUH553Cv+OdNyIPdEDndGluYNhojopS9hfvfo/65zbtOscnaStFsb 59aqSJnFTzRQjtuRcmB3LaRgUJQUOUlahK5Fo= Received: by 10.52.90.45 with SMTP id bt13mr23616682vdb.25.1319481575771; Mon, 24 Oct 2011 11:39:35 -0700 (PDT) Received: from nj-morriss-test.ulticom.com (pooh.ulticom.com. [208.255.120.2]) by mx.google.com with ESMTPS id be17sm23887212vdc.15.2011.10.24.11.39.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 11:39:34 -0700 (PDT) Message-ID: <4EA5B0E5.5090501@gmail.com> Date: Mon, 24 Oct 2011 14:39:33 -0400 From: Jeff Morriss User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: tsvwg@ietf.org Subject: SCTP Verification Tag: network byte order? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 18:39:37 -0000 Hi list, A pretty trivial question/point: is there any reason that the SCTP Verification Tag must be in network byte order? Since it's an integer (which doesn't appear to have an exception to the "MUST be transmitted in network byte order" clause) it seems the answer is yes, but since it's a random number which is (AFAICS) of significance only to the generator, I don't see why it MUST be so. -Jeff From Michael.Tuexen@lurchi.franken.de Mon Oct 24 12:10:59 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAE521F8B3D for ; Mon, 24 Oct 2011 12:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.922, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5vOpremUsQw for ; Mon, 24 Oct 2011 12:10:59 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 24B0C21F8AFB for ; Mon, 24 Oct 2011 12:10:58 -0700 (PDT) Received: from [192.168.1.200] (p508FBE32.dip.t-dialin.net [80.143.190.50]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B81721C0B461C; Mon, 24 Oct 2011 21:10:56 +0200 (CEST) Subject: Re: SCTP Verification Tag: network byte order? Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4EA5B0E5.5090501@gmail.com> Date: Mon, 24 Oct 2011 21:10:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B64D9E5-92C5-48C6-B10B-4484D90C8D37@lurchi.franken.de> References: <4EA5B0E5.5090501@gmail.com> To: Jeff Morriss X-Mailer: Apple Mail (2.1251.1) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 19:11:00 -0000 On Oct 24, 2011, at 8:39 PM, Jeff Morriss wrote: > Hi list, >=20 > A pretty trivial question/point: is there any reason that the SCTP = Verification Tag must be in network byte order? >=20 > Since it's an integer (which doesn't appear to have an exception to = the "MUST be transmitted in network byte order" clause) it seems the = answer is yes, but since it's a random number which is (AFAICS) of = significance only to the generator, I don't see why it MUST be so. Since the verification tag is not exposed via the socket API, there is = no way whether you sent it in network byte order or not... Best regards Michael >=20 > -Jeff >=20 From cbenson@adax.com Mon Oct 24 12:28:16 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A6411E80C8 for ; Mon, 24 Oct 2011 12:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3bo9sxdzCBn for ; Mon, 24 Oct 2011 12:28:15 -0700 (PDT) Received: from mail1.adax.com (mail1.adax.com [70.36.226.176]) by ietfa.amsl.com (Postfix) with ESMTP id 25FE411E80C7 for ; Mon, 24 Oct 2011 12:28:15 -0700 (PDT) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id C2EEE1E1141; Mon, 24 Oct 2011 12:28:13 -0700 (PDT) Received: by adax (Postfix, from userid 243) id D9AE08EE07; Mon, 24 Oct 2011 12:31:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id D4C2B8EE05; Mon, 24 Oct 2011 12:31:22 -0700 (PDT) Date: Mon, 24 Oct 2011 12:31:22 -0700 (PDT) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Jeff Morriss Subject: Re: SCTP Verification Tag: network byte order? In-Reply-To: <3B64D9E5-92C5-48C6-B10B-4484D90C8D37@lurchi.franken.de> Message-ID: References: <4EA5B0E5.5090501@gmail.com> <3B64D9E5-92C5-48C6-B10B-4484D90C8D37@lurchi.franken.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="808960-1239404909-1319484682=:19656" Cc: =?UTF-8?Q?Michael_T=C3=BCxen?= , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 19:28:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --808960-1239404909-1319484682=:19656 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Jeff (and Michael), The important aspects are only that it is reflected outwards in the same byte sequence "on the wire" as received, and that the round trip verification operates in the same way. From=20the protocol perspective, it is irrelevant how you=20 locally interpret that sequence of four bytes. If it is considered as an ordered sequence of four bytes, then there is no "network byte order" issue. The=20 "random" algorithm that generates a new tag can be considered to include the network byte ordering where necessary, so that the random output is just the four ordered byte values to transmit, reflect, and verify. I thus don't think it matters whether you consider the value to have been rearranged for network byte order or not. Only the "network-byte-order-value" is important. By the way, I don't believe totally random values are=20 acceptable because of the last sentence of RFC 4960 Section 5.3.1: "A new Verification Tag value MUST be used each time the endpoint tears down and then reestablishes an association in the same peer". To me, this implies that the new value must be different from the previous value, which is obviously better for the protocol. Truly random number sequences contain duplicates (or might!). With thanks, from Chris. Chris Benson, Software Engineer, Adax Inc., Oakland, California, USA. cbenson@adax.com +1 510 548-7047 ext. 189 www.adax.com On Mon, 24 Oct 2011, Michael T=C3=83=C2=BCxen wrote: >> Date: Mon, 24 Oct 2011 21:10:52 +0200 >> From: Michael T=C3=83=C2=BCxen >> To: Jeff Morriss >> Cc: >> Subject: Re: SCTP Verification Tag: network byte order? >> =20 >> On Oct 24, 2011, at 8:39 PM, Jeff Morriss wrote: >> =20 >> > Hi list, >> >=20 >> > A pretty trivial question/point: is there any reason that the SCTP Ve= rification Tag must be in network byte order? >> >=20 >> > Since it's an integer (which doesn't appear to have an exception to t= he "MUST be transmitted in network byte order" clause) it seems the answer = is yes, but since it's a random number which is (AFAICS) of significance o= nly to the generator, I don't see why it MUST be so. >> Since the verification tag is not exposed via the socket API, there is = no way whether you >> sent it in network byte order or not... >> =20 >> Best regards >> Michael >> >=20 >> > -Jeff >> >=20 >> =20 --808960-1239404909-1319484682=:19656-- From jeff.morriss.ws@gmail.com Mon Oct 24 12:55:28 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2480311E810B for ; Mon, 24 Oct 2011 12:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gErVvmM5vg+c for ; Mon, 24 Oct 2011 12:55:27 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86DB411E80C4 for ; Mon, 24 Oct 2011 12:55:27 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so6272733vcb.31 for ; Mon, 24 Oct 2011 12:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xkMlF2x3Ce6kdgb/YracsD3ujBg7y8Vicjp/vdo4inM=; b=DU+Cdh487AbQP04M3QH0z0YRzTppAZzUdkllx4o4mCvAalcWB/5VG8HLyg2mmn2blC sPzjsQkRmEbvt9jrUAtCm70UmbAg/o2uOzKlxONsDjqEWGn5reuZuj9/3eyMPC2eBTKu TMwMBkRWNYjvpz2G2ezu5quDq3Hk6vbFSVZ9c= Received: by 10.52.240.131 with SMTP id wa3mr23794806vdc.95.1319486127051; Mon, 24 Oct 2011 12:55:27 -0700 (PDT) Received: from nj-morriss-test.ulticom.com (pooh.ulticom.com. [208.255.120.2]) by mx.google.com with ESMTPS id j4sm11843414vdk.5.2011.10.24.12.55.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 12:55:26 -0700 (PDT) Message-ID: <4EA5C2AD.6080604@gmail.com> Date: Mon, 24 Oct 2011 15:55:25 -0400 From: Jeff Morriss User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= Subject: Re: SCTP Verification Tag: network byte order? References: <4EA5B0E5.5090501@gmail.com> <3B64D9E5-92C5-48C6-B10B-4484D90C8D37@lurchi.franken.de> In-Reply-To: <3B64D9E5-92C5-48C6-B10B-4484D90C8D37@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 19:55:28 -0000 Michael Tüxen wrote: > On Oct 24, 2011, at 8:39 PM, Jeff Morriss wrote: > >> Hi list, >> >> A pretty trivial question/point: is there any reason that the SCTP Verification Tag must be in network byte order? >> >> Since it's an integer (which doesn't appear to have an exception to the "MUST be transmitted in network byte order" clause) it seems the answer is yes, but since it's a random number which is (AFAICS) of significance only to the generator, I don't see why it MUST be so. > Since the verification tag is not exposed via the socket API, there is no way whether you > sent it in network byte order or not... Sorry, I wasn't asking from an SCTP-User's perspective, but from an SCTP implementation perspective. By looking into the implementation (or comparing an implementation's debug output--which includes the vtags--to what is on the wire) I can know whether the local vtag is sent in network byte order or not. From jeff.morriss.ws@gmail.com Mon Oct 24 15:15:46 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69911E81A3 for ; Mon, 24 Oct 2011 15:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkCV0N3o5fOU for ; Mon, 24 Oct 2011 15:15:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D130011E81A2 for ; Mon, 24 Oct 2011 15:15:45 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so6388851vcb.31 for ; Mon, 24 Oct 2011 15:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NhTEPzgw9GnpsNK7qX8yV1ahN+iDca3rJWAwgRYCjHA=; b=VPg9CjioIZkVdUd0w2vaddggdJRcnBlGQVt0b6e1Ocrcays52nF1TUvI1LSO1Zq68b i4TLeIIeXF/RGExm35bs++JLvX9sSzCKa0u+A5BDr3AREshoXNGK6p6kiifRnOS6OIX2 WRt5yx7wDwFKph3jGnbB9465BQ3DtkYpGSdQ4= Received: by 10.220.6.207 with SMTP id a15mr1829956vca.70.1319494541217; Mon, 24 Oct 2011 15:15:41 -0700 (PDT) Received: from nj-morriss-test.ulticom.com (pooh.ulticom.com. [208.255.120.2]) by mx.google.com with ESMTPS id eu4sm15087083vdc.8.2011.10.24.15.15.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 15:15:40 -0700 (PDT) Message-ID: <4EA5E38A.7030309@gmail.com> Date: Mon, 24 Oct 2011 18:15:38 -0400 From: Jeff Morriss User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Chris Benson Subject: Re: SCTP Verification Tag: network byte order? References: <4EA5B0E5.5090501@gmail.com> <3B64D9E5-92C5-48C6-B10B-4484D90C8D37@lurchi.franken.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?TWljaGFlbCBUw7x4ZW4=?= , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 22:15:46 -0000 Chris Benson wrote: > Jeff (and Michael), > > The important aspects are only that it is reflected outwards > in the same byte sequence "on the wire" as received, and > that the round trip verification operates in the same way. > > From the protocol perspective, it is irrelevant how you > locally interpret that sequence of four bytes. If it > is considered as an ordered sequence of four bytes, > then there is no "network byte order" issue. The > "random" algorithm that generates a new tag can be > considered to include the network byte ordering > where necessary, so that the random output is just > the four ordered byte values to transmit, reflect, > and verify. > > I thus don't think it matters whether you consider the > value to have been rearranged for network byte order or not. > Only the "network-byte-order-value" is important. In fact I had been thinking primarily from the side of the vtag generator, but it's doubly true for the vtag receiver/reflector. From dreibh@iem.uni-due.de Mon Oct 24 22:55:59 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45A121F84B3 for ; Mon, 24 Oct 2011 22:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nicZNPGd+hkz for ; Mon, 24 Oct 2011 22:55:58 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id B167E21F84B1 for ; Mon, 24 Oct 2011 22:55:56 -0700 (PDT) Received: from lupo.localnet ([46.115.32.179]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p9P5tnW0017068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Oct 2011 07:55:53 +0200 From: Thomas Dreibholz To: tsvwg@ietf.org Subject: Re: SCTP Verification Tag: network byte order? Date: Tue, 25 Oct 2011 07:55:43 +0200 Message-ID: <7374016.jalx7bqW8v@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.7.2 (Linux/3.0.0-12-generic; KDE/4.7.2; x86_64; ; ) In-Reply-To: <3B64D9E5-92C5-48C6-B10B-4484D90C8D37@lurchi.franken.de> References: <4EA5B0E5.5090501@gmail.com> <3B64D9E5-92C5-48C6-B10B-4484D90C8D37@lurchi.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1441339.IguvDsQPHh"; micalg="pgp-sha1"; protocol="application/pgp-signature" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Cc: Michael =?ISO-8859-1?Q?T=FCxen?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 05:55:59 -0000 --nextPart1441339.IguvDsQPHh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Am Montag 24 Oktober 2011, 21:10:52 schrieb Michael T=FCxen: > On Oct 24, 2011, at 8:39 PM, Jeff Morriss wrote: > > Hi list, > >=20 > > A pretty trivial question/point: is there any reason that the SCTP > > Verification Tag must be in network byte order? > >=20 > > Since it's an integer (which doesn't appear to have an exception to= the > > "MUST be transmitted in network byte order" clause) it seems the an= swer > > is yes, but since it's a random number which is (AFAICS) of > > significance only to the generator, I don't see why it MUST be so. > Since the verification tag is not exposed via the socket API, there i= s no > way whether you sent it in network byte order or not... Yes. However, for debugging purposes, it may be useful to send the verificat= ion tag=20 in network byte order. Tools like Wireshark interpret the verification = tag as=20 32-bit value in network byte order and convert it to host byte order to= =20 display it appropriately. I have also checked the SCTP implementation sources for FreeBSD, Linux = and=20 sctplib. All three implementations convert the verification tag to netw= ork byte=20 order. Best regards --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Thomas Dreibholz University of Duisburg-Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany -----------------------------------------------------------------------= E-Mail: dreibh@iem.uni-due.de Homepage: http://www.iem.uni-due.de/~dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --nextPart1441339.IguvDsQPHh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk6mT18ACgkQ32BbsHYPLWVryACeNb7hCHetolh7rE7vPXKRyK1N dZcAn23l12t9yosIixlhRGU8ycDNxUeA =GPdr -----END PGP SIGNATURE----- --nextPart1441339.IguvDsQPHh-- From randall@lakerest.net Sat Oct 29 06:02:27 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9FA21F886A for ; Sat, 29 Oct 2011 06:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSgYNdotS8hx for ; Sat, 29 Oct 2011 06:02:27 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id BE17A21F87E2 for ; Sat, 29 Oct 2011 06:02:26 -0700 (PDT) Received: from [192.168.0.2] (67-5-125-198.spok.qwest.net [67.5.125.198]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p9TD12h2032264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 29 Oct 2011 09:01:06 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: SCTP Verification Tag: network byte order? Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: Date: Sat, 29 Oct 2011 09:01:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EA5B0E5.5090501@gmail.com> <3B64D9E5-92C5-48C6-B10B-4484D90C8D37@lurchi.franken.de> To: Chris Benson X-Mailer: Apple Mail (2.1251.1) Cc: =?iso-8859-1?Q?Michael_T=FCxen?= , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 13:02:27 -0000 Chris: Comments in-line=85 On Oct 24, 2011, at 3:31 PM, Chris Benson wrote: > Jeff (and Michael), >=20 > The important aspects are only that it is reflected outwards > in the same byte sequence "on the wire" as received, and > that the round trip verification operates in the same way. >=20 > =46rom the protocol perspective, it is irrelevant how you=20 > locally interpret that sequence of four bytes. If it > is considered as an ordered sequence of four bytes, > then there is no "network byte order" issue. The=20 > "random" algorithm that generates a new tag can be > considered to include the network byte ordering > where necessary, so that the random output is just > the four ordered byte values to transmit, reflect, > and verify. >=20 > I thus don't think it matters whether you consider the > value to have been rearranged for network byte order or not. > Only the "network-byte-order-value" is important. Exactly=85 >=20 > By the way, I don't believe totally random values are=20 > acceptable because of the last sentence of RFC 4960 > Section 5.3.1: >=20 > "A new Verification Tag value MUST be used each time the > endpoint tears down and then reestablishes an association > in the same peer". >=20 > To me, this implies that the new value must be different from > the previous value, which is obviously better for the protocol. > Truly random number sequences contain duplicates (or might!). Well actually this is something thats not talked about in the RFC and maybe should have been. In TCP you have something called timed-wait, in SCTP we don't have that concept since a v-tag "protects" us against old packets.. however, you do need to "timed-wait" the vtags themselves. So yes, any good implementation is going to keep a "cache" of recently used vtags and hold them to prevent reuse for 2MSL or so. I know that most implementations do this.. but it is something we failed to point out in the RFC. R >=20 > With thanks, from Chris. >=20 >=20 > Chris Benson, Software Engineer, > Adax Inc., Oakland, California, USA. > cbenson@adax.com > +1 510 548-7047 ext. 189 > www.adax.com >=20 > On Mon, 24 Oct 2011, Michael T=C3=BCxen wrote: >=20 >>> Date: Mon, 24 Oct 2011 21:10:52 +0200 >>> From: Michael T=C3=BCxen >>> To: Jeff Morriss >>> Cc: >>> Subject: Re: SCTP Verification Tag: network byte order? >>>=20 >>> On Oct 24, 2011, at 8:39 PM, Jeff Morriss wrote: >>>=20 >>>> Hi list, >>>>=20 >>>> A pretty trivial question/point: is there any reason that the SCTP = Verification Tag must be in network byte order? >>>>=20 >>>> Since it's an integer (which doesn't appear to have an exception to = the "MUST be transmitted in network byte order" clause) it seems the = answer is yes, but since it's a random number which is (AFAICS) of = significance only to the generator, I don't see why it MUST be so. >>> Since the verification tag is not exposed via the socket API, there = is no way whether you >>> sent it in network byte order or not... >>>=20 >>> Best regards >>> Michael >>>>=20 >>>> -Jeff >>>>=20 ----- Randall Stewart randall@lakerest.net From randall@lakerest.net Sat Oct 29 06:04:26 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A58E21F849E for ; Sat, 29 Oct 2011 06:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSxypTKxUV9i for ; Sat, 29 Oct 2011 06:04:26 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id 058B721F8492 for ; Sat, 29 Oct 2011 06:04:25 -0700 (PDT) Received: from [192.168.0.2] (67-5-125-198.spok.qwest.net [67.5.125.198]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p9TD36eN032291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 29 Oct 2011 09:03:08 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: SCTP Verification Tag: network byte order? Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: <4EA5C2AD.6080604@gmail.com> Date: Sat, 29 Oct 2011 09:03:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2EB3D813-97D6-47F1-AD7C-FCEB787398D9@lakerest.net> References: <4EA5B0E5.5090501@gmail.com> <3B64D9E5-92C5-48C6-B10B-4484D90C8D37@lurchi.franken.de> <4EA5C2AD.6080604@gmail.com> To: Jeff Morriss X-Mailer: Apple Mail (2.1251.1) Cc: =?iso-8859-1?Q?Michael_T=FCxen?= , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 13:04:26 -0000 On Oct 24, 2011, at 3:55 PM, Jeff Morriss wrote: > Michael T=FCxen wrote: >> On Oct 24, 2011, at 8:39 PM, Jeff Morriss wrote: >>> Hi list, >>>=20 >>> A pretty trivial question/point: is there any reason that the SCTP = Verification Tag must be in network byte order? >>>=20 >>> Since it's an integer (which doesn't appear to have an exception to = the "MUST be transmitted in network byte order" clause) it seems the = answer is yes, but since it's a random number which is (AFAICS) of = significance only to the generator, I don't see why it MUST be so. >> Since the verification tag is not exposed via the socket API, there = is no way whether you >> sent it in network byte order or not... >=20 > Sorry, I wasn't asking from an SCTP-User's perspective, but from an = SCTP implementation perspective. By looking into the implementation (or = comparing an implementation's debug output--which includes the vtags--to = what is on the wire) I can know whether the local vtag is sent in = network byte order or not. >=20 Hmm.. but as Chris pointed out=85 if you considered the random number = generator giving you v-tags as one giving you a network-byte order vtag ready to be sent, then you don't = have to do anything. Of course you are welcome to "un-network" it in your debug output and then compare = it to a previous un-networked vtag=85 but as long as the physical 4 bytes are the same on the wire.. = it really does not matter=85 R ----- Randall Stewart randall@lakerest.net From internet-drafts@ietf.org Sat Oct 29 10:33:01 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32FF21F8ABB; Sat, 29 Oct 2011 10:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIeCinOTAQ4v; Sat, 29 Oct 2011 10:33:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783D921F8564; Sat, 29 Oct 2011 10:33:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111029173301.2853.89257.idtracker@ietfa.amsl.com> Date: Sat, 29 Oct 2011 10:33:01 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 17:33:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : UDP Encapsulation of SCTP Packets Author(s) : Michael Tuexen Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-udp-encaps-01.txt Pages : 9 Date : 2011-10-29 This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-udp-encaps-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-udp-encaps-01.txt From dwing@cisco.com Mon Oct 31 13:11:06 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF87321F8DDF for ; Mon, 31 Oct 2011 13:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.514 X-Spam-Level: X-Spam-Status: No, score=-105.514 tagged_above=-999 required=5 tests=[AWL=1.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2lUDl1L5LZD for ; Mon, 31 Oct 2011 13:11:04 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C8ED321F8DDD for ; Mon, 31 Oct 2011 13:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=720; q=dns/txt; s=iport; t=1320091858; x=1321301458; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=WJm/HFzKf7tuJGqVyaVrXWCTrHSSQdW/jzeEK0v6P8I=; b=AP5H4TgpakFIx89+bKwP5fBDTmbrC64eE9FUd1lrjgWJ/VvWviQetBCT e/XNIy16T/YvQskVdKllUDtLIhu8Y1qrtftfH1SjZJcaMQZaejolJpmY/ yUkrTWduX4YDPd/bgh4Pupd7yEF9Ae/hTYos3Race8BUom+VOzeZDjCBo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFALoAr06rRDoI/2dsb2JhbABEm06NaIEFgXkICgEXEEwFGFAjHAEEAR0Xh2iVUAGeP4kCBIgGngc X-IronPort-AV: E=Sophos;i="4.69,434,1315180800"; d="scan'208";a="11490730" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 31 Oct 2011 20:10:50 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9VKAoXP011603; Mon, 31 Oct 2011 20:10:50 GMT From: "Dan Wing" To: , "'Michael Tuexen'" , Subject: SCTP-over-UDP and port 9899 Date: Mon, 31 Oct 2011 13:10:51 -0700 Message-ID: <193601cc9809$2ffa6b50$8fef41f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyYCS+hu+pmIlMsTRy0MExRcxu1Lw== Content-Language: en-us X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:11:06 -0000 http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-01 and its predecessor both say: "When inserting the UDP header, the source port is 9899, the destination port is the one stored for the destination address the packet is sent to or 9899 if no destination address is stored." Why is it important to use a specific source port? Does that not cause difficulties if there are two (or more) instances of SCTP- over-UDP applications running on the same host? Does that not cause difficulties, in implementation assumptions, if there are two hosts behind the same NAPT and only one can get UDP/9899 forwarded to them? In short, what is the benefit of using 9899 as the source port? -d From tuexen@fh-muenster.de Mon Oct 31 14:27:03 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA221F0C7E for ; Mon, 31 Oct 2011 14:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln9ufOITRHuX for ; Mon, 31 Oct 2011 14:27:02 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8891F0C7A for ; Mon, 31 Oct 2011 14:27:02 -0700 (PDT) Received: from [192.168.1.200] (p508FC512.dip.t-dialin.net [80.143.197.18]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5ECE11C0C0BD9; Mon, 31 Oct 2011 22:27:01 +0100 (CET) Subject: Re: SCTP-over-UDP and port 9899 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <193601cc9809$2ffa6b50$8fef41f0$@com> Date: Mon, 31 Oct 2011 22:27:00 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <193601cc9809$2ffa6b50$8fef41f0$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1251.1) Cc: tsvwg@ietf.org, randall@lakerest.net X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:27:03 -0000 On Oct 31, 2011, at 9:10 PM, Dan Wing wrote: > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-01 and its > predecessor both say: > > "When inserting the UDP header, the source port is 9899, the > destination port is the one stored for the destination address the > packet is sent to or 9899 if no destination address is stored." > > Why is it important to use a specific source port? Does that not > cause difficulties if there are two (or more) instances of SCTP- > over-UDP applications running on the same host? Does that not > cause difficulties, in implementation assumptions, if there are > two hosts behind the same NAPT and only one can get UDP/9899 > forwarded to them? Hi Dan, for sending out the initial packet of an association, the source port is not important. The peer will send back the response to any port. But the destination port of the initial packet is important. It must be the same port the peer is accepting UDP packets. It can be any port, but then it needs to be negotiated somehow. Since there is one registered port for SCTP/UDP, I used that. But you can use a different one, if negotiated. If you want to run two hosts as servers behind a NAT, you need different UDP ports. If they are clients, you don't. > > In short, what is the benefit of using 9899 as the source port? It is more a default, if nothing else is known. In the socketAPI section the remote port is configurable. The local port (at least in the FreeBSD/MacOS X implementation) is a parameter controller by a sysctl variable. So (currently) a single host uses a single port number for all associations. Does this makes things clearer? Best regards Michael > > -d > > > From internet-drafts@ietf.org Mon Oct 31 16:48:23 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1A91F0DA3; Mon, 31 Oct 2011 16:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMB7odduTWTw; Mon, 31 Oct 2011 16:48:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D861F0D9E; Mon, 31 Oct 2011 16:48:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-byte-pkt-congest-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031234823.8045.47616.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:48:23 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:48:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Byte and Packet Congestion Notification Author(s) : Bob Briscoe Jukka Manner Filename : draft-ietf-tsvwg-byte-pkt-congest-05.txt Pages : 43 Date : 2011-10-31 This memo concerns dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre- congestion notification (PCN). We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-05.txt From bob.briscoe@bt.com Mon Oct 31 16:59:28 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F9621F8EC5 for ; Mon, 31 Oct 2011 16:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1eSwqQJCshu for ; Mon, 31 Oct 2011 16:59:27 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 68B2621F863E for ; Mon, 31 Oct 2011 16:59:24 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 23:59:23 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 23:59:23 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1320105563871; Mon, 31 Oct 2011 23:59:23 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.80.13]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p9VNxITn006610; Mon, 31 Oct 2011 23:59:19 GMT Message-Id: <201110312359.p9VNxITn006610@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 31 Oct 2011 23:59:16 +0000 To: Gorry Fairhurst , "BLACK, David" , Fred Baker , "EARDLEY, Phil" From: Bob Briscoe Subject: Fwd: New Version Notification for draft-ietf-tsvwg-byte-pkt-congest-05.txt In-Reply-To: <20111031234823.8045.79519.idtracker@ietfa.amsl.com> References: <20111031234823.8045.79519.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 31 Oct 2011 23:59:23.0289 (UTC) FILETIME=[1CE71890:01CC9829] Cc: tsvwg IETF list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:59:28 -0000 Gorry, David, Phil & Fred, Thank you all for your reviews. I'm very happy with the doc now. We've made considerable changes as a result of your comments, in particular completely re-writing a couple of the motivations for the recommendations. If you get a chance, we'd appreciate re-reviewing just the changed motivation sub-sections, if nothing else. Here's the summary of the changes: From -04 to -05: * Changed from Informational to BCP and highlighted non-normative sections and appendices * Removed language about consensus * Added "Example Comparing Packet-Mode Drop and Byte-Mode Drop" * Arranged "Motivating Arguments" into a more logical order and completely rewrote "Transport-Independent Network" & "Scaling Congestion Control with Packet Size" arguments. Removed "Why Now?" * Clarified applicability of certain recommendations * Shifted vendor survey to an Appendix * Cut down "Outstanding Issues and Next Steps" * Re-drafted the start of the conclusions to highlight the three distinct areas of concern * Completely re-wrote appendices * Editorial corrections throughout. Bob At 23:48 31/10/2011, internet-drafts@ietf.org wrote: >A new version of I-D, draft-ietf-tsvwg-byte-pkt-congest-05.txt has >been successfully submitted by Bob Briscoe and posted to the IETF repository. > >Filename: draft-ietf-tsvwg-byte-pkt-congest >Revision: 05 >Title: Byte and Packet Congestion Notification >Creation date: 2011-10-31 >WG ID: tsvwg >Number of pages: 43 > >Abstract: > This memo concerns dropping or marking packets using active queue > management (AQM) such as random early detection (RED) or pre- > congestion notification (PCN). We give three strong recommendations: > (1) packet size should be taken into account when transports read and > respond to congestion indications, (2) packet size should not be > taken into account when network equipment creates congestion signals > (marking, dropping), and therefore (3) the byte-mode packet drop > variant of the RED AQM algorithm that drops fewer small packets > should not be used. > > > > > >The IETF Secretariat ________________________________________________________________ Bob Briscoe, BT Innovate & Design From wwwrun@rfc-editor.org Mon Oct 31 21:57:02 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F7621F8EF7; Mon, 31 Oct 2011 21:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.646 X-Spam-Level: X-Spam-Status: No, score=-103.646 tagged_above=-999 required=5 tests=[AWL=1.431, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcib5PWeR9jE; Mon, 31 Oct 2011 21:57:00 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3868521F8EFE; Mon, 31 Oct 2011 21:57:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 068A0B1E00D; Mon, 31 Oct 2011 21:52:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6401 on RSVP Extensions for Admission Priority From: rfc-editor@rfc-editor.org Message-Id: <20111101045242.068A0B1E00D@rfc-editor.org> Date: Mon, 31 Oct 2011 21:52:42 -0700 (PDT) Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 04:57:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6401 Title: RSVP Extensions for Admission Priority Author: F. Le Faucheur, J. Polk, K. Carlberg Status: Standards Track Stream: IETF Date: October 2011 Mailbox: flefauch@cisco.com, jmpolk@cisco.com, carlberg@g11.org.uk Pages: 32 Characters: 72343 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-emergency-rsvp-15.txt URL: http://www.rfc-editor.org/rfc/rfc6401.txt Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer. Based on current security concerns, these extensions are intended for use in a single administrative domain. [STANDARDS-TRACK] This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Oct 31 22:09:56 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1121F8E17; Mon, 31 Oct 2011 22:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.895 X-Spam-Level: X-Spam-Status: No, score=-101.895 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohFXc3R74-oE; Mon, 31 Oct 2011 22:09:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC6D21F8E15; Mon, 31 Oct 2011 22:09:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 50922B1E009; Mon, 31 Oct 2011 21:52:53 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6411 on Applicability of Keying Methods for RSVP Security From: rfc-editor@rfc-editor.org Message-Id: <20111101045253.50922B1E009@rfc-editor.org> Date: Mon, 31 Oct 2011 21:52:53 -0700 (PDT) Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 05:09:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6411 Title: Applicability of Keying Methods for RSVP Security Author: M. Behringer, F. Le Faucheur, B. Weis Status: Informational Stream: IETF Date: October 2011 Mailbox: mbehring@cisco.com, flefauch@cisco.com, bew@cisco.com Pages: 19 Characters: 46072 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-rsvp-security-groupkeying-11.txt URL: http://www.rfc-editor.org/rfc/rfc6411.txt The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. This document also discusses applicability of encrypting RSVP messages. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Transport Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC