From nobody Thu May 8 04:04:07 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A2B1A0299 for ; Thu, 8 May 2014 04:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVLocLJAPuy5 for ; Thu, 8 May 2014 04:04:02 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8EC1A0188 for ; Thu, 8 May 2014 04:04:02 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 206042B452E; Thu, 8 May 2014 12:03:57 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 46E162B43B3 for ; Thu, 8 May 2014 12:03:56 +0100 (BST) Message-ID: <536B649C.2070302@erg.abdn.ac.uk> Date: Thu, 08 May 2014 12:03:56 +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:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tsvwg WG References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/MoUZ9XWiF4-brI08BhyJSNttNrc Subject: [tsvwg] Circuit Breakers - draft-fairhurst-tsvwg-circuit-breaker-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 11:04:04 -0000 TSVWG, Last IETF meeting, there was much discussion on when/where a circuit breaker function may be needed and what form it could take to protect the transport service. I've written the draft below, and would appreciate comments and feedback about using this as a starting point. best wishes Gorry -------------------------------------------------------------------------- A new version of I-D, draft-fairhurst-tsvwg-circuit-breaker-01.txt has been successfully submitted by Godred Fairhurst and posted to the IETF repository. Name: draft-fairhurst-tsvwg-circuit-breaker Revision: 01 Title: Network Transport Circuit Breakers Document date: 2014-05-05 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg-circuit-breaker-01.txt Status: https://datatracker.ietf.org/doc/draft-fairhurst-tsvwg-circuit-breaker/ Htmlized: http://tools.ietf.org/html/draft-fairhurst-tsvwg-circuit-breaker-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-fairhurst-tsvwg-circuit-breaker-01 Abstract: This note explains what is meant by the term "network transport circuit breaker" (CB). It describes the needs for circuit breakers when using network tunnels, and other non-congestion controlled applications. It defines requirements for building a circuit breaker and the expected outcomes of using a circuit breaker within the Internet. From nobody Sun May 11 14:45:23 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEABA1A037B for ; Sun, 11 May 2014 14:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBf28XCHOV9U for ; Sun, 11 May 2014 14:45:19 -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 F42101A0375 for ; Sun, 11 May 2014 14:45:18 -0700 (PDT) Received: from [192.168.1.200] (p508F2564.dip0.t-ipconnect.de [80.143.37.100]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D62DB1C0B3F66; Sun, 11 May 2014 23:45:09 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <53515469.3010703@isi.edu> Date: Sun, 11 May 2014 23:45:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E12C59B-6F68-46CA-81EE-270122677E65@lurchi.franken.de> References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> <53457BA3.5030707@isi.edu> <5345BD4F.5070007@isi.edu> <35E3EA2E-46C7-40C0-8AEA-4B5C4B3FF901@lurchi.franken.de> <535061C5.3030206@isi.edu> <6C98A0A7-4727-4B53-A78B-186AEAAF15D1@lurchi.franken.de> <53515469.3010703@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/mNK3BtjfHltj3_U9x7_Qr9sX3Nw Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 21:45:22 -0000 On 18 Apr 2014, at 18:35, Joe Touch wrote: > Cutting down a bit... Thanks a lot, sorry for the delay. See me comments in-line. Best regards Michael >=20 > On 4/18/2014 4:39 AM, Michael Tuexen wrote: > ... >>>> That is why we write in this document that when you run SCTP over = DTLS >>>> as defined in this document, you MUST use the PLMTUD. >>>=20 >>> At the DTLS layer. > > >> Either at the DTLS layer or at the SCTP layer. >=20 > How would an implementer know what to do per se? If they built this = using userland SCTP, which they could AFAICT, they might not know. >=20 > IMO, that means you should say something more like: >=20 > - if you know, it can be at either layer > - one layer MUST do it Based on discussions, my current text reads : 4. General Considerations An implementation of SCTP over DTLS MUST implement and use a path maximum transmission unit (MTU) discovery method that functions without ICMP to provide SCTP/DTLS with an MTU estimate. An implementation of "Packetization Layer Path MTU Discovery" [RFC4821] either in SCTP or DTLS is RECOMMENDED. Doesn't this address your comment? Please note that http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-08 states that the PMTUD is done by SCTP when SCTP over DTLS is used for data channels. Maybe I should resubmit my current version such that we have the same document to discuss? There have been some changes based on discussions... What do you think? This would not imply that I don't want to address the still open points, just to make the discussion easier. >=20 >>>> So this document >>>> mandates what to do, it refers to other specs how to do it, but the >>>> other documents don't mandate it. >>>> Isn't that a valid way of doing it? >>>=20 >>> The way you describe it in Sec 4 is (emphasis mine): >>>=20 >>> If path MTU discovery is performed by the *DTLS* layer, the method >>> described in [RFC4821] MUST be used. >>>=20 >>> But RFC4821 doesn't talk about DTLS. That's what's confusing me. It = only talks about SCTP, and gives two methods - one using pads and one at = the user level (like TCP). >>>=20 >>> For probe packets, the >>> extension defined in [RFC6520] MUST be used. >>>=20 >>> Now you're back to talking about DTLS. > > >> Have a look at >> https://tools.ietf.org/html/rfc4821#section-10.4 >> Since DTLS is running on top of UDP, it qualifies as an >> application in the sense of that section, I think. >> In the second paragraph it talks about packets similar >> to SCTP HB plus PAD. This is exactly what is described in >> https://tools.ietf.org/html/rfc6520#section-4 >=20 > That's far too vague to qualify as a "method" that you can tie to a = MUST, IMO. I would expect that your doc ought to give the needed = details, "inspired" by 4821. By repeating the text of RFC 4821? >=20 >>> I think what you might want to say is that: >>>=20 >>> If path MTU discovery is performed by the DTLS layer, the method >>> described in [RFC4821] as for SCTP using a PAD in the extension >>> described in [RFC6520] MUST be used. > > >> OK. I'm fine with that text. >=20 > You might need a little more (not sure; I'll let the SCTP folks = decide). I just don't know if that's enough detail to qualify as a = standards requirement. I think that is enough... >=20 >>> --- >>>=20 >>> If path MTU discovery is performed by the *SCTP* layer and IPv4 is = used >>> as the network layer protocol, the DTLS implementation MUST allow = the >>> DTLS user to enforce that the corresponding IPv4 packet is sent = with >>> the DF bit set. >>>=20 >>> Now I don't know where to do discovery - in DTLS or SCTP. That's not = a mandate; that's two alternatives. > > >> Since it is "performed by the SCTP layer", SCTP is sending the probe = packets. It usea >> the ones defined in http://tools.ietf.org/html/rfc4820. However, the = requirement for >> the DTLS layer is to expose the control of the DF bit. >> Any suggestion how to make that clearer? >=20 > As noted above: >=20 > a) say "do X or Y, but you MUST do one of these" >=20 > b) give the details a little more of how to do things in either case. Hmm. I'm not sure what is missing compared to https://tools.ietf.org/html/rfc4821#section-10.2 and https://tools.ietf.org/html/rfc4821#section-10.4 >=20 > ... >>>> What I don't understand: >>>> * A compressed message can be larger than the original = uncompressed. So it won't fit. >>>=20 >>> Then your compression is broken. A compressed message should never = be larger than uncompressed - ever. > > >> Really? If you present some random data, the compression won't give = you anything (there >> is no redundancy). Some compression algorithms add an overhead. So = the compressed message would >> be larger. Or am I wrong? >=20 > That's a really bad compression algorithm. A reasonable one should = leave things alone (with no overhead) if it can't make things better. Hmm. Possible. But=20 http://tools.ietf.org/html/rfc5246#section-6.2.2 contains in the second paragraph: Compression must be lossless and may not increase the content length by more than 1024 bytes. So at least at the specification level, the above is explicitly covered. >>>> * If SCTP sends the probe packets, doesn't this mean that the probe = packets >>>> must bypass compression? >>>=20 >>> At the SCTP layer; SCTP can't force lower layers to bypass = compression. > > >> Correct. >> So assume SCTP send probe packets and the padding is constant data. = So it is highly >> compressible. Wouldn't SCTP then conclude that you can send a large = message without >> fragmentation? If SCTP takes that as the PMTU, it would fragment user = messages for >> that boundary, compression might not be as efficient and you would = need IP fragmentation. >=20 > PMTUD is supposed to tell you when a segment of a given size at a = given layer *can get there*. If it gets there, then the MTU is valid. I agree. >=20 > E.g., PMTUD won't tell you that ATM has 53-byte cells with 48-byte = payloads either. I agree. But I don't get the point... >=20 > ... >>>> I don't think we can define a DTLS API in TSVWG... At least this is = not in the scope >>>> of this document. >>>=20 >>> Sure, but then you're stuck with SCTP only assuming it can >>> interact with DTLS as if it were a DTLS user. DTLS users can't set = DF. > > >> Why? It depends on the implementation of DTLS... >=20 > Then you can't require it in a standards doc. Hmm. Then we can't deal with PMTUD at all... I would like to tell people = what to do if the implementation allows it... >=20 > Joe >=20 From nobody Mon May 12 09:25:12 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0D51A0765 for ; Mon, 12 May 2014 09:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UaVWxt9thcC for ; Mon, 12 May 2014 09:24:55 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D26FE1A0732 for ; Mon, 12 May 2014 09:24:44 -0700 (PDT) Received: from [10.133.205.183] (UAPublic-35.guest.arizona.edu [206.207.225.35]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4CGOJfw020461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 May 2014 09:24:22 -0700 (PDT) Message-ID: <5370F5B3.6020601@isi.edu> Date: Mon, 12 May 2014 09:24:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Tuexen References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> <53457BA3.5030707@isi.edu> <5345BD4F.5070007@isi.edu> <35E3EA2E-46C7-40C0-8AEA-4B5C4B3FF901@lurchi.franken.de> <535061C5.3030206@isi.edu> <6C98A0A7-4727-4B53-A78B-186AEAAF15D1@lurchi.franken.de> <53515469.3010703@isi.edu> <8E12C59B-6F68-46CA-81EE-270122677E65@lurchi.franken.de> In-Reply-To: <8E12C59B-6F68-46CA-81EE-270122677E65@lurchi.franken.de> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/XgyB1k87c2fUAIPVDICjFI659R4 Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 16:25:00 -0000 It might be useful to see the updated document at this point. I think the bottom line is the conclusion point below - this doc needs to be careful about what it requires/assumes from other layers, and if it's implementation-dependent, present the approach as "SHOULD, where implementations permit" and address what to do when this is not the case. Joe On 5/11/2014 2:45 PM, Michael Tuexen wrote: > On 18 Apr 2014, at 18:35, Joe Touch wrote: > >> Cutting down a bit... > Thanks a lot, sorry for the delay. See me comments in-line. > > Best regards > Michael >> >> On 4/18/2014 4:39 AM, Michael Tuexen wrote: >> ... >>>>> That is why we write in this document that when you run SCTP over DTLS >>>>> as defined in this document, you MUST use the PLMTUD. >>>> >>>> At the DTLS layer. >>> >>> Either at the DTLS layer or at the SCTP layer. >> >> How would an implementer know what to do per se? If they built this using userland SCTP, which they could AFAICT, they might not know. >> >> IMO, that means you should say something more like: >> >> - if you know, it can be at either layer >> - one layer MUST do it > Based on discussions, my current text reads : > > 4. General Considerations > > An implementation of SCTP over DTLS MUST implement and use a path > maximum transmission unit (MTU) discovery method that functions > without ICMP to provide SCTP/DTLS with an MTU estimate. An > implementation of "Packetization Layer Path MTU Discovery" [RFC4821] > either in SCTP or DTLS is RECOMMENDED. > > Doesn't this address your comment? > > Please note that > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-08 > states that the PMTUD is done by SCTP when SCTP over DTLS is used > for data channels. > > Maybe I should resubmit my current version such that we have the > same document to discuss? There have been some changes based on > discussions... What do you think? This would not imply that > I don't want to address the still open points, just to make the > discussion easier. >> >>>>> So this document >>>>> mandates what to do, it refers to other specs how to do it, but the >>>>> other documents don't mandate it. >>>>> Isn't that a valid way of doing it? >>>> >>>> The way you describe it in Sec 4 is (emphasis mine): >>>> >>>> If path MTU discovery is performed by the *DTLS* layer, the method >>>> described in [RFC4821] MUST be used. >>>> >>>> But RFC4821 doesn't talk about DTLS. That's what's confusing me. It only talks about SCTP, and gives two methods - one using pads and one at the user level (like TCP). >>>> >>>> For probe packets, the >>>> extension defined in [RFC6520] MUST be used. >>>> >>>> Now you're back to talking about DTLS. >>> >>> Have a look at >>> https://tools.ietf.org/html/rfc4821#section-10.4 >>> Since DTLS is running on top of UDP, it qualifies as an >>> application in the sense of that section, I think. >>> In the second paragraph it talks about packets similar >>> to SCTP HB plus PAD. This is exactly what is described in >>> https://tools.ietf.org/html/rfc6520#section-4 >> >> That's far too vague to qualify as a "method" that you can tie to a MUST, IMO. I would expect that your doc ought to give the needed details, "inspired" by 4821. > By repeating the text of RFC 4821? >> >>>> I think what you might want to say is that: >>>> >>>> If path MTU discovery is performed by the DTLS layer, the method >>>> described in [RFC4821] as for SCTP using a PAD in the extension >>>> described in [RFC6520] MUST be used. >>> >>> OK. I'm fine with that text. >> >> You might need a little more (not sure; I'll let the SCTP folks decide). I just don't know if that's enough detail to qualify as a standards requirement. > I think that is enough... >> >>>> --- >>>> >>>> If path MTU discovery is performed by the *SCTP* layer and IPv4 is used >>>> as the network layer protocol, the DTLS implementation MUST allow the >>>> DTLS user to enforce that the corresponding IPv4 packet is sent with >>>> the DF bit set. >>>> >>>> Now I don't know where to do discovery - in DTLS or SCTP. That's not a mandate; that's two alternatives. >>> >>> Since it is "performed by the SCTP layer", SCTP is sending the probe packets. It usea >>> the ones defined in http://tools.ietf.org/html/rfc4820. However, the requirement for >>> the DTLS layer is to expose the control of the DF bit. >>> Any suggestion how to make that clearer? >> >> As noted above: >> >> a) say "do X or Y, but you MUST do one of these" >> >> b) give the details a little more of how to do things in either case. > Hmm. I'm not sure what is missing compared to > https://tools.ietf.org/html/rfc4821#section-10.2 > and > https://tools.ietf.org/html/rfc4821#section-10.4 >> >> ... >>>>> What I don't understand: >>>>> * A compressed message can be larger than the original uncompressed. So it won't fit. >>>> >>>> Then your compression is broken. A compressed message should never be larger than uncompressed - ever. >>> >>> Really? If you present some random data, the compression won't give you anything (there >>> is no redundancy). Some compression algorithms add an overhead. So the compressed message would >>> be larger. Or am I wrong? >> >> That's a really bad compression algorithm. A reasonable one should leave things alone (with no overhead) if it can't make things better. > Hmm. Possible. But > http://tools.ietf.org/html/rfc5246#section-6.2.2 > contains in the second paragraph: > Compression must be lossless and may not increase the content length > by more than 1024 bytes. > So at least at the specification level, the above is explicitly covered. >>>>> * If SCTP sends the probe packets, doesn't this mean that the probe packets >>>>> must bypass compression? >>>> >>>> At the SCTP layer; SCTP can't force lower layers to bypass compression. >>> >>> Correct. >>> So assume SCTP send probe packets and the padding is constant data. So it is highly >>> compressible. Wouldn't SCTP then conclude that you can send a large message without >>> fragmentation? If SCTP takes that as the PMTU, it would fragment user messages for >>> that boundary, compression might not be as efficient and you would need IP fragmentation. >> >> PMTUD is supposed to tell you when a segment of a given size at a given layer *can get there*. If it gets there, then the MTU is valid. > I agree. >> >> E.g., PMTUD won't tell you that ATM has 53-byte cells with 48-byte payloads either. > I agree. But I don't get the point... >> >> ... >>>>> I don't think we can define a DTLS API in TSVWG... At least this is not in the scope >>>>> of this document. >>>> >>>> Sure, but then you're stuck with SCTP only assuming it can >>>> interact with DTLS as if it were a DTLS user. DTLS users can't set DF. >>> >>> Why? It depends on the implementation of DTLS... >> >> Then you can't require it in a standards doc. > Hmm. Then we can't deal with PMTUD at all... I would like to tell people what to > do if the implementation allows it... >> >> Joe >> > From nobody Tue May 13 02:01:31 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FC31A0455; Tue, 13 May 2014 02:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfxnLdv_BhE7; Tue, 13 May 2014 02:01:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D26F1A018F; Tue, 13 May 2014 02:01:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140513090128.28963.83421.idtracker@ietfa.amsl.com> Date: Tue, 13 May 2014 02:01:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/qFejqt53jkjB2wOL6oxiFclLdKU Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 09:01:30 -0000 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. Title : DTLS Encapsulation of SCTP Packets Authors : Michael Tuexen Randall R. Stewart Randell Jesup Salvatore Loreto Filename : draft-ietf-tsvwg-sctp-dtls-encaps-04.txt Pages : 8 Date : 2014-05-13 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using encapsulation method described in this document, SCTP is agnostic about the protocols being used below DTLS, explicit IP addresses can not be used in the SCTP control chunks. As a consequence, the SCTP associations are single homed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-dtls-encaps-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 13 02:05:25 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A581A0887 for ; Tue, 13 May 2014 02:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWvb_qYlganz for ; Tue, 13 May 2014 02:05:22 -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 C48021A0884 for ; Tue, 13 May 2014 02:05:21 -0700 (PDT) Received: from [192.168.1.200] (p54819945.dip0.t-ipconnect.de [84.129.153.69]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 8C6241C10491E; Tue, 13 May 2014 11:05:14 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <5370F5B3.6020601@isi.edu> Date: Tue, 13 May 2014 11:05:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7326D2FB-B5BE-4AE6-8715-F67D3B5AC33B@lurchi.franken.de> References: <53190AEC.2010209@isi.edu> <625217B1-E56E-48B4-9E1F-B5A8E13C5034@lurchi.franken.de> <53444401.9030905@isi.edu> <146DE290-E6FA-4719-BE2C-EDCDF9FA6904@lurchi.franken.de> <53445AEE.9070303@isi.edu> <1FC35FE3-5891-4B79-97BF-1603CCF67692@lurchi.franken.de> <53457BA3.5030707@isi.edu> <5345BD4F.5070007@isi.edu> <35E3EA2E-46C7-40C0-8AEA-4B5C4B3FF901@lurchi.franken.de> <535061C5.3030206@isi.edu> <6C98A0A7-4727-4B53-A78B-186AEAAF15D1@lurchi.franken.de> <53515469.3010703@isi.edu> <8E12C59B-6F68-46CA-81EE-270122677E65@lurchi.franken.de> <5370F5B3.6020601@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/-P6-WSAjoqCSZSc7Q8ZnKtCka4A Cc: tsvwg WG Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 09:05:24 -0000 On 12 May 2014, at 18:24, Joe Touch wrote: > It might be useful to see the updated document at this point. OK, I resubmitted the document. >=20 > I think the bottom line is the conclusion point below - this doc needs = to be careful about what it requires/assumes from other layers, and if = it's implementation-dependent, present the approach as "SHOULD, where = implementations permit" and address what to do when this is not the = case. I agree with this high level point. I think we can reach that. Please have a look at the updated document and provide feedback where = this goal is not met yet. Best regards Michael >=20 > Joe >=20 > On 5/11/2014 2:45 PM, Michael Tuexen wrote: >> On 18 Apr 2014, at 18:35, Joe Touch wrote: >>=20 >>> Cutting down a bit... >> Thanks a lot, sorry for the delay. See me comments in-line. >>=20 >> Best regards >> Michael >>>=20 >>> On 4/18/2014 4:39 AM, Michael Tuexen wrote: >>> ... >>>>>> That is why we write in this document that when you run SCTP over = DTLS >>>>>> as defined in this document, you MUST use the PLMTUD. >>>>>=20 >>>>> At the DTLS layer. >>>>=20 >>>> Either at the DTLS layer or at the SCTP layer. >>>=20 >>> How would an implementer know what to do per se? If they built this = using userland SCTP, which they could AFAICT, they might not know. >>>=20 >>> IMO, that means you should say something more like: >>>=20 >>> - if you know, it can be at either layer >>> - one layer MUST do it >> Based on discussions, my current text reads : >>=20 >> 4. General Considerations >>=20 >> An implementation of SCTP over DTLS MUST implement and use a path >> maximum transmission unit (MTU) discovery method that functions >> without ICMP to provide SCTP/DTLS with an MTU estimate. An >> implementation of "Packetization Layer Path MTU Discovery" = [RFC4821] >> either in SCTP or DTLS is RECOMMENDED. >>=20 >> Doesn't this address your comment? >>=20 >> Please note that >> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-08 >> states that the PMTUD is done by SCTP when SCTP over DTLS is used >> for data channels. >>=20 >> Maybe I should resubmit my current version such that we have the >> same document to discuss? There have been some changes based on >> discussions... What do you think? This would not imply that >> I don't want to address the still open points, just to make the >> discussion easier. >>>=20 >>>>>> So this document >>>>>> mandates what to do, it refers to other specs how to do it, but = the >>>>>> other documents don't mandate it. >>>>>> Isn't that a valid way of doing it? >>>>>=20 >>>>> The way you describe it in Sec 4 is (emphasis mine): >>>>>=20 >>>>> If path MTU discovery is performed by the *DTLS* layer, the = method >>>>> described in [RFC4821] MUST be used. >>>>>=20 >>>>> But RFC4821 doesn't talk about DTLS. That's what's confusing me. = It only talks about SCTP, and gives two methods - one using pads and one = at the user level (like TCP). >>>>>=20 >>>>> For probe packets, the >>>>> extension defined in [RFC6520] MUST be used. >>>>>=20 >>>>> Now you're back to talking about DTLS. >>>>=20 >>>> Have a look at >>>> https://tools.ietf.org/html/rfc4821#section-10.4 >>>> Since DTLS is running on top of UDP, it qualifies as an >>>> application in the sense of that section, I think. >>>> In the second paragraph it talks about packets similar >>>> to SCTP HB plus PAD. This is exactly what is described in >>>> https://tools.ietf.org/html/rfc6520#section-4 >>>=20 >>> That's far too vague to qualify as a "method" that you can tie to a = MUST, IMO. I would expect that your doc ought to give the needed = details, "inspired" by 4821. >> By repeating the text of RFC 4821? >>>=20 >>>>> I think what you might want to say is that: >>>>>=20 >>>>> If path MTU discovery is performed by the DTLS layer, the method >>>>> described in [RFC4821] as for SCTP using a PAD in the extension >>>>> described in [RFC6520] MUST be used. >>>>=20 >>>> OK. I'm fine with that text. >>>=20 >>> You might need a little more (not sure; I'll let the SCTP folks = decide). I just don't know if that's enough detail to qualify as a = standards requirement. >> I think that is enough... >>>=20 >>>>> --- >>>>>=20 >>>>> If path MTU discovery is performed by the *SCTP* layer and IPv4 = is used >>>>> as the network layer protocol, the DTLS implementation MUST = allow the >>>>> DTLS user to enforce that the corresponding IPv4 packet is sent = with >>>>> the DF bit set. >>>>>=20 >>>>> Now I don't know where to do discovery - in DTLS or SCTP. That's = not a mandate; that's two alternatives. >>>>=20 >>>> Since it is "performed by the SCTP layer", SCTP is sending the = probe packets. It usea >>>> the ones defined in http://tools.ietf.org/html/rfc4820. However, = the requirement for >>>> the DTLS layer is to expose the control of the DF bit. >>>> Any suggestion how to make that clearer? >>>=20 >>> As noted above: >>>=20 >>> a) say "do X or Y, but you MUST do one of these" >>>=20 >>> b) give the details a little more of how to do things in either = case. >> Hmm. I'm not sure what is missing compared to >> https://tools.ietf.org/html/rfc4821#section-10.2 >> and >> https://tools.ietf.org/html/rfc4821#section-10.4 >>>=20 >>> ... >>>>>> What I don't understand: >>>>>> * A compressed message can be larger than the original = uncompressed. So it won't fit. >>>>>=20 >>>>> Then your compression is broken. A compressed message should never = be larger than uncompressed - ever. >>>>=20 >>>> Really? If you present some random data, the compression won't give = you anything (there >>>> is no redundancy). Some compression algorithms add an overhead. So = the compressed message would >>>> be larger. Or am I wrong? >>>=20 >>> That's a really bad compression algorithm. A reasonable one should = leave things alone (with no overhead) if it can't make things better. >> Hmm. Possible. But >> http://tools.ietf.org/html/rfc5246#section-6.2.2 >> contains in the second paragraph: >> Compression must be lossless and may not increase the content length >> by more than 1024 bytes. >> So at least at the specification level, the above is explicitly = covered. >>>>>> * If SCTP sends the probe packets, doesn't this mean that the = probe packets >>>>>> must bypass compression? >>>>>=20 >>>>> At the SCTP layer; SCTP can't force lower layers to bypass = compression. >>>>=20 >>>> Correct. >>>> So assume SCTP send probe packets and the padding is constant data. = So it is highly >>>> compressible. Wouldn't SCTP then conclude that you can send a large = message without >>>> fragmentation? If SCTP takes that as the PMTU, it would fragment = user messages for >>>> that boundary, compression might not be as efficient and you would = need IP fragmentation. >>>=20 >>> PMTUD is supposed to tell you when a segment of a given size at a = given layer *can get there*. If it gets there, then the MTU is valid. >> I agree. >>>=20 >>> E.g., PMTUD won't tell you that ATM has 53-byte cells with 48-byte = payloads either. >> I agree. But I don't get the point... >>>=20 >>> ... >>>>>> I don't think we can define a DTLS API in TSVWG... At least this = is not in the scope >>>>>> of this document. >>>>>=20 >>>>> Sure, but then you're stuck with SCTP only assuming it can >>>>> interact with DTLS as if it were a DTLS user. DTLS users can't = set DF. >>>>=20 >>>> Why? It depends on the implementation of DTLS... >>>=20 >>> Then you can't require it in a standards doc. >> Hmm. Then we can't deal with PMTUD at all... I would like to tell = people what to >> do if the implementation allows it... >>>=20 >>> Joe >>>=20 >>=20 >=20 From nobody Wed May 14 13:53:07 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982711A01A0; Wed, 14 May 2014 13:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n25Z5PkH58x; Wed, 14 May 2014 13:53:01 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id CC91A1A016A; Wed, 14 May 2014 13:53:00 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4EKqqrr016202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2014 16:52:53 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s4EKqqrr016202 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1400100773; bh=ql0m+3m64aq/oqY0jCjX6T9rVBw=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=tQXJOWfJQxE44rsxbnFAP5oQRoipQ9LLUa5ZkI+R+En8MhcrdqxP/dPf/V3sM6fnw ppKgkRdgFneU+3VH/jJBGpIcag1xCSFXIZAZa7n4jWa5XTH48tpwoCsJaU6/kslujw cxqWoUGDo+mvifix9azf7MTRi5CwdkBGrdkoATBs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s4EKqqrr016202 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 14 May 2014 16:52:42 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4EKqgxo018627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 16:52:42 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Wed, 14 May 2014 16:52:42 -0400 From: "Black, David" To: "tsvwg@ietf.org" , "tsv-area@ietf.org" Date: Wed, 14 May 2014 16:52:40 -0400 Thread-Topic: Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/SKh39UajaC8GP3rcbN90WlbyNIs Subject: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 20:53:03 -0000 Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains some text on dealing with the fragmentation and MTU effects of tunnels. I thought I'd ask for some early review of this text, given recent IESG excitement around fragmentation and Path MTU topics in another draft: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ball= ot/=20 I believe that the nvo3 draft is in better shape in these areas. Nonethele= ss, I've included its current text on fragmentation and path MTU below, and (on behalf of the draft authors and nvo3 WG chairs) I'm looking for input on what that text should say and why. In nvo3 terminology, an overlay network is an inner network that is tunnele= d over an outer underlay network. The nvo3 WG also uses "Tenant System" as the term for a sender/receiver of network traffic because multi-tenancy is an important motivation for the WG's activities in network virtualization. -------------------------------------- 3.5. Path MTU The tunnel overlay header can cause the MTU of the path to the egress tunnel endpoint to be exceeded. =20 IP fragmentation SHOULD be avoided for performance reasons. =20 The interface MTU as seen by a Tenant System SHOULD be adjusted such that no fragmentation is needed. This can be achieved by configuration or be discovered dynamically. =20 Either of the following options MUST be supported: =20 o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or Extended MTU Path Discovery techniques such as defined in [RFC4821] =20 o Segmentation and reassembly support from the overlay layer operations without relying on the Tenant Systems to know about the end-to-end MTU =20 o The underlay network MAY be designed in such a way that the MTU can accommodate the extra tunnel overhead. -------------------------------------- Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Wed May 14 14:05:35 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBE11A01FB; Wed, 14 May 2014 14:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuYqHoX1oc2v; Wed, 14 May 2014 14:05:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 655881A01A6; Wed, 14 May 2014 14:05:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140514210529.2128.791.idtracker@ietfa.amsl.com> Date: Wed, 14 May 2014 14:05:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/CmoD7yn7gZtFg2s4agBOph7AgKI Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 21:05:31 -0000 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. Title : Recommendations for Transport Port Uses Author : Joe Touch Filename : draft-ietf-tsvwg-port-use-04.txt Pages : 19 Date : 2014-05-14 Abstract: This document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-port-use-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 15 00:38:40 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA62C1A03F5; Thu, 15 May 2014 00:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzgjNAbnIKqQ; Thu, 15 May 2014 00:38:34 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2E81A026B; Thu, 15 May 2014 00:38:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,1057,1389772800"; d="scan'208";a="164518043" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 15 May 2014 00:38:26 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Thu, 15 May 2014 00:38:26 -0700 From: "Eggert, Lars" To: "Black, David" Thread-Topic: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEwAlOISA Date: Thu, 15 May 2014 07:38:25 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.21] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/h3EZhfW3lqQ26rxSw3qXLnEDu4k Cc: "tsv-area@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 07:38:36 -0000 Hi, On 2014-5-14, at 22:52, Black, David wrote: > o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or > Extended MTU Path Discovery techniques such as defined in > [RFC4821] Will the NVO3 dataplane protocols have mechanisms to detect loss, so they c= an actually do RFC4821? (I've often seen 4821 cited alongside 1981, because people think it's a dro= p-in replacement when it isn't.) Lars From nobody Thu May 15 07:45:37 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350051A02A7; Thu, 15 May 2014 07:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HynQhH5SorWn; Thu, 15 May 2014 07:45:27 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00A81A00BD; Thu, 15 May 2014 07:45:27 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4FEjJvF016934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 10:45:19 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s4FEjJvF016934 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1400165119; bh=VtnfNTvEWtiKPcl79nBEeNs8aM8=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=g1kYlldTx5uck3zkGejuB49nIIwD0YPU9NGZKAtA1t+8DvCswNNBKp5M+zAJN+u0D rM5yxvx/rjnHYpSpQs1t48WocTiT7qKmpuf8w7EGtCV8qBecDX1jUU65rM6qtRGVHk 3AESMuewNw4OTYwGE0TeQVBiscoyL3xJP4iInY1Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s4FEjJvF016934 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor); Thu, 15 May 2014 10:45:00 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4FEix3T031851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 10:45:00 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Thu, 15 May 2014 10:44:59 -0400 From: "Black, David" To: "Eggert, Lars" Date: Thu, 15 May 2014 10:44:58 -0400 Thread-Topic: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEwAlOISAAAADQ8A= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C55B896@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/OubSwUPHuGCElzUd0abfBNrdp_A Cc: "tsv-area@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 14:45:30 -0000 > Will the NVO3 dataplane protocols have mechanisms to detect loss, so > they can actually do RFC4821? That would definitely be worth calling out; I'll see about writing some text ... in my "copious spare time" ;-). > (I've often seen 4821 cited alongside 1981, because people think it's > a drop-in replacement when it isn't.) Some of the dataplane protocols under consideration do not have that ability, and in addition, there's a strong tendency in nvo3 to shove this problem up the stack, i.e., expect the applications using the overlay to do their own MTU discovery. Thanks, --David > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Thursday, May 15, 2014 3:38 AM > To: Black, David > Cc: tsvwg@ietf.org; tsv-area@ietf.org > Subject: Re: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane re= qts > draft >=20 > Hi, >=20 > On 2014-5-14, at 22:52, Black, David wrote: > > o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] o= r > > Extended MTU Path Discovery techniques such as defined in > > [RFC4821] >=20 > Will the NVO3 dataplane protocols have mechanisms to detect loss, so they= can > actually do RFC4821? >=20 > (I've often seen 4821 cited alongside 1981, because people think it's a d= rop- > in replacement when it isn't.) >=20 > Lars From nobody Thu May 15 12:46:03 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F331A0168 for ; Thu, 15 May 2014 12:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B4aVr8w6pDT for ; Thu, 15 May 2014 12:46:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78881A013C for ; Thu, 15 May 2014 12:46:00 -0700 (PDT) Received: from [128.9.176.34] (c1-vpn4.isi.edu [128.9.176.34]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s4FJjdOd020690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 May 2014 12:45:39 -0700 (PDT) Message-ID: <53751964.6070100@isi.edu> Date: Thu, 15 May 2014 12:45:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tsvwg References: <20140514210529.2128.85580.idtracker@ietfa.amsl.com> In-Reply-To: <20140514210529.2128.85580.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140514210529.2128.85580.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/V36sBWbMxhPl3Ym56slJ2lI5q7E Subject: [tsvwg] Fwd: New Version Notification for draft-ietf-tsvwg-port-use-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 19:46:02 -0000 FYI. These changes reflect: - feedback from Gorry (thanks) - full head-to-tail scrub for language consistency and clarity removed first and second person informal language made RFC citations consistent made capitalization consistent provided examples for the variety of ways to use ports moved some of the citations to the normative section - added one new recommendation based on existing BCP advice: >> Users MUST NOT deploy implementations that default to using the experimental System ports (1021 and 1022 [RFC4727]) outside a controlled environment where they can be updated with a subsequent assigned port [RFC3692]. This addresses all pending issues. Joe -------- Original Message -------- Subject: New Version Notification for draft-ietf-tsvwg-port-use-04.txt Date: Wed, 14 May 2014 14:05:29 -0700 From: internet-drafts@ietf.org To: Dr. Joseph D. Touch , Joe Touch A new version of I-D, draft-ietf-tsvwg-port-use-04.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-ietf-tsvwg-port-use Revision: 04 Title: Recommendations for Transport Port Uses Document date: 2014-05-14 Group: tsvwg Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ Htmlized: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-port-use-04 Abstract: This document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri May 16 13:45:46 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010211A028C; Fri, 16 May 2014 13:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l88ps8oNHLO9; Fri, 16 May 2014 13:45:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55511A0319; Fri, 16 May 2014 13:45:36 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s4GKimeo024080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 16 May 2014 13:44:51 -0700 (PDT) Message-ID: <537678C0.8090602@isi.edu> Date: Fri, 16 May 2014 13:44:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/jdXcYimQ1H9Nl7sZofTb2LGm2R0 Cc: Mark Townsley , "int-area@ietf.org" Subject: Re: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 20:45:40 -0000 On 5/15/2014 3:40 PM, Templin, Fred L wrote: > Hi, > >> -----Original Message----- >> From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Black, David >> Sent: Wednesday, May 14, 2014 1:53 PM >> To: tsvwg@ietf.org; tsv-area@ietf.org >> Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts draft >> >> ... > Over in the intarea, there have been sporadic ongoing discussions about > how to recommend generic MTU mitigations for tunnels. Joe Touch and Mark > Townsley have been working for a long time on a document titled > "Tunnels in the Internet Architecture": > > http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt > > That document should be the place to put generic recommendations for > tunnel MTU handling that apply to all tunnel types. > > Tunnel MTU issues keep popping up in all places, and this is just > another example. Is it time to revive Joe and Mark's document? It's being revived - Mark and I already discussed it, and I'm preparing a revision; my cycles are thin, though - I just completed one on TCP security and another on transport ports, but this is next on my table. Joe From nobody Sat May 17 09:01:34 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275BF1A0326; Fri, 16 May 2014 11:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2a7oI7THVmu; Fri, 16 May 2014 11:28:01 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19661A0322; Fri, 16 May 2014 11:28:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s4GIRqfv009963; Fri, 16 May 2014 13:27:52 -0500 Received: from XCH-PHX-111.sw.nos.boeing.com (xch-phx-111.sw.nos.boeing.com [130.247.25.132]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s4GIRmhQ009726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 16 May 2014 13:27:49 -0500 Received: from XCH-BLV-205.nw.nos.boeing.com (10.57.37.61) by XCH-PHX-111.sw.nos.boeing.com (130.247.25.132) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 16 May 2014 11:27:47 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-205.nw.nos.boeing.com ([169.254.5.221]) with mapi id 14.03.0181.006; Fri, 16 May 2014 11:27:45 -0700 From: "Templin, Fred L" To: "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: AQHPcTSH/Asq9x/h/UWLdY5SldYekg== Date: Fri, 16 May 2014 18:27:44 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2AD6AE@XCH-BLV-504.nw.nos.boeing.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/xM4Y1bQ_uvY1n4oaQC6JLnUy7os X-Mailman-Approved-At: Sat, 17 May 2014 09:01:04 -0700 Cc: Mark Townsley , "int-area@ietf.org" Subject: Re: [tsvwg] [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 18:28:03 -0000 > That document should be the place to put generic recommendations for > tunnel MTU handling that apply to all tunnel types. In case you are wondering what I think "generic recommendations for tunnel MTU handling" should look like, here is what I think: The tunnel link Maximum Transmission Unit (MTU) is 64KB minus the encapsulation overhead for IPv4 [RFC0791] and 4GB minus the encapsulation overhead for IPv6 [RFC2675]. This is the most that IPv4 and IPv6 (respectively) can convey within the constraints of protocol constants, but actual sizes available for tunneling will frequently be much smaller. The base tunneling specifications for IPv4 and IPv6 typically set a static MTU on the tunnel ingress to 1500 bytes minus the encapsulation overhead or smaller still if the tunnel is likely to incur additional encapsulations on the path. This can result in path MTU related black holes when packets that are too large to be accommodated over the tunnel are dropped, but the resulting ICMP Packet Too Big (PTB) messages are lost on the return path. As a result, tunnels use the following MTU mitigations to accommodate larger packets. Tunnels set their ingress MTU to the larger of the underlying interface MTU minus the encapsulation overhead, and 1500 bytes. Tunnels optionally cache per-egress MTU values in the underlying IP path MTU discovery cache initialized to the underlying interface MTU. Tunnels admit packets that are no larger than 1280 bytes minus the encapsulation overhead (*) as well as packets that are larger than 1500 bytes into the tunnel without fragmentation, i.e., as long as they are no larger than the tunnel ingress MTU before encapsulation and also no larger than the cached per-egress MTU following encapsulation. For IPv4, the ingress sets the "Don't Fragment" (DF) bit to 0 for packets no larger than 1280 bytes minus the encapsulation overhead (*) and sets the DF bit to 1 for packets larger than 1500 bytes. If a large packet is lost in the path, the ingress may optionally cache the MTU reported in the resulting PTB message or may ignore the message, e.g., if there is a possibility that the message is spurious. For packets admitted into the tunnel that are larger than 1280 bytes minus the encapsulation overhead (*) but no larger than 1500 bytes, the ingress uses IP fragmentation to fragment the encapsulated packet into two pieces (where the first fragment contains 1024 bytes of the fragmented inner packet) then sends the fragments to the egress. If the outer protocol is IPv4, the node sends the fragments with DF set to 0 and subject to rate limiting to avoid reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the ingress also sends a 1500 byte probe message (**) to the egress, subject to rate limiting. To construct a probe, the ingress prepares an ICMPv6 Neighbor Solicitation (NS) message with trailing padding octets added to a length of 1500 bytes but does not include the length of the padding in the IPv6 Payload Length field. The ingress then encapsulates the NS in the outer encapsulation headers (while including the length of the padding in the outer length fields), sets DF to 1 (for IPv4) and sends the padded NS message to the neighbor. If the egress returns an NA message, the ingress may then send whole packets within this size range and (for IPv4) relax the rate limiting requirement. (Note that for tunnels that do not perform IPv6 neighbor discovery, an ICMP echo request message can be used instead of NS.)=20 The egress MUST be capable of reassembling packets up to 1500 bytes plus the encapsulation overhead length. It is therefore RECOMMENDED that the egress be capable of reassembling at least 2KB. (*) Note that if it is known without probing that the minimum Path MTU to a tunnel egress is MINMTU bytes (where 1280 < MINMTU < 1500) then MINMTU can be used instead of 1280 in the fragmentation threshold considerations listed above. (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used for MTU probing purposes, since smaller probes may be fragmented if there is a nested tunnel somewhere on the path to the egress. Probe sizes larger than 1500 bytes MAY be used, but may be unnecessary since original sources are expected to use [RFC4821] when sending large packets. I think this applies to all IP-in-(foo)-in-IP tunnel types, and could go as a set of generic recommendations to be cited by other documents. Comments? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, F= red L > Sent: Thursday, May 15, 2014 3:41 PM > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane= reqts draft >=20 > Hi, >=20 > > -----Original Message----- > > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Black, D= avid > > Sent: Wednesday, May 14, 2014 1:53 PM > > To: tsvwg@ietf.org; tsv-area@ietf.org > > Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts draft > > > > > > > > Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains > > some text on dealing with the fragmentation and MTU effects of tunnels. > > I thought I'd ask for some early review of this text, given recent IESG > > excitement around fragmentation and Path MTU topics in another draft: >=20 > All tunnels have trouble with path MTU, and in some cases have no choice > but to fragment. However, they should strive to tune out fragmentation > and forward whole packets whenever possible. >=20 > Over in the intarea, there have been sporadic ongoing discussions about > how to recommend generic MTU mitigations for tunnels. Joe Touch and Mark > Townsley have been working for a long time on a document titled > "Tunnels in the Internet Architecture": >=20 > http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt >=20 > That document should be the place to put generic recommendations for > tunnel MTU handling that apply to all tunnel types. >=20 > Tunnel MTU issues keep popping up in all places, and this is just > another example. Is it time to revive Joe and Mark's document? >=20 > Thanks - Fred > fred.l.templin@boeing. >=20 > > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/= ballot/ > > > > I believe that the nvo3 draft is in better shape in these areas. Nonet= heless, > > I've included its current text on fragmentation and path MTU below, and= (on > > behalf of the draft authors and nvo3 WG chairs) I'm looking for input o= n > > what that text should say and why. > > > > In nvo3 terminology, an overlay network is an inner network that is tun= neled > > over an outer underlay network. The nvo3 WG also uses "Tenant System" = as > > the term for a sender/receiver of network traffic because multi-tenancy= is > > an important motivation for the WG's activities in network virtualizati= on. > > > > -------------------------------------- > > > > 3.5. Path MTU > > > > The tunnel overlay header can cause the MTU of the path to the > > egress tunnel endpoint to be exceeded. > > > > IP fragmentation SHOULD be avoided for performance reasons. > > > > The interface MTU as seen by a Tenant System SHOULD be adjusted = such > > that no fragmentation is needed. This can be achieved by > > configuration or be discovered dynamically. > > > > Either of the following options MUST be supported: > > > > o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981]= or > > Extended MTU Path Discovery techniques such as defined in > > [RFC4821] > > > > o Segmentation and reassembly support from the overlay layer > > operations without relying on the Tenant Systems to know ab= out > > the end-to-end MTU > > > > o The underlay network MAY be designed in such a way that the= MTU > > can accommodate the extra tunnel overhead. > > > > -------------------------------------- > > > > > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Sat May 17 09:01:37 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFFC1A0322; Fri, 16 May 2014 12:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NkM30vP0dFI; Fri, 16 May 2014 12:11:07 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5351A1A0366; Fri, 16 May 2014 12:09:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s4GJ9nIj010204; Fri, 16 May 2014 12:09:49 -0700 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s4GJ9ete010096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 16 May 2014 12:09:41 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.51]) with mapi id 14.03.0181.006; Fri, 16 May 2014 12:09:40 -0700 From: "Templin, Fred L" To: Linda Dunbar , "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: AQHPcTpiayvL/eBQg0aL8rjprMnvlQ== Date: Fri, 16 May 2014 19:09:39 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2AD82D@XCH-BLV-504.nw.nos.boeing.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2AD6AE@XCH-BLV-504.nw.nos.boeing.com> <4A95BA014132FF49AE685FAB4B9F17F645D0B178@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D0B178@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/kpfvE4y-NXDbuvBg4FDEgcVTDzM X-Mailman-Approved-At: Sat, 17 May 2014 09:01:03 -0700 Cc: Mark Townsley , "int-area@ietf.org" Subject: Re: [tsvwg] [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 19:11:20 -0000 Hi Linda, The maximum MTU for an IPv4 link is 64KB (per RFC0791) and the maximum MTU for an IPv6 link is 4GB (per RFC2675). For tunnels over IPv4, the IPv4 network itself is the link layer for the tunnel. For tunnels over IPv6, the IPv6 network is the link-layer. That means that the largest encapsulated packet that will fit over an IPv4 "link" is 64KB minus the encapsulation overhead, and the largest over an IPv6 "link" is 4GB minus overhead. But, typical values will be much smaller than this because most underlying links configure smaller MTUs. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Friday, May 16, 2014 11:56 AM > To: Templin, Fred L; Black, David; tsvwg@ietf.org; tsv-area@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane= reqts draft >=20 > I am confused of the math here. If most physical links MTU is 1500 bytes = (or 2000 bytes for some), how > do we have""4GB"" minus the encapsulation overhead for IPv6, as the "tunn= el link Maximum Transmission > Unit (MTU)". >=20 > Is 4GB correct ??? >=20 > Linda >=20 > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, F= red L > Sent: Friday, May 16, 2014 1:28 PM > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane= reqts draft >=20 > > That document should be the place to put generic recommendations for > > tunnel MTU handling that apply to all tunnel types. >=20 > In case you are wondering what I think "generic recommendations for tunne= l MTU handling" should look > like, here is what I think: >=20 > The tunnel link Maximum Transmission Unit (MTU) is 64KB minus the > encapsulation overhead for IPv4 [RFC0791] and 4GB minus the > encapsulation overhead for IPv6 [RFC2675]. This is the most that > IPv4 and IPv6 (respectively) can convey within the constraints of > protocol constants, but actual sizes available for tunneling will > frequently be much smaller. >=20 > The base tunneling specifications for IPv4 and IPv6 typically set a > static MTU on the tunnel ingress to 1500 bytes minus the > encapsulation overhead or smaller still if the tunnel is likely to > incur additional encapsulations on the path. This can result in path > MTU related black holes when packets that are too large to be > accommodated over the tunnel are dropped, but the resulting ICMP > Packet Too Big (PTB) messages are lost on the return path. As a > result, tunnels use the following MTU mitigations to accommodate > larger packets. >=20 > Tunnels set their ingress MTU to the larger of the > underlying interface MTU minus the encapsulation overhead, and 1500 > bytes. Tunnels optionally cache per-egress MTU values in > the underlying IP path MTU discovery cache initialized to the > underlying interface MTU. >=20 > Tunnels admit packets that are no larger than 1280 bytes minus the > encapsulation overhead (*) as well as packets that are larger than > 1500 bytes into the tunnel without fragmentation, i.e., as long as > they are no larger than the tunnel ingress MTU before encapsulation > and also no larger than the cached per-egress MTU following > encapsulation. For IPv4, the ingress sets the "Don't Fragment" (DF) > bit to 0 for packets no larger than 1280 bytes minus the encapsulation > overhead (*) and sets the DF bit to 1 for packets larger than 1500 > bytes. If a large packet is lost in the path, the ingress may > optionally cache the MTU reported in the resulting PTB message or may > ignore the message, e.g., if there is a possibility that the message > is spurious. >=20 > For packets admitted into the tunnel that are larger than 1280 bytes > minus the encapsulation overhead (*) but no larger than 1500 bytes, > the ingress uses IP fragmentation to fragment the encapsulated packet > into two pieces (where the first fragment contains 1024 bytes of the > fragmented inner packet) then sends the fragments to the egress. > If the outer protocol is IPv4, the node sends the fragments with > DF set to 0 and subject to rate limiting to avoid > reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the > ingress also sends a 1500 byte probe message (**) to the egress, > subject to rate limiting. To construct a probe, the ingress prepares > an ICMPv6 Neighbor Solicitation (NS) message with trailing padding > octets added to a length of 1500 bytes but does not include the > length of the padding in the IPv6 Payload Length field. The ingress > then encapsulates the NS in the outer encapsulation headers (while > including the length of the padding in the outer length fields), sets > DF to 1 (for IPv4) and sends the padded NS message to the neighbor. > If the egress returns an NA message, the ingress may then send whole > packets within this size range and (for IPv4) relax the rate limiting > requirement. (Note that for tunnels that do not perform IPv6 neighbor > discovery, an ICMP echo request message can be used instead of NS.) >=20 > The egress MUST be capable of reassembling packets up to 1500 bytes > plus the encapsulation overhead length. It is therefore RECOMMENDED > that the egress be capable of reassembling at least 2KB. >=20 > (*) Note that if it is known without probing that the minimum Path > MTU to a tunnel egress is MINMTU bytes (where 1280 < MINMTU < 1500) > then MINMTU can be used instead of 1280 in the fragmentation threshold > considerations listed above. >=20 > (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used > for MTU probing purposes, since smaller probes may be fragmented if > there is a nested tunnel somewhere on the path to the egress. > Probe sizes larger than 1500 bytes MAY be used, but may be > unnecessary since original sources are expected to use [RFC4821] > when sending large packets. >=20 > I think this applies to all IP-in-(foo)-in-IP tunnel types, and could go = as a set of generic > recommendations to be cited by other documents. >=20 > Comments? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of > > Templin, Fred L > > Sent: Thursday, May 15, 2014 3:41 PM > > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > Cc: Mark Townsley; int-area@ietf.org > > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3 > > dataplane reqts draft > > > > Hi, > > > > > -----Original Message----- > > > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of > > > Black, David > > > Sent: Wednesday, May 14, 2014 1:53 PM > > > To: tsvwg@ietf.org; tsv-area@ietf.org > > > Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts > > > draft > > > > > > > > > > > > Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 > > > contains some text on dealing with the fragmentation and MTU effects = of tunnels. > > > I thought I'd ask for some early review of this text, given recent > > > IESG excitement around fragmentation and Path MTU topics in another d= raft: > > > > All tunnels have trouble with path MTU, and in some cases have no > > choice but to fragment. However, they should strive to tune out > > fragmentation and forward whole packets whenever possible. > > > > Over in the intarea, there have been sporadic ongoing discussions > > about how to recommend generic MTU mitigations for tunnels. Joe Touch > > and Mark Townsley have been working for a long time on a document > > titled "Tunnels in the Internet Architecture": > > > > http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt > > > > That document should be the place to put generic recommendations for > > tunnel MTU handling that apply to all tunnel types. > > > > Tunnel MTU issues keep popping up in all places, and this is just > > another example. Is it time to revive Joe and Mark's document? > > > > Thanks - Fred > > fred.l.templin@boeing. > > > > > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentati > > > on/ballot/ > > > > > > I believe that the nvo3 draft is in better shape in these areas. > > > Nonetheless, I've included its current text on fragmentation and > > > path MTU below, and (on behalf of the draft authors and nvo3 WG > > > chairs) I'm looking for input on what that text should say and why. > > > > > > In nvo3 terminology, an overlay network is an inner network that is > > > tunneled over an outer underlay network. The nvo3 WG also uses > > > "Tenant System" as the term for a sender/receiver of network traffic > > > because multi-tenancy is an important motivation for the WG's activit= ies in network > virtualization. > > > > > > -------------------------------------- > > > > > > 3.5. Path MTU > > > > > > The tunnel overlay header can cause the MTU of the path to the > > > egress tunnel endpoint to be exceeded. > > > > > > IP fragmentation SHOULD be avoided for performance reasons. > > > > > > The interface MTU as seen by a Tenant System SHOULD be adjuste= d such > > > that no fragmentation is needed. This can be achieved by > > > configuration or be discovered dynamically. > > > > > > Either of the following options MUST be supported: > > > > > > o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC198= 1] or > > > Extended MTU Path Discovery techniques such as defined in > > > [RFC4821] > > > > > > o Segmentation and reassembly support from the overlay laye= r > > > operations without relying on the Tenant Systems to know = about > > > the end-to-end MTU > > > > > > o The underlay network MAY be designed in such a way that t= he MTU > > > can accommodate the extra tunnel overhead. > > > > > > -------------------------------------- > > > > > > > > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South > > > St., Hopkinton, MA=A0 01748 > > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 2= 93-7786 > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Sat May 17 09:01:39 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C5B1A017C; Fri, 16 May 2014 13:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOzYVIR1Ysuq; Fri, 16 May 2014 13:13:45 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B9D1A0066; Fri, 16 May 2014 13:13:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s4GKDcoR015590; Fri, 16 May 2014 13:13:38 -0700 Received: from XCH-PHX-410.sw.nos.boeing.com (xch-phx-410.sw.nos.boeing.com [10.57.37.41]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s4GKDTIg015001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 16 May 2014 13:13:29 -0700 Received: from XCH-BLV-403.nw.nos.boeing.com (130.247.25.62) by XCH-PHX-410.sw.nos.boeing.com (10.57.37.41) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 16 May 2014 13:13:28 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-403.nw.nos.boeing.com ([169.254.3.26]) with mapi id 14.03.0181.006; Fri, 16 May 2014 13:13:27 -0700 From: "Templin, Fred L" To: Linda Dunbar , "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: AQHPcTpiayvL/eBQg0aL8rjprMnvlZtEFlOA//+L7nA= Date: Fri, 16 May 2014 20:13:27 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2ADA4E@XCH-BLV-504.nw.nos.boeing.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2AD6AE@XCH-BLV-504.nw.nos.boeing.com> <4A95BA014132FF49AE685FAB4B9F17F645D0B178@dfweml701-chm.china.huawei.com> <2134F8430051B64F815C691A62D983181B2AD82D@XCH-BLV-504.nw.nos.boeing.com> <4A95BA014132FF49AE685FAB4B9F17F645D0B464@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D0B464@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Omz0EiyfVSqcKISgvv7b9fxBGBM X-Mailman-Approved-At: Sat, 17 May 2014 09:01:00 -0700 Cc: Mark Townsley , "int-area@ietf.org" Subject: Re: [tsvwg] [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 20:13:49 -0000 X-List-Received-Date: Fri, 16 May 2014 20:13:49 -0000 Hi Linda, > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Friday, May 16, 2014 1:02 PM > To: Templin, Fred L; Black, David; tsvwg@ietf.org; tsv-area@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane= reqts draft >=20 > Can we challenge the 4GB MTU size recommendation by RFC2675? Network cons= ists of nodes and links. The > MTU of a network should be limited by the MTU of the links. Yes, the path MTU is the minimum MTU of all links in the path. The path MTU minus the encapsulation is the largest packet that will traverse the tunnel without fragmentation. But, consider that the path MTU may be as large 64KB for IPv4 or 4GB for IPv6. > With 4GB MTU recommendation, it would require the network ingress node to= fragment packets and egress > node to reassemble packets. No, if you look further into my text you will see that we will never allow fragmentation for packets larger than 1500 bytes; anything larger will go as an unfragmented whole packet or will be dropped at a link within the tunnel that configures an insufficient MTU. 64KB/4GB are not "recommendations"; they are protocol constants. > If the network ingress can fragment and egress can reassemble packets, th= ere is no need to define the > network MTU size. Therefore, this recommendation is meaningless. Fragmentation and reassembly limit is 1500 bytes; larger packets go through unfragmented or not at all. Take care of the smalls, and let the bigs take care of themselves. Thanks - Fred fred.l.templin@boeing.com =20 > Linda >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Friday, May 16, 2014 2:10 PM > To: Linda Dunbar; Black, David; tsvwg@ietf.org; tsv-area@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane= reqts draft >=20 > Hi Linda, >=20 > The maximum MTU for an IPv4 link is 64KB (per RFC0791) and the maximum MT= U for an IPv6 link is 4GB > (per RFC2675). For tunnels over IPv4, the > IPv4 network itself is the link layer for the tunnel. For tunnels over IP= v6, the IPv6 network is the > link-layer. That means that the largest encapsulated packet that will fit= over an IPv4 "link" is 64KB > minus the encapsulation overhead, and the largest over an IPv6 "link" is = 4GB minus overhead. But, > typical values will be much smaller than this because most underlying lin= ks configure smaller MTUs. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > Sent: Friday, May 16, 2014 11:56 AM > > To: Templin, Fred L; Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > Cc: Mark Townsley; int-area@ietf.org > > Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 > > dataplane reqts draft > > > > I am confused of the math here. If most physical links MTU is 1500 > > bytes (or 2000 bytes for some), how do we have""4GB"" minus the > > encapsulation overhead for IPv6, as the "tunnel link Maximum Transmissi= on Unit (MTU)". > > > > Is 4GB correct ??? > > > > Linda > > > > -----Original Message----- > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of > > Templin, Fred L > > Sent: Friday, May 16, 2014 1:28 PM > > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > Cc: Mark Townsley; int-area@ietf.org > > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3 > > dataplane reqts draft > > > > > That document should be the place to put generic recommendations for > > > tunnel MTU handling that apply to all tunnel types. > > > > In case you are wondering what I think "generic recommendations for > > tunnel MTU handling" should look like, here is what I think: > > > > The tunnel link Maximum Transmission Unit (MTU) is 64KB minus the > > encapsulation overhead for IPv4 [RFC0791] and 4GB minus the > > encapsulation overhead for IPv6 [RFC2675]. This is the most that > > IPv4 and IPv6 (respectively) can convey within the constraints of > > protocol constants, but actual sizes available for tunneling will > > frequently be much smaller. > > > > The base tunneling specifications for IPv4 and IPv6 typically set a > > static MTU on the tunnel ingress to 1500 bytes minus the > > encapsulation overhead or smaller still if the tunnel is likely to > > incur additional encapsulations on the path. This can result in pat= h > > MTU related black holes when packets that are too large to be > > accommodated over the tunnel are dropped, but the resulting ICMP > > Packet Too Big (PTB) messages are lost on the return path. As a > > result, tunnels use the following MTU mitigations to accommodate > > larger packets. > > > > Tunnels set their ingress MTU to the larger of the > > underlying interface MTU minus the encapsulation overhead, and 1500 > > bytes. Tunnels optionally cache per-egress MTU values in > > the underlying IP path MTU discovery cache initialized to the > > underlying interface MTU. > > > > Tunnels admit packets that are no larger than 1280 bytes minus the > > encapsulation overhead (*) as well as packets that are larger than > > 1500 bytes into the tunnel without fragmentation, i.e., as long as > > they are no larger than the tunnel ingress MTU before encapsulation > > and also no larger than the cached per-egress MTU following > > encapsulation. For IPv4, the ingress sets the "Don't Fragment" (DF) > > bit to 0 for packets no larger than 1280 bytes minus the encapsulati= on > > overhead (*) and sets the DF bit to 1 for packets larger than 1500 > > bytes. If a large packet is lost in the path, the ingress may > > optionally cache the MTU reported in the resulting PTB message or ma= y > > ignore the message, e.g., if there is a possibility that the message > > is spurious. > > > > For packets admitted into the tunnel that are larger than 1280 bytes > > minus the encapsulation overhead (*) but no larger than 1500 bytes, > > the ingress uses IP fragmentation to fragment the encapsulated packe= t > > into two pieces (where the first fragment contains 1024 bytes of the > > fragmented inner packet) then sends the fragments to the egress. > > If the outer protocol is IPv4, the node sends the fragments with > > DF set to 0 and subject to rate limiting to avoid > > reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the > > ingress also sends a 1500 byte probe message (**) to the egress, > > subject to rate limiting. To construct a probe, the ingress prepares > > an ICMPv6 Neighbor Solicitation (NS) message with trailing padding > > octets added to a length of 1500 bytes but does not include the > > length of the padding in the IPv6 Payload Length field. The ingress > > then encapsulates the NS in the outer encapsulation headers (while > > including the length of the padding in the outer length fields), set= s > > DF to 1 (for IPv4) and sends the padded NS message to the neighbor. > > If the egress returns an NA message, the ingress may then send whole > > packets within this size range and (for IPv4) relax the rate limitin= g > > requirement. (Note that for tunnels that do not perform IPv6 neighbo= r > > discovery, an ICMP echo request message can be used instead of NS.) > > > > The egress MUST be capable of reassembling packets up to 1500 bytes > > plus the encapsulation overhead length. It is therefore RECOMMENDED > > that the egress be capable of reassembling at least 2KB. > > > > (*) Note that if it is known without probing that the minimum Path > > MTU to a tunnel egress is MINMTU bytes (where 1280 < MINMTU < 1500) > > then MINMTU can be used instead of 1280 in the fragmentation thresho= ld > > considerations listed above. > > > > (**) It is RECOMMENDED that no probes smaller than 1500 bytes be use= d > > for MTU probing purposes, since smaller probes may be fragmented if > > there is a nested tunnel somewhere on the path to the egress. > > Probe sizes larger than 1500 bytes MAY be used, but may be > > unnecessary since original sources are expected to use [RFC4821] > > when sending large packets. > > > > I think this applies to all IP-in-(foo)-in-IP tunnel types, and could > > go as a set of generic recommendations to be cited by other documents. > > > > Comments? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > -----Original Message----- > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of > > > Templin, Fred L > > > Sent: Thursday, May 15, 2014 3:41 PM > > > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > > Cc: Mark Townsley; int-area@ietf.org > > > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3 > > > dataplane reqts draft > > > > > > Hi, > > > > > > > -----Original Message----- > > > > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of > > > > Black, David > > > > Sent: Wednesday, May 14, 2014 1:53 PM > > > > To: tsvwg@ietf.org; tsv-area@ietf.org > > > > Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts > > > > draft > > > > > > > > > > > > > > > > Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 > > > > contains some text on dealing with the fragmentation and MTU effect= s of tunnels. > > > > I thought I'd ask for some early review of this text, given recent > > > > IESG excitement around fragmentation and Path MTU topics in another= draft: > > > > > > All tunnels have trouble with path MTU, and in some cases have no > > > choice but to fragment. However, they should strive to tune out > > > fragmentation and forward whole packets whenever possible. > > > > > > Over in the intarea, there have been sporadic ongoing discussions > > > about how to recommend generic MTU mitigations for tunnels. Joe > > > Touch and Mark Townsley have been working for a long time on a > > > document titled "Tunnels in the Internet Architecture": > > > > > > http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt > > > > > > That document should be the place to put generic recommendations for > > > tunnel MTU handling that apply to all tunnel types. > > > > > > Tunnel MTU issues keep popping up in all places, and this is just > > > another example. Is it time to revive Joe and Mark's document? > > > > > > Thanks - Fred > > > fred.l.templin@boeing. > > > > > > > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmenta > > > > ti > > > > on/ballot/ > > > > > > > > I believe that the nvo3 draft is in better shape in these areas. > > > > Nonetheless, I've included its current text on fragmentation and > > > > path MTU below, and (on behalf of the draft authors and nvo3 WG > > > > chairs) I'm looking for input on what that text should say and why. > > > > > > > > In nvo3 terminology, an overlay network is an inner network that > > > > is tunneled over an outer underlay network. The nvo3 WG also uses > > > > "Tenant System" as the term for a sender/receiver of network > > > > traffic because multi-tenancy is an important motivation for the > > > > WG's activities in network > > virtualization. > > > > > > > > -------------------------------------- > > > > > > > > 3.5. Path MTU > > > > > > > > The tunnel overlay header can cause the MTU of the path to t= he > > > > egress tunnel endpoint to be exceeded. > > > > > > > > IP fragmentation SHOULD be avoided for performance reasons. > > > > > > > > The interface MTU as seen by a Tenant System SHOULD be adjus= ted such > > > > that no fragmentation is needed. This can be achieved by > > > > configuration or be discovered dynamically. > > > > > > > > Either of the following options MUST be supported: > > > > > > > > o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1= 981] or > > > > Extended MTU Path Discovery techniques such as defined = in > > > > [RFC4821] > > > > > > > > o Segmentation and reassembly support from the overlay la= yer > > > > operations without relying on the Tenant Systems to kno= w about > > > > the end-to-end MTU > > > > > > > > o The underlay network MAY be designed in such a way that= the MTU > > > > can accommodate the extra tunnel overhead. > > > > > > > > -------------------------------------- > > > > > > > > > > > > > > > > Thanks, > > > > --David > > > > ---------------------------------------------------- > > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South > > > > St., Hopkinton, MA=A0 01748 > > > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508)= 293-7786 > > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > > ---------------------------------------------------- > > > > > > _______________________________________________ > > > Int-area mailing list > > > Int-area@ietf.org > > > https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area From nobody Sat May 17 09:01:40 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F334A1A01D4; Fri, 16 May 2014 13:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFCYoFlzNosP; Fri, 16 May 2014 13:57:07 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E91E1A006C; Fri, 16 May 2014 13:57:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s4GKuxST019483; Fri, 16 May 2014 13:56:59 -0700 Received: from XCH-PHX-410.sw.nos.boeing.com (xch-phx-410.sw.nos.boeing.com [10.57.37.41]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s4GKuthR019447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 16 May 2014 13:56:57 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-410.sw.nos.boeing.com ([169.254.10.15]) with mapi id 14.03.0181.006; Fri, 16 May 2014 13:56:55 -0700 From: "Templin, Fred L" To: Linda Dunbar , "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: AQHPcTpiayvL/eBQg0aL8rjprMnvlZtEFlOA//+L7nCAAIAhAP//jELQ Date: Fri, 16 May 2014 20:56:54 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2ADB79@XCH-BLV-504.nw.nos.boeing.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2AD6AE@XCH-BLV-504.nw.nos.boeing.com> <4A95BA014132FF49AE685FAB4B9F17F645D0B178@dfweml701-chm.china.huawei.com> <2134F8430051B64F815C691A62D983181B2AD82D@XCH-BLV-504.nw.nos.boeing.com> <4A95BA014132FF49AE685FAB4B9F17F645D0B464@dfweml701-chm.china.huawei.com> <2134F8430051B64F815C691A62D983181B2ADA4E@XCH-BLV-504.nw.nos.boeing.com> <4A95BA014132FF49AE685FAB4B9F17F645D0B4EC@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D0B4EC@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/eS4ueSLczwVpaU4ZSr3U_ztF2Ns X-Mailman-Approved-At: Sat, 17 May 2014 09:01:02 -0700 Cc: Mark Townsley , "int-area@ietf.org" Subject: Re: [tsvwg] [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 20:57:11 -0000 Hi Linda, > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Friday, May 16, 2014 1:45 PM > To: Templin, Fred L; Black, David; tsvwg@ietf.org; tsv-area@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane= reqts draft >=20 > Fred, >=20 > Thanks for the clarification. >=20 > Since the topic is about tunneling, a.k.a. encapsulating additional heade= rs to data packets that > increases the risk of exceeding link MTU, we should focus on the Path MTU= , not the network Layer MTU. >=20 > So we shouldn't use the 64K/4GB recommended by RFC2675 for "The tunnel li= nk Maximum Transmission Unit" The "link" for a tunnel over IPv4 is the IPv4 network. The maximum MTU for traversing an IPv4 network is 64KB. The "link" for a tunnel over IPv6 is the IPv6 network. The maximum MTU for traversing an IPv6 network is 4GB. These are protocol constants; not recommendations. In order to change them, we would need to (bis) RFC0791 and RFC2675. If you read further in the text (say, beginning with the next sentence) all will be made clear. Thanks - Fred fred.l.templin@boeing.com >=20 > Linda >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >=20 >=20 > No, if you look further into my text you will see that we will never allo= w fragmentation for packets > larger than 1500 bytes; anything larger will go as an unfragmented whole = packet or will be dropped at > a link within the tunnel that configures an insufficient MTU. > 64KB/4GB are not "recommendations"; they are protocol constants. >=20 > > If the network ingress can fragment and egress can reassemble packets, > > there is no need to define the network MTU size. Therefore, this recomm= endation is meaningless. >=20 > Fragmentation and reassembly limit is 1500 bytes; larger packets go throu= gh unfragmented or not at > all. Take care of the smalls, and let the bigs take care of themselves. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Linda > > > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Friday, May 16, 2014 2:10 PM > > To: Linda Dunbar; Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > Cc: Mark Townsley; int-area@ietf.org > > Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 > > dataplane reqts draft > > > > Hi Linda, > > > > The maximum MTU for an IPv4 link is 64KB (per RFC0791) and the maximum > > MTU for an IPv6 link is 4GB (per RFC2675). For tunnels over IPv4, the > > IPv4 network itself is the link layer for the tunnel. For tunnels over > > IPv6, the IPv6 network is the link-layer. That means that the largest > > encapsulated packet that will fit over an IPv4 "link" is 64KB minus > > the encapsulation overhead, and the largest over an IPv6 "link" is 4GB = minus overhead. But, typical > values will be much smaller than this because most underlying links confi= gure smaller MTUs. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > -----Original Message----- > > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > > Sent: Friday, May 16, 2014 11:56 AM > > > To: Templin, Fred L; Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > > Cc: Mark Townsley; int-area@ietf.org > > > Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 > > > dataplane reqts draft > > > > > > I am confused of the math here. If most physical links MTU is 1500 > > > bytes (or 2000 bytes for some), how do we have""4GB"" minus the > > > encapsulation overhead for IPv6, as the "tunnel link Maximum Transmis= sion Unit (MTU)". > > > > > > Is 4GB correct ??? > > > > > > Linda > > > > > > -----Original Message----- > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of > > > Templin, Fred L > > > Sent: Friday, May 16, 2014 1:28 PM > > > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > > Cc: Mark Townsley; int-area@ietf.org > > > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3 > > > dataplane reqts draft > > > > > > > That document should be the place to put generic recommendations > > > > for tunnel MTU handling that apply to all tunnel types. > > > > > > In case you are wondering what I think "generic recommendations for > > > tunnel MTU handling" should look like, here is what I think: > > > > > > The tunnel link Maximum Transmission Unit (MTU) is 64KB minus the > > > encapsulation overhead for IPv4 [RFC0791] and 4GB minus the > > > encapsulation overhead for IPv6 [RFC2675]. This is the most that > > > IPv4 and IPv6 (respectively) can convey within the constraints of > > > protocol constants, but actual sizes available for tunneling will > > > frequently be much smaller. > > > > > > The base tunneling specifications for IPv4 and IPv6 typically set = a > > > static MTU on the tunnel ingress to 1500 bytes minus the > > > encapsulation overhead or smaller still if the tunnel is likely to > > > incur additional encapsulations on the path. This can result in p= ath > > > MTU related black holes when packets that are too large to be > > > accommodated over the tunnel are dropped, but the resulting ICMP > > > Packet Too Big (PTB) messages are lost on the return path. As a > > > result, tunnels use the following MTU mitigations to accommodate > > > larger packets. > > > > > > Tunnels set their ingress MTU to the larger of the > > > underlying interface MTU minus the encapsulation overhead, and 150= 0 > > > bytes. Tunnels optionally cache per-egress MTU values in > > > the underlying IP path MTU discovery cache initialized to the > > > underlying interface MTU. > > > > > > Tunnels admit packets that are no larger than 1280 bytes minus the > > > encapsulation overhead (*) as well as packets that are larger than > > > 1500 bytes into the tunnel without fragmentation, i.e., as long as > > > they are no larger than the tunnel ingress MTU before encapsulatio= n > > > and also no larger than the cached per-egress MTU following > > > encapsulation. For IPv4, the ingress sets the "Don't Fragment" (D= F) > > > bit to 0 for packets no larger than 1280 bytes minus the encapsula= tion > > > overhead (*) and sets the DF bit to 1 for packets larger than 1500 > > > bytes. If a large packet is lost in the path, the ingress may > > > optionally cache the MTU reported in the resulting PTB message or = may > > > ignore the message, e.g., if there is a possibility that the messa= ge > > > is spurious. > > > > > > For packets admitted into the tunnel that are larger than 1280 byt= es > > > minus the encapsulation overhead (*) but no larger than 1500 bytes= , > > > the ingress uses IP fragmentation to fragment the encapsulated pac= ket > > > into two pieces (where the first fragment contains 1024 bytes of t= he > > > fragmented inner packet) then sends the fragments to the egress. > > > If the outer protocol is IPv4, the node sends the fragments with > > > DF set to 0 and subject to rate limiting to avoid > > > reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the > > > ingress also sends a 1500 byte probe message (**) to the egress, > > > subject to rate limiting. To construct a probe, the ingress prepar= es > > > an ICMPv6 Neighbor Solicitation (NS) message with trailing padding > > > octets added to a length of 1500 bytes but does not include the > > > length of the padding in the IPv6 Payload Length field. The ingre= ss > > > then encapsulates the NS in the outer encapsulation headers (while > > > including the length of the padding in the outer length fields), s= ets > > > DF to 1 (for IPv4) and sends the padded NS message to the neighbor= . > > > If the egress returns an NA message, the ingress may then send who= le > > > packets within this size range and (for IPv4) relax the rate limit= ing > > > requirement. (Note that for tunnels that do not perform IPv6 neigh= bor > > > discovery, an ICMP echo request message can be used instead of > > > NS.) > > > > > > The egress MUST be capable of reassembling packets up to 1500 byte= s > > > plus the encapsulation overhead length. It is therefore RECOMMEND= ED > > > that the egress be capable of reassembling at least 2KB. > > > > > > (*) Note that if it is known without probing that the minimum Path > > > MTU to a tunnel egress is MINMTU bytes (where 1280 < MINMTU < 1500= ) > > > then MINMTU can be used instead of 1280 in the fragmentation thres= hold > > > considerations listed above. > > > > > > (**) It is RECOMMENDED that no probes smaller than 1500 bytes be u= sed > > > for MTU probing purposes, since smaller probes may be fragmented i= f > > > there is a nested tunnel somewhere on the path to the egress. > > > Probe sizes larger than 1500 bytes MAY be used, but may be > > > unnecessary since original sources are expected to use [RFC4821] > > > when sending large packets. > > > > > > I think this applies to all IP-in-(foo)-in-IP tunnel types, and > > > could go as a set of generic recommendations to be cited by other doc= uments. > > > > > > Comments? > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > -----Original Message----- > > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of > > > > Templin, Fred L > > > > Sent: Thursday, May 15, 2014 3:41 PM > > > > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > > > Cc: Mark Townsley; int-area@ietf.org > > > > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3 > > > > dataplane reqts draft > > > > > > > > Hi, > > > > > > > > > -----Original Message----- > > > > > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of > > > > > Black, David > > > > > Sent: Wednesday, May 14, 2014 1:53 PM > > > > > To: tsvwg@ietf.org; tsv-area@ietf.org > > > > > Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts > > > > > draft > > > > > > > > > > > > > > > > > > > > Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 > > > > > contains some text on dealing with the fragmentation and MTU effe= cts of tunnels. > > > > > I thought I'd ask for some early review of this text, given > > > > > recent IESG excitement around fragmentation and Path MTU topics i= n another draft: > > > > > > > > All tunnels have trouble with path MTU, and in some cases have no > > > > choice but to fragment. However, they should strive to tune out > > > > fragmentation and forward whole packets whenever possible. > > > > > > > > Over in the intarea, there have been sporadic ongoing discussions > > > > about how to recommend generic MTU mitigations for tunnels. Joe > > > > Touch and Mark Townsley have been working for a long time on a > > > > document titled "Tunnels in the Internet Architecture": > > > > > > > > http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt > > > > > > > > That document should be the place to put generic recommendations > > > > for tunnel MTU handling that apply to all tunnel types. > > > > > > > > Tunnel MTU issues keep popping up in all places, and this is just > > > > another example. Is it time to revive Joe and Mark's document? > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing. > > > > > > > > > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmen > > > > > ta > > > > > ti > > > > > on/ballot/ > > > > > > > > > > I believe that the nvo3 draft is in better shape in these areas. > > > > > Nonetheless, I've included its current text on fragmentation and > > > > > path MTU below, and (on behalf of the draft authors and nvo3 WG > > > > > chairs) I'm looking for input on what that text should say and wh= y. > > > > > > > > > > In nvo3 terminology, an overlay network is an inner network that > > > > > is tunneled over an outer underlay network. The nvo3 WG also > > > > > uses "Tenant System" as the term for a sender/receiver of > > > > > network traffic because multi-tenancy is an important motivation > > > > > for the WG's activities in network > > > virtualization. > > > > > > > > > > -------------------------------------- > > > > > > > > > > 3.5. Path MTU > > > > > > > > > > The tunnel overlay header can cause the MTU of the path to= the > > > > > egress tunnel endpoint to be exceeded. > > > > > > > > > > IP fragmentation SHOULD be avoided for performance reasons= . > > > > > > > > > > The interface MTU as seen by a Tenant System SHOULD be adj= usted such > > > > > that no fragmentation is needed. This can be achieved by > > > > > configuration or be discovered dynamically. > > > > > > > > > > Either of the following options MUST be supported: > > > > > > > > > > o Classical ICMP-based MTU Path Discovery [RFC1191] [RF= C1981] or > > > > > Extended MTU Path Discovery techniques such as define= d in > > > > > [RFC4821] > > > > > > > > > > o Segmentation and reassembly support from the overlay = layer > > > > > operations without relying on the Tenant Systems to k= now about > > > > > the end-to-end MTU > > > > > > > > > > o The underlay network MAY be designed in such a way th= at the MTU > > > > > can accommodate the extra tunnel overhead. > > > > > > > > > > -------------------------------------- > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > --David > > > > > ---------------------------------------------------- > > > > > David L. Black, Distinguished Engineer EMC Corporation, 176 > > > > > South St., Hopkinton, MA=A0 01748 > > > > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (50= 8) 293-7786 > > > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-775= 4 > > > > > ---------------------------------------------------- > > > > > > > > _______________________________________________ > > > > Int-area mailing list > > > > Int-area@ietf.org > > > > https://www.ietf.org/mailman/listinfo/int-area > > > > > > _______________________________________________ > > > Int-area mailing list > > > Int-area@ietf.org > > > https://www.ietf.org/mailman/listinfo/int-area From nobody Sat May 17 09:01:47 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA361A02D7; Wed, 14 May 2014 15:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pPJyBxmMPxi; Wed, 14 May 2014 15:02:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 76B121A01FB; Wed, 14 May 2014 15:02:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT93917; Wed, 14 May 2014 22:02:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 14 May 2014 23:01:41 +0100 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 14 May 2014 23:02:39 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Wed, 14 May 2014 15:02:33 -0700 From: Linda Dunbar To: "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEwACH6cQ Date: Wed, 14 May 2014 22:02:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D09D6D@dfweml701-chm.china.huawei.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.155] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/AM6UY5-3YftgdUTXmBkqsbWIi2Y X-Mailman-Approved-At: Sat, 17 May 2014 09:01:21 -0700 Cc: "sfc@ietf.org" Subject: Re: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 22:02:50 -0000 I think that the "fragmentation and path MTU text" should be seriously disc= ussed in SFC WG that is considering Service Chain Header format.=20 I've heard people mentioning encoding the explicit Service Chain path as me= tadata to the data packet header for some scenarios where head-end SC class= ifier node determines the chain path dynamically.=20 Just imagine having IPv6 addresses encoded in the packet header to show exp= licit service chain path, which can be very long. =20 Cheers, Linda -----Original Message----- From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Black, David Sent: Wednesday, May 14, 2014 3:53 PM To: tsvwg@ietf.org; tsv-area@ietf.org Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts draft Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains som= e text on dealing with the fragmentation and MTU effects of tunnels. I thought I'd ask for some early review of this text, given recent IESG exc= itement around fragmentation and Path MTU topics in another draft: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ball= ot/=20 I believe that the nvo3 draft is in better shape in these areas. Nonethele= ss, I've included its current text on fragmentation and path MTU below, and= (on behalf of the draft authors and nvo3 WG chairs) I'm looking for input = on what that text should say and why. In nvo3 terminology, an overlay network is an inner network that is tunnele= d over an outer underlay network. The nvo3 WG also uses "Tenant System" as= the term for a sender/receiver of network traffic because multi-tenancy is= an important motivation for the WG's activities in network virtualization. -------------------------------------- 3.5. Path MTU The tunnel overlay header can cause the MTU of the path to the egress tunnel endpoint to be exceeded. =20 IP fragmentation SHOULD be avoided for performance reasons. =20 The interface MTU as seen by a Tenant System SHOULD be adjusted such that no fragmentation is needed. This can be achieved by configuration or be discovered dynamically. =20 Either of the following options MUST be supported: =20 o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or Extended MTU Path Discovery techniques such as defined in [RFC4821] =20 o Segmentation and reassembly support from the overlay layer operations without relying on the Tenant Systems to know about the end-to-end MTU =20 o The underlay network MAY be designed in such a way that the MTU can accommodate the extra tunnel overhead. -------------------------------------- Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Sat May 17 09:01:49 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81551A0213; Wed, 14 May 2014 20:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND1cvAQF1TRD; Wed, 14 May 2014 20:46:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EBA1A01E8; Wed, 14 May 2014 20:46:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU09750; Thu, 15 May 2014 03:46:25 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 04:45:25 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 04:46:24 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 15 May 2014 11:46:13 +0800 From: Xuxiaohu To: Linda Dunbar , "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: [sfc] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEwACH6cQAAisYSA= Date: Thu, 15 May 2014 03:46:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082721AF@NKGEML512-MBS.china.huawei.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> <4A95BA014132FF49AE685FAB4B9F17F645D09D6D@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D09D6D@dfweml701-chm.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/jS75pbaZQ8zbzNKNwWwS-vaNWMs X-Mailman-Approved-At: Sat, 17 May 2014 09:01:20 -0700 Cc: "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [tsvwg] [sfc] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 03:46:37 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggTGluZGEgRHVuYmFyDQo+IOWPkemAgeaXtumXtDog MjAxNOW5tDXmnIgxNeaXpSA2OjAzDQo+IOaUtuS7tuS6ujogQmxhY2ssIERhdmlkOyB0c3Z3Z0Bp ZXRmLm9yZzsgdHN2LWFyZWFAaWV0Zi5vcmcNCj4g5oqE6YCBOiBzZmNAaWV0Zi5vcmcNCj4g5Li7 6aKYOiBSZTogW3NmY10gRnJhZ21lbnRhdGlvbiBhbmQgUGF0aCBNVFUgdGV4dCBpbiBudm8zIGRh dGFwbGFuZSByZXF0cyBkcmFmdA0KPiANCj4gSSB0aGluayB0aGF0IHRoZSAiZnJhZ21lbnRhdGlv biBhbmQgcGF0aCBNVFUgdGV4dCIgc2hvdWxkIGJlIHNlcmlvdXNseSBkaXNjdXNzZWQNCj4gaW4g U0ZDIFdHIHRoYXQgaXMgY29uc2lkZXJpbmcgU2VydmljZSBDaGFpbiBIZWFkZXIgZm9ybWF0Lg0K PiANCj4gSSd2ZSBoZWFyZCBwZW9wbGUgbWVudGlvbmluZyBlbmNvZGluZyB0aGUgZXhwbGljaXQg U2VydmljZSBDaGFpbiBwYXRoIGFzDQo+IG1ldGFkYXRhIHRvIHRoZSBkYXRhIHBhY2tldCBoZWFk ZXIgZm9yIHNvbWUgc2NlbmFyaW9zIHdoZXJlIGhlYWQtZW5kIFNDDQo+IGNsYXNzaWZpZXIgbm9k ZSBkZXRlcm1pbmVzIHRoZSBjaGFpbiBwYXRoIGR5bmFtaWNhbGx5Lg0KDQpUbyBhbGxvdyB0aGUg Y2xhc3NpZmllciB0byBkZXRlcm1pbmUgdGhlIHNlcnZpY2UgcGF0aCBkeW5hbWljYWxseSwgd2h5 IG5vdCBkaXJlY3RseSBlbmNvZGluZyB0aGUgZXhwbGljaXQgc2VydmljZSBwYXRoIGluZm9ybWF0 aW9uIHdpdGhpbiB0aGUgU1IgKHNvdXJjZSByb3V0aW5nIG9yIHNlZ21lbnQgcm91dGluZykgaGVh ZGVyIChzZWUgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLXNmYy11 c2UtY2FzZS0wMCksIGVzcGVjaWFsbHkgdGhlIE1QTFMgbGFiZWwgc3RhY2sgYmFzZWQgU1IgaGVh ZGVyIGlmIE1UVSBpcyBzdGlsbCBhIGNvbmNlcm4/IA0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUN Cg0KPiBKdXN0IGltYWdpbmUgaGF2aW5nIElQdjYgYWRkcmVzc2VzIGVuY29kZWQgaW4gdGhlIHBh Y2tldCBoZWFkZXIgdG8gc2hvdw0KPiBleHBsaWNpdCBzZXJ2aWNlIGNoYWluIHBhdGgsIHdoaWNo IGNhbiBiZSB2ZXJ5IGxvbmcuDQoNCg0KPiBDaGVlcnMsDQo+IA0KPiBMaW5kYQ0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRzdi1hcmVh IFttYWlsdG86dHN2LWFyZWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJsYWNrLCBE YXZpZA0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAxNCwgMjAxNCAzOjUzIFBNDQo+IFRvOiB0c3Z3 Z0BpZXRmLm9yZzsgdHN2LWFyZWFAaWV0Zi5vcmcNCj4gU3ViamVjdDogRnJhZ21lbnRhdGlvbiBh bmQgUGF0aCBNVFUgdGV4dCBpbiBudm8zIGRhdGFwbGFuZSByZXF0cyBkcmFmdA0KPiANCj4gPFdH IGNoYWlyIGhhdCBvZmY+DQo+IA0KPiBPdmVyIGluIHRoZSBudm8zIFdHLCBkcmFmdC1pZXRmLW52 bzMtZGF0YXBsYW5lLXJlcXVpcmVtZW50cy0wMyBjb250YWlucw0KPiBzb21lIHRleHQgb24gZGVh bGluZyB3aXRoIHRoZSBmcmFnbWVudGF0aW9uIGFuZCBNVFUgZWZmZWN0cyBvZiB0dW5uZWxzLg0K PiBJIHRob3VnaHQgSSdkIGFzayBmb3Igc29tZSBlYXJseSByZXZpZXcgb2YgdGhpcyB0ZXh0LCBn aXZlbiByZWNlbnQgSUVTRyBleGNpdGVtZW50DQo+IGFyb3VuZCBmcmFnbWVudGF0aW9uIGFuZCBQ YXRoIE1UVSB0b3BpY3MgaW4gYW5vdGhlciBkcmFmdDoNCj4gDQo+IGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLWlrZXYyLWZyYWdtZW50YXRpb24vYmFs bG90Lw0KPiANCj4gSSBiZWxpZXZlIHRoYXQgdGhlIG52bzMgZHJhZnQgaXMgaW4gYmV0dGVyIHNo YXBlIGluIHRoZXNlIGFyZWFzLiAgTm9uZXRoZWxlc3MsIEkndmUNCj4gaW5jbHVkZWQgaXRzIGN1 cnJlbnQgdGV4dCBvbiBmcmFnbWVudGF0aW9uIGFuZCBwYXRoIE1UVSBiZWxvdywgYW5kIChvbiBi ZWhhbGYNCj4gb2YgdGhlIGRyYWZ0IGF1dGhvcnMgYW5kIG52bzMgV0cgY2hhaXJzKSBJJ20gbG9v a2luZyBmb3IgaW5wdXQgb24gd2hhdCB0aGF0IHRleHQNCj4gc2hvdWxkIHNheSBhbmQgd2h5Lg0K PiANCj4gSW4gbnZvMyB0ZXJtaW5vbG9neSwgYW4gb3ZlcmxheSBuZXR3b3JrIGlzIGFuIGlubmVy IG5ldHdvcmsgdGhhdCBpcyB0dW5uZWxlZA0KPiBvdmVyIGFuIG91dGVyIHVuZGVybGF5IG5ldHdv cmsuICBUaGUgbnZvMyBXRyBhbHNvIHVzZXMgIlRlbmFudCBTeXN0ZW0iIGFzDQo+IHRoZSB0ZXJt IGZvciBhIHNlbmRlci9yZWNlaXZlciBvZiBuZXR3b3JrIHRyYWZmaWMgYmVjYXVzZSBtdWx0aS10 ZW5hbmN5IGlzIGFuDQo+IGltcG9ydGFudCBtb3RpdmF0aW9uIGZvciB0aGUgV0cncyBhY3Rpdml0 aWVzIGluIG5ldHdvcmsgdmlydHVhbGl6YXRpb24uDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gMy41LiBQYXRoIE1UVQ0KPiANCj4gICAgICAgIFRo ZSB0dW5uZWwgb3ZlcmxheSBoZWFkZXIgY2FuIGNhdXNlIHRoZSBNVFUgb2YgdGhlIHBhdGggdG8g dGhlDQo+ICAgICAgICBlZ3Jlc3MgdHVubmVsIGVuZHBvaW50IHRvIGJlIGV4Y2VlZGVkLg0KPiAN Cj4gICAgICAgIElQIGZyYWdtZW50YXRpb24gU0hPVUxEIGJlIGF2b2lkZWQgZm9yIHBlcmZvcm1h bmNlIHJlYXNvbnMuDQo+IA0KPiAgICAgICAgVGhlIGludGVyZmFjZSBNVFUgYXMgc2VlbiBieSBh IFRlbmFudCBTeXN0ZW0gU0hPVUxEIGJlIGFkanVzdGVkDQo+IHN1Y2gNCj4gICAgICAgIHRoYXQg bm8gZnJhZ21lbnRhdGlvbiBpcyBuZWVkZWQuIFRoaXMgY2FuIGJlIGFjaGlldmVkIGJ5DQo+ICAg ICAgICBjb25maWd1cmF0aW9uIG9yIGJlIGRpc2NvdmVyZWQgZHluYW1pY2FsbHkuDQo+IA0KPiAg ICAgICAgRWl0aGVyIG9mIHRoZSBmb2xsb3dpbmcgb3B0aW9ucyBNVVNUIGJlIHN1cHBvcnRlZDoN Cj4gDQo+ICAgICAgICAgICBvIENsYXNzaWNhbCBJQ01QLWJhc2VkIE1UVSBQYXRoIERpc2NvdmVy eSBbUkZDMTE5MV0gW1JGQzE5ODFdIG9yDQo+ICAgICAgICAgICAgIEV4dGVuZGVkIE1UVSBQYXRo IERpc2NvdmVyeSB0ZWNobmlxdWVzIHN1Y2ggYXMgZGVmaW5lZCBpbg0KPiAgICAgICAgICAgICBb UkZDNDgyMV0NCj4gDQo+ICAgICAgICAgICBvIFNlZ21lbnRhdGlvbiBhbmQgcmVhc3NlbWJseSBz dXBwb3J0IGZyb20gdGhlIG92ZXJsYXkgbGF5ZXINCj4gICAgICAgICAgICAgb3BlcmF0aW9ucyB3 aXRob3V0IHJlbHlpbmcgb24gdGhlIFRlbmFudCBTeXN0ZW1zIHRvIGtub3cgYWJvdXQNCj4gICAg ICAgICAgICAgdGhlIGVuZC10by1lbmQgTVRVDQo+IA0KPiAgICAgICAgICAgbyBUaGUgdW5kZXJs YXkgbmV0d29yayBNQVkgYmUgZGVzaWduZWQgaW4gc3VjaCBhIHdheSB0aGF0IHRoZQ0KPiBNVFUN Cj4gICAgICAgICAgICAgY2FuIGFjY29tbW9kYXRlIHRoZSBleHRyYSB0dW5uZWwgb3ZlcmhlYWQu DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gPC9X RyBjaGFpciBoYXQgb2ZmPg0KPiANCj4gVGhhbmtzLA0KPiAtLURhdmlkDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRGF2aWQgTC4gQmxh Y2ssIERpc3Rpbmd1aXNoZWQgRW5naW5lZXINCj4gRU1DIENvcnBvcmF0aW9uLCAxNzYgU291dGgg U3QuLCBIb3BraW50b24sIE1BwqAgMDE3NDgNCj4gKzEgKDUwOCkgMjkzLTc5NTPCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgRkFYOiArMSAoNTA4KSAyOTMtNzc4Ng0KPiBkYXZpZC5ibGFja0BlbWMu Y29twqDCoMKgwqDCoMKgwqAgTW9iaWxlOiArMSAoOTc4KSAzOTQtNzc1NA0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBs aXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0K From nobody Sat May 17 09:01:50 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4451A0195; Thu, 15 May 2014 15:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge_zz0NgZoFx; Thu, 15 May 2014 15:41:13 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902891A0158; Thu, 15 May 2014 15:41:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s4FMf6pc030594; Thu, 15 May 2014 15:41:06 -0700 Received: from XCH-PHX-109.sw.nos.boeing.com (xch-phx-109.sw.nos.boeing.com [130.247.25.36]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s4FMf0Nf030277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 15 May 2014 15:41:00 -0700 Received: from XCH-BLV-506.nw.nos.boeing.com (2002:82f7:19c4::82f7:19c4) by XCH-PHX-109.sw.nos.boeing.com (2002:82f7:1924::82f7:1924) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 15 May 2014 15:40:59 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-506.nw.nos.boeing.com ([169.254.6.199]) with mapi id 14.03.0181.006; Thu, 15 May 2014 15:40:58 -0700 From: "Templin, Fred L" To: "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEwA1bjtw Date: Thu, 15 May 2014 22:40:58 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ReD1H7m5QNU2Cmu8uzcK14dbPaI X-Mailman-Approved-At: Sat, 17 May 2014 09:01:03 -0700 Cc: Mark Townsley , "int-area@ietf.org" , Joe Touch Subject: Re: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 22:41:16 -0000 X-List-Received-Date: Thu, 15 May 2014 22:41:16 -0000 Hi, > -----Original Message----- > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Black, Dav= id > Sent: Wednesday, May 14, 2014 1:53 PM > To: tsvwg@ietf.org; tsv-area@ietf.org > Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts draft >=20 > >=20 > Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains > some text on dealing with the fragmentation and MTU effects of tunnels. > I thought I'd ask for some early review of this text, given recent IESG > excitement around fragmentation and Path MTU topics in another draft: All tunnels have trouble with path MTU, and in some cases have no choice but to fragment. However, they should strive to tune out fragmentation and forward whole packets whenever possible. Over in the intarea, there have been sporadic ongoing discussions about how to recommend generic MTU mitigations for tunnels. Joe Touch and Mark Townsley have been working for a long time on a document titled "Tunnels in the Internet Architecture": http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt That document should be the place to put generic recommendations for tunnel MTU handling that apply to all tunnel types. Tunnel MTU issues keep popping up in all places, and this is just another example. Is it time to revive Joe and Mark's document? Thanks - Fred fred.l.templin@boeing.=20 > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ba= llot/ >=20 > I believe that the nvo3 draft is in better shape in these areas. Nonethe= less, > I've included its current text on fragmentation and path MTU below, and (= on > behalf of the draft authors and nvo3 WG chairs) I'm looking for input on > what that text should say and why. >=20 > In nvo3 terminology, an overlay network is an inner network that is tunne= led > over an outer underlay network. The nvo3 WG also uses "Tenant System" as > the term for a sender/receiver of network traffic because multi-tenancy i= s > an important motivation for the WG's activities in network virtualization= . >=20 > -------------------------------------- >=20 > 3.5. Path MTU >=20 > The tunnel overlay header can cause the MTU of the path to the > egress tunnel endpoint to be exceeded. >=20 > IP fragmentation SHOULD be avoided for performance reasons. >=20 > The interface MTU as seen by a Tenant System SHOULD be adjusted su= ch > that no fragmentation is needed. This can be achieved by > configuration or be discovered dynamically. >=20 > Either of the following options MUST be supported: >=20 > o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] o= r > Extended MTU Path Discovery techniques such as defined in > [RFC4821] >=20 > o Segmentation and reassembly support from the overlay layer > operations without relying on the Tenant Systems to know abou= t > the end-to-end MTU >=20 > o The underlay network MAY be designed in such a way that the M= TU > can accommodate the extra tunnel overhead. >=20 > -------------------------------------- >=20 > >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From nobody Sat May 17 09:01:51 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900321A00EA; Fri, 16 May 2014 11:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18HE9YlAbHSb; Fri, 16 May 2014 11:56:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6C61A0147; Fri, 16 May 2014 11:56:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEF61684; Fri, 16 May 2014 18:56:26 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 19:55:21 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 19:56:25 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml703-chm.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0158.001; Fri, 16 May 2014 11:56:13 -0700 From: Linda Dunbar To: "Templin, Fred L" , "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEwA1bjtwADjCOwAADdAtAA== Date: Fri, 16 May 2014 18:56:14 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D0B178@dfweml701-chm.china.huawei.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2AD6AE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2AD6AE@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.197] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/L2i2xleH6EFith98rsF_IRM6WeE X-Mailman-Approved-At: Sat, 17 May 2014 09:01:21 -0700 Cc: Mark Townsley , "int-area@ietf.org" Subject: Re: [tsvwg] [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 18:56:39 -0000 I am confused of the math here. If most physical links MTU is 1500 bytes (o= r 2000 bytes for some), how do we have""4GB"" minus the encapsulation overh= ead for IPv6, as the "tunnel link Maximum Transmission Unit (MTU)".=20 Is 4GB correct ??? Linda=20 -----Original Message----- From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, Fre= d L Sent: Friday, May 16, 2014 1:28 PM To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org Cc: Mark Townsley; int-area@ietf.org Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane r= eqts draft > That document should be the place to put generic recommendations for=20 > tunnel MTU handling that apply to all tunnel types. In case you are wondering what I think "generic recommendations for tunnel = MTU handling" should look like, here is what I think: The tunnel link Maximum Transmission Unit (MTU) is 64KB minus the encapsulation overhead for IPv4 [RFC0791] and 4GB minus the encapsulation overhead for IPv6 [RFC2675]. This is the most that IPv4 and IPv6 (respectively) can convey within the constraints of protocol constants, but actual sizes available for tunneling will frequently be much smaller. The base tunneling specifications for IPv4 and IPv6 typically set a static MTU on the tunnel ingress to 1500 bytes minus the encapsulation overhead or smaller still if the tunnel is likely to incur additional encapsulations on the path. This can result in path MTU related black holes when packets that are too large to be accommodated over the tunnel are dropped, but the resulting ICMP Packet Too Big (PTB) messages are lost on the return path. As a result, tunnels use the following MTU mitigations to accommodate larger packets. Tunnels set their ingress MTU to the larger of the underlying interface MTU minus the encapsulation overhead, and 1500 bytes. Tunnels optionally cache per-egress MTU values in the underlying IP path MTU discovery cache initialized to the underlying interface MTU. Tunnels admit packets that are no larger than 1280 bytes minus the encapsulation overhead (*) as well as packets that are larger than 1500 bytes into the tunnel without fragmentation, i.e., as long as they are no larger than the tunnel ingress MTU before encapsulation and also no larger than the cached per-egress MTU following encapsulation. For IPv4, the ingress sets the "Don't Fragment" (DF) bit to 0 for packets no larger than 1280 bytes minus the encapsulation overhead (*) and sets the DF bit to 1 for packets larger than 1500 bytes. If a large packet is lost in the path, the ingress may optionally cache the MTU reported in the resulting PTB message or may ignore the message, e.g., if there is a possibility that the message is spurious. For packets admitted into the tunnel that are larger than 1280 bytes minus the encapsulation overhead (*) but no larger than 1500 bytes, the ingress uses IP fragmentation to fragment the encapsulated packet into two pieces (where the first fragment contains 1024 bytes of the fragmented inner packet) then sends the fragments to the egress. If the outer protocol is IPv4, the node sends the fragments with DF set to 0 and subject to rate limiting to avoid reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the ingress also sends a 1500 byte probe message (**) to the egress, subject to rate limiting. To construct a probe, the ingress prepares an ICMPv6 Neighbor Solicitation (NS) message with trailing padding octets added to a length of 1500 bytes but does not include the length of the padding in the IPv6 Payload Length field. The ingress then encapsulates the NS in the outer encapsulation headers (while including the length of the padding in the outer length fields), sets DF to 1 (for IPv4) and sends the padded NS message to the neighbor. If the egress returns an NA message, the ingress may then send whole packets within this size range and (for IPv4) relax the rate limiting requirement. (Note that for tunnels that do not perform IPv6 neighbor discovery, an ICMP echo request message can be used instead of NS.)=20 The egress MUST be capable of reassembling packets up to 1500 bytes plus the encapsulation overhead length. It is therefore RECOMMENDED that the egress be capable of reassembling at least 2KB. (*) Note that if it is known without probing that the minimum Path MTU to a tunnel egress is MINMTU bytes (where 1280 < MINMTU < 1500) then MINMTU can be used instead of 1280 in the fragmentation threshold considerations listed above. (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used for MTU probing purposes, since smaller probes may be fragmented if there is a nested tunnel somewhere on the path to the egress. Probe sizes larger than 1500 bytes MAY be used, but may be unnecessary since original sources are expected to use [RFC4821] when sending large packets. I think this applies to all IP-in-(foo)-in-IP tunnel types, and could go as= a set of generic recommendations to be cited by other documents. Comments? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of=20 > Templin, Fred L > Sent: Thursday, May 15, 2014 3:41 PM > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3=20 > dataplane reqts draft >=20 > Hi, >=20 > > -----Original Message----- > > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of=20 > > Black, David > > Sent: Wednesday, May 14, 2014 1:53 PM > > To: tsvwg@ietf.org; tsv-area@ietf.org > > Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts=20 > > draft > > > > > > > > Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03=20 > > contains some text on dealing with the fragmentation and MTU effects of= tunnels. > > I thought I'd ask for some early review of this text, given recent=20 > > IESG excitement around fragmentation and Path MTU topics in another dra= ft: >=20 > All tunnels have trouble with path MTU, and in some cases have no=20 > choice but to fragment. However, they should strive to tune out=20 > fragmentation and forward whole packets whenever possible. >=20 > Over in the intarea, there have been sporadic ongoing discussions=20 > about how to recommend generic MTU mitigations for tunnels. Joe Touch=20 > and Mark Townsley have been working for a long time on a document=20 > titled "Tunnels in the Internet Architecture": >=20 > http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt >=20 > That document should be the place to put generic recommendations for=20 > tunnel MTU handling that apply to all tunnel types. >=20 > Tunnel MTU issues keep popping up in all places, and this is just=20 > another example. Is it time to revive Joe and Mark's document? >=20 > Thanks - Fred > fred.l.templin@boeing. >=20 > > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentati > > on/ballot/ > > > > I believe that the nvo3 draft is in better shape in these areas. =20 > > Nonetheless, I've included its current text on fragmentation and=20 > > path MTU below, and (on behalf of the draft authors and nvo3 WG=20 > > chairs) I'm looking for input on what that text should say and why. > > > > In nvo3 terminology, an overlay network is an inner network that is=20 > > tunneled over an outer underlay network. The nvo3 WG also uses=20 > > "Tenant System" as the term for a sender/receiver of network traffic=20 > > because multi-tenancy is an important motivation for the WG's activitie= s in network virtualization. > > > > -------------------------------------- > > > > 3.5. Path MTU > > > > The tunnel overlay header can cause the MTU of the path to the > > egress tunnel endpoint to be exceeded. > > > > IP fragmentation SHOULD be avoided for performance reasons. > > > > The interface MTU as seen by a Tenant System SHOULD be adjusted = such > > that no fragmentation is needed. This can be achieved by > > configuration or be discovered dynamically. > > > > Either of the following options MUST be supported: > > > > o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981]= or > > Extended MTU Path Discovery techniques such as defined in > > [RFC4821] > > > > o Segmentation and reassembly support from the overlay layer > > operations without relying on the Tenant Systems to know ab= out > > the end-to-end MTU > > > > o The underlay network MAY be designed in such a way that the= MTU > > can accommodate the extra tunnel overhead. > > > > -------------------------------------- > > > > > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer EMC Corporation, 176 South=20 > > St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From nobody Sat May 17 09:01:53 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596DF1A015D; Fri, 16 May 2014 13:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbtGW1bffxM4; Fri, 16 May 2014 13:02:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D361A0167; Fri, 16 May 2014 13:02:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGV77907; Fri, 16 May 2014 20:02:18 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 21:01:14 +0100 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 21:02:17 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Fri, 16 May 2014 13:02:09 -0700 From: Linda Dunbar To: "Templin, Fred L" , "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEwA1bjtwADjCOwAADdAtAP//nTSAgABoWoA= Date: Fri, 16 May 2014 20:02:09 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D0B464@dfweml701-chm.china.huawei.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2AD6AE@XCH-BLV-504.nw.nos.boeing.com> <4A95BA014132FF49AE685FAB4B9F17F645D0B178@dfweml701-chm.china.huawei.com> <2134F8430051B64F815C691A62D983181B2AD82D@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2AD82D@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.197] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/ADLuNpciGT5xirI6CuRthjCNQCE X-Mailman-Approved-At: Sat, 17 May 2014 09:01:22 -0700 Cc: Mark Townsley , "int-area@ietf.org" Subject: Re: [tsvwg] [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 20:02:32 -0000 Can we challenge the 4GB MTU size recommendation by RFC2675? Network consis= ts of nodes and links. The MTU of a network should be limited by the MTU of= the links.=20 With 4GB MTU recommendation, it would require the network ingress node to f= ragment packets and egress node to reassemble packets. =20 If the network ingress can fragment and egress can reassemble packets, ther= e is no need to define the network MTU size. Therefore, this recommendation= is meaningless.=20 Linda -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Friday, May 16, 2014 2:10 PM To: Linda Dunbar; Black, David; tsvwg@ietf.org; tsv-area@ietf.org Cc: Mark Townsley; int-area@ietf.org Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane r= eqts draft Hi Linda, The maximum MTU for an IPv4 link is 64KB (per RFC0791) and the maximum MTU = for an IPv6 link is 4GB (per RFC2675). For tunnels over IPv4, the IPv4 network itself is the link layer for the tunnel. For tunnels over IPv6= , the IPv6 network is the link-layer. That means that the largest encapsula= ted packet that will fit over an IPv4 "link" is 64KB minus the encapsulatio= n overhead, and the largest over an IPv6 "link" is 4GB minus overhead. But,= typical values will be much smaller than this because most underlying link= s configure smaller MTUs. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Friday, May 16, 2014 11:56 AM > To: Templin, Fred L; Black, David; tsvwg@ietf.org; tsv-area@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3=20 > dataplane reqts draft >=20 > I am confused of the math here. If most physical links MTU is 1500=20 > bytes (or 2000 bytes for some), how do we have""4GB"" minus the=20 > encapsulation overhead for IPv6, as the "tunnel link Maximum Transmission= Unit (MTU)". >=20 > Is 4GB correct ??? >=20 > Linda >=20 > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of=20 > Templin, Fred L > Sent: Friday, May 16, 2014 1:28 PM > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3=20 > dataplane reqts draft >=20 > > That document should be the place to put generic recommendations for=20 > > tunnel MTU handling that apply to all tunnel types. >=20 > In case you are wondering what I think "generic recommendations for=20 > tunnel MTU handling" should look like, here is what I think: >=20 > The tunnel link Maximum Transmission Unit (MTU) is 64KB minus the > encapsulation overhead for IPv4 [RFC0791] and 4GB minus the > encapsulation overhead for IPv6 [RFC2675]. This is the most that > IPv4 and IPv6 (respectively) can convey within the constraints of > protocol constants, but actual sizes available for tunneling will > frequently be much smaller. >=20 > The base tunneling specifications for IPv4 and IPv6 typically set a > static MTU on the tunnel ingress to 1500 bytes minus the > encapsulation overhead or smaller still if the tunnel is likely to > incur additional encapsulations on the path. This can result in path > MTU related black holes when packets that are too large to be > accommodated over the tunnel are dropped, but the resulting ICMP > Packet Too Big (PTB) messages are lost on the return path. As a > result, tunnels use the following MTU mitigations to accommodate > larger packets. >=20 > Tunnels set their ingress MTU to the larger of the > underlying interface MTU minus the encapsulation overhead, and 1500 > bytes. Tunnels optionally cache per-egress MTU values in > the underlying IP path MTU discovery cache initialized to the > underlying interface MTU. >=20 > Tunnels admit packets that are no larger than 1280 bytes minus the > encapsulation overhead (*) as well as packets that are larger than > 1500 bytes into the tunnel without fragmentation, i.e., as long as > they are no larger than the tunnel ingress MTU before encapsulation > and also no larger than the cached per-egress MTU following > encapsulation. For IPv4, the ingress sets the "Don't Fragment" (DF) > bit to 0 for packets no larger than 1280 bytes minus the encapsulation > overhead (*) and sets the DF bit to 1 for packets larger than 1500 > bytes. If a large packet is lost in the path, the ingress may > optionally cache the MTU reported in the resulting PTB message or may > ignore the message, e.g., if there is a possibility that the message > is spurious. >=20 > For packets admitted into the tunnel that are larger than 1280 bytes > minus the encapsulation overhead (*) but no larger than 1500 bytes, > the ingress uses IP fragmentation to fragment the encapsulated packet > into two pieces (where the first fragment contains 1024 bytes of the > fragmented inner packet) then sends the fragments to the egress. > If the outer protocol is IPv4, the node sends the fragments with > DF set to 0 and subject to rate limiting to avoid > reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the > ingress also sends a 1500 byte probe message (**) to the egress, > subject to rate limiting. To construct a probe, the ingress prepares > an ICMPv6 Neighbor Solicitation (NS) message with trailing padding > octets added to a length of 1500 bytes but does not include the > length of the padding in the IPv6 Payload Length field. The ingress > then encapsulates the NS in the outer encapsulation headers (while > including the length of the padding in the outer length fields), sets > DF to 1 (for IPv4) and sends the padded NS message to the neighbor. > If the egress returns an NA message, the ingress may then send whole > packets within this size range and (for IPv4) relax the rate limiting > requirement. (Note that for tunnels that do not perform IPv6 neighbor > discovery, an ICMP echo request message can be used instead of NS.) >=20 > The egress MUST be capable of reassembling packets up to 1500 bytes > plus the encapsulation overhead length. It is therefore RECOMMENDED > that the egress be capable of reassembling at least 2KB. >=20 > (*) Note that if it is known without probing that the minimum Path > MTU to a tunnel egress is MINMTU bytes (where 1280 < MINMTU < 1500) > then MINMTU can be used instead of 1280 in the fragmentation threshold > considerations listed above. >=20 > (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used > for MTU probing purposes, since smaller probes may be fragmented if > there is a nested tunnel somewhere on the path to the egress. > Probe sizes larger than 1500 bytes MAY be used, but may be > unnecessary since original sources are expected to use [RFC4821] > when sending large packets. >=20 > I think this applies to all IP-in-(foo)-in-IP tunnel types, and could=20 > go as a set of generic recommendations to be cited by other documents. >=20 > Comments? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of=20 > > Templin, Fred L > > Sent: Thursday, May 15, 2014 3:41 PM > > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > Cc: Mark Townsley; int-area@ietf.org > > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3=20 > > dataplane reqts draft > > > > Hi, > > > > > -----Original Message----- > > > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of=20 > > > Black, David > > > Sent: Wednesday, May 14, 2014 1:53 PM > > > To: tsvwg@ietf.org; tsv-area@ietf.org > > > Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts=20 > > > draft > > > > > > > > > > > > Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 > > > contains some text on dealing with the fragmentation and MTU effects = of tunnels. > > > I thought I'd ask for some early review of this text, given recent=20 > > > IESG excitement around fragmentation and Path MTU topics in another d= raft: > > > > All tunnels have trouble with path MTU, and in some cases have no=20 > > choice but to fragment. However, they should strive to tune out=20 > > fragmentation and forward whole packets whenever possible. > > > > Over in the intarea, there have been sporadic ongoing discussions=20 > > about how to recommend generic MTU mitigations for tunnels. Joe=20 > > Touch and Mark Townsley have been working for a long time on a=20 > > document titled "Tunnels in the Internet Architecture": > > > > http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt > > > > That document should be the place to put generic recommendations for=20 > > tunnel MTU handling that apply to all tunnel types. > > > > Tunnel MTU issues keep popping up in all places, and this is just=20 > > another example. Is it time to revive Joe and Mark's document? > > > > Thanks - Fred > > fred.l.templin@boeing. > > > > > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmenta > > > ti > > > on/ballot/ > > > > > > I believe that the nvo3 draft is in better shape in these areas. > > > Nonetheless, I've included its current text on fragmentation and=20 > > > path MTU below, and (on behalf of the draft authors and nvo3 WG > > > chairs) I'm looking for input on what that text should say and why. > > > > > > In nvo3 terminology, an overlay network is an inner network that=20 > > > is tunneled over an outer underlay network. The nvo3 WG also uses=20 > > > "Tenant System" as the term for a sender/receiver of network=20 > > > traffic because multi-tenancy is an important motivation for the=20 > > > WG's activities in network > virtualization. > > > > > > -------------------------------------- > > > > > > 3.5. Path MTU > > > > > > The tunnel overlay header can cause the MTU of the path to the > > > egress tunnel endpoint to be exceeded. > > > > > > IP fragmentation SHOULD be avoided for performance reasons. > > > > > > The interface MTU as seen by a Tenant System SHOULD be adjuste= d such > > > that no fragmentation is needed. This can be achieved by > > > configuration or be discovered dynamically. > > > > > > Either of the following options MUST be supported: > > > > > > o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC198= 1] or > > > Extended MTU Path Discovery techniques such as defined in > > > [RFC4821] > > > > > > o Segmentation and reassembly support from the overlay laye= r > > > operations without relying on the Tenant Systems to know = about > > > the end-to-end MTU > > > > > > o The underlay network MAY be designed in such a way that t= he MTU > > > can accommodate the extra tunnel overhead. > > > > > > -------------------------------------- > > > > > > > > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South=20 > > > St., Hopkinton, MA=A0 01748 > > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 2= 93-7786 > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Sat May 17 09:01:55 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9198B1A033A; Fri, 16 May 2014 13:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAuMKWPUt2dW; Fri, 16 May 2014 13:45:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9433D1A032F; Fri, 16 May 2014 13:45:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEF66024; Fri, 16 May 2014 20:45:35 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 21:44:30 +0100 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 16 May 2014 21:45:34 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml704-chm.china.huawei.com ([169.254.6.56]) with mapi id 14.03.0158.001; Fri, 16 May 2014 13:45:19 -0700 From: Linda Dunbar To: "Templin, Fred L" , "Black, David" , "tsvwg@ietf.org" , "tsv-area@ietf.org" Thread-Topic: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft Thread-Index: Ac9vtnHd0ZAyZrcySACl53YRIUspEwA1bjtwADjCOwAADdAtAP//nTSAgABoWoD//6l6gIAAbvCA Date: Fri, 16 May 2014 20:45:18 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D0B4EC@dfweml701-chm.china.huawei.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55B7B1@MX15A.corp.emc.com> <2134F8430051B64F815C691A62D983181B2AC94E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983181B2AD6AE@XCH-BLV-504.nw.nos.boeing.com> <4A95BA014132FF49AE685FAB4B9F17F645D0B178@dfweml701-chm.china.huawei.com> <2134F8430051B64F815C691A62D983181B2AD82D@XCH-BLV-504.nw.nos.boeing.com> <4A95BA014132FF49AE685FAB4B9F17F645D0B464@dfweml701-chm.china.huawei.com> <2134F8430051B64F815C691A62D983181B2ADA4E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2ADA4E@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.197] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/jlMD774GP_hzn3K1GG3IFx1FWUI X-Mailman-Approved-At: Sat, 17 May 2014 09:01:22 -0700 Cc: Mark Townsley , "int-area@ietf.org" Subject: Re: [tsvwg] [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 20:45:51 -0000 Fred,=20 Thanks for the clarification.=20 Since the topic is about tunneling, a.k.a. encapsulating additional headers= to data packets that increases the risk of exceeding link MTU, we should f= ocus on the Path MTU, not the network Layer MTU.=20 So we shouldn't use the 64K/4GB recommended by RFC2675 for "The tunnel link= Maximum Transmission Unit" Linda -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 No, if you look further into my text you will see that we will never allow = fragmentation for packets larger than 1500 bytes; anything larger will go a= s an unfragmented whole packet or will be dropped at a link within the tunn= el that configures an insufficient MTU. 64KB/4GB are not "recommendations"; they are protocol constants. > If the network ingress can fragment and egress can reassemble packets,=20 > there is no need to define the network MTU size. Therefore, this recommen= dation is meaningless. Fragmentation and reassembly limit is 1500 bytes; larger packets go through= unfragmented or not at all. Take care of the smalls, and let the bigs take= care of themselves. Thanks - Fred fred.l.templin@boeing.com =20 > Linda >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Friday, May 16, 2014 2:10 PM > To: Linda Dunbar; Black, David; tsvwg@ietf.org; tsv-area@ietf.org > Cc: Mark Townsley; int-area@ietf.org > Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3=20 > dataplane reqts draft >=20 > Hi Linda, >=20 > The maximum MTU for an IPv4 link is 64KB (per RFC0791) and the maximum=20 > MTU for an IPv6 link is 4GB (per RFC2675). For tunnels over IPv4, the > IPv4 network itself is the link layer for the tunnel. For tunnels over=20 > IPv6, the IPv6 network is the link-layer. That means that the largest=20 > encapsulated packet that will fit over an IPv4 "link" is 64KB minus=20 > the encapsulation overhead, and the largest over an IPv6 "link" is 4GB mi= nus overhead. But, typical values will be much smaller than this because mo= st underlying links configure smaller MTUs. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > Sent: Friday, May 16, 2014 11:56 AM > > To: Templin, Fred L; Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > Cc: Mark Townsley; int-area@ietf.org > > Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3=20 > > dataplane reqts draft > > > > I am confused of the math here. If most physical links MTU is 1500=20 > > bytes (or 2000 bytes for some), how do we have""4GB"" minus the=20 > > encapsulation overhead for IPv6, as the "tunnel link Maximum Transmissi= on Unit (MTU)". > > > > Is 4GB correct ??? > > > > Linda > > > > -----Original Message----- > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of=20 > > Templin, Fred L > > Sent: Friday, May 16, 2014 1:28 PM > > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > Cc: Mark Townsley; int-area@ietf.org > > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3=20 > > dataplane reqts draft > > > > > That document should be the place to put generic recommendations=20 > > > for tunnel MTU handling that apply to all tunnel types. > > > > In case you are wondering what I think "generic recommendations for=20 > > tunnel MTU handling" should look like, here is what I think: > > > > The tunnel link Maximum Transmission Unit (MTU) is 64KB minus the > > encapsulation overhead for IPv4 [RFC0791] and 4GB minus the > > encapsulation overhead for IPv6 [RFC2675]. This is the most that > > IPv4 and IPv6 (respectively) can convey within the constraints of > > protocol constants, but actual sizes available for tunneling will > > frequently be much smaller. > > > > The base tunneling specifications for IPv4 and IPv6 typically set a > > static MTU on the tunnel ingress to 1500 bytes minus the > > encapsulation overhead or smaller still if the tunnel is likely to > > incur additional encapsulations on the path. This can result in pat= h > > MTU related black holes when packets that are too large to be > > accommodated over the tunnel are dropped, but the resulting ICMP > > Packet Too Big (PTB) messages are lost on the return path. As a > > result, tunnels use the following MTU mitigations to accommodate > > larger packets. > > > > Tunnels set their ingress MTU to the larger of the > > underlying interface MTU minus the encapsulation overhead, and 1500 > > bytes. Tunnels optionally cache per-egress MTU values in > > the underlying IP path MTU discovery cache initialized to the > > underlying interface MTU. > > > > Tunnels admit packets that are no larger than 1280 bytes minus the > > encapsulation overhead (*) as well as packets that are larger than > > 1500 bytes into the tunnel without fragmentation, i.e., as long as > > they are no larger than the tunnel ingress MTU before encapsulation > > and also no larger than the cached per-egress MTU following > > encapsulation. For IPv4, the ingress sets the "Don't Fragment" (DF) > > bit to 0 for packets no larger than 1280 bytes minus the encapsulati= on > > overhead (*) and sets the DF bit to 1 for packets larger than 1500 > > bytes. If a large packet is lost in the path, the ingress may > > optionally cache the MTU reported in the resulting PTB message or ma= y > > ignore the message, e.g., if there is a possibility that the message > > is spurious. > > > > For packets admitted into the tunnel that are larger than 1280 bytes > > minus the encapsulation overhead (*) but no larger than 1500 bytes, > > the ingress uses IP fragmentation to fragment the encapsulated packe= t > > into two pieces (where the first fragment contains 1024 bytes of the > > fragmented inner packet) then sends the fragments to the egress. > > If the outer protocol is IPv4, the node sends the fragments with > > DF set to 0 and subject to rate limiting to avoid > > reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the > > ingress also sends a 1500 byte probe message (**) to the egress, > > subject to rate limiting. To construct a probe, the ingress prepares > > an ICMPv6 Neighbor Solicitation (NS) message with trailing padding > > octets added to a length of 1500 bytes but does not include the > > length of the padding in the IPv6 Payload Length field. The ingress > > then encapsulates the NS in the outer encapsulation headers (while > > including the length of the padding in the outer length fields), set= s > > DF to 1 (for IPv4) and sends the padded NS message to the neighbor. > > If the egress returns an NA message, the ingress may then send whole > > packets within this size range and (for IPv4) relax the rate limitin= g > > requirement. (Note that for tunnels that do not perform IPv6 neighbo= r > > discovery, an ICMP echo request message can be used instead of=20 > > NS.) > > > > The egress MUST be capable of reassembling packets up to 1500 bytes > > plus the encapsulation overhead length. It is therefore RECOMMENDED > > that the egress be capable of reassembling at least 2KB. > > > > (*) Note that if it is known without probing that the minimum Path > > MTU to a tunnel egress is MINMTU bytes (where 1280 < MINMTU < 1500) > > then MINMTU can be used instead of 1280 in the fragmentation thresho= ld > > considerations listed above. > > > > (**) It is RECOMMENDED that no probes smaller than 1500 bytes be use= d > > for MTU probing purposes, since smaller probes may be fragmented if > > there is a nested tunnel somewhere on the path to the egress. > > Probe sizes larger than 1500 bytes MAY be used, but may be > > unnecessary since original sources are expected to use [RFC4821] > > when sending large packets. > > > > I think this applies to all IP-in-(foo)-in-IP tunnel types, and=20 > > could go as a set of generic recommendations to be cited by other docum= ents. > > > > Comments? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > -----Original Message----- > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of=20 > > > Templin, Fred L > > > Sent: Thursday, May 15, 2014 3:41 PM > > > To: Black, David; tsvwg@ietf.org; tsv-area@ietf.org > > > Cc: Mark Townsley; int-area@ietf.org > > > Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3=20 > > > dataplane reqts draft > > > > > > Hi, > > > > > > > -----Original Message----- > > > > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of=20 > > > > Black, David > > > > Sent: Wednesday, May 14, 2014 1:53 PM > > > > To: tsvwg@ietf.org; tsv-area@ietf.org > > > > Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts=20 > > > > draft > > > > > > > > > > > > > > > > Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 > > > > contains some text on dealing with the fragmentation and MTU effect= s of tunnels. > > > > I thought I'd ask for some early review of this text, given=20 > > > > recent IESG excitement around fragmentation and Path MTU topics in = another draft: > > > > > > All tunnels have trouble with path MTU, and in some cases have no=20 > > > choice but to fragment. However, they should strive to tune out=20 > > > fragmentation and forward whole packets whenever possible. > > > > > > Over in the intarea, there have been sporadic ongoing discussions=20 > > > about how to recommend generic MTU mitigations for tunnels. Joe=20 > > > Touch and Mark Townsley have been working for a long time on a=20 > > > document titled "Tunnels in the Internet Architecture": > > > > > > http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt > > > > > > That document should be the place to put generic recommendations=20 > > > for tunnel MTU handling that apply to all tunnel types. > > > > > > Tunnel MTU issues keep popping up in all places, and this is just=20 > > > another example. Is it time to revive Joe and Mark's document? > > > > > > Thanks - Fred > > > fred.l.templin@boeing. > > > > > > > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmen > > > > ta > > > > ti > > > > on/ballot/ > > > > > > > > I believe that the nvo3 draft is in better shape in these areas. > > > > Nonetheless, I've included its current text on fragmentation and=20 > > > > path MTU below, and (on behalf of the draft authors and nvo3 WG > > > > chairs) I'm looking for input on what that text should say and why. > > > > > > > > In nvo3 terminology, an overlay network is an inner network that=20 > > > > is tunneled over an outer underlay network. The nvo3 WG also=20 > > > > uses "Tenant System" as the term for a sender/receiver of=20 > > > > network traffic because multi-tenancy is an important motivation=20 > > > > for the WG's activities in network > > virtualization. > > > > > > > > -------------------------------------- > > > > > > > > 3.5. Path MTU > > > > > > > > The tunnel overlay header can cause the MTU of the path to t= he > > > > egress tunnel endpoint to be exceeded. > > > > > > > > IP fragmentation SHOULD be avoided for performance reasons. > > > > > > > > The interface MTU as seen by a Tenant System SHOULD be adjus= ted such > > > > that no fragmentation is needed. This can be achieved by > > > > configuration or be discovered dynamically. > > > > > > > > Either of the following options MUST be supported: > > > > > > > > o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1= 981] or > > > > Extended MTU Path Discovery techniques such as defined = in > > > > [RFC4821] > > > > > > > > o Segmentation and reassembly support from the overlay la= yer > > > > operations without relying on the Tenant Systems to kno= w about > > > > the end-to-end MTU > > > > > > > > o The underlay network MAY be designed in such a way that= the MTU > > > > can accommodate the extra tunnel overhead. > > > > > > > > -------------------------------------- > > > > > > > > > > > > > > > > Thanks, > > > > --David > > > > ---------------------------------------------------- > > > > David L. Black, Distinguished Engineer EMC Corporation, 176=20 > > > > South St., Hopkinton, MA=A0 01748 > > > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508)= 293-7786 > > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > > ---------------------------------------------------- > > > > > > _______________________________________________ > > > Int-area mailing list > > > Int-area@ietf.org > > > https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue May 20 01:23:26 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A281A0495 for ; Tue, 20 May 2014 01:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afgWpOhSQXU5 for ; Tue, 20 May 2014 01:23:23 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 43DBD1A04A4 for ; Tue, 20 May 2014 01:23:23 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0BC452B44C7; Tue, 20 May 2014 09:23:21 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 20 May 2014 09:23:21 +0100 Message-ID: <824f22194e3f478f1aaea378d2ea479e.squirrel@www.erg.abdn.ac.uk> Date: Tue, 20 May 2014 09:23:21 +0100 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/sWIRJpLpItUo1cb2WCD9rvhKKjo Cc: gorry@erg.abdn.ac.uk Subject: [tsvwg] Comments on SCTP PR policies draft (-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 08:23:25 -0000 I have read the SCTP PR policies draft (draft-ietf-tsvwg-sctp-prpolicies-02). This is short and was an easy read, but I have few comments noted below, and one question. Best wishes, Gorry --- Section 2: /This section defined/This section defines/ I think this section needs RFC 2119 language - see below, because it defines protocol mechanisms. Section 2.1 /The sender must abandon a user message...//The sender MUST abandon a user message.../ /includes the fast and the timer based/includes both fast and timer-based/ /Limiting the number of retransmissions to 0 is allowed. / The sender MAY limit the number of retransmissions to 0./ /send any retransmissions either./perform any retransmissions./ /in the WebRTC protocol stack./ - REF needed to this usage. Section 2.2 /the SCTP stack may abandon other user messages/ - I understand this as a sender-side change, if this is so please be explicit, otherwise please explain. /stack may abandon/stack MAY abandon/ /or failing the send call (if used in non-blocking mode)./ - unclear to me: does this mean the send call fails? Section 3.1 /in [RFC6458]/in [RFC6458]./ --- Question on 2.2/security model - I assume that this mechanism can take transmit opportunity away from other flows, hence in theory starving another SCTP association of resource. If this is so, can it be used on a host to mount a DOS attack on another flow originating from the same sender? - This doesn't seem serious, given the attacker already needs access to the sending host. --- From nobody Tue May 20 01:46:21 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0A91A04C5 for ; Tue, 20 May 2014 01:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_YOU_CAN_BECOME=1.258, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7L-sB5GJzHh for ; Tue, 20 May 2014 01:46:19 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF6E1A02F3 for ; Tue, 20 May 2014 01:46:18 -0700 (PDT) Received: from [192.168.1.102] (p5481887C.dip0.t-ipconnect.de [84.129.136.124]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 2B2C41C104D8F; Tue, 20 May 2014 10:46:15 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen X-Priority: 3 (Normal) In-Reply-To: <824f22194e3f478f1aaea378d2ea479e.squirrel@www.erg.abdn.ac.uk> Date: Tue, 20 May 2014 10:46:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5EE78EA2-29A6-4389-B844-ADFB6ED06144@lurchi.franken.de> References: <824f22194e3f478f1aaea378d2ea479e.squirrel@www.erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/FgEZEn2V3zoExhR_DcpLiad82zw Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Comments on SCTP PR policies draft (-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 08:46:21 -0000 On 20 May 2014, at 10:23, gorry@erg.abdn.ac.uk wrote: > I have read the SCTP PR policies draft > (draft-ietf-tsvwg-sctp-prpolicies-02). This is short and was an easy = read, > but I have few comments noted below, and one question. Hi Gorry, thank you very much for your comments. See me responses in-line. Best regards Michael >=20 > Best wishes, >=20 > Gorry >=20 > --- >=20 > Section 2: >=20 > /This section defined/This section defines/ Fixed. >=20 > I think this section needs RFC 2119 language - see below, because it > defines protocol mechanisms. That implies changing the document from Informational to Proposed = Standard. Is that OK? I'm happy to do that... We even reference this document in the normative reference section of a document targeting for PS. >=20 > Section 2.1 >=20 > /The sender must abandon a user message...//The sender MUST abandon a = user > message.../ I agree, but we need to head for PS then... >=20 > /includes the fast and the timer based/includes both fast and = timer-based/ Fixed. >=20 > /Limiting the number of retransmissions to 0 is allowed. / > The sender MAY limit the number of retransmissions to 0./ Same as above. PS OK? >=20 >=20 > /send any retransmissions either./perform any retransmissions./ Fixed. >=20 > /in the WebRTC protocol stack./ > - REF needed to this usage. Added reference to = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-09 which has also a normative reference to this ID. >=20 > Section 2.2 >=20 > /the SCTP stack may abandon other user messages/ > - I understand this as a sender-side change, if this is so please be > explicit, otherwise please explain. Changed to When storing a user message in the send buffer while there is not enough available space, the SCTP stack at the sender side may abandon = other user messages of the same SCTP association with a priority lower than = the provided one. Clear enough? >=20 > /stack may abandon/stack MAY abandon/ See the PS question above. >=20 > /or failing the send call (if used in non-blocking > mode)./ > - unclear to me: does this mean the send call fails? Correct. In non-blocking mode the send call returns -1 and the errno is set to EWOULDBLOCK/EAGAIN. Could you elaborate on what is not clear such that the text can be = improved. >=20 > Section 3.1 >=20 > /in [RFC6458]/in [RFC6458]./ Fixed. >=20 > --- >=20 > Question on 2.2/security model > - I assume that this mechanism can take transmit opportunity away from > other flows, hence in theory starving another SCTP association of > resource. If this is so, can it be used on a host to mount a DOS = attack on > another flow originating from the same sender? - This doesn't seem PR-SCTP in general doesn't make an SCTP association more aggressive than the CC allows. So I don't see a problem with the general mechanism. I = also don't see how you can become more aggressive by using the specific = policies defined in this document. I don't see how you can take away transmit opportunities from other associations. Using the SCTP_PR_SCTP_TTL policy you might take = transmission policies from the association away in case of messages abandoning before they are transmitted, but that makes you send less than allowed, not = more. > serious, given the attacker already needs access to the sending host. >=20 > --- >=20 >=20 >=20 From nobody Tue May 20 02:52:19 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D20A1A0676 for ; Tue, 20 May 2014 02:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_YOU_CAN_BECOME=1.258, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vKplEa-JpfO for ; Tue, 20 May 2014 02:52:12 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 355631A05F5 for ; Tue, 20 May 2014 02:52:12 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3748F2B44C7; Tue, 20 May 2014 10:52:11 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 20 May 2014 10:52:11 +0100 Message-ID: <205dc831156d6be91df55c8002c16f88.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <5EE78EA2-29A6-4389-B844-ADFB6ED06144@lurchi.franken.de> References: <824f22194e3f478f1aaea378d2ea479e.squirrel@www.erg.abdn.ac.uk> <5EE78EA2-29A6-4389-B844-ADFB6ED06144@lurchi.franken.de> Date: Tue, 20 May 2014 10:52:11 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Tuexen" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/3_KiCsIRw5uSU8vM1La0z2SVVFA Cc: Gorry Fairhurst , tsvwg@ietf.org Subject: Re: [tsvwg] Comments on SCTP PR policies draft (-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 09:52:14 -0000 See response in-line. Gorry > On 20 May 2014, at 10:23, gorry@erg.abdn.ac.uk wrote: > >> I have read the SCTP PR policies draft >> (draft-ietf-tsvwg-sctp-prpolicies-02). This is short and was an easy >> read, >> but I have few comments noted below, and one question. > Hi Gorry, > > thank you very much for your comments. See me responses in-line. > > Best regards > Michael >> >> Best wishes, >> >> Gorry >> >> --- >> >> Section 2: >> >> /This section defined/This section defines/ > Fixed. >> >> I think this section needs RFC 2119 language - see below, because it >> defines protocol mechanisms. > That implies changing the document from Informational to Proposed > Standard. > I don't think so - I can check on whether our AD would sanction use of RFC 2119 language within INFO. > Is that OK? I'm happy to do that... We even reference this document in > the normative reference section of a document targeting for PS. > >> >> Section 2.1 >> >> /The sender must abandon a user message...//The sender MUST abandon a >> user >> message.../ > I agree, but we need to head for PS then... >> >> /includes the fast and the timer based/includes both fast and >> timer-based/ > Fixed. >> >> /Limiting the number of retransmissions to 0 is allowed. / >> The sender MAY limit the number of retransmissions to 0./ > Same as above. PS OK? > The question is really where is the protocol behaviour specified? If it's in this document then let's do it clearly. >> >> >> /send any retransmissions either./perform any retransmissions./ > Fixed. >> >> /in the WebRTC protocol stack./ >> - REF needed to this usage. > Added reference to > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-09 > which has also a normative reference to this ID. OK >> >> Section 2.2 >> >> /the SCTP stack may abandon other user messages/ >> - I understand this as a sender-side change, if this is so please be >> explicit, otherwise please explain. > Changed to > > When storing a user message in the send buffer while there is not > enough available space, the SCTP stack at the sender side may abandon > other > user messages of the same SCTP association with a priority lower than the > provided one. > > Clear enough? Yes, clear to me. >> >> /stack may abandon/stack MAY abandon/ > See the PS question above. >> >> /or failing the send call (if used in non-blocking >> mode)./ >> - unclear to me: does this mean the send call fails? > Correct. In non-blocking mode the send call returns -1 and the errno > is set to EWOULDBLOCK/EAGAIN. > Could you elaborate on what is not clear such that the text can be > improved. In that case it is just wording. Maybe try something like: /or failing to complete the send call/ or /or the send call fails/ >> >> Section 3.1 >> >> /in [RFC6458]/in [RFC6458]./ > Fixed. >> >> --- >> >> Question on 2.2/security model >> - I assume that this mechanism can take transmit opportunity away from >> other flows, hence in theory starving another SCTP association of >> resource. If this is so, can it be used on a host to mount a DOS attack >> on >> another flow originating from the same sender? >T his doesn't seem > PR-SCTP in general doesn't make an SCTP association more aggressive than > the CC allows. So I don't see a problem with the general mechanism. I also > don't see how you can become more aggressive by using the specific > policies defined in this document. > I didn't say that - the attack I was speculating about was a host DoS attack on the stack, not a network DOS attack on capacity. > I don't see how you can take away transmit opportunities from other > associations. Using the SCTP_PR_SCTP_TTL policy you might take > transmission. > Right, so I was hoping you'd say this - which means that you can only pre-empt flows from the same association? What I'd like to figure-out is where the "priority" is applied - within a single association or between entirely separate associations (from different apps). > policies from the association away in case of messages abandoning before > they are transmitted, but that makes you send less than allowed, not more. I got that. >> serious, given the attacker already needs access to the sending host. >> >> --- >> >> >> > From nobody Tue May 20 13:53:30 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999071A0784 for ; Tue, 20 May 2014 13:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_YOU_CAN_BECOME=1.258, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy0wfcFvhTTR for ; Tue, 20 May 2014 13:53:27 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436E71A00EA for ; Tue, 20 May 2014 13:53:27 -0700 (PDT) Received: from [192.168.1.102] (p508F324C.dip0.t-ipconnect.de [80.143.50.76]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E36021C10465B; Tue, 20 May 2014 22:53:24 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen X-Priority: 3 (Normal) In-Reply-To: <205dc831156d6be91df55c8002c16f88.squirrel@www.erg.abdn.ac.uk> Date: Tue, 20 May 2014 22:53:23 +0200 Content-Transfer-Encoding: 7bit Message-Id: <4C2BC593-EAFD-4F88-8667-189A8636CB3D@lurchi.franken.de> References: <824f22194e3f478f1aaea378d2ea479e.squirrel@www.erg.abdn.ac.uk> <5EE78EA2-29A6-4389-B844-ADFB6ED06144@lurchi.franken.de> <205dc831156d6be91df55c8002c16f88.squirrel@www.erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Cv2WLnpkMMkycEJsXdxxVrVFOno Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Comments on SCTP PR policies draft (-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:53:29 -0000 On 20 May 2014, at 11:52, gorry@erg.abdn.ac.uk wrote: > See response in-line. See in-line. Best regards Michael > > Gorry > >> On 20 May 2014, at 10:23, gorry@erg.abdn.ac.uk wrote: >> >>> I have read the SCTP PR policies draft >>> (draft-ietf-tsvwg-sctp-prpolicies-02). This is short and was an easy >>> read, >>> but I have few comments noted below, and one question. >> Hi Gorry, >> >> thank you very much for your comments. See me responses in-line. >> >> Best regards >> Michael >>> >>> Best wishes, >>> >>> Gorry >>> >>> --- >>> >>> Section 2: >>> >>> /This section defined/This section defines/ >> Fixed. >>> >>> I think this section needs RFC 2119 language - see below, because it >>> defines protocol mechanisms. >> That implies changing the document from Informational to Proposed >> Standard. >> > I don't think so - I can check on whether our AD would sanction use of RFC > 2119 language within INFO. > >> Is that OK? I'm happy to do that... We even reference this document in >> the normative reference section of a document targeting for PS. >> >>> >>> Section 2.1 >>> >>> /The sender must abandon a user message...//The sender MUST abandon a >>> user >>> message.../ >> I agree, but we need to head for PS then... >>> >>> /includes the fast and the timer based/includes both fast and >>> timer-based/ >> Fixed. >>> >>> /Limiting the number of retransmissions to 0 is allowed. / >>> The sender MAY limit the number of retransmissions to 0./ >> Same as above. PS OK? >> > > The question is really where is the protocol behaviour specified? If it's > in this document then let's do it clearly. > >>> >>> >>> /send any retransmissions either./perform any retransmissions./ >> Fixed. >>> >>> /in the WebRTC protocol stack./ >>> - REF needed to this usage. >> Added reference to >> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-09 >> which has also a normative reference to this ID. > OK > >>> >>> Section 2.2 >>> >>> /the SCTP stack may abandon other user messages/ >>> - I understand this as a sender-side change, if this is so please be >>> explicit, otherwise please explain. >> Changed to >> >> When storing a user message in the send buffer while there is not >> enough available space, the SCTP stack at the sender side may abandon >> other >> user messages of the same SCTP association with a priority lower than the >> provided one. >> >> Clear enough? > Yes, clear to me. Great. > >>> >>> /stack may abandon/stack MAY abandon/ >> See the PS question above. >>> >>> /or failing the send call (if used in non-blocking >>> mode)./ >>> - unclear to me: does this mean the send call fails? >> Correct. In non-blocking mode the send call returns -1 and the errno >> is set to EWOULDBLOCK/EAGAIN. >> Could you elaborate on what is not clear such that the text can be >> improved. > In that case it is just wording. > Maybe try something like: > /or failing to complete the send call/ > or > /or the send call fails/ OK. I'm using 'or the send call fails'. > > >>> >>> Section 3.1 >>> >>> /in [RFC6458]/in [RFC6458]./ >> Fixed. >>> >>> --- >>> >>> Question on 2.2/security model >>> - I assume that this mechanism can take transmit opportunity away from >>> other flows, hence in theory starving another SCTP association of >>> resource. If this is so, can it be used on a host to mount a DOS attack >>> on >>> another flow originating from the same sender? >> T his doesn't seem >> PR-SCTP in general doesn't make an SCTP association more aggressive than >> the CC allows. So I don't see a problem with the general mechanism. I also >> don't see how you can become more aggressive by using the specific >> policies defined in this document. >> > I didn't say that - the attack I was speculating about was a host DoS > attack on the stack, not a network DOS attack on capacity. > >> I don't see how you can take away transmit opportunities from other >> associations. Using the SCTP_PR_SCTP_TTL policy you might take >> transmission. >> > Right, so I was hoping you'd say this - which means that you can only > pre-empt flows from the same association? What I'd like to figure-out is > where the "priority" is applied - within a single association or between > entirely separate associations (from different apps). Only within a single association. > >> policies from the association away in case of messages abandoning before >> they are transmitted, but that makes you send less than allowed, not more. > I got that. So we don't need additional text, right? > >>> serious, given the attacker already needs access to the sending host. >>> >>> --- >>> >>> >>> >> > > From nobody Wed May 21 01:52:49 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82401A045D for ; Wed, 21 May 2014 01:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_YOU_CAN_BECOME=1.258, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPlwVty3uFwX for ; Wed, 21 May 2014 01:52:44 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 463AC1A031F for ; Wed, 21 May 2014 01:52:44 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id A59BE2B454E; Wed, 21 May 2014 09:52:42 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 02D0F2B4044; Wed, 21 May 2014 09:52:40 +0100 (BST) Message-ID: <537C6958.1000307@erg.abdn.ac.uk> Date: Wed, 21 May 2014 09:52:40 +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:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Tuexen References: <824f22194e3f478f1aaea378d2ea479e.squirrel@www.erg.abdn.ac.uk> <5EE78EA2-29A6-4389-B844-ADFB6ED06144@lurchi.franken.de> <205dc831156d6be91df55c8002c16f88.squirrel@www.erg.abdn.ac.uk> <4C2BC593-EAFD-4F88-8667-189A8636CB3D@lurchi.franken.de> In-Reply-To: <4C2BC593-EAFD-4F88-8667-189A8636CB3D@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/H2ockU7EEK2fo8jIDo9Qr29iRfI Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Comments on SCTP PR policies draft (-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 21 May 2014 08:52:47 -0000 OK, let's just work on the last topic a little further... On 20/05/2014 21:53, Michael Tuexen wrote: > On 20 May 2014, at 11:52, gorry@erg.abdn.ac.uk wrote: > >> See response in-line. > See in-line. > > Best regards > Michael >> >> Gorry >> >>> On 20 May 2014, at 10:23, gorry@erg.abdn.ac.uk wrote: >>> >>>> I have read the SCTP PR policies draft >>>> (draft-ietf-tsvwg-sctp-prpolicies-02). This is short and was an easy >>>> read, >>>> but I have few comments noted below, and one question. >>> Hi Gorry, >>> >>> thank you very much for your comments. See me responses in-line. >>> >>> Best regards >>> Michael >>>> >>>> Best wishes, >>>> >>>> Gorry >>>> >>>> --- >>>> >>>> Section 2: >>>> >>>> /This section defined/This section defines/ >>> Fixed. >>>> >>>> I think this section needs RFC 2119 language - see below, because it >>>> defines protocol mechanisms. >>> That implies changing the document from Informational to Proposed >>> Standard. >>> >> I don't think so - I can check on whether our AD would sanction use of RFC >> 2119 language within INFO. >> >>> Is that OK? I'm happy to do that... We even reference this document in >>> the normative reference section of a document targeting for PS. >>> >>>> >>>> Section 2.1 >>>> >>>> /The sender must abandon a user message...//The sender MUST abandon a >>>> user >>>> message.../ >>> I agree, but we need to head for PS then... >>>> >>>> /includes the fast and the timer based/includes both fast and >>>> timer-based/ >>> Fixed. >>>> >>>> /Limiting the number of retransmissions to 0 is allowed. / >>>> The sender MAY limit the number of retransmissions to 0./ >>> Same as above. PS OK? >>> >> >> The question is really where is the protocol behaviour specified? If it's >> in this document then let's do it clearly. >> >>>> >>>> >>>> /send any retransmissions either./perform any retransmissions./ >>> Fixed. >>>> >>>> /in the WebRTC protocol stack./ >>>> - REF needed to this usage. >>> Added reference to >>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-09 >>> which has also a normative reference to this ID. >> OK >> >>>> >>>> Section 2.2 >>>> >>>> /the SCTP stack may abandon other user messages/ >>>> - I understand this as a sender-side change, if this is so please be >>>> explicit, otherwise please explain. >>> Changed to >>> >>> When storing a user message in the send buffer while there is not >>> enough available space, the SCTP stack at the sender side may abandon >>> other >>> user messages of the same SCTP association with a priority lower than the >>> provided one. >>> >>> Clear enough? >> Yes, clear to me. > Great. >> >>>> >>>> /stack may abandon/stack MAY abandon/ >>> See the PS question above. >>>> >>>> /or failing the send call (if used in non-blocking >>>> mode)./ >>>> - unclear to me: does this mean the send call fails? >>> Correct. In non-blocking mode the send call returns -1 and the errno >>> is set to EWOULDBLOCK/EAGAIN. >>> Could you elaborate on what is not clear such that the text can be >>> improved. >> In that case it is just wording. >> Maybe try something like: >> /or failing to complete the send call/ >> or >> /or the send call fails/ > OK. I'm using 'or the send call fails'. >> >> >>>> >>>> Section 3.1 >>>> >>>> /in [RFC6458]/in [RFC6458]./ >>> Fixed. >>>> >>>> --- >>>> >>>> Question on 2.2/security model >>>> - I assume that this mechanism can take transmit opportunity away from >>>> other flows, hence in theory starving another SCTP association of >>>> resource. If this is so, can it be used on a host to mount a DOS attack >>>> on >>>> another flow originating from the same sender? >>> T his doesn't seem >>> PR-SCTP in general doesn't make an SCTP association more aggressive than >>> the CC allows. So I don't see a problem with the general mechanism. I also >>> don't see how you can become more aggressive by using the specific >>> policies defined in this document. >>> >> I didn't say that - the attack I was speculating about was a host DoS >> attack on the stack, not a network DOS attack on capacity. >> >>> I don't see how you can take away transmit opportunities from other >>> associations. Using the SCTP_PR_SCTP_TTL policy you might take >>> transmission. >>> >> Right, so I was hoping you'd say this - which means that you can only >> pre-empt flows from the same association? What I'd like to figure-out is >> where the "priority" is applied - within a single association or between >> entirely separate associations (from different apps). > > Only within a single association. > This should certainly be written in the section where you speak of priority, and also within the security considerations section. >>> policies from the association away in case of messages abandoning before >>> they are transmitted, but that makes you send less than allowed, not more. >> I got that. > So we don't need additional text, right? > It would be good also to note this does not change the CC model for SCTP. i.e. The CC rules must take into account any loss, even though the packet is not retransmitted (that would be the norm for SCTP-PR, correct?), but worthwhile saying as a second point in the security considerations form a network perspective. >>>> serious, given the attacker already needs access to the sending host. >>>> >>>> --- > I think it may be worth tagging this in the boilerplate as an update to RFC 3758, have you considered this - it helps explain this as a simple addition. Gorry From nobody Wed May 21 05:03:36 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063711A0340 for ; Wed, 21 May 2014 05:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_YOU_CAN_BECOME=1.258, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8YcNsOhScvO for ; Wed, 21 May 2014 05:03:31 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533E81A017A for ; Wed, 21 May 2014 05:03:31 -0700 (PDT) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EFA841C104937; Wed, 21 May 2014 14:03:28 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: <537C6958.1000307@erg.abdn.ac.uk> Date: Wed, 21 May 2014 14:03:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C332D00-C467-436E-B39E-2774DFFA7B14@lurchi.franken.de> References: <824f22194e3f478f1aaea378d2ea479e.squirrel@www.erg.abdn.ac.uk> <5EE78EA2-29A6-4389-B844-ADFB6ED06144@lurchi.franken.de> <205dc831156d6be91df55c8002c16f88.squirrel@www.erg.abdn.ac.uk> <4C2BC593-EAFD-4F88-8667-189A8636CB3D@lurchi.franken.de> <537C6958.1000307@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/SuORwXjdTSO1SfmsBIuOvJEpcuw Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Comments on SCTP PR policies draft (-02) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 12:03:34 -0000 On 21 May 2014, at 10:52, Gorry Fairhurst wrote: > OK, let's just work on the last topic a little further... >=20 > On 20/05/2014 21:53, Michael Tuexen wrote: >> On 20 May 2014, at 11:52, gorry@erg.abdn.ac.uk wrote: >>=20 >>> See response in-line. >> See in-line. >>=20 >> Best regards >> Michael >>>=20 >>> Gorry >>>=20 >>>> On 20 May 2014, at 10:23, gorry@erg.abdn.ac.uk wrote: >>>>=20 >>>>> I have read the SCTP PR policies draft >>>>> (draft-ietf-tsvwg-sctp-prpolicies-02). This is short and was an = easy >>>>> read, >>>>> but I have few comments noted below, and one question. >>>> Hi Gorry, >>>>=20 >>>> thank you very much for your comments. See me responses in-line. >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> Best wishes, >>>>>=20 >>>>> Gorry >>>>>=20 >>>>> --- >>>>>=20 >>>>> Section 2: >>>>>=20 >>>>> /This section defined/This section defines/ >>>> Fixed. >>>>>=20 >>>>> I think this section needs RFC 2119 language - see below, because = it >>>>> defines protocol mechanisms. >>>> That implies changing the document from Informational to Proposed >>>> Standard. >>>>=20 >>> I don't think so - I can check on whether our AD would sanction use = of RFC >>> 2119 language within INFO. >>>=20 >>>> Is that OK? I'm happy to do that... We even reference this document = in >>>> the normative reference section of a document targeting for PS. >>>>=20 >>>>>=20 >>>>> Section 2.1 >>>>>=20 >>>>> /The sender must abandon a user message...//The sender MUST = abandon a >>>>> user >>>>> message.../ >>>> I agree, but we need to head for PS then... >>>>>=20 >>>>> /includes the fast and the timer based/includes both fast and >>>>> timer-based/ >>>> Fixed. >>>>>=20 >>>>> /Limiting the number of retransmissions to 0 is allowed. / >>>>> The sender MAY limit the number of retransmissions to 0./ >>>> Same as above. PS OK? >>>>=20 >>>=20 >>> The question is really where is the protocol behaviour specified? If = it's >>> in this document then let's do it clearly. >>>=20 >>>>>=20 >>>>>=20 >>>>> /send any retransmissions either./perform any retransmissions./ >>>> Fixed. >>>>>=20 >>>>> /in the WebRTC protocol stack./ >>>>> - REF needed to this usage. >>>> Added reference to >>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-09 >>>> which has also a normative reference to this ID. >>> OK >>>=20 >>>>>=20 >>>>> Section 2.2 >>>>>=20 >>>>> /the SCTP stack may abandon other user messages/ >>>>> - I understand this as a sender-side change, if this is so please = be >>>>> explicit, otherwise please explain. >>>> Changed to >>>>=20 >>>> When storing a user message in the send buffer while there is not >>>> enough available space, the SCTP stack at the sender side may = abandon >>>> other >>>> user messages of the same SCTP association with a priority lower = than the >>>> provided one. >>>>=20 >>>> Clear enough? >>> Yes, clear to me. >> Great. >>>=20 >>>>>=20 >>>>> /stack may abandon/stack MAY abandon/ >>>> See the PS question above. >>>>>=20 >>>>> /or failing the send call (if used in non-blocking >>>>> mode)./ >>>>> - unclear to me: does this mean the send call fails? >>>> Correct. In non-blocking mode the send call returns -1 and the = errno >>>> is set to EWOULDBLOCK/EAGAIN. >>>> Could you elaborate on what is not clear such that the text can be >>>> improved. >>> In that case it is just wording. >>> Maybe try something like: >>> /or failing to complete the send call/ >>> or >>> /or the send call fails/ >> OK. I'm using 'or the send call fails'. >>>=20 >>>=20 >>>>>=20 >>>>> Section 3.1 >>>>>=20 >>>>> /in [RFC6458]/in [RFC6458]./ >>>> Fixed. >>>>>=20 >>>>> --- >>>>>=20 >>>>> Question on 2.2/security model >>>>> - I assume that this mechanism can take transmit opportunity away = from >>>>> other flows, hence in theory starving another SCTP association of >>>>> resource. If this is so, can it be used on a host to mount a DOS = attack >>>>> on >>>>> another flow originating from the same sender? >>>> T his doesn't seem >>>> PR-SCTP in general doesn't make an SCTP association more aggressive = than >>>> the CC allows. So I don't see a problem with the general mechanism. = I also >>>> don't see how you can become more aggressive by using the specific >>>> policies defined in this document. >>>>=20 >>> I didn't say that - the attack I was speculating about was a host = DoS >>> attack on the stack, not a network DOS attack on capacity. >>>=20 >>>> I don't see how you can take away transmit opportunities from other >>>> associations. Using the SCTP_PR_SCTP_TTL policy you might take >>>> transmission. >>>>=20 >>> Right, so I was hoping you'd say this - which means that you can = only >>> pre-empt flows from the same association? What I'd like to = figure-out is >>> where the "priority" is applied - within a single association or = between >>> entirely separate associations (from different apps). > > >> Only within a single association. >>=20 > This should certainly be written in the section where you speak of = priority, and also within the security considerations section. My current text says:
Using the Priority Policy allows the sender of a user message to = specify a priority. When storing a user message in the send buffer while there = is not enough available space, the SCTP stack at the sender side MAY abandon = other user messages of the same SCTP association with a priority lower than = the provided one. ... So I guess it is addressed in the section where the policy is defined. We can repeat this in the security section if you want... >>>> policies from the association away in case of messages abandoning = before >>>> they are transmitted, but that makes you send less than allowed, = not more. >>> I got that. >> So we don't need additional text, right? >>=20 > It would be good also to note this does not change the CC model for = SCTP. But this is a consequence of PR-SCTP as defined in RFC 3758, independent = from the particular policy being used. Therefore I think it really doesn't = fit here, since this document only deals with additional policies. >=20 > i.e. The CC rules must take into account any loss, even though the = packet is not retransmitted (that would be the norm for SCTP-PR, = correct?), but worthwhile saying as a second point in the security = considerations form a network perspective. We can state that, now problem. But from a principle point, we just = define points for abandoning messages, nothing else. But we can make that clear. = However, I would prefer to write this with RFC 2119 language in the text defining that = policy. >=20 >>>>> serious, given the attacker already needs access to the sending = host. >>>>>=20 >>>>> --- >>=20 >=20 > I think it may be worth tagging this in the boilerplate as an update = to RFC 3758, have you considered this - it helps explain this as a = simple addition. If you want to take the update route, shouldn't it update RFC 3758 = (because of adding policies) and RFC 6458? However, other documents also extending RFC 6458 don't = update it... I'm also not sure if updating RFC 3758 is right. You might want to = implement only RFC 3758 without the policies defined in this document. It is an addition... Best regards Michael >=20 > Gorry >=20 >=20 >=20 From nobody Wed May 21 23:35:59 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E781A00DD for ; Wed, 21 May 2014 23:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xF1li-O03BN for ; Wed, 21 May 2014 23:35:53 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id DF85F1A00DC for ; Wed, 21 May 2014 23:35:52 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 352512B454E; Thu, 22 May 2014 07:35:51 +0100 (BST) Received: from Gorry-2.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3B71B2B4075 for ; Thu, 22 May 2014 07:35:50 +0100 (BST) Message-ID: <537D9AC4.80602@erg.abdn.ac.uk> Date: Thu, 22 May 2014 07:35:48 +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:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Zfeu92w0S_I_Jlf_Amfr5ZUi7nY Subject: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 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, 22 May 2014 06:35:54 -0000 This email announces the start of a working group last call to confirm publication of "Recommendations for Transport Port Uses". The TSV WG is requesting feedback on this document with the intention to proceed to publish this as a BCP. Please send any comments to the TSVWG list (tsvwg@ietf.org). The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04 The last call will run for TWO weeks, ending midnight 5th June. James, David, and Gorry (TSVWG Chairs) tsvwg-chairs@ietf.org From nobody Thu May 22 05:25:36 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317A71A00EF for ; Thu, 22 May 2014 05:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id An2B53sPkbn4 for ; Thu, 22 May 2014 05:25:33 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DA81A0039 for ; Thu, 22 May 2014 05:25:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,887,1392192000"; d="asc'?scan'208";a="165913756" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 22 May 2014 05:25:32 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Thu, 22 May 2014 05:25:32 -0700 From: "Eggert, Lars" To: Gorry Fairhust Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) Thread-Index: AQHPdYgZANAWYovF00yGpdDU6CjCPptM/B8A Date: Thu, 22 May 2014 12:25:31 +0000 Message-ID: <7473763B-BFAB-4C43-B300-19ED3D041BB3@netapp.com> References: <537D9AC4.80602@erg.abdn.ac.uk> In-Reply-To: <537D9AC4.80602@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.11] Content-Type: multipart/signed; boundary="Apple-Mail=_AD9CFB07-4074-4550-871C-24C48F2EC59E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/E9yZh4GJ09Rirr3HPHR8lCB7zJ0 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 12:25:35 -0000 --Apple-Mail=_AD9CFB07-4074-4550-871C-24C48F2EC59E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, I think this is mostly ready. I do have a few comments (below) that I'd = like to see addressed before this progresses. Lars Meta-comment: It would be good to be a bit more consistent with terms. The terms "port" and "port number" are used interchangeably in the document, although Section 3 clearly describes their difference. Maybe do a pass over the doc and check whether you really meant "port" and not "port number" wherever the term is used? Section 1., paragraph 1: > This document provides information and advice to system designers = on > the use of transport port numbers and services. "And services" - do you mean service names? Section 3., paragraph 10: > In [RFC820] those range meanings disappeared, and a single list of > assignments is presented. By [RFC900] the ranges appeared as = decimal > numbers rather than the octal ranges used previously. [RFC1340] > increased this range from 0..255 to 0..1023, and began to list TCP > and UDP port assignments individually (although the assumption was, > and remains, that once assigned a port applies to all transport > protocols, including TCP, UDP, recently SCTP and DCCP, as well as > ISO-TP4 for a brief period in the early 1990s). I'm not sure about the "and remains" part. RFC 6335 changed the procedure so that port numbers for protocols not requested become reserved, and may eventually be assigned to other services, if we run out of space. (See the paragraph beginning with "Effective with the publication of this document" in RFC6335 Section 7.2.) Section 4., paragraph 4: > 0-1023 0x03FF Well-Known (also System) > 1024-49151 0x0400-0xBFFF Registered (also User) > 49152-65535 0xC000-0xFFFF Dynamic (also Private) Nit: The naming here is actually backwards with regards to which terms we used in RFC6335 - there, we used the terms you have in brackets here. It would be nice to stay consistent. Section 6., paragraph 8: > o Different performance requirements can already be supported > using separate connections or endpoints with different > capabilities or configurations. I don't understand this bullet point. Section 7.4., paragraph 1: > a host over a network, an service can also be the opening through Nit: s/an service/a service/ Section 7.6., paragraph 5: > >> When UDP is used for discovery of an active TCP service, the UDP > service name SHOULD end in "-disc". This is slightly stronger than what RFC6335 says ('Names referring to discovery services, e.g., using multicast or broadcast to identify endpoints capable of a given service, SHOULD use an easily identifiable suffix (e.g., "-disc").' It would be good to be consistent. Section 255.255.255.255, paragraph 2: > There are several issues that should be considered in > such cases, each summarized from [RFC5405]: The bullets below don't summarize RFC5405 accurately (and some bullets aren't even in RRC5405). I'd recommend either quoting Table 1 from RFC5405 here, or simply pointing there rather than attempting to summarize. Section 255.255.255.255, paragraph 3: > >> UDP services SHOULD be rate limited so that they use only = nominal > network capacity. Users should keep in mind that "nominal" may vary > depending on the deployment environment and may be very low. That's different from RFC5405. There is no notion of "nominal capacity" there. Section 255.255.255.255, paragraph 4: > >> UDP services that use multipoint communication SHOULD be > scalable, and SHOULD NOT rely solely on the efficiency of multicast > transmission for scalability. That's not from RFC5405 - multicast is out of scope there. Section 255.255.255.255, paragraph 5: > >> UDP services SHOULD include congestion detection and back-off. Also not fully accurate. Section 255.255.255.255, paragraph 6: > >> UDP SHOULD NOT be used as a performance enhancement over TCP, > i.e., to circumnavigate TCP's congestion control. That's not in RFC5405 either. Section 7.7., paragraph 7: > Applications made through Internet Draft / RFC publication = typically > use a placeholder ("PORTNUM") in the text, and use an experimental > port number until a final assignment has been made [RFC6335]. Nit: s/and use an experimental/and implementations use an experimental/ Section 7.7., paragraph 8: > That > assignment is initially indicated in the IANA Considerations = section > of the document, and is tracked by the RFC Editor. When the RFC > reaches the last stages of publication, that request is forwarded = to > IANA for handling. At that time, IANA typically requests that the > applicant fill out the application form on their website, because > not every protocol document addresses the information required. > "Early" assignments can be made when justified, e.g., for early > interoperability testing, according to existing process [RFC4020] > [RFC6335]. I don't think that IANA requires that the form be filled out for numbers assigned in RFCs. They get the information from the IANA Considerations section, and will notify the authors if that section is incomplete. Section 7.7., paragraph 9: > Using this single application process also ensures that IANA has > complete information even if the RFC publication is interrupted. = For > this reason as well, the application should be complete and not > refer solely to the Internet Draft, RFC, a website, or any other > external documentation. See above - I don't think there is a single process here. I think ports from IETF Stream RFCs are handled differently. Section 7.7., paragraph 10: > >> Users writing specifications SHOULD use symbolic names for port > numbers and service names until an IANA assignment has been > completed. Suggest to add another recommendation about implementations using the experimental ports during this time. Section 7.8., paragraph 2: > Note that there are numerous services that have squatted on such > numbers that are in widespread use. Even such widespread de-facto > use may not justify a later IANA assignment of that value, > especially if either the value has already been assigned to a > legitimate applicant or if the service would not qualify for an > assignment of its own accord. I'd like to add a paragraph here that encourages squatters to come clean and properly register their ports. They still need to provide the information, and having squatted is not fast path to assignment, but I think everyone is better off if the IANA registry is in line with reality as possible. --Apple-Mail=_AD9CFB07-4074-4550-871C-24C48F2EC59E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU33sutZcnpRveo1xAQJpgwP8DXYvBy2ZWkv+VTGGLPj7784Sb3njh9Ha luqwsANGN8xq0qN59fufQEem/GnHrVw6nbhGmfO7xoGq30rmptyzpR9Qlxv+oocK lxrCz+sq+Rcurq7HxSr00RaUPh05QphItYkCD2URKxt3Yl/a4MPtndE+y7PWEtAE JEmoWNbiK+Y= =7xwd -----END PGP SIGNATURE----- --Apple-Mail=_AD9CFB07-4074-4550-871C-24C48F2EC59E-- From nobody Thu May 22 14:12:56 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5B11A0324 for ; Thu, 22 May 2014 14:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WF_zWAz8GBIA for ; Thu, 22 May 2014 14:12:53 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84AAA1A0283 for ; Thu, 22 May 2014 14:12:53 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4MLCGoU015299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 May 2014 14:12:16 -0700 (PDT) Message-ID: <537E6830.2050903@isi.edu> Date: Thu, 22 May 2014 14:12:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Eggert, Lars" , Gorry Fairhust References: <537D9AC4.80602@erg.abdn.ac.uk> <7473763B-BFAB-4C43-B300-19ED3D041BB3@netapp.com> In-Reply-To: <7473763B-BFAB-4C43-B300-19ED3D041BB3@netapp.com> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/kw63jqbM7QC4RQJoep7Dfk8Uub4 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 21:12:55 -0000 Hi, Lars, Thanks for the scrub. FWIW, I was also wondering if we should include some more potent (anti)advice about squatting, e.g.: --- Squatted ports remain unassigned, and IANA retains the right to assign it to others. Protocol designers are reminded that is is never appropriate to use ports that have not been directly assigned [RFC6335]. In particular, any unassigned code from the assigned ranges will be assigned by IANA, and any conflict will be easily resolved as the protocol designer's fault once that happens (because they would not be the assignee). This may reflect in the public's judgement on the quality of their expertise and cooperation with the Internet community. --- Other comments addressed below. Joe On 5/22/2014 5:25 AM, Eggert, Lars wrote: > Hi, > > I think this is mostly ready. I do have a few comments (below) that I'd like to see addressed before this progresses. > > Lars > > > Meta-comment: It would be good to be a bit more consistent with terms. > The terms "port" and "port number" are used interchangeably in the > document, although Section 3 clearly describes their difference. Maybe > do a pass over the doc and check whether you really meant "port" and > not "port number" wherever the term is used? Good catch; will do. > Section 1., paragraph 1: >> This document provides information and advice to system designers on >> the use of transport port numbers and services. > > "And services" - do you mean service names? Yes; will fix. > Section 3., paragraph 10: >> In [RFC820] those range meanings disappeared, and a single list of >> assignments is presented. By [RFC900] the ranges appeared as decimal >> numbers rather than the octal ranges used previously. [RFC1340] >> increased this range from 0..255 to 0..1023, and began to list TCP >> and UDP port assignments individually (although the assumption was, >> and remains, that once assigned a port applies to all transport >> protocols, including TCP, UDP, recently SCTP and DCCP, as well as >> ISO-TP4 for a brief period in the early 1990s). > > I'm not sure about the "and remains" part. RFC 6335 changed the > procedure so that port numbers for protocols not requested become > reserved, and may eventually be assigned to other services, if we run > out of space. (See the paragraph beginning with "Effective with the > publication of this document" in RFC6335 Section 7.2.) Agreed; that paragraph was originally written before RFC6335 was completed and we decided to formalize assigning only transports requested. Will fix. > Section 4., paragraph 4: >> 0-1023 0x03FF Well-Known (also System) >> 1024-49151 0x0400-0xBFFF Registered (also User) >> 49152-65535 0xC000-0xFFFF Dynamic (also Private) > > Nit: The naming here is actually backwards with regards to which terms > we used in RFC6335 - there, we used the terms you have in brackets > here. It would be nice to stay consistent. The point of this section is that the original official names were Well-Known and Registered, and we only really clarified that those terms were ambiguous and should not be used in RFC6335. So the intent is to end up consistent with RFC6335, but also to explain the origin. If this is confusing, I can revise. > Section 6., paragraph 8: >> o Different performance requirements can already be supported >> using separate connections or endpoints with different >> capabilities or configurations. > > I don't understand this bullet point. Some requests have sought two ports - one for high-BW and one for low, or one for fast access to processing and one for "everyone else". Those sorts of distinctions can me supported in different connections, and don't need port numbers as indicators. I will add text to explain. > Section 7.4., paragraph 1: >> a host over a network, an service can also be the opening through > > Nit: s/an service/a service/ Agreed. Will fix. > Section 7.6., paragraph 5: >> >> When UDP is used for discovery of an active TCP service, the UDP >> service name SHOULD end in "-disc". > > This is slightly stronger than what RFC6335 says ('Names referring to > discovery services, e.g., using multicast or broadcast to identify > endpoints capable of a given service, SHOULD use an easily > identifiable suffix (e.g., "-disc").' It would be good to be > consistent. I'll match the text. > Section 255.255.255.255, paragraph 2: >> There are several issues that should be considered in >> such cases, each summarized from [RFC5405]: > > The bullets below don't summarize RFC5405 accurately (and some bullets > aren't even in RRC5405). I'd recommend either quoting Table 1 from > RFC5405 here, or simply pointing there rather than attempting to > summarize. I'll point there, so that updates to RFC5405 will be carried along. > Section 255.255.255.255, paragraph 3: >> >> UDP services SHOULD be rate limited so that they use only nominal >> network capacity. Users should keep in mind that "nominal" may vary >> depending on the deployment environment and may be very low. > > That's different from RFC5405. There is no notion of "nominal > capacity" there. Sec 3.1.2 is what this is intended to refer to. However, if we just get rid of the bullet we don't need to clarify. > Section 255.255.255.255, paragraph 4: >> >> UDP services that use multipoint communication SHOULD be >> scalable, and SHOULD NOT rely solely on the efficiency of multicast >> transmission for scalability. > > That's not from RFC5405 - multicast is out of scope there. OK - so we need to keep this one (and not cite RFC5405). > Section 255.255.255.255, paragraph 5: >> >> UDP services SHOULD include congestion detection and back-off. > > Also not fully accurate. That was intended to refer to Sec 3.1.1; again, omitting this bullet and referring just to RFC5405 is sufficient. > Section 255.255.255.255, paragraph 6: >> >> UDP SHOULD NOT be used as a performance enhancement over TCP, >> i.e., to circumnavigate TCP's congestion control. > > That's not in RFC5405 either. OK, but that's worth keeping IMO. > Section 7.7., paragraph 7: >> Applications made through Internet Draft / RFC publication typically >> use a placeholder ("PORTNUM") in the text, and use an experimental >> port number until a final assignment has been made [RFC6335]. > > Nit: s/and use an experimental/and implementations use an > experimental/ Agreed. > Section 7.7., paragraph 8: >> That >> assignment is initially indicated in the IANA Considerations section >> of the document, and is tracked by the RFC Editor. When the RFC >> reaches the last stages of publication, that request is forwarded to >> IANA for handling. At that time, IANA typically requests that the >> applicant fill out the application form on their website, because >> not every protocol document addresses the information required. >> "Early" assignments can be made when justified, e.g., for early >> interoperability testing, according to existing process [RFC4020] >> [RFC6335]. > > I don't think that IANA requires that the form be filled out for > numbers assigned in RFCs. They get the information from the IANA > Considerations section, and will notify the authors if that section is > incomplete. I didn't say "requires", but it's not practical to expect IANA to translate the contents of an RFC into what's needed for an application. IMO, it's much more appropriate to just have the authors fill out the form, even if it's not strictly "required". > Section 7.7., paragraph 9: >> Using this single application process also ensures that IANA has >> complete information even if the RFC publication is interrupted. For >> this reason as well, the application should be complete and not >> refer solely to the Internet Draft, RFC, a website, or any other >> external documentation. > > See above - I don't think there is a single process here. I think > ports from IETF Stream RFCs are handled differently. See above. > Section 7.7., paragraph 10: >> >> Users writing specifications SHOULD use symbolic names for port >> numbers and service names until an IANA assignment has been >> completed. > > Suggest to add another recommendation about implementations using the > experimental ports during this time. Sure. > Section 7.8., paragraph 2: >> Note that there are numerous services that have squatted on such >> numbers that are in widespread use. Even such widespread de-facto >> use may not justify a later IANA assignment of that value, >> especially if either the value has already been assigned to a >> legitimate applicant or if the service would not qualify for an >> assignment of its own accord. > > I'd like to add a paragraph here that encourages squatters to come > clean and properly register their ports. They still need to provide > the information, and having squatted is not fast path to assignment, > but I think everyone is better off if the IANA registry is in line > with reality as possible. We can ask them to apply, but we need to remind them that their application will be considered without regard for their squatting (either pro or con). I.e., just because a service is deployed and in widespread use does not circumvent IANA procedures, criteria, or decisions. I'll add text to roughly that effect, unless you disagree or have an additional suggestion. ---- From nobody Thu May 22 16:06:05 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260261A0278 for ; Thu, 22 May 2014 16:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNySLNEnF9N2 for ; Thu, 22 May 2014 16:05:59 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129261A0270 for ; Thu, 22 May 2014 16:05:57 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4MN5sDm019789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 May 2014 19:05:55 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s4MN5sDm019789 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1400799955; bh=jOcM3OpO1rLx0kWi39Kq8KmseI4=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=YkPuAOrO3E4tEiLBvbTOuIv/jo1MycxVSOLN4oG+nt0+hXFCamAxTCRqLQLs834Fq kgj0/hav2GkmzBVFGeU/KmhT45hruLx6rMVigW5iL6jVa4gnX4D0dTgyDuwahRShZS q7k7FGbzhQ68C9Z8Y1B1gMMvoQ3+dNNqIOzL14mk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s4MN5sDm019789 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd53.lss.emc.com (RSA Interceptor) for ; Thu, 22 May 2014 19:05:37 -0400 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4MN5a60029346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 22 May 2014 19:05:37 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Thu, 22 May 2014 19:05:36 -0400 From: "Black, David" To: "tsvwg@ietf.org" Date: Thu, 22 May 2014 19:05:36 -0400 Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) Thread-Index: Ac91iBq+oFTFZN9RR6CoFlH5z1uaiQAf8XqA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> References: <537D9AC4.80602@erg.abdn.ac.uk> In-Reply-To: <537D9AC4.80602@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/scHuN1TpVXJCsyz9aTgf7WbvqfM Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 23:06:02 -0000 Some WGLC comments as an individual ... -- Section 4: System ports do not always require special (i.e., 'root') privilege. Nit "(i.e., 'root')" -> "(e.g., operating system superuser)" For clarity, the remainder of this document refers to the port ranges as System, User, and Dynamic. Following up on Lars's comment, please add a statement that these are the terms used in RFC 6335. -- Section 5: The first purpose requires that each transport connection between a given pair of IP addresses use a different pair of ports, but does not require either coordination or registration of port use. Almost, but not quite - insert "that uses the same transport protocol" after "each transport connection". Also, I'm not sure that "connection" is the best word here, e.g., for UDP, but I'm not sure what to do without making this sentence wordy and unclear. This is the primary reason for requesting assigned ports with IANA - to have a common agreement between all endpoints on the Internet as to the meaning of a port. Insert "default" or "expected" before "meaning", e.g., in light of the example a couple of paragraphs earlier of running a web server on port 53 instead of port 80. -- Section 6 o If more than one port is desired, consider revising the architecture until only one is needed, or, preferably, none. An example of how to get to "none" would be helpful. There are examples in Section 7.1, so a forward reference may suffice. -- Section 7.1 o Ports are not for performance. Performance enhancement can occur within separate connections. That's a bit cryptic. The first sentence should be expanded to convey the misuse (e.g., ports for ordinary- and higher-performance variants of the same service?). o Additional ports are not to replicate an existing service. For example, a device is configured using a typical web browser then it is a copy of HTTP port 80 and does not warrant a new assignment. Nit: Insert "if" before "a device" Nit: "it is a copy of" -> "then the port used for configuration is a copy o= f" or -> "then that device configuration service is a copy of the www service that is associated with" such as the use of TLS or SSL [Hi95] [RFC5246]. Please send the SSL mention and reference to /dev/null before anyone in the Security Area notices ;-). The TLS reference will suffice. NB: [RFC6101] is better reference for SSL 3 than [Hi95]. -- Section 7.2 Although automatic configuration protocols have been proposed and developed, system designers cannot yet rely on their presence. Should reference those protocols, e.g., STUN and TURN. The current RTCWEB work looks like a counterexample to the "cannot yet rely" statement, e.g., see the TRAM WG charter: http://datatracker.ietf.org/wg/tram/charter/ -- Section 7.3 Would a TCP port number assignment be needed useful if the corresponding UDP one were unavailable (assuming the proposed service needed only a TCP port)? This question seems backwards. If the proposed service only needs a TCP port, why reserve the UDP one? Nit: "needed useful" -> "useful" Nit: "needed only" -> "only requires" Even so, System port assignments have continued at an average rate of 3-4 per year over the past 7 years (2007-2013), indicating that the desire to keep this distinction continues. Or that old habits die hard. I might actually add those words ;-). Further, if System ports were no longer assigned, it would cost only 180 of the 1024 system values (17%), or 180 of the overall 49152 assigned values (<0.04%). Attach a date to the number 180, as it will almost certainly change before this draft is published as an RFC and change "assigned" to "System plus User". -- Section 7.4 Given the current state of cybersecurity in the Internet, Please cite a reference for that. Optional security can penalize performance, requiring additional round-trip exchanges before a connection can be established. As discussed earlier, ports are a critical resource and it is inappropriate to consume assignments to increase performance. I don't understand the point that this paragraph is trying to make. -- Section 7.6 I generally agree with Lars's concerns about the relationship of the material at the end of this section to RFC 5405; I'll leave it to him to work those out w/Joe. -- Section 8 Security Considerations There are additional security considerations in Sections 7.1, 7.3 and 7.4 that should be noted here. This document reminds protocol designers that port numbers are not a substitute for security, The single word "security" is a bit vague - what sort of security? Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: Thursday, May 22, 2014 2:36 AM > To: tsvwg@ietf.org > Subject: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) >=20 > This email announces the start of a working group last call to > confirm publication of "Recommendations for Transport Port Uses". >=20 > The TSV WG is requesting feedback on this document with the intention to > proceed to publish this as a BCP. >=20 > Please send any comments to the TSVWG list (tsvwg@ietf.org). >=20 > The draft is available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04 >=20 > The last call will run for TWO weeks, ending midnight 5th June. >=20 > James, David, and Gorry > (TSVWG Chairs) > tsvwg-chairs@ietf.org >=20 >=20 >=20 From nobody Thu May 22 22:24:48 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7EC1A0370 for ; Thu, 22 May 2014 22:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsnNgUnvCSwl for ; Thu, 22 May 2014 22:24:45 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7C41A036E for ; Thu, 22 May 2014 22:24:45 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so4315052wes.2 for ; Thu, 22 May 2014 22:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=VLYCBr/xXkav+u7ugDjUies7LJYAXpuTHXLnyLgBK+U=; b=LgeC05mEl0S6RUsgMonAUAdeP1d8Si3JsAmTXGFVzWPAY2nNtJzM8ZBpcNy9b1SRjF 2Go5dTogIufLf7os0GRJ89LljokeHuiViJRnLgvZdxmv/rE6Hl3aN1PK0ccPMsGCmFPf 9XnsVXEly+mmS57AUYxndSdE5XjQyOokgefI8eUDqffI+XqLOMJk5n7xbNulGmLO8/FU /7m1+fn4AGCmM6g/34HI69bxcOz3dwf3PKMZgSnSjolDHgNJfuwyQfzmQ+YSP6ggnhS8 PGO7AAnqOHfSxrF37Gz8fmTDJN2lwqp0HGabJvpgiM94tsLGKfEWc7BaiOtBQvn2YK8H d6Vw== MIME-Version: 1.0 X-Received: by 10.180.75.45 with SMTP id z13mr1029051wiv.41.1400822682493; Thu, 22 May 2014 22:24:42 -0700 (PDT) Received: by 10.217.122.80 with HTTP; Thu, 22 May 2014 22:24:42 -0700 (PDT) Date: Fri, 23 May 2014 10:54:42 +0530 Message-ID: From: Prasanna Kumar To: tsvwg@ietf.org Content-Type: multipart/alternative; boundary=f46d043893ed622dbb04fa0a7239 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/4f5L3jfDDQ9mlNNaKs8BsZDqmXU Subject: [tsvwg] Need Clarification on User initiated Abort X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 05:24:46 -0000 --f46d043893ed622dbb04fa0a7239 Content-Type: text/plain; charset=UTF-8 Hi, In the SCTP RFC 4960, we have following information for the User Initiated abort cause: 3.3.10.12 . User-Initiated Abort (12) Cause of error -------------- This error cause MAY be included in ABORT chunks that are sent because of an upper-layer request. The upper layer can specify an Upper Layer Abort Reason that is transported by SCTP transparently and MAY be delivered to the upper-layer protocol at the peer. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=12 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Upper Layer Abort Reason / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It says, upper layer can specify the cause. So my questions are: 1. Is it mandatory to upper layer to send this cause? 2. If Upper layer doesn't send any cause, what SCTP should do? Is it should send the cause by its own (like zero)? Thanks for your help. Thanks & Regards, Prasanna. --f46d043893ed622dbb04fa0a7239 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

In the SCTP RFC 4960, we h= ave following information for the User Initiated abort cause:

3.3.10.12.=
  User-Initiated Abort (12)



   Cause of error
   --------------

   This error cause MAY be included in ABORT chunks that are sent
   because of an upper-layer request.  The upper layer can specify an
   Upper Layer Abort Reason that is transported by SCTP transparently
   and MAY be delivered to the upper-layer protocol at the peer.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Cause Code=3D12         |      Cause Length=3DVariable    =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                    Upper Layer Abort Reason                   /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+It says, upper layer can specify the cause. 
So my questions are:
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1. Is it mandatory to uppe=
r layer to send this cause?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2. If Upper layer doesn= 9;t send any cause, what SCTP should do? Is it should send the cause by its= own (like zero)?

Thanks for your help.
=

Thanks & Regards,
Prasanna.
--f46d043893ed622dbb04fa0a7239-- From nobody Fri May 23 02:26:42 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C631A0150 for ; Fri, 23 May 2014 02:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r-thVK7ag1B for ; Fri, 23 May 2014 02:26:39 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00BF1A014F for ; Fri, 23 May 2014 02:26:38 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id tp5so4773230ieb.39 for ; Fri, 23 May 2014 02:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xq1dl/UrQpeg7W+6UgWiBUAcN+VLpA+MRZXw8i8asJA=; b=vP4IWxYKS//fmZpGl4qXLsotMpCMTBjS9fAfEpv4Fq4SiaQn1BA+qur9hVp3dw8/Us T4apICYSQEIJk3Cd36Wp7iTCQrsW1NJA+t6B0K2ETIXcTgFpi3MwQPYUknTDo3vDyy6A LOc3GBHluT+5gvfVLG6/XVU6lDChwVFLTpzjd+FECptjqN7GmFS9NENO2qHSjhBntaBw ZLpHgsrZcZLIbKh76EjoudfdJeDVhq1YLj+AD9e3QNjideQwpq3OmAIrgr4aV1Xy5Gb0 pVocDCq36buZUyzpr/Sd2mHjaw9DEBuCmOk1e7mYzGqCaLCN/Wg2rj3JLqGTX5wrpJOm bDRQ== MIME-Version: 1.0 X-Received: by 10.50.124.101 with SMTP id mh5mr2547832igb.41.1400837197011; Fri, 23 May 2014 02:26:37 -0700 (PDT) Received: by 10.50.117.103 with HTTP; Fri, 23 May 2014 02:26:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 May 2014 13:26:36 +0400 Message-ID: From: Sergey Mikhailov To: tsvwg@ietf.org Content-Type: multipart/alternative; boundary=089e010d954284259504fa0dd3b0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/0cB9KyISjiG70yNHFP4bg09m1og Subject: [tsvwg] Fwd: Need Clarification on User initiated Abort X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 09:26:40 -0000 --089e010d954284259504fa0dd3b0 Content-Type: text/plain; charset=UTF-8 Prasanna, see my comments below. On Fri, May 23, 2014 at 9:24 AM, Prasanna Kumar wrote: > Hi, > > In the SCTP RFC 4960, we have following information for the User Initiated > abort cause: > > 3.3.10.12 . User-Initiated Abort (12) > > > Cause of error > -------------- > > This error cause MAY be included in ABORT chunks that are sent > because of an upper-layer request. The upper layer can specify an > Upper Layer Abort Reason that is transported by SCTP transparently > and MAY be delivered to the upper-layer protocol at the peer. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Cause Code=12 | Cause Length=Variable | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / Upper Layer Abort Reason / > \ \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > It says, upper layer can specify the cause. > So my questions are: > 1. Is it mandatory to upper layer to send this cause? > The strict and short answer is No. Unfortunately, section 2.21.2 of RFC 4460 modified the text of section 9.1 of the current SCTP specification (now RFC 4960) so that it introduced some inconsistency between 9.1 (saying SHOULD) and 3.3.10.12 (saying MAY). See also items 3 and 5 of RFC 2119. But anyway it is not mandatory. Looks like section 3.3.10.12 should have been updated to reflect a bit more strict requirement (SHOULD instead of MAY) to match that of section 9.1. Section 3.3.10.12: This error cause MAY be included in ABORT chunks that are sent because of an upper-layer request. Section 9.1: If the association is aborted on request of the upper layer, a User-Initiated Abort error cause (see Section 3.3.10.12 ) SHOULD be present in the ABORT chunk. > 2. If Upper layer doesn't send any cause, what SCTP should do? > Is it should send the cause by its own (like zero)? > In this case (when association is aborted on request of the upper layer, which doesn't provide an error cause) SCTP should use Error Cause parameter with "User Initiated Abort" error cause and, in my view, should NOT include any Cause-Specific Information (in this case Cause Length parameter is set to 4 - see also section 3.2.1), while sending this Error Cause within Abort chunk. You see, SCTP simply does not have this information to send. Best regards, Sergey Mikhailov. --089e010d954284259504fa0dd3b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Prasanna,
s= ee my comments below.


On Fri, May 23, 2014 at 9:24 AM, Prasanna = Kumar <prasanna2602@gmail.com> wrote:
Hi,

In the SCTP RFC 4960, we have following information= for the User Initiated abort cause:

3.3.10.12.  User-Initiat=
ed Abort (12)





   Cause of error
   --------------

   This error cause MAY be included in ABORT chunks that are sent
   because of an upper-layer request.  The upper layer can specify an
   Upper Layer Abort Reason that is transported by SCTP transparently
   and MAY be delivered to the upper-layer protocol at the peer.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Cause Code=3D12         |      Cause Length=3DVariable    =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       /                    Upper Layer Abort Reason                   /
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+It says, upper layer can specify the cause. 
So my questions are:
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1. Is it mandatory to uppe=
r layer to send this cause?

The strict and short ans= wer is No.

Unfortunately, section 2.21.2 of RFC 4460 modi= fied the text of section 9.1 of the current SCTP specification (now RFC 49= 60) so that it introduced some inconsistency between 9.1 (saying SHOULD) an= d 3.3.10.12 (saying MAY). See also items 3 and 5 of RFC 2119.

But anyway it is not mandatory.
Looks like section 3.3.10= .12 should have been updated to reflect a bit more strict requirement (SHOU= LD instead of MAY) to match that of section 9.1.


Section 3.3.10.12:

This error cause MAY be included in ABORT chunks t=
hat are sent
   because of an upper-layer request.
Section 9.1:
If the association is aborted on request of the upper layer, a User-Initiated Abort error cause (see Section 3.3.10.12) SHOULD be present in the ABORT chunk= .
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2. If Upper layer doesn= 9;t send any cause, what SCTP should do? Is it should send the cause by its= own (like zero)?

In = this case (when association is aborted on request of the upper layer, which= doesn't provide an error cause) SCTP should use Error Cause parameter = with "User Initiated Abort" error cause and, in my view, should N= OT include any Cause-Specific Information (in this case Cause Length parame= ter is set to 4 - see also section 3.2.1), while sending this Error Cause w= ithin Abort chunk. You see, SCTP simply does not have this information to s= end.

Best regards,
Sergey Mikhailov.

--089e010d954284259504fa0dd3b0-- From nobody Fri May 23 02:41:57 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1A01A0172 for ; Fri, 23 May 2014 02:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdLSKjLhQ7kO for ; Fri, 23 May 2014 02:41:52 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB531A0150 for ; Fri, 23 May 2014 02:41:52 -0700 (PDT) Received: from [47.73.225.87] (unknown [47.73.225.87]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 129B41C0E9738; Fri, 23 May 2014 11:41:48 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: Date: Fri, 23 May 2014 11:41:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Prasanna Kumar X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/rsYhjy80k34AXQ-rh3QyIkpC-ig Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Need Clarification on User initiated Abort X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 09:41:54 -0000 On 23 May 2014, at 07:24, Prasanna Kumar wrote: > Hi, >=20 > In the SCTP RFC 4960, we have following information for the User = Initiated abort cause: >=20 > 3.3.10.12. User-Initiated Abort (12) >=20 >=20 >=20 >=20 > Cause of error > -------------- >=20 > This error cause MAY be included in ABORT chunks that are sent > because of an upper-layer request. The upper layer can specify an > Upper Layer Abort Reason that is transported by SCTP transparently > and MAY be delivered to the upper-layer protocol at the peer. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Cause Code=3D12 | Cause Length=3DVariable = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / Upper Layer Abort Reason = / > \ = \ > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > It says, upper layer can specify the cause.=20 > So my questions are: > 1. Is it mandatory to upper layer to send this cause?=20 No. However, in the FreeBSD implementation, we send it, if the ABORT is = initiated by the user. This helps in debugging any problems where you see all the = sudden an ABORT... > 2. If Upper layer doesn't send any cause, what SCTP should = do? Is it should send the cause by its own (like zero)? Just use an empty cause, so a cause with no Cause-Specific Information. >=20 > Thanks for your help. >=20 > Thanks & Regards, > Prasanna. From nobody Fri May 23 05:25:00 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E313D1A0193 for ; Fri, 23 May 2014 05:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8ZwMkn7He6X for ; Fri, 23 May 2014 05:24:56 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4771A0192 for ; Fri, 23 May 2014 05:24:55 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id i17so7745428qcy.8 for ; Fri, 23 May 2014 05:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ucE2KBUyx+q3UAUVoqZpN4PakLUEny7S6TT0JfZqRA=; b=rY+gGfyBQbGkAd+D2fx4ul/4gao+md8H0/pHM1bbHLNBgRpjts8aMQQgVaLxskkGkO HWOezYES3J4VludEs+JKXY9IjFpIMmCHhkAkIU3tnsSKwf2v5gkMo1+mA6VB4cW9XOHk cbx/jnIPaQWYvqIl8SSBebnMyJZH+QnwCbfjgYEWRJBzRUj58l3weblmcNHUDLGGITap zF1gTZMNndbUWu9bw8EoAKBSmj2zhKdk0AyhQhpCdLV+iY4zKK0e2OF23E4/zw+7H2oH HY+VoYpYqqatE2dpohYhMwL7swCa6WMTIrTnG395tIo9/pEq/MTp4xuGcpfwwkhE2T+8 nEZQ== MIME-Version: 1.0 X-Received: by 10.229.220.197 with SMTP id hz5mr6084899qcb.9.1400847893669; Fri, 23 May 2014 05:24:53 -0700 (PDT) Received: by 10.96.62.10 with HTTP; Fri, 23 May 2014 05:24:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 May 2014 17:54:53 +0530 Message-ID: From: Prasanna Kumar To: Michael Tuexen , sergey.mikhailov@gmail.com Content-Type: multipart/alternative; boundary=001a11346f6a16315204fa105177 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/S8sH6LmYjr4M15VA5OHRbpSR5QA Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Need Clarification on User initiated Abort X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 12:24:57 -0000 --001a11346f6a16315204fa105177 Content-Type: text/plain; charset=UTF-8 Hi Michael and Sergey, Thanks a lot for quick response. It clarifies my doubt. Thanks & Regards, Prasanna. On Fri, May 23, 2014 at 3:11 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > On 23 May 2014, at 07:24, Prasanna Kumar wrote: > > > Hi, > > > > In the SCTP RFC 4960, we have following information for the User > Initiated abort cause: > > > > 3.3.10.12. User-Initiated Abort (12) > > > > > > > > > > Cause of error > > -------------- > > > > This error cause MAY be included in ABORT chunks that are sent > > because of an upper-layer request. The upper layer can specify an > > Upper Layer Abort Reason that is transported by SCTP transparently > > and MAY be delivered to the upper-layer protocol at the peer. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Cause Code=12 | Cause Length=Variable | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > / Upper Layer Abort Reason / > > \ \ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > It says, upper layer can specify the cause. > > So my questions are: > > 1. Is it mandatory to upper layer to send this cause? > No. However, in the FreeBSD implementation, we send it, if the ABORT is > initiated > by the user. This helps in debugging any problems where you see all the > sudden an > ABORT... > > 2. If Upper layer doesn't send any cause, what SCTP should do? > Is it should send the cause by its own (like zero)? > Just use an empty cause, so a cause with no Cause-Specific Information. > > > > Thanks for your help. > > > > Thanks & Regards, > > Prasanna. > > --001a11346f6a16315204fa105177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael and Sergey,

Thanks a lot= for quick response. It clarifies my doubt.

Thanks & Regar= ds,
Prasanna.


On Fri, May 23, 2014 at 3:11 PM, Michael Tuexen <Michael.Tu= exen@lurchi.franken.de> wrote:
On 23 May 2014, at 07:24, Prasanna Kumar <prasanna2602@gmail.com> wrote:

> Hi,
>
> In the SCTP RFC 4960, we have following information for the User Initi= ated abort cause:
>
> 3.3.10.12. =C2=A0User-Initiated Abort (12)
>
>
>
>
> =C2=A0 =C2=A0Cause of error
> =C2=A0 =C2=A0--------------
>
> =C2=A0 =C2=A0This error cause MAY be included in ABORT chunks that are= sent
> =C2=A0 =C2=A0because of an upper-layer request. =C2=A0The upper layer = can specify an
> =C2=A0 =C2=A0Upper Layer Abort Reason that is transported by SCTP tran= sparently
> =C2=A0 =C2=A0and MAY be delivered to the upper-layer protocol at the p= eer.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 3
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 2 3 4 5 6 7 8 9 0 1
> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+
> =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cause Code=3D= 12 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0Cause Length=3DVariabl= e =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+
> =C2=A0 =C2=A0 =C2=A0 =C2=A0/ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Upper Layer Abort Reason =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /
> =C2=A0 =C2=A0 =C2=A0 =C2=A0\ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+
>
> It says, upper layer can specify the cause.
> So my questions are:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. Is it mandatory to upper layer to= send this cause?
No. However, in the FreeBSD implementation, we send it, if the ABORT = is initiated
by the user. This helps in debugging any problems where you see all the sud= den an
ABORT...
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. If Upper layer do= esn't send any cause, what SCTP should do? Is it should send the cause = by its own (like zero)?
Just use an empty cause, so a cause with no Cause-Specific Informatio= n.
>
> Thanks for your help.
>
> Thanks & Regards,
> Prasanna.





--001a11346f6a16315204fa105177-- From nobody Fri May 23 09:47:27 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3625C1A01EB for ; Fri, 23 May 2014 09:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhk_aUd_4ago for ; Fri, 23 May 2014 09:47:23 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728C21A016D for ; Fri, 23 May 2014 09:47:23 -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 s4NGk6Gw008669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 May 2014 09:46:06 -0700 (PDT) Message-ID: <537F7B51.1090809@isi.edu> Date: Fri, 23 May 2014 09:46:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pearl Liang References: In-Reply-To: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/W0qdgfonbvHBKCrBff_FPEH2Lt0 Cc: tsvwg Subject: Re: [tsvwg] Fwd: New Version Notification for draft-ietf-tsvwg-port-use-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:47:25 -0000 On 5/23/2014 9:25 AM, Pearl Liang wrote: > Hi Joe, > > When IANA processed port requests, it appears that some users are unclear > on the differences between a service name with a port number and an SRV > service name. It'll be useful to clarify the (usage) differences of the > two. What do you think? Absolutely - I'll add that too. Joe > > Thanks, > ~pl > > > On 5/15/14 12:45 PM, "Joe Touch" wrote: > >> FYI. >> >> These changes reflect: >> - feedback from Gorry (thanks) >> - full head-to-tail scrub for language consistency and clarity >> removed first and second person informal language >> made RFC citations consistent >> made capitalization consistent >> provided examples for the variety of ways to use ports >> moved some of the citations to the normative section >> - added one new recommendation based on existing BCP advice: >> >>>> Users MUST NOT deploy implementations that default to using the >> experimental System ports (1021 and 1022 [RFC4727]) outside a >> controlled environment where they can be updated with a subsequent >> assigned port [RFC3692]. >> >> This addresses all pending issues. >> >> Joe >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-ietf-tsvwg-port-use-04.txt >> Date: Wed, 14 May 2014 14:05:29 -0700 >> From: internet-drafts@ietf.org >> To: Dr. Joseph D. Touch , Joe Touch >> >> >> A new version of I-D, draft-ietf-tsvwg-port-use-04.txt >> has been successfully submitted by Joe Touch and posted to the >> IETF repository. >> >> Name: draft-ietf-tsvwg-port-use >> Revision: 04 >> Title: Recommendations for Transport Port Uses >> Document date: 2014-05-14 >> Group: tsvwg >> Pages: 19 >> URL: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-04.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ >> Htmlized: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-port-use-04 >> >> Abstract: >> This document provides recommendations to application and service >> designers on how to use the transport protocol port number space to >> help in its preservation. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> From nobody Fri May 23 10:29:35 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD2A1A06D8 for ; Fri, 23 May 2014 09:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu7sQue3rZYv for ; Fri, 23 May 2014 09:25:14 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38FE1A06D4 for ; Fri, 23 May 2014 09:25:14 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Fri, 23 May 2014 09:25:12 -0700 From: Pearl Liang To: Joe Touch Date: Fri, 23 May 2014 09:25:13 -0700 Thread-Topic: [tsvwg] Fwd: New Version Notification for draft-ietf-tsvwg-port-use-04.txt Thread-Index: Ac92o5IoHJMW0EP6QPG/HPCvtrbnrg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3483681913_7148448" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/JoOrAaJbqOPlQv-rdlls-RMDk24 X-Mailman-Approved-At: Fri, 23 May 2014 10:29:33 -0700 Cc: tsvwg Subject: Re: [tsvwg] Fwd: New Version Notification for draft-ietf-tsvwg-port-use-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:25:17 -0000 --B_3483681913_7148448 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Joe, When IANA processed port requests, it appears that some users are unclear on the differences between a service name with a port number and an SRV service name. It'll be useful to clarify the (usage) differences of the two. What do you think? Thanks, ~pl On 5/15/14 12:45 PM, "Joe Touch" wrote: >FYI. > >These changes reflect: > - feedback from Gorry (thanks) > - full head-to-tail scrub for language consistency and clarity > removed first and second person informal language > made RFC citations consistent > made capitalization consistent > provided examples for the variety of ways to use ports > moved some of the citations to the normative section > - added one new recommendation based on existing BCP advice: > > >> Users MUST NOT deploy implementations that default to using the >experimental System ports (1021 and 1022 [RFC4727]) outside a >controlled environment where they can be updated with a subsequent >assigned port [RFC3692]. > >This addresses all pending issues. > >Joe > >-------- Original Message -------- >Subject: New Version Notification for draft-ietf-tsvwg-port-use-04.txt >Date: Wed, 14 May 2014 14:05:29 -0700 >From: internet-drafts@ietf.org >To: Dr. Joseph D. Touch , Joe Touch > > >A new version of I-D, draft-ietf-tsvwg-port-use-04.txt >has been successfully submitted by Joe Touch and posted to the >IETF repository. > >Name: draft-ietf-tsvwg-port-use >Revision: 04 >Title: Recommendations for Transport Port Uses >Document date: 2014-05-14 >Group: tsvwg >Pages: 19 >URL: >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-04.txt >Status: >https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ >Htmlized: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-port-use-04 > >Abstract: > This document provides recommendations to application and service > designers on how to use the transport protocol port number space to > help in its preservation. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > --B_3483681913_7148448 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITtQYJKoZIhvcNAQcCoIITpjCCE6ICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYEwggbxMIIF2aADAgECAhAMLkv5nQhscPoo31D/rbC0MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGeMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczENMAsGA1UECxMESUFOQTEUMBIG A1UEAxMLUGVhcmwgTGlhbmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8XGvf FNfD+o9rdi4/smO4ca3Km10vSC7ACMwISGnnCXV06iC2QCI6J+fFEh0aEVqmr2QkpkYNG9Tz FQogvKVdm/flqOdCYtOCiOyfGTyeWm9B5NTvwdLjZi7q6mTKGUKrsU/y9taKDvQEUL+oCcFS 4hYHeJ/Gp58awDUYzxeqeX9b4apULEqtv+gqVy4pdcAnuMYBEpxB6ks5KqG1xw4yL3kfA8qd PYIpQKIBW5yDsm/q83mvACBwnitLvdloFz+18HqIJiT5gHNMfj9zbvTC2EF/KrsOu3yyl7oq 4iq5FG3ukw8jVuJ4lByEnpCfPoRO4b5jaMl6vqlhL5edYBulAgMBAAGjggNkMIIDYDAfBgNV HSMEGDAWgBQVABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUV/t8ik0UQWj04TEFh1kc pPW8nxkwIAYDVR0RBBkwF4EVcGVhcmwubGlhbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0 cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSG Mmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIB xQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDov L3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOCAQEAqpa7gV+8c/xXFcaU2o6GN2faOkqhsGy/ItSa17RkOvYWDldiUfv0 3UMKQJWRE6UidyvfpzmJzmZCcD3bXRhnrEuByEb2lOvfT0lgUEiBTt7k5gxvNPGqUOBY4qk9 N6i7s88faHXs+daugs2INpkuAIF5Zo282bsZIynL3S74tIx9VTU9cJsYrigKbm/1tdhfMc85 rclJITwfBG3c4pkxWNXC6kG70HZ2EPonK8lJFPKzC3FqDh1XMdEIgzs9MPFn+O+cNkV4m1yU 5vcv5SlRK5PCjo84ompBEIDsDBWDCWm+WfojQDLG6/p46ScSi/gQgdxrn6L+HsifWT4/yt1k kDCCBs0wggW1oAMCAQICEAb9+QOWA63qAArrPye7uhswDQYJKoZIhvcNAQEFBQAwZTELMAkG A1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAw MDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNz dXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKV pYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2w cTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj /qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26C cz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X 8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDejCCA3YwDgYDVR0PAQH/ BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUF BwMEBggrBgEFBQcDCDCCAdIGA1UdIASCAckwggHFMIIBtAYKYIZIAYb9bAABBDCCAaQwOgYI KwYBBQUHAgEWLmh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5o dG0wggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBj AGMAZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQ AC8AQwBQAFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAg AEEAZwByAGUAZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBp AGwAaQB0AHkAIABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABo AGUAcgBlAGkAbgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wCwYJYIZIAYb9bAMVMBIG A1UdEwEB/wQIMAYBAf8CAQAweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcnQwgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0OBBYEFBUAEisTmLKZB+0e36K+Vw0rZwLNMB8GA1UdIwQYMBaAFEXroq/0ksuC MS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQBGUD7Jtygkpzgdtlspr1LPUukxR6tW XHvVDQtBs+/sdR90OPKyXGGinJXDUOSCuSPRujqGcq04eKx1XRcXNHJHhZRW0eu7NoR3zCSl 8wQZVann4+erYs37iy2QwsDStZS9Xk+xBdIOPRqpFFumhjFiqKgz5Js5p8T1zh14dpQlc+Qq q8+cdkvtX8JLFuRLcEwAiR78xXm8TBJX/l/hHrwCXaj++wc4Tw3GXZG5D2dFzdaD7eeSDY2x aYxP+1ngIw/Sqq4AfO6cQg7PkdcntxbuD8O9fAqg7iwIVYUiuOsYGk38KiGtSTGDR5V3cdyx G0tLHBCcdxTBnU8vWpUIKRAmMIIDtzCCAp+gAwIBAgIQDOfg5RfYRv6P5WD8G/AwOTANBgkq hkiG9w0BAQUFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJv b3QgQ0EwHhcNMDYxMTEwMDAwMDAwWhcNMzExMTEwMDAwMDAwWjBlMQswCQYDVQQGEwJVUzEV MBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYD VQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCtDhXO5EOAXLGH87dg+XESpa7cJpSIqvTO9SA5KFhgDPiA2qkVlTJhPLWx KISKityfCgyDF3qPkKyK53lTXDGEKvYPmDI2dsze3Tyoou9q+yHyUmHfnyDXH+Kx2f4YZNIS W1/5WBg1vEfNoTb5a3/UsDg+wRvDjDPZ2C8Y/igPs6eD1sNuRMBhNZYW/lmci3Zt1/GiSw0r /wty2p5g0I6QNcZ4VYcgoc/lbQrISXwxmDNsIumH0DJaoroTghHtORedmTpyoeb6pNnVFzF1 roV9Iq4/AUaG9ih5yLHa5FcXxH4cDrC0kqZWs72yl+2qp/C3xag/lRbQ/6GW6whfGHdPAgMB AAGjYzBhMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRF66Kv 9JLLgjEtUYunpyGd823IDzAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkq hkiG9w0BAQUFAAOCAQEAog683+Lt8ONyc3pklL/3cmbYMuRCdWKuh+vy1dneVrOfzM4UKLkN l2BcEkxY5NM9g0lFWJc1aRqoR+pWxnmrEthngYTffwk8lOa4JiwgvT2zKIn3X/8i4peEH+ll 74fg38FnSbNd67IJKusm7Xi+fT8r87cmNW1fiQG2SVufAQWbqz0lwcy2f8Lxb4bG+mRo64Et lOtCt/qMHt1i8b5QZ7dsvfPxH2sMNgcWfzd8qVttevESRmCD1ycEvkvOl77DZypoEd+A5wwz Zr8TDRRu838fYxAe+o0bJW1sj6W3YQGx0qMmoRBxna3iw/nDmVG3KwcIzi7mULKn+gpFL6Lw 8jGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZ MBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJ RCBDQS0xAhAMLkv5nQhscPoo31D/rbC0MAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU 6Sq8iwpFj4UtQQfRO0CtXiwmt6QwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNTIzMTYyNTEzWjANBgkqhkiG9w0BAQEFAASCAQBY4na11nxZGfEJmOc5 /yLIoHRMWU2d0r9g4P1GnU03qwsmeL6Lt5qPrczlNqgaLXrgbZ5t0UY4Tiz6RZAP089geNEb iurHhmDdRs+X23XuacyWgioNeLnO0QSMkYViei5+QzUSFaADb7FWhfcNQJk6dPQXXeAtPTUM G9zojB1BZizorHjb8Z7jPWalgP9f+7h1RLZuXUYBrZ/kkUJbhddcr2L99SUS/wR9IwappGK+ nS8jQtxXMN0oVMS6l+3aSGzfvmXGx5rp/24CzTRqNX8LJzHSU/qaUGHpG9QSfZVl9w6eexG8 sqCWffZVV2qw5PVhDxIprNHWW++yJgrIBzz7 --B_3483681913_7148448-- From nobody Fri May 23 22:31:31 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64A31A0083 for ; Fri, 23 May 2014 22:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNXdzs0UQ2Up for ; Fri, 23 May 2014 22:31:28 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8354C1A007B for ; Fri, 23 May 2014 22:31:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,899,1392192000"; d="p7s'?scan'208";a="124963147" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 23 May 2014 22:31:25 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by vmwexceht04-prd.hq.netapp.com (10.106.77.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 23 May 2014 22:31:25 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 23 May 2014 22:31:23 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d865:b6fe:275f:ffef%21]) with mapi id 15.00.0847.030; Fri, 23 May 2014 22:31:17 -0700 From: "Eggert, Lars" To: Pearl Liang Thread-Topic: [tsvwg] New Version Notification for draft-ietf-tsvwg-port-use-04.txt Thread-Index: AQHPdxFiIsCjNbktiUiU1mUJKmhcvg== Date: Sat, 24 May 2014 05:31:17 +0000 Message-ID: <8EA0C0EA-7C81-41ED-85BA-4E9B8F690B77@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.35] Content-Type: multipart/signed; boundary="Apple-Mail=_BEBEFAAA-AAE1-4FB1-A363-FCDEDC1582B1"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/MLLQDdIveoxFVbdI7XGosZ48ako Cc: tsvwg , Joe Touch Subject: Re: [tsvwg] New Version Notification for draft-ietf-tsvwg-port-use-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 05:31:30 -0000 --Apple-Mail=_BEBEFAAA-AAE1-4FB1-A363-FCDEDC1582B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Pearl, On 2014-5-23, at 18:25, Pearl Liang wrote: > When IANA processed port requests, it appears that some users are = unclear > on the differences between a service name with a port number and an = SRV > service name. It'll be useful to clarify the (usage) differences of = the > two. What do you think? there is no difference, right? Whether or not they have an assigned port = number doesn't matter for what they can use the service name for. Lars= --Apple-Mail=_BEBEFAAA-AAE1-4FB1-A363-FCDEDC1582B1 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVzCCBhsw ggUDoAMCAQICAwhPlDANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMTIwNjA3MDk0N1oXDTE0MTIwNzA3MDY0MVowOjEYMBYGA1UEAwwPbGFyc0BuZXRhcHAu Y29tMR4wHAYJKoZIhvcNAQkBFg9sYXJzQG5ldGFwcC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDS6c3AH5ZSxTExtqA4RCkRMWmh84KVsbd85iNmeq2VHJv2Pc9TXG6aZz7r3Fjp qXV+VtHlHOzZ1ncpMV0ldJMgi8F45/5WpSMEg4sXnYdtheE3drgWeR816PEaydHqSnaMNutAC7Td ykkOFHXIsVg8IblDXhfiVQiZBZd+Wz6BpyMe59gr4Bpveft18uPQIXSxE95EsDTMyd/UDLVB+AkB gHhO0+XxauzCbNUnubyiYYGOzgQ9G8J3Ewgrr/nVR+CrBCYgIsBP3foo0/h1hE7dHyI0Gl341yR7 J0AHDQ0DPIQOQtscFuRlthksCZLCfVSK6Mh6hVCOMEjVJxrgeBU3AgMBAAGjggLVMIIC0TAJBgNV HRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O BBYEFHIOXgd2Y3/7a+OqwJ2giDTpYULAMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGC MBoGA1UdEQQTMBGBD2xhcnNAbmV0YXBwLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGB tTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRm MIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEB GoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBW YWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5j ZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRw Oi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAMCLv+Qk QYJxSendSLJPbFKuMkgm1PdAVoqxKAi8HmbirBTPhxh0vzhmZ/rneCHHlqY4p6r81+Se9HsqDsB6 DBQ/IbNgs7FQlCqOvCIwbn7VK+k/0eJAyOjIaUDPoD1ZaA1AkaFjJxvD2ZUZLBNq4AvOuP52j0Dm i0FBC6pbBfnz57wuB++3P4NBTfZABbdazHlxl/2z1RGQNGov3R6zwNZLbxU2o2ftEJ48j4unuHjP islFru3GRp4dbm5JLuHjUdDyXtMw6CdDvlmWQCcAgtEfqbGDp9bSSE9vbXbgf8n6iHoIA96HnTBW BTDERdixe8t0T9AyT4ks9eHFLPL+PbwwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk aWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0U jM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQ dcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O 2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB /wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5z dGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmww J6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1Bgsr BgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRm MA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY 1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A +hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0 t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHD RHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI /EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO 7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMY u9jGfIpDLtUUGSgsg2zMGs5R4jGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwhPlDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA1MjQwNTMxMTRaMCMGCSqGSIb3DQEJBDEWBBSbfz34FXp29Ks2UpulhZet UcbrRjCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwhP lDCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCE+U MA0GCSqGSIb3DQEBAQUABIIBAITiE4Isj5bDD2B8lBjXnWNp/sSPdFs30r6rQzumUiPAW03w/x1Q zLrUEkyKOueBUt4PSjjHk1nrNbvNDwfIaVq5uEltUqA2KiGIUDjUcu8OqedfY8GVpeU/A6CsI+aP aO67QSdzFr5m+xM5eHrmxpHkRVJv5rsdikKdwu2BcBQcYGfXNwQmNYt7NwEIeVqOIV/SOUp7RxfY 8EuhjaON/d+bxWiusd9ZiJzPl/iOdlHRTx1Gfb2QjcdH8/tIKFqx4UViJH79Ydj1PBVg/lNiuFcg wSFuCCuBscGNXU/TvH8oQLnvs8uokG15BIFsIOPOc+dSdGXzOmjAffXtLofgVjwAAAAAAAA= --Apple-Mail=_BEBEFAAA-AAE1-4FB1-A363-FCDEDC1582B1-- From nobody Mon May 26 13:50:52 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A2E1A027C for ; Mon, 26 May 2014 13:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ttJpKggTQpO for ; Mon, 26 May 2014 13:50:38 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D901A0286 for ; Mon, 26 May 2014 13:50:38 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id sa20so9629667veb.23 for ; Mon, 26 May 2014 13:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sliSm/3Du0rqufJo8Q3acq9OIUinm8b1rgCECBCNUC4=; b=JfkrYrMfxJzoiBGxjYrQNWAq/9o2EYCKrckgkjk7zRADM3xWnxcjrltQbJG28VsmOp x/QnWbO0V4YwE4AnQ2vrqHESHiQRIdKSCrKLi/+fIjHaVMpNvpZrAYyKeqsIuA0DFmUH Z1KaKXGf9SO7/AwwtwzD2j/zuCIv7wqKYwoeO5Uyzi4x7hPC6Km/0U/9s++yhsyDFsx/ qFIJ5MKXazKQt7Tv7LY52o1VS5f75ddfWWPUenI4rWQ1nUs/B88hZi2svCr4UgXIE4C/ cLHXsEe5uU1BcW0gWBGuS2c9YN63HMiu4cYgYpo2ZcqYalnE2ly6yjIsbaWEEHQLhveM Aa/w== MIME-Version: 1.0 X-Received: by 10.220.94.146 with SMTP id z18mr9175374vcm.40.1401137434858; Mon, 26 May 2014 13:50:34 -0700 (PDT) Received: by 10.220.104.8 with HTTP; Mon, 26 May 2014 13:50:34 -0700 (PDT) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> Date: Mon, 26 May 2014 13:50:34 -0700 Message-ID: From: Paul Hoffman To: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1e9d0161a8004fa53bb2f Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/rgyEcZkxFPlu8d5jqEqLEnOZ9kw Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 20:50:40 -0000 --001a11c1e9d0161a8004fa53bb2f Content-Type: text/plain; charset=UTF-8 This draft, when taken in light of RFC 6335, is completely unnecessary. If it is moved forward at this time, it will cause harm to the Internet for absolutely no purpose. There is no evidence that that port numbers are actually scarce. The number of new ports assigned in the past decade is tiny. RFC 6335, which is the current BCP for TCP/UDP port number allocation from just three years ago, says: As noted earlier, only about 9% of the User Port space is currently assigned. The current rate of assignment is approximately 400 ports per year, and has remained steady for the past 8 years. At that rate, if similar conservation continues, this resource will sustain another 85 years of assignment - without the need to resort to reassignment of released values or revocation. The draft presumes that preservation of port numbers, even when there is in fact no significant scarcity, is more important than letting Application and Security Area WGs determine what their ports needs are. The information about applications that use one fixed port and then dynamic ports ignores experience that has revealed significant problems. Even if there were real scarcity (which the BCP shows that there isn't), it is impossible to weigh the needs of port scarcity against the need to create less fragile protocols. Ten years from now, if more than 25% of the port space is assigned, the Transport, Applications, and Security Areas can reconsider something like this document. Until there is any evidence that there is scarcity that would cause Application and Security Area changes, the idea should be shelved and not even discussed. --001a11c1e9d0161a8004fa53bb2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This draft, when taken in light of RFC 6335, is completely= unnecessary. If it is moved forward at this time, it will cause harm to th= e Internet for absolutely no purpose.

There is no evidence that that= port numbers are actually scarce. The number of new ports assigned in the = past decade is tiny. RFC 6335, which is the current BCP for TCP/UDP port nu= mber allocation from just three years ago, says:

=C2=A0=C2=A0 As noted earlier, only about 9% of the User Port space is = currently
=C2=A0=C2=A0 assigned.=C2=A0 The current rate of assignment is= approximately 400 ports
=C2=A0=C2=A0 per year, and has remained steady = for the past 8 years.=C2=A0 At that
=C2=A0=C2=A0 rate, if similar conservation continues, this resource will su= stain
=C2=A0=C2=A0 another 85 years of assignment - without the need to = resort to
=C2=A0=C2=A0 reassignment of released values or revocation.
The draft presumes that preservation of port numbers, even when there = is in fact no significant scarcity, is more important than letting Applicat= ion and Security Area WGs determine what their ports needs are.=C2=A0 The i= nformation about applications that use one fixed port and then dynamic port= s ignores experience that has revealed significant problems. Even if there = were real scarcity (which the BCP shows that there isn't), it is imposs= ible to weigh the needs of port scarcity against the need to create less fr= agile protocols.

Ten years from now, if more than 25% of the port space is assigned, the= Transport, Applications, and Security Areas can reconsider something like = this document. Until there is any evidence that there is scarcity that woul= d cause Application and Security Area changes, the idea should be shelved a= nd not even discussed.

--001a11c1e9d0161a8004fa53bb2f-- From nobody Mon May 26 23:27:10 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C860B1A02C0 for ; Mon, 26 May 2014 15:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2wbZH3ySlbs for ; Mon, 26 May 2014 15:48:41 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9211A02BC for ; Mon, 26 May 2014 15:48:41 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 26 May 2014 15:48:38 -0700 From: Pearl Liang To: "Eggert, Lars" Date: Mon, 26 May 2014 15:48:41 -0700 Thread-Topic: [tsvwg] New Version Notification for draft-ietf-tsvwg-port-use-04.txt Thread-Index: Ac95NKEdKiBQbxgNT2eonvF+vJVB6A== Message-ID: References: <8EA0C0EA-7C81-41ED-85BA-4E9B8F690B77@netapp.com> In-Reply-To: <8EA0C0EA-7C81-41ED-85BA-4E9B8F690B77@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3483964121_8882982" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/MeD_wPCsZSinCXitBkbLqo9cAuQ X-Mailman-Approved-At: Mon, 26 May 2014 23:27:09 -0700 Cc: tsvwg , Joe Touch Subject: Re: [tsvwg] New Version Notification for draft-ietf-tsvwg-port-use-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 22:48:43 -0000 --B_3483964121_8882982 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Lars, Apologies in advance if I asked a wrong question. So, - does the word 'SRV' apply to all service names regardless one with a port number or without it? - When and how a user decide to add a port number with the DNS SRV service name? In another word, why can a user simply register an DNS SRV service name without a port number? Make sense? Thank you, ~pl On 5/23/14 10:31 PM, "Eggert, Lars" wrote: >Hi Pearl, > >On 2014-5-23, at 18:25, Pearl Liang wrote: >> When IANA processed port requests, it appears that some users are >>unclear >> on the differences between a service name with a port number and an SRV >> service name. It'll be useful to clarify the (usage) differences of the >> two. What do you think? > >there is no difference, right? Whether or not they have an assigned port >number doesn't matter for what they can use the service name for. > >Lars --B_3483964121_8882982 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITtQYJKoZIhvcNAQcCoIITpjCCE6ICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYEwggbxMIIF2aADAgECAhAMLkv5nQhscPoo31D/rbC0MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGeMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczENMAsGA1UECxMESUFOQTEUMBIG A1UEAxMLUGVhcmwgTGlhbmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8XGvf FNfD+o9rdi4/smO4ca3Km10vSC7ACMwISGnnCXV06iC2QCI6J+fFEh0aEVqmr2QkpkYNG9Tz FQogvKVdm/flqOdCYtOCiOyfGTyeWm9B5NTvwdLjZi7q6mTKGUKrsU/y9taKDvQEUL+oCcFS 4hYHeJ/Gp58awDUYzxeqeX9b4apULEqtv+gqVy4pdcAnuMYBEpxB6ks5KqG1xw4yL3kfA8qd PYIpQKIBW5yDsm/q83mvACBwnitLvdloFz+18HqIJiT5gHNMfj9zbvTC2EF/KrsOu3yyl7oq 4iq5FG3ukw8jVuJ4lByEnpCfPoRO4b5jaMl6vqlhL5edYBulAgMBAAGjggNkMIIDYDAfBgNV HSMEGDAWgBQVABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUV/t8ik0UQWj04TEFh1kc pPW8nxkwIAYDVR0RBBkwF4EVcGVhcmwubGlhbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0 cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSG Mmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIB xQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDov L3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOCAQEAqpa7gV+8c/xXFcaU2o6GN2faOkqhsGy/ItSa17RkOvYWDldiUfv0 3UMKQJWRE6UidyvfpzmJzmZCcD3bXRhnrEuByEb2lOvfT0lgUEiBTt7k5gxvNPGqUOBY4qk9 N6i7s88faHXs+daugs2INpkuAIF5Zo282bsZIynL3S74tIx9VTU9cJsYrigKbm/1tdhfMc85 rclJITwfBG3c4pkxWNXC6kG70HZ2EPonK8lJFPKzC3FqDh1XMdEIgzs9MPFn+O+cNkV4m1yU 5vcv5SlRK5PCjo84ompBEIDsDBWDCWm+WfojQDLG6/p46ScSi/gQgdxrn6L+HsifWT4/yt1k kDCCBs0wggW1oAMCAQICEAb9+QOWA63qAArrPye7uhswDQYJKoZIhvcNAQEFBQAwZTELMAkG A1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAw MDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNz dXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKV pYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2w cTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj /qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26C cz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X 8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDejCCA3YwDgYDVR0PAQH/ BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUF BwMEBggrBgEFBQcDCDCCAdIGA1UdIASCAckwggHFMIIBtAYKYIZIAYb9bAABBDCCAaQwOgYI KwYBBQUHAgEWLmh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5o dG0wggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBj AGMAZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQ AC8AQwBQAFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAg AEEAZwByAGUAZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBp AGwAaQB0AHkAIABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABo AGUAcgBlAGkAbgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wCwYJYIZIAYb9bAMVMBIG A1UdEwEB/wQIMAYBAf8CAQAweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcnQwgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0OBBYEFBUAEisTmLKZB+0e36K+Vw0rZwLNMB8GA1UdIwQYMBaAFEXroq/0ksuC MS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQBGUD7Jtygkpzgdtlspr1LPUukxR6tW XHvVDQtBs+/sdR90OPKyXGGinJXDUOSCuSPRujqGcq04eKx1XRcXNHJHhZRW0eu7NoR3zCSl 8wQZVann4+erYs37iy2QwsDStZS9Xk+xBdIOPRqpFFumhjFiqKgz5Js5p8T1zh14dpQlc+Qq q8+cdkvtX8JLFuRLcEwAiR78xXm8TBJX/l/hHrwCXaj++wc4Tw3GXZG5D2dFzdaD7eeSDY2x aYxP+1ngIw/Sqq4AfO6cQg7PkdcntxbuD8O9fAqg7iwIVYUiuOsYGk38KiGtSTGDR5V3cdyx G0tLHBCcdxTBnU8vWpUIKRAmMIIDtzCCAp+gAwIBAgIQDOfg5RfYRv6P5WD8G/AwOTANBgkq hkiG9w0BAQUFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJv b3QgQ0EwHhcNMDYxMTEwMDAwMDAwWhcNMzExMTEwMDAwMDAwWjBlMQswCQYDVQQGEwJVUzEV MBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYD VQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCtDhXO5EOAXLGH87dg+XESpa7cJpSIqvTO9SA5KFhgDPiA2qkVlTJhPLWx KISKityfCgyDF3qPkKyK53lTXDGEKvYPmDI2dsze3Tyoou9q+yHyUmHfnyDXH+Kx2f4YZNIS W1/5WBg1vEfNoTb5a3/UsDg+wRvDjDPZ2C8Y/igPs6eD1sNuRMBhNZYW/lmci3Zt1/GiSw0r /wty2p5g0I6QNcZ4VYcgoc/lbQrISXwxmDNsIumH0DJaoroTghHtORedmTpyoeb6pNnVFzF1 roV9Iq4/AUaG9ih5yLHa5FcXxH4cDrC0kqZWs72yl+2qp/C3xag/lRbQ/6GW6whfGHdPAgMB AAGjYzBhMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRF66Kv 9JLLgjEtUYunpyGd823IDzAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkq hkiG9w0BAQUFAAOCAQEAog683+Lt8ONyc3pklL/3cmbYMuRCdWKuh+vy1dneVrOfzM4UKLkN l2BcEkxY5NM9g0lFWJc1aRqoR+pWxnmrEthngYTffwk8lOa4JiwgvT2zKIn3X/8i4peEH+ll 74fg38FnSbNd67IJKusm7Xi+fT8r87cmNW1fiQG2SVufAQWbqz0lwcy2f8Lxb4bG+mRo64Et lOtCt/qMHt1i8b5QZ7dsvfPxH2sMNgcWfzd8qVttevESRmCD1ycEvkvOl77DZypoEd+A5wwz Zr8TDRRu838fYxAe+o0bJW1sj6W3YQGx0qMmoRBxna3iw/nDmVG3KwcIzi7mULKn+gpFL6Lw 8jGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZ MBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJ RCBDQS0xAhAMLkv5nQhscPoo31D/rbC0MAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU iJrPi7AlewOCYrnD45TXEFPh7HQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNTI2MjI0ODQxWjANBgkqhkiG9w0BAQEFAASCAQB8qV30qFfOP4wQzCTc S3LCAfmU9InoAQFkNZ7Gp/dgRLiEhau5KleExOFBz7mr4hFM0793vG+kuCSmkS8D1nHc7tNJ 1NzTOQquxUkz8yEV7cSZdjSXCn+Zl72Qtng5czB80HXkWwYPGBiaTJuMddCqGUpR7G8Uni2U JZutMkXn0DutlWTRE7HxPb0bM2zAPL/GOsuhL4mAr99tZ3JqxmHa6ME9IHUb84VwdqXAkczK NwTMx5sWbMdB35pKvQ+dBxJxuMQoHOxnBbLTuwfBemX1+HEOOoyTt+l1nUUHvqkMvGYbhJ3b vpb2/LCbfli+5eB++R3zxdrl5QRJl4bfCHPS --B_3483964121_8882982-- From nobody Mon May 26 23:30:37 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710AB1A039B for ; Mon, 26 May 2014 23:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A61jEF46cUCj for ; Mon, 26 May 2014 23:30:33 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2C31A0396 for ; Mon, 26 May 2014 23:30:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,917,1392192000"; d="asc'?scan'208";a="166662078" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 26 May 2014 23:30:30 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 26 May 2014 23:30:29 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 26 May 2014 23:30:23 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d865:b6fe:275f:ffef%21]) with mapi id 15.00.0847.030; Mon, 26 May 2014 23:30:22 -0700 From: "Eggert, Lars" To: Pearl Liang Thread-Topic: [tsvwg] New Version Notification for draft-ietf-tsvwg-port-use-04.txt Thread-Index: AQHPdxFiIsCjNbktiUiU1mUJKmhcvptT8H2AgACA/YA= Date: Tue, 27 May 2014 06:30:22 +0000 Message-ID: <0EEE0BBC-C9D0-43F8-A162-0278F6B8173D@netapp.com> References: <8EA0C0EA-7C81-41ED-85BA-4E9B8F690B77@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_29A2D399-4F55-4C13-8866-890A455F15A8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/GTiRZNeyZZL7or64UJtKV6g0hd0 Cc: tsvwg , Joe Touch Subject: Re: [tsvwg] New Version Notification for draft-ietf-tsvwg-port-use-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 06:30:34 -0000 --Apple-Mail=_29A2D399-4F55-4C13-8866-890A455F15A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-5-27, at 0:48, Pearl Liang wrote: >=20 > - does the word 'SRV' apply to all service names regardless one with a > port number or without it? SRV comes from DNS SRV records. That's one (important) way in which = service names can be used, but it is not the only one. The canonical = term is service name. And yes, they are all service names, whether or = not they have port numbers assigned. > - When and how a user decide to add a port number with the DNS SRV = service > name? In another word, why can a user simply register an DNS SRV = service > name without a port number? This is discussed in RFC6335. Applicants can ask for a service name (not = an SRV name, a service name - DNS SRVs are just one way in which service = names are used; see above) when they do not need an assigned port, = because - for example - they are using a service discovery protocol like = mDNS and only require a name, not a number. Lars --Apple-Mail=_29A2D399-4F55-4C13-8866-890A455F15A8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU4Qw/tZcnpRveo1xAQJsUAQAl5jPHx1W8Rt4XVTqznnhInG6PHqbnbik 2dgyUB3EKA6HOSkGumiAZpRCesBuEYuYio7riwCNjW/rprxjabe0gzCiTpmJp+xI bjWpNX3aqem0XLVrI4w1MIc6PNOUhTu6Qm5sNVTA4UtfOzDCQsFD/HEkaUNO6iXt YgOVE2Sz7NM= =+XLU -----END PGP SIGNATURE----- --Apple-Mail=_29A2D399-4F55-4C13-8866-890A455F15A8-- From nobody Tue May 27 06:06:31 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A92D1A0148 for ; Tue, 27 May 2014 06:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwpNfgNpPvYI for ; Tue, 27 May 2014 06:06:25 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA4E1A0143 for ; Tue, 27 May 2014 06:06:25 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4RD6Iw9009963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 May 2014 09:06:19 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s4RD6Iw9009963 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401195979; bh=I9opmZIKu+VHcmnbZHvrpuSGjJ0=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=LYYG7D/awZINL0+6mAc75Ua+fx9s1+RAG/G/WXGHlSM49RIoOBGJ/E0Pqq34N1HsB d3oGp8CGsMINN6XRgxI+5AutBN/avLi96yosSXk/EMUmVxVFL7F6nVhVHzR4yKYBXu zNk4HUbGqgxY0UUmNEudhLksydFhMitvg6whmO6A= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s4RD6Iw9009963 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 27 May 2014 06:05:59 -0700 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4RD5wST006203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 09:05:58 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Tue, 27 May 2014 09:05:58 -0400 From: "Black, David" To: Paul Hoffman , "tsvwg@ietf.org" Date: Tue, 27 May 2014 09:05:56 -0400 Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) Thread-Index: Ac95JDLENeF3rdtHSgS805UYq+v3twAhqszQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C66303C@MX15A.corp.emc.com> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712076C66303CMX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/bQQtUwAIOilCuyfy7k92dmk1src Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:06:29 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE712076C66303CMX15Acorpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGF1bCwNCg0KPFdHIGNoYWlyIGhhdCBvbj4NCg0KVGhhbmsgeW91IGZvciBjb21tZW50aW5nLiAg SW4gdGhlIGhvcGUgb2YgZnJhbWluZyBmdXJ0aGVyIGRpc2N1c3Npb24sDQpJIGhhdmUgYSBmZXcg cHJvY2Vzcy1vcmllbnRlZCBjb21tZW50cy4NCg0KVGhlIHN0YXJ0aW5nIHBvaW50IGZvciB0aGlz IGRpc2N1c3Npb24gc2hvdWxkIGJlIFJGQyA2MzM1LCBlc3BlY2lhbGx5DQpTZWN0aW9ucyA3IGFu ZCA4IG9uIHByaW5jaXBsZXMgYW5kIHByb2NlZHVyZXMuDQoNClRoaXMgZHJhZnQgaXMgbm90IGlu dGVuZGVkIHRvIG1vZGlmeSBSRkMgNjMzNS4gIE9uIHRoYXQgYmFzaXMsIEnigJlkDQpzdWdnZXN0 IGEgY291cGxlIG9mIHF1ZXN0aW9ucyBmb3IgZnVydGhlciBkaXNjdXNzaW9uICh0byB3aGljaCBJ DQpiZWxpZXZlIHlvdXIgY29tbWVudHMgYXJlIHJlbGV2YW50KToNCg0KLSBIb3cvd2hlcmUgZG9l cyB0aGlzIGRyYWZ0IGFwcGVhciB0byBtb2RpZnkgUkZDIDYzMzUgYW5kL29yIG90aGVyd2lzZQ0K ZGl2ZXJnZSBmcm9tIHRoZSBhcHByb2FjaCBzZXQgb3V0IGluIHRoYXQgUkZDPw0KDQotIFdoYXQg c29ydCBvZiBndWlkYW5jZSBiZXlvbmQgUkZDIDYzMzUgd291bGQgYmUgdXNlZnVsIHRvIGFwcGxp Y2F0aW9uDQphbmQgc2VydmljZSBkZXNpZ25lcnM/DQoNCjwvV0cgY2hhaXIgaGF0IG9uPg0KDQpU aGFua3MsDQotLURhdmlkDQoNCkZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFBhdWwgSG9mZm1hbg0KU2VudDogTW9uZGF5LCBNYXkgMjYsIDIw MTQgNDo1MSBQTQ0KVG86IHRzdndnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RzdndnXSBXR0xD IGZvciBkcmFmdC1pZXRmLXRzdndnLXBvcnQtdXNlLTA0ICh0byBlbmQgNnRoIEp1bmUpDQoNClRo aXMgZHJhZnQsIHdoZW4gdGFrZW4gaW4gbGlnaHQgb2YgUkZDIDYzMzUsIGlzIGNvbXBsZXRlbHkg dW5uZWNlc3NhcnkuIElmIGl0IGlzIG1vdmVkIGZvcndhcmQgYXQgdGhpcyB0aW1lLCBpdCB3aWxs IGNhdXNlIGhhcm0gdG8gdGhlIEludGVybmV0IGZvciBhYnNvbHV0ZWx5IG5vIHB1cnBvc2UuDQoN ClRoZXJlIGlzIG5vIGV2aWRlbmNlIHRoYXQgdGhhdCBwb3J0IG51bWJlcnMgYXJlIGFjdHVhbGx5 IHNjYXJjZS4gVGhlIG51bWJlciBvZiBuZXcgcG9ydHMgYXNzaWduZWQgaW4gdGhlIHBhc3QgZGVj YWRlIGlzIHRpbnkuIFJGQyA2MzM1LCB3aGljaCBpcyB0aGUgY3VycmVudCBCQ1AgZm9yIFRDUC9V RFAgcG9ydCBudW1iZXIgYWxsb2NhdGlvbiBmcm9tIGp1c3QgdGhyZWUgeWVhcnMgYWdvLCBzYXlz Og0KDQogICBBcyBub3RlZCBlYXJsaWVyLCBvbmx5IGFib3V0IDklIG9mIHRoZSBVc2VyIFBvcnQg c3BhY2UgaXMgY3VycmVudGx5DQogICBhc3NpZ25lZC4gIFRoZSBjdXJyZW50IHJhdGUgb2YgYXNz aWdubWVudCBpcyBhcHByb3hpbWF0ZWx5IDQwMCBwb3J0cw0KICAgcGVyIHllYXIsIGFuZCBoYXMg cmVtYWluZWQgc3RlYWR5IGZvciB0aGUgcGFzdCA4IHllYXJzLiAgQXQgdGhhdA0KICAgcmF0ZSwg aWYgc2ltaWxhciBjb25zZXJ2YXRpb24gY29udGludWVzLCB0aGlzIHJlc291cmNlIHdpbGwgc3Vz dGFpbg0KICAgYW5vdGhlciA4NSB5ZWFycyBvZiBhc3NpZ25tZW50IC0gd2l0aG91dCB0aGUgbmVl ZCB0byByZXNvcnQgdG8NCiAgIHJlYXNzaWdubWVudCBvZiByZWxlYXNlZCB2YWx1ZXMgb3IgcmV2 b2NhdGlvbi4NCg0KVGhlIGRyYWZ0IHByZXN1bWVzIHRoYXQgcHJlc2VydmF0aW9uIG9mIHBvcnQg bnVtYmVycywgZXZlbiB3aGVuIHRoZXJlIGlzIGluIGZhY3Qgbm8gc2lnbmlmaWNhbnQgc2NhcmNp dHksIGlzIG1vcmUgaW1wb3J0YW50IHRoYW4gbGV0dGluZyBBcHBsaWNhdGlvbiBhbmQgU2VjdXJp dHkgQXJlYSBXR3MgZGV0ZXJtaW5lIHdoYXQgdGhlaXIgcG9ydHMgbmVlZHMgYXJlLiAgVGhlIGlu Zm9ybWF0aW9uIGFib3V0IGFwcGxpY2F0aW9ucyB0aGF0IHVzZSBvbmUgZml4ZWQgcG9ydCBhbmQg dGhlbiBkeW5hbWljIHBvcnRzIGlnbm9yZXMgZXhwZXJpZW5jZSB0aGF0IGhhcyByZXZlYWxlZCBz aWduaWZpY2FudCBwcm9ibGVtcy4gRXZlbiBpZiB0aGVyZSB3ZXJlIHJlYWwgc2NhcmNpdHkgKHdo aWNoIHRoZSBCQ1Agc2hvd3MgdGhhdCB0aGVyZSBpc24ndCksIGl0IGlzIGltcG9zc2libGUgdG8g d2VpZ2ggdGhlIG5lZWRzIG9mIHBvcnQgc2NhcmNpdHkgYWdhaW5zdCB0aGUgbmVlZCB0byBjcmVh dGUgbGVzcyBmcmFnaWxlIHByb3RvY29scy4NCg0KVGVuIHllYXJzIGZyb20gbm93LCBpZiBtb3Jl IHRoYW4gMjUlIG9mIHRoZSBwb3J0IHNwYWNlIGlzIGFzc2lnbmVkLCB0aGUgVHJhbnNwb3J0LCBB cHBsaWNhdGlvbnMsIGFuZCBTZWN1cml0eSBBcmVhcyBjYW4gcmVjb25zaWRlciBzb21ldGhpbmcg bGlrZSB0aGlzIGRvY3VtZW50LiBVbnRpbCB0aGVyZSBpcyBhbnkgZXZpZGVuY2UgdGhhdCB0aGVy ZSBpcyBzY2FyY2l0eSB0aGF0IHdvdWxkIGNhdXNlIEFwcGxpY2F0aW9uIGFuZCBTZWN1cml0eSBB cmVhIGNoYW5nZXMsIHRoZSBpZGVhIHNob3VsZCBiZSBzaGVsdmVkIGFuZCBub3QgZXZlbiBkaXNj dXNzZWQuDQo= --_000_8D3D17ACE214DC429325B2B98F3AE712076C66303CMX15Acorpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj azsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNv cmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o ZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+UGF1bCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+Jmx0O1dHIGNoYWly IGhhdCBvbiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6 YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjpibGFjayc+VGhhbmsgeW91IGZvciBjb21tZW50aW5nLsKgIEluIHRoZSBob3BlIG9mIGZyYW1p bmcgZnVydGhlciBkaXNjdXNzaW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijtjb2xvcjpibGFjayc+SSBoYXZlIGEgZmV3IHByb2Nlc3Mtb3JpZW50ZWQgY29tbWVudHMu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPlRo ZSBzdGFydGluZyBwb2ludCBmb3IgdGhpcyBkaXNjdXNzaW9uIHNob3VsZCBiZSBSRkMgNjMzNSwg ZXNwZWNpYWxseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpi bGFjayc+U2VjdGlvbnMgNyBhbmQgOCBvbiBwcmluY2lwbGVzIGFuZCBwcm9jZWR1cmVzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5UaGlzIGRy YWZ0IGlzIG5vdCBpbnRlbmRlZCB0byBtb2RpZnkgUkZDIDYzMzUuwqAgT24gdGhhdCBiYXNpcywg SeKAmWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2sn PnN1Z2dlc3QgYSBjb3VwbGUgb2YgcXVlc3Rpb25zIGZvciBmdXJ0aGVyIGRpc2N1c3Npb24gKHRv IHdoaWNoIEk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6Ymxh Y2snPmJlbGlldmUgeW91ciBjb21tZW50cyBhcmUgcmVsZXZhbnQpOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4tIEhvdy93aGVyZSBkb2VzIHRo aXMgZHJhZnQgYXBwZWFyIHRvIG1vZGlmeSBSRkMgNjMzNSBhbmQvb3Igb3RoZXJ3aXNlPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6LjVp bic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijtjb2xvcjpibGFjayc+ZGl2ZXJnZSBmcm9tIHRoZSBhcHByb2FjaCBzZXQgb3V0IGluIHRoYXQg UkZDPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNr Jz4tIFdoYXQgc29ydCBvZiBndWlkYW5jZSBiZXlvbmQgUkZDIDYzMzUgd291bGQgYmUgdXNlZnVs IHRvIGFwcGxpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0ndGV4dC1pbmRlbnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+YW5kIHNlcnZpY2UgZGVzaWduZXJz PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4m bHQ7L1dHIGNoYWlyIGhhdCBvbiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciO2NvbG9yOmJsYWNrJz5UaGFua3MsPGJyPi0tRGF2aWQ8L3NwYW4+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9y OmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2Vz QGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlBhdWwgSG9mZm1hbjxicj48Yj5TZW50Ojwv Yj4gTW9uZGF5LCBNYXkgMjYsIDIwMTQgNDo1MSBQTTxicj48Yj5Ubzo8L2I+IHRzdndnQGlldGYu b3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3RzdndnXSBXR0xDIGZvciBkcmFmdC1pZXRmLXRz dndnLXBvcnQtdXNlLTA0ICh0byBlbmQgNnRoIEp1bmUpPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPlRoaXMgZHJhZnQs IHdoZW4gdGFrZW4gaW4gbGlnaHQgb2YgUkZDIDYzMzUsIGlzIGNvbXBsZXRlbHkgdW5uZWNlc3Nh cnkuIElmIGl0IGlzIG1vdmVkIGZvcndhcmQgYXQgdGhpcyB0aW1lLCBpdCB3aWxsIGNhdXNlIGhh cm0gdG8gdGhlIEludGVybmV0IGZvciBhYnNvbHV0ZWx5IG5vIHB1cnBvc2UuPGJyPjxicj5UaGVy ZSBpcyBubyBldmlkZW5jZSB0aGF0IHRoYXQgcG9ydCBudW1iZXJzIGFyZSBhY3R1YWxseSBzY2Fy Y2UuIFRoZSBudW1iZXIgb2YgbmV3IHBvcnRzIGFzc2lnbmVkIGluIHRoZSBwYXN0IGRlY2FkZSBp cyB0aW55LiBSRkMgNjMzNSwgd2hpY2ggaXMgdGhlIGN1cnJlbnQgQkNQIGZvciBUQ1AvVURQIHBv cnQgbnVtYmVyIGFsbG9jYXRpb24gZnJvbSBqdXN0IHRocmVlIHllYXJzIGFnbywgc2F5czo8YnI+ PGJyPiZuYnNwOyZuYnNwOyBBcyBub3RlZCBlYXJsaWVyLCBvbmx5IGFib3V0IDklIG9mIHRoZSBV c2VyIFBvcnQgc3BhY2UgaXMgY3VycmVudGx5PGJyPiZuYnNwOyZuYnNwOyBhc3NpZ25lZC4mbmJz cDsgVGhlIGN1cnJlbnQgcmF0ZSBvZiBhc3NpZ25tZW50IGlzIGFwcHJveGltYXRlbHkgNDAwIHBv cnRzPGJyPiZuYnNwOyZuYnNwOyBwZXIgeWVhciwgYW5kIGhhcyByZW1haW5lZCBzdGVhZHkgZm9y IHRoZSBwYXN0IDggeWVhcnMuJm5ic3A7IEF0IHRoYXQ8YnI+Jm5ic3A7Jm5ic3A7IHJhdGUsIGlm IHNpbWlsYXIgY29uc2VydmF0aW9uIGNvbnRpbnVlcywgdGhpcyByZXNvdXJjZSB3aWxsIHN1c3Rh aW48YnI+Jm5ic3A7Jm5ic3A7IGFub3RoZXIgODUgeWVhcnMgb2YgYXNzaWdubWVudCAtIHdpdGhv dXQgdGhlIG5lZWQgdG8gcmVzb3J0IHRvPGJyPiZuYnNwOyZuYnNwOyByZWFzc2lnbm1lbnQgb2Yg cmVsZWFzZWQgdmFsdWVzIG9yIHJldm9jYXRpb24uPGJyPjxicj5UaGUgZHJhZnQgcHJlc3VtZXMg dGhhdCBwcmVzZXJ2YXRpb24gb2YgcG9ydCBudW1iZXJzLCBldmVuIHdoZW4gdGhlcmUgaXMgaW4g ZmFjdCBubyBzaWduaWZpY2FudCBzY2FyY2l0eSwgaXMgbW9yZSBpbXBvcnRhbnQgdGhhbiBsZXR0 aW5nIEFwcGxpY2F0aW9uIGFuZCBTZWN1cml0eSBBcmVhIFdHcyBkZXRlcm1pbmUgd2hhdCB0aGVp ciBwb3J0cyBuZWVkcyBhcmUuJm5ic3A7IFRoZSBpbmZvcm1hdGlvbiBhYm91dCBhcHBsaWNhdGlv bnMgdGhhdCB1c2Ugb25lIGZpeGVkIHBvcnQgYW5kIHRoZW4gZHluYW1pYyBwb3J0cyBpZ25vcmVz IGV4cGVyaWVuY2UgdGhhdCBoYXMgcmV2ZWFsZWQgc2lnbmlmaWNhbnQgcHJvYmxlbXMuIEV2ZW4g aWYgdGhlcmUgd2VyZSByZWFsIHNjYXJjaXR5ICh3aGljaCB0aGUgQkNQIHNob3dzIHRoYXQgdGhl cmUgaXNuJ3QpLCBpdCBpcyBpbXBvc3NpYmxlIHRvIHdlaWdoIHRoZSBuZWVkcyBvZiBwb3J0IHNj YXJjaXR5IGFnYWluc3QgdGhlIG5lZWQgdG8gY3JlYXRlIGxlc3MgZnJhZ2lsZSBwcm90b2NvbHMu PGJyPjxicj5UZW4geWVhcnMgZnJvbSBub3csIGlmIG1vcmUgdGhhbiAyNSUgb2YgdGhlIHBvcnQg c3BhY2UgaXMgYXNzaWduZWQsIHRoZSBUcmFuc3BvcnQsIEFwcGxpY2F0aW9ucywgYW5kIFNlY3Vy aXR5IEFyZWFzIGNhbiByZWNvbnNpZGVyIHNvbWV0aGluZyBsaWtlIHRoaXMgZG9jdW1lbnQuIFVu dGlsIHRoZXJlIGlzIGFueSBldmlkZW5jZSB0aGF0IHRoZXJlIGlzIHNjYXJjaXR5IHRoYXQgd291 bGQgY2F1c2UgQXBwbGljYXRpb24gYW5kIFNlY3VyaXR5IEFyZWEgY2hhbmdlcywgdGhlIGlkZWEg c2hvdWxkIGJlIHNoZWx2ZWQgYW5kIG5vdCBldmVuIGRpc2N1c3NlZC48bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_8D3D17ACE214DC429325B2B98F3AE712076C66303CMX15Acorpemcc_-- From nobody Tue May 27 09:17:50 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68AA1A0197 for ; Tue, 27 May 2014 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YWGE3eCms6W for ; Tue, 27 May 2014 09:17:43 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393C41A0186 for ; Tue, 27 May 2014 09:17:43 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id hy4so10930289vcb.11 for ; Tue, 27 May 2014 09:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nh1fAEJZ798L0Flwaz8qRuvisrslTPNCsaPsk97QWKU=; b=s14gJsrMUCd9u5YTxMGv12uskh6bYupsfA0lG2xcz0ZDLCw3jfvoK+7Xt3Ndiqwvc4 VYdcVQc0dfpNSBC+2gmn7yBdSaD8Oa+jEGqZTvsVaumSQ5rWiDMD7EFUc0+qhsY1rlrq MdTPwmrw5FmEWMfZZMtoEW2VIJoKJpE2P3gacDdEszXHvkOiS1VCBNQwFwVrgdSFlqMO CoOf+mRRB8NbNWZ1L94pTzD9mBJn//BAH6G5wBvah+fcUTQOkmgaaa6xzX2QWxrlI4wZ F/VKOPsCl4SJ8VwR7z7X5Pm+669/ZBuvzHGp6EN4CsfB6zRSzqXt3uYrc42sJRzxIjx8 4uzA== MIME-Version: 1.0 X-Received: by 10.220.250.203 with SMTP id mp11mr28350869vcb.2.1401207459543; Tue, 27 May 2014 09:17:39 -0700 (PDT) Received: by 10.220.104.8 with HTTP; Tue, 27 May 2014 09:17:39 -0700 (PDT) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C66303C@MX15A.corp.emc.com> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C66303C@MX15A.corp.emc.com> Date: Tue, 27 May 2014 09:17:39 -0700 Message-ID: From: Paul Hoffman To: "Black, David" Content-Type: multipart/alternative; boundary=089e013d0502e1ff9304fa640880 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/mwyzdwaxwdSYuctXKVetMGe7FcI Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 16:17:46 -0000 --089e013d0502e1ff9304fa640880 Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 6:05 AM, Black, David wrote: > - How/where does this draft appear to modify RFC 6335 and/or otherwise diverge > from the approach set out in that RFC? > The draft modifies/diverges from RFC 6335 (a BCP) in at least two significant ways. - The draft says that port numbers are scarce, while the RFC says precisely the opposite. This would be a modification of the existing RFC, albeit without any numeric support for the change. - The approach in the RFC is to tell IANA how to register ports. The approach in this update to the RFC is to restrict protocol developers through the use of SHOULD and SHOULD NOT statements. > - What sort of guidance beyond RFC 6335 would be useful to application > > and service designers? > None, really. Most new protocols that need one or more ports are pretty different than what has come before them. It is the responsibility of the WGs to know the history of protocol design in their field. Any guidance will inherently be opinionated. For example, many people in the Apps area think FTP is a great example of the right way to do ports, and many people in the Apps area think that it is a great example of how to do it wrong. It might be useful for someone to try to collect a large body of examples of port multiplexing and multiple port use, but only as long as it stays unopinionated. Neither Joe nor I would be good candidate editors for that. :-) --Paul Hoffman --089e013d0502e1ff9304fa640880 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 27, 2014 at 6:05 AM, Black, David <david.bl= ack@emc.com> wrote:
=C2=A0

= - How/where does this draft appear to modify RFC 6335 and/or otherwise <= /u>diverge from the approach set out in that RFC?<= /p>


The draft modifies/diverges fr= om RFC 6335 (a BCP) in at least two significant ways.

- T= he draft says that port numbers are scarce, while the RFC says precisely th= e opposite. This would be a modification of the existing RFC, albeit withou= t any numeric support for the change.

- The approach in the RFC is to tell IANA how to register po= rts. The approach in this update to the RFC is to restrict protocol develop= ers through the use of SHOULD and SHOULD NOT statements.
=C2=A0

<= u>

- What sort of guidance beyond RFC 6335 would be= useful to application

and service designers?


None, really. Most new protocols that need one or more ports are pre= tty different than what has come before them. It is the responsibility of t= he WGs to know the history of protocol design in their field. Any guidance = will inherently be opinionated. For example, many people in the Apps area t= hink FTP is a great example of the right way to do ports, and many people i= n the Apps area think that it is a great example of how to do it wrong.

It might be useful for someone to try to collect a large bod= y of examples of port multiplexing and multiple port use, but only as long = as it stays unopinionated. Neither Joe nor I would be good candidate editor= s for that. :-)

--Paul Hoffman
--089e013d0502e1ff9304fa640880-- From nobody Tue May 27 09:20:24 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1741A046B for ; Tue, 27 May 2014 09:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXjYTQuad3ah for ; Tue, 27 May 2014 09:20:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE2B1A045D for ; Tue, 27 May 2014 09:20:18 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s4RGJ38c007458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 09:19:13 -0700 (PDT) Message-ID: <5384BAFA.106@isi.edu> Date: Tue, 27 May 2014 09:19:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Eggert, Lars" , Pearl Liang References: <8EA0C0EA-7C81-41ED-85BA-4E9B8F690B77@netapp.com> <0EEE0BBC-C9D0-43F8-A162-0278F6B8173D@netapp.com> In-Reply-To: <0EEE0BBC-C9D0-43F8-A162-0278F6B8173D@netapp.com> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/u1nw6_g4FTpUeS1zNygQOd87R-k Cc: tsvwg Subject: Re: [tsvwg] New Version Notification for draft-ietf-tsvwg-port-use-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 16:20:21 -0000 HI, all, First, I do need to do a scrub to make sure that this doc's core (not the history part) ends up referring to "service names" and "service numbers" as per RFC 6335. That said... On 5/26/2014 11:30 PM, Eggert, Lars wrote: > Hi, > > On 2014-5-27, at 0:48, Pearl Liang wrote: >> >> - does the word 'SRV' apply to all service names regardless one with a >> port number or without it? As Lars noted, all service names can be used in the DNS SRV mechanism, however this doc ought to discuss the relationship in more detail... >> - When and how a user decide to add a port number with the DNS SRV service >> name? In another word, why can a user simply register an DNS SRV service >> name without a port number? Service names assigned without a service number are useful only for indices such as DNS SRV or mechanisms like TCP port names. The service is assigned a dynamic port number and that number is advertised to others via such methods. Service names intended for DNS SRV may also include registration of other SRV parameters (indicated as {key, value} pairs in associated TXT records) - that's why IANA asks specifically about SRV use. Use in SRV records isn't strictly related to whether a service name has an associated assigned port number; even though typical use would be without an assigned number, it still might be useful to indicate SRV use in the application for service names primarily used as SRVs because such assigned numbers help with firewall traversal *and* SRV use could indicate additional service parameter in TXT records. Joe From nobody Tue May 27 11:33:50 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60BE1A0664 for ; Tue, 27 May 2014 11:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FliNmLde3ZRB for ; Tue, 27 May 2014 11:33:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C091A065C for ; Tue, 27 May 2014 11:33:39 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s4RIWjj1002675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 11:32:45 -0700 (PDT) Message-ID: <5384DA4F.7000509@isi.edu> Date: Tue, 27 May 2014 11:32:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" , "tsvwg@ietf.org" References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/2q6MQGLy9YB4ZWKNhahm0w_c9ew Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:33:46 -0000 Hi, David, Thanks for the detailed feedback. Some questions and alternate suggestions below. I'll take the security performance issue to a separate thread later today. Joe On 5/22/2014 4:05 PM, Black, David wrote: > > > Some WGLC comments as an individual ... > > -- Section 4: > > System ports do not always require special (i.e., 'root') privilege. > > Nit "(i.e., 'root')" -> "(e.g., operating system superuser)" How is this: (i.e., privileged user, typically known as 'root') ("Superuser" is somewhat antiquated, but the notion of privileged users is still current AFAICT). > For clarity, the remainder of this document refers to the port ranges as > System, User, and Dynamic. > > Following up on Lars's comment, please add a statement that these are > the terms used in RFC 6335. Will do. > -- Section 5: > > The first purpose requires that each transport connection between a > given pair of IP addresses use a different pair of ports, but does > not require either coordination or registration of port use. > > Almost, but not quite - insert "that uses the same transport protocol" > after "each transport connection". Will do. > Also, I'm not sure that "connection" > is the best word here, e.g., for UDP, but I'm not sure what to do > without making this sentence wordy and unclear. Association? > This is > the primary reason for requesting assigned ports with IANA - to have > a common agreement between all endpoints on the Internet as to the > meaning of a port. > > Insert "default" or "expected" before "meaning", e.g., in light of the > example a couple of paragraphs earlier of running a web server on port > 53 instead of port 80. Will do. > -- Section 6 > > o If more than one port is desired, consider revising the > architecture until only one is needed, or, preferably, none. > > An example of how to get to "none" would be helpful. There are examples > in Section 7.1, so a forward reference may suffice. Will do. > -- Section 7.1 > > o Ports are not for performance. Performance enhancement can > occur within separate connections. > > That's a bit cryptic. The first sentence should be expanded to convey the > misuse (e.g., ports for ordinary- and higher-performance variants of the > same service?). Will do. > o Additional ports are not to replicate an existing service. For > example, a device is configured using a typical web browser > then it is a copy of HTTP port 80 and does not warrant a new > assignment. > > Nit: Insert "if" before "a device" Will do. > Nit: "it is a copy of" -> "then the port used for configuration is a copy of" > or -> "then that device configuration service is a copy of the www > service that is associated with" "then that port"? > such as the use of TLS or SSL [Hi95] [RFC5246]. > > Please send the SSL mention and reference to /dev/null before anyone in > the Security Area notices ;-). The TLS reference will suffice. The term SSL is still in widespread use - even the recent discussions of heartbleed refer to both. Is there a good reason to not refer to SSL at all? or should we say: TLS (or its deprecated predcessor, SSL) ? > NB: [RFC6101] is better reference for SSL 3 than [Hi95]. Will do. > -- Section 7.2 > > Although > automatic configuration protocols have been proposed and developed, > system designers cannot yet rely on their presence. > > Should reference those protocols, e.g., STUN and TURN. Will do. > The current > RTCWEB work looks like a counterexample to the "cannot yet rely" > statement, e.g., see the TRAM WG charter: > > http://datatracker.ietf.org/wg/tram/charter/ Any given system can declare reliance on other features -- that alone doesn't mean they're in widespread use and generic designers should do the same. I can clarify this to say: Although automatic configuration protocols have been proposed and developed, system designers cannot yet rely on their widespread presence. > -- Section 7.3 > > Would a TCP port number assignment be > needed useful if the corresponding UDP one were unavailable > (assuming the proposed service needed only a TCP port)? > > This question seems backwards. If the proposed service only needs > a TCP port, why reserve the UDP one? TCP is indeed more typical. The question happens in the following case: TCP yyyy - unassigned UDP yyyy - assigned If someone asks for a new assignment, IANA needs to understand whether they could assign yyyy for TCP. > Nit: "needed useful" -> "useful" It should have said "needed and useful". > Nit: "needed only" -> "only requires" Will do. > Even so, > System port assignments have continued at an average rate of 3-4 per > year over the past 7 years (2007-2013), indicating that the desire > to keep this distinction continues. > > Or that old habits die hard. I might actually add those words ;-). If it were merely a habit, it wouldn't stand up to IESG review. > Further, if > System ports were no longer assigned, it would cost only 180 of the > 1024 system values (17%), or 180 of the overall 49152 assigned > values (<0.04%). > > Attach a date to the number 180, as it will almost certainly change > before this draft is published as an RFC and change "assigned" to > "System plus User". I can, but at the rate it's been going it won't change much (I'm hoping we'll be done in less than one year). > -- Section 7.4 > > Given the current state of cybersecurity in the Internet, > > Please cite a reference for that. I had stated it as common knowledge; if it needs a citation, it's better to remove the statement IMO. > Optional security can penalize performance, requiring additional > round-trip exchanges before a connection can be established. As > discussed earlier, ports are a critical resource and it is > inappropriate to consume assignments to increase performance. > > I don't understand the point that this paragraph is trying to make. I'll raise that as a separate thread, as it relates to some feedback Pearl provided off-list. > -- Section 7.6 > > I generally agree with Lars's concerns about the relationship of the > material at the end of this section to RFC 5405; I'll leave it to him > to work those out w/Joe. > > -- Section 8 Security Considerations > > There are additional security considerations in Sections 7.1, 7.3 > and 7.4 that should be noted here. Will do. > This document reminds protocol designers that port numbers are not a > substitute for security, > > The single word "security" is a bit vague - what sort of security? Using assigned numbers for port filtering isn't a substitute for authentication, encryption, and integrity protection. I'll clarify in the revision with more descriptive text, if that works... > > > > Thanks, > --David > > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurst >> Sent: Thursday, May 22, 2014 2:36 AM >> To: tsvwg@ietf.org >> Subject: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) >> >> This email announces the start of a working group last call to >> confirm publication of "Recommendations for Transport Port Uses". >> >> The TSV WG is requesting feedback on this document with the intention to >> proceed to publish this as a BCP. >> >> Please send any comments to the TSVWG list (tsvwg@ietf.org). >> >> The draft is available at: >> http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04 >> >> The last call will run for TWO weeks, ending midnight 5th June. >> >> James, David, and Gorry >> (TSVWG Chairs) >> tsvwg-chairs@ietf.org >> >> >> > From nobody Tue May 27 11:42:07 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFFE1A0669 for ; Tue, 27 May 2014 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CUJIB0bE6AH for ; Tue, 27 May 2014 11:42:04 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A26D1A05E5 for ; Tue, 27 May 2014 11:42:04 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s4RIfK2t004269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 11:41:20 -0700 (PDT) Message-ID: <5384DC52.60802@isi.edu> Date: Tue, 27 May 2014 11:41:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Hoffman , "tsvwg@ietf.org" References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/rhWVR6uSgTH4DA62oB6xqPopY4g Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:42:05 -0000 On 5/26/2014 1:50 PM, Paul Hoffman wrote: > This draft, when taken in light of RFC 6335, is completely unnecessary. > If it is moved forward at this time, it will cause harm to the Internet > for absolutely no purpose. > > There is no evidence that that port numbers are actually scarce. Although that's true (as already noted in RFC6335, and should be cited in this doc too) it's only because of the 1:1 feedback that the review process has been providing. The intent of this doc is to provide broader advice, in a single place, that's been vetted by the entire transport community. ... > The draft presumes that preservation of port numbers, even when there is > in fact no significant scarcity, is more important than letting > Application and Security Area WGs determine what their ports needs are. There is no aspect of this doc that overrides the current assignment process, which includes expert review for requests outside the IETF (the bulk of the requests, FWIW) and RFC process for those inside WGs. ... > The information about applications that use one fixed port and then > dynamic ports ignores experience that has revealed significant problems. It's still in widespread use in FTP, SIP, etc. The challenges of doing so are already noted. > Even if there were real scarcity (which the BCP shows that there isn't), FWIW, because these rules have been informally encouraged for decades... > it is impossible to weigh the needs of port scarcity against the need to > create less fragile protocols. I'll certainly highlight better the issue of in-band identifiers and protocol fragility. Joe From nobody Tue May 27 11:45:15 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A591A06D1 for ; Tue, 27 May 2014 11:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PB0Td5c50WZ for ; Tue, 27 May 2014 11:45:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E611A06D0 for ; Tue, 27 May 2014 11:45:11 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s4RIhPwv004890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 11:43:26 -0700 (PDT) Message-ID: <5384DCCF.4060706@isi.edu> Date: Tue, 27 May 2014 11:43:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" , Paul Hoffman , "tsvwg@ietf.org" References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C66303C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C66303C@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/vODfW_A5HRoTzCICOoIlXEblRLM Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:45:12 -0000 Some observations... On 5/27/2014 6:05 AM, Black, David wrote: > Paul, > > > > Thank you for commenting. In the hope of framing further discussion, > > I have a few process-oriented comments. > > The starting point for this discussion should be RFC 6335, especially > Sections 7 and 8 on principles and procedures. 6335 describes IANA process. This doc is intended to provide users with advice that was deemed beyond the scope of 6335. Joe From nobody Tue May 27 13:33:21 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BC41A06B4 for ; Tue, 27 May 2014 13:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fsRGEwlMu8u for ; Tue, 27 May 2014 13:33:15 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FB31A028F for ; Tue, 27 May 2014 13:33:15 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4RKWue3023033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 13:32:56 -0700 (PDT) Message-ID: <5384F678.9060303@isi.edu> Date: Tue, 27 May 2014 13:32:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Hoffman , "Black, David" References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C66303C@MX15A.corp.emc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/9J-un2IHn3E2xe5jRI_REaig6Xo Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 20:33:17 -0000 On 5/27/2014 9:17 AM, Paul Hoffman wrote: > On Tue, May 27, 2014 at 6:05 AM, Black, David > wrote: > > - How/where does this draft appear to modify RFC 6335 and/or > otherwise ____diverge from the approach set out in that RFC? > > > The draft modifies/diverges from RFC 6335 (a BCP) in at least two > significant ways. Again, RFC 6335 is intended as updating IANA procedures; this doc is intended as advice to users. > - The draft says that port numbers are scarce, while the RFC says > precisely the opposite. This would be a modification of the existing > RFC, albeit without any numeric support for the change. Scarce is relative, of course. Right now I count 5847 TCP and 5570 UDP numbers, but the total range is 16 bits, and that's not considered a large range overall. > - The approach in the RFC is to tell IANA how to register ports. The > approach in this update to the RFC is to restrict protocol developers > through the use of SHOULD and SHOULD NOT statements. Both the IETF process and expert review already do this, which is part of the only reason we continue to have a large amount of remaining space. It's still somewhat common to get requests for 10's-100's of port numbers. > ____ > > - What sort of guidance beyond RFC 6335 would be useful to application > > and service designers? > > > None, really. Most new protocols that need one or more ports are pretty > different than what has come before them. That's false based on the application's I've been reviewing for years. Again, remember that IETF WG assignments are a very small portion of those assigned overall. > It is the responsibility of > the WGs to know the history of protocol design in their field. Any > guidance will inherently be opinionated. For example, many people in the > Apps area think FTP is a great example of the right way to do ports, and > many people in the Apps area think that it is a great example of how to > do it wrong. And the WG can override a BCP with cause and argument - just as for any BCP. The bigger problem is that it's not feasible for every WG to have that working knowlege - and the overwhelming number of non-WG requests don't benefit from WG guidance anyway. That's why we have BCPs; by your argument, we would never have any. Joe From nobody Tue May 27 14:13:10 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC2F1A0698 for ; Tue, 27 May 2014 14:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0DvqxiJEq98 for ; Tue, 27 May 2014 14:13:03 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389051A04B6 for ; Tue, 27 May 2014 14:13:03 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4RLC8vJ005747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 14:12:09 -0700 (PDT) Message-ID: <5384FFA8.9030306@isi.edu> Date: Tue, 27 May 2014 14:12:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tsvwg References: <537E7815.8090702@isi.edu> In-Reply-To: <537E7815.8090702@isi.edu> X-Forwarded-Message-Id: <537E7815.8090702@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/PGmpHcmpVnTDWqEp6IeOfMZVZ80 Cc: Pearl Liang via RT Subject: [tsvwg] Fwd: Re: [IANA #759106] Re: IANA early review for: draft-ietf-tsvwg-port-use X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 21:13:04 -0000 The following is part of an off-list thread that we'd like to share to the list. Joe -------- Original Message -------- Subject: Re: [IANA #759106] Re: IANA early review for: draft-ietf-tsvwg-port-use Date: Thu, 22 May 2014 15:20:05 -0700 From: Joe Touch To: iana-issues@iana.org CC: gorry@erg.abdn.ac.uk, liang@icann.org Hi, Pearl, On 5/22/2014 3:09 PM, Pearl Liang via RT wrote: > Hi Gorry and Joe, > > I've reviewed this version and have some questions for clarifications: > > Section 7.1. Is a port assignment necessary? > > Question: Often time, users argued that they need a dedicated port > because they wanted to make sure no collision. Should we add > that to this draft and telling users that a port assignment does > not guarantee they are going to get a clean/good traffic? Good point; that's worth addressing. > Section 7.6. Transport Protocols > > Question: Should this document also address the needed of SCTP or DCCP > in addition to TCP and UDP? Yes, will do. > Section 7.9 > > "Port names and numbers are not intended to be changed. " > > Question: we received some service names that included company name > or the abbreviation of the company name. Should this be discouraged > when IANA reviews the applications? We can talk about this; I don't think it matters, so long as the understanding is that the name won't change just because the company does. ------ From nobody Tue May 27 14:24:26 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9551F1A026B for ; Tue, 27 May 2014 14:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf2xCMSBlEg8 for ; Tue, 27 May 2014 14:24:18 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049C21A077F for ; Tue, 27 May 2014 14:24:17 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4RLNxNg009312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 14:23:59 -0700 (PDT) Message-ID: <5385026F.5000908@isi.edu> Date: Tue, 27 May 2014 14:23:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" , "tsvwg@ietf.org" References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/jxwY_J6Y-fNd-dvpWrnjO8UiWec Subject: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 21:24:24 -0000 Hi, all, I'd like to raise this as a distinct thread for discussion. The question is what advice to give regarding secure vs. insecure ports. The current document text is: > Optional security can penalize performance, requiring additional > round-trip exchanges before a connection can be established. As > discussed earlier, ports are a critical resource and it is > inappropriate to consume assignments to increase performance. Here are the issues, which should be presented in more detail in the doc. Comments welcome, of course. Joe ---- - given a current non-secure assignment, what if a user requests a (new) second port for secure access? this is fine, if not a good idea; the current (insecure) port is likely blocked at many firewalls, and assigning a new port that requires security provides an opportunity to safely open access to that service - given a current secure assignment, what if a user requests a (new) second port for insecure access? it seems like a SHOULD NOT recommendation is appropriate; this creates new vulnerability; the primary reason would be performance, and assigning additional ports primarily for performance should be discouraged in this doc, as it has historically been for a very long time. - should a user request two ports for a new service, one secure and one insecure? IMO, the secure port is easy, if otherwise warranted (not a duplicate of existing service, e.g.), but the insecure one similarly creates a new vulnerability, and again I would say SHOULD NOT request a new insecure port - GIVEN a request for an insecure and secure port, what are appropriate justifications? IMO, separate firewall control is a sufficient reason. however, performance should not be - i.e., if both ports will typically have the same firewall configuration, then only one port is needed and security should be negotiated as present/absent in-band. The performance impact of that negotation (IMO) should not factor into whether an additional port should be assigned. ---- From nobody Tue May 27 14:42:26 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493CB1A027D for ; Tue, 27 May 2014 14:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.9 X-Spam-Level: * X-Spam-Status: No, score=1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_CIALIS_LEO3=3.899, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwonc0PF8M2H for ; Tue, 27 May 2014 14:42:21 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CEC71A027A for ; Tue, 27 May 2014 14:42:21 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id oy12so11562315veb.10 for ; Tue, 27 May 2014 14:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ybvcj+ATCtSyZpc1CKlG8VG6063mR18GRxORob77oiQ=; b=ctAfK9WNXIDm9r3LjuVfguIol29wainoy/8HCf2DmKFQ3BNz+tzPBq2W198hYEnUY2 fHTRT8IoIW0/vZ01390b58ws5v6RmDlV5rHkhykTgcVQV29E6KrwPrXnNW2ApSqKapmn VtaE8ShFirrksAif2Cmg+VeDgqCob25l+R8nhNt2H2rzN9UhxPk3buUA3F+8Lg/Pj/Q6 1qrrlbnGWWvkXbelayKpMqw9hx6aETPhP9Jk7RxxMNNIa4ggBEUHNS9bBZ7AEn2h9Aaw a8dya3+yTeFSWueIDGPWI/f/nxrBWpx+2DcVfkrgL3nTSnR133X9OS3PmZhNHUF0Jb5l uZ1g== MIME-Version: 1.0 X-Received: by 10.58.161.101 with SMTP id xr5mr4997273veb.36.1401226937895; Tue, 27 May 2014 14:42:17 -0700 (PDT) Received: by 10.220.104.8 with HTTP; Tue, 27 May 2014 14:42:17 -0700 (PDT) In-Reply-To: <5384DC52.60802@isi.edu> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5384DC52.60802@isi.edu> Date: Tue, 27 May 2014 14:42:17 -0700 Message-ID: From: Paul Hoffman To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b5d5b0ae213d504fa68911e Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/9o07ojVDb-pc-T_qdPyGBUByuqc Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 21:42:23 -0000 --047d7b5d5b0ae213d504fa68911e Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 11:41 AM, Joe Touch wrote: > > > On 5/26/2014 1:50 PM, Paul Hoffman wrote: > >> This draft, when taken in light of RFC 6335, is completely unnecessary. >> If it is moved forward at this time, it will cause harm to the Internet >> for absolutely no purpose. >> >> There is no evidence that that port numbers are actually scarce. >> > > Although that's true (as already noted in RFC6335, and should be cited in > this doc too) it's only because of the 1:1 feedback that the review process > has been providing. Is there any evidence to support the statement that feedback has changed this for new IETF protocols? If so, it should certainly be cited. But, regardless, given that you agree that there is no evidence for the scarcity, the whole reason for this document seems to fall apart. The advice of "you should consider multiplexing one one port" is fine, of course; the theme of the first half of the document that the advice comes from scarcity is not if there is no scarcity. > The intent of this doc is to provide broader advice, in a single place, > that's been vetted by the entire transport community. > A BCP is not "broader advice": it is a statement of what the IETF believes to have been proven as best practice. Much of the advice in the document ("systems might require a single port assignment, but rarely require multiple ports") cannot be proven as a best practice. It is a practice to consider, but it is not "best". > ... > > The draft presumes that preservation of port numbers, even when there is >> in fact no significant scarcity, is more important than letting >> Application and Security Area WGs determine what their ports needs are. >> > > There is no aspect of this doc that overrides the current assignment > process, which includes expert review for requests outside the IETF (the > bulk of the requests, FWIW) and RFC process for those inside WGs. > That statement is orthogonal with the statement I made. This draft keeps hammering at the scarcity as a justification for giving advice; the RFC says there is no scarcity; thus, this document updates the RFC. Removing all discussion of scarcity and dropping the intended level of this document to Informational would go a long way to fixing that problem. > > ... > > The information about applications that use one fixed port and then >> dynamic ports ignores experience that has revealed significant problems. >> > > It's still in widespread use in FTP, SIP, etc. The challenges of doing so > are already noted. "Noted" but still pushed in the name of scarcity. A less opinionated discussion of the problems that FTP and SIP have encountered, and a comparison to protocols that don't have those problems because they use fixed ports, would be more informational. > > Even if there were real scarcity (which the BCP shows that there isn't), >> > > FWIW, because these rules have been informally encouraged for decades... > > > it is impossible to weigh the needs of port scarcity against the need to >> create less fragile protocols. >> > > I'll certainly highlight better the issue of in-band identifiers and > protocol fragility. > Then why even do this at all? That is, if there really is no scarcity, what value is this document? I have not heard application or security developers say "we don't know where to find examples of protocols that use ports in interesting ways, let's look for an RFC that lists them". Once the scarcity argument is stripped out, and even if the firewalls discussion is brought up to date (it uses examples that are about a decade out of date), the meat of the document is "you can design your protocol's use of ports however you want". This doesn't seem useful, and still could be harmful if used as a blunt object during IANA review. --Paul Hoffman --047d7b5d5b0ae213d504fa68911e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 27, 2014 at 11:41 AM, Joe Touch <touch@isi.edu> wrote:


On 5/26/2014 1:50 PM, Paul Hoffman wrote:
This draft, when taken in light of RFC 6335, is completely unnecessary.
If it is moved forward at this time, it will cause harm to the Internet
for absolutely no purpose.

There is no evidence that that port numbers are actually scarce.

Although that's true (as already noted in RFC6335, and should be cited = in this doc too) it's only because of the 1:1 feedback that the review = process has been providing.

Is there any e= vidence to support the statement that feedback has changed this for new IET= F protocols? If so, it should certainly be cited.

But, regardless, given that you agree that there is no evidence for the= scarcity, the whole reason for this document seems to fall apart. The advi= ce of "you should consider multiplexing one one port" is fine, of= course; the theme of the first half of the document that the advice comes = from scarcity is not if there is no scarcity.
=C2=A0
Th= e intent of this doc is to provide broader advice, in a single place, that&= #39;s been vetted by the entire transport community.

A BCP is not "broader advice": i= t is a statement of what the IETF believes to have been proven as best prac= tice. Much of the advice in the document ("systems might require a sin= gle port assignment, but rarely require multiple ports") cannot be pro= ven as a best practice. It is a practice to consider, but it is not "b= est".
=C2=A0
...

The draft presumes that preservation of port numbers, even when there is in fact no significant scarcity, is more important than letting
Application and Security Area WGs determine what their ports needs are.

There is no aspect of this doc that overrides the current assignment proces= s, which includes expert review for requests outside the IETF (the bulk of = the requests, FWIW) and RFC process for those inside WGs.

That statement is orthogonal with the statement I made.= This draft keeps hammering at the scarcity as a justification for giving a= dvice; the RFC says there is no scarcity; thus, this document updates the R= FC. Removing all discussion of scarcity and dropping the intended level of = this document to Informational would go a long way to fixing that problem.<= br>
=C2=A0

...

The information about applications that use one fixed port and then
dynamic ports ignores experience that has revealed significant problems.

It's still in widespread use in FTP, SIP, etc. The challenges of doing = so are already noted.

"Noted" but= still pushed in the name of scarcity. A less opinionated discussion of the= problems that FTP and SIP have encountered, and a comparison to protocols = that don't have those problems because they use fixed ports, would be m= ore informational.
=C2=A0

Even if there were real scarcity (which the BCP shows that there isn't)= ,

FWIW, because these rules have been informally encouraged for decades...

it is impossible to weigh the needs of port scarcity against the need to create less fragile protocols.

I'll certainly highlight better the issue of in-band identifiers and pr= otocol fragility.

Then why even do this at all? That is, if= there really is no scarcity, what value is this document? I have not heard= application or security developers say "we don't know where to fi= nd examples of protocols that use ports in interesting ways, let's look= for an RFC that lists them". Once the scarcity argument is stripped o= ut, and even if the firewalls discussion is brought up to date (it uses exa= mples that are about a decade out of date), the meat of the document is &qu= ot;you can design your protocol's use of ports however you want". = This doesn't seem useful, and still could be harmful if used as a blunt= object during IANA review.

--Paul Hoffman
--047d7b5d5b0ae213d504fa68911e-- From nobody Tue May 27 14:50:02 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FFA1A029A for ; Tue, 27 May 2014 14:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjUrqlJCMUbg for ; Tue, 27 May 2014 14:49:59 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A2F1A0292 for ; Tue, 27 May 2014 14:49:59 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id db11so11489848veb.15 for ; Tue, 27 May 2014 14:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y/R72SCRLf6Iq0Fy4fPvLAvNhqqTuvQaS69FR+wUgHY=; b=ad8ExsXjEIucnk0CbkegbVTJR/2BAIb/7uWNiuOhAE1DaH9oFPfqyvk8dwAdaCLnlC hHd35rk+vaoAFZQiaRdThVNoJQahCk+lRfo59oGypDHXZPGCTpNULh/unbhMilLDEy3C S8JPhygbE59/WtKDew9PtSM0k2TcN2NnuQwSYjLYQWkIYpZvgxlPMTQjY2YYYvfFcVex 19F+X+SoY/c+WopRt8edj0PZjWaavZuqZPThGV+xaB3nEP5R1QntIeA/s1YKKrTUH0G5 e8MBAfxgzj4y7fJiFYknMDjSn++mT64MaUN71a5uFY01qafjkC9WW1gXR66EeyeB1Y27 EzhA== MIME-Version: 1.0 X-Received: by 10.220.98.143 with SMTP id q15mr4653025vcn.38.1401227395568; Tue, 27 May 2014 14:49:55 -0700 (PDT) Received: by 10.220.104.8 with HTTP; Tue, 27 May 2014 14:49:55 -0700 (PDT) In-Reply-To: <5385026F.5000908@isi.edu> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> Date: Tue, 27 May 2014 14:49:55 -0700 Message-ID: From: Paul Hoffman To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c1da06299a6204fa68ad80 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/7NhLnI3BgA7T7h1KBqFIJmlwjhk Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 21:50:00 -0000 --001a11c1da06299a6204fa68ad80 Content-Type: text/plain; charset=UTF-8 Is this new advice based on any actual evidence or even a security analysis? Further, a statement of "SHOULD NOT request" sounds a hell of a lot more like a demand than advice. This gets to the crux of my concern of the document: it feel like the advice is meant to come from on high (namely, someone who can block IANA requests), not friendly advice from one developer to another. We went through this in the discussion a few years ago, and it seemed then that TSVWG didn't agree that such heavy-handed "advice", particularly without specific justification, was the way to go. --001a11c1da06299a6204fa68ad80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is this new advice based on any actual evidence or ev= en a security analysis?

Further, a statement of "SHOULD N= OT request" sounds a hell of a lot more like a demand than advice. Thi= s gets to the crux of my concern of the document: it feel like the advice i= s meant to come from on high (namely, someone who can block IANA requests),= not friendly advice from one developer to another. We went through this in= the discussion a few years ago, and it seemed then that TSVWG didn't a= gree that such heavy-handed "advice", particularly without specif= ic justification, was the way to go.
--001a11c1da06299a6204fa68ad80-- From nobody Tue May 27 15:03:42 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648571A029A for ; Tue, 27 May 2014 15:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82jM0gcxyqMM for ; Tue, 27 May 2014 15:03:35 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDFC1A0292 for ; Tue, 27 May 2014 15:03:35 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4RM2lkt021918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 15:02:48 -0700 (PDT) Message-ID: <53850B87.6010604@isi.edu> Date: Tue, 27 May 2014 15:02:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Hoffman References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/wqGC4kUoWN15feBA9ervCpQ68po Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:03:36 -0000 On 5/27/2014 2:49 PM, Paul Hoffman wrote: > Is this new advice based on any actual evidence or even a security analysis? It's based on 8 years of running the review team and discussions within that team. It's based on the analysis provided. If you disagree with the analysis, you should present a counterargument. > Further, a statement of "SHOULD NOT request" sounds a hell of a lot more > like a demand than advice. What exactly can we *demand* of a user making an application other that to provide advice? It's not advice to IANA or the ports team in how to make a decision. > This gets to the crux of my concern of the > document: it feel like the advice is meant to come from on high (namely, > someone who can block IANA requests), not friendly advice from one > developer to another. Can you provide a rationale for that claim other than "because Joe Touch wrote it"? > We went through this in the discussion a few years > ago, and it seemed then that TSVWG didn't agree that such heavy-handed > "advice", particularly without specific justification, was the way to go. TSVWG agreed that limiting IANA was not appropriate; this document doesn't limit IANA. And specific justification is provided in the discussion I gave. Again, if you disagree with that discussion, please explain. E.g., do you actually think it's good security practice to create new, insecure services? If so, on what basis of good security practice? Joe From nobody Tue May 27 15:19:21 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62181A07AA for ; Tue, 27 May 2014 15:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.348 X-Spam-Level: * X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asuEhWwS6btG for ; Tue, 27 May 2014 15:19:18 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2D51A07AF for ; Tue, 27 May 2014 15:19:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4RMIZwI026533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 15:18:36 -0700 (PDT) Message-ID: <53850F3B.5060401@isi.edu> Date: Tue, 27 May 2014 15:18:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Hoffman References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5384DC52.60802@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/mP-aA9Sab3gH3PEwZSWRkQQiykg Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:19:20 -0000 On 5/27/2014 2:42 PM, Paul Hoffman wrote: > On Tue, May 27, 2014 at 11:41 AM, Joe Touch > wrote: > > > > On 5/26/2014 1:50 PM, Paul Hoffman wrote: > > This draft, when taken in light of RFC 6335, is completely > unnecessary. > If it is moved forward at this time, it will cause harm to the > Internet > for absolutely no purpose. > > There is no evidence that that port numbers are actually scarce. > > > Although that's true (as already noted in RFC6335, and should be > cited in this doc too) it's only because of the 1:1 feedback that > the review process has been providing. > > Is there any evidence to support the statement that feedback has changed > this for new IETF protocols? If so, it should certainly be cited. IANA didn't maintain information on assignments per year; I've gotten them for the time since I've helped manage the assignments. There were a few distinct assignment periods and associated policies: - prior to ICANN, Jon Postel managed them largely as we do now, treating them as something to conserve as much as we knew; some apps were assigned ranges (notably X Windows) because we didn't know better at the time - after ICANN (1998), but before the expert review process was active (2008) - active expert review process (2008-present) Here is the data from the recent years, measured in requests. Not all request are for a single assignment. As you can see, the number dropped roughly in half since 2008. I don't have more recent statistics: Year submitted resolved % 2012 200 80 40.00% 2011 187 88 47.06% 2010 210 118 56.19% 2009 209 149 71.29% 2008 257 166 64.59% I've been trying to get some information about the historical assignment rate, but it's slow-going. The rate of assignment approvals has dropped since we started putting this advice in place. However, again, this is NOT intended to be new advice; this is simply the same style of advice we have been giving on case-by-case basis to applicants. In the vast majority of cases, applicants have appreciated getting the feedback and it has led to better protocol design IMO. There are some corner cases, as there would be with *any* process. > But, regardless, given that you agree that there is no evidence for the > scarcity, the whole reason for this document seems to fall apart. Scarcity is a relative measure. There are only 16 bits of port space, and yes, it's only 11% used. But we've turned away dozens of requests for 10s-100s of ports, and cut a large number of requests for multiple ports down to one or two. > The > advice of "you should consider multiplexing one one port" is fine, of > course; the theme of the first half of the document that the advice > comes from scarcity is not if there is no scarcity. Your argument seems to stem from the impression that this doc is claiming that something changed that necessitates new, urgent conservation. The reality is that the only reason we've been able to keep down to 11% of use is because of ongoing conservation. 16 bits is not a large space. > The intent of this doc is to provide broader advice, in a single > place, that's been vetted by the entire transport community. > > > A BCP is not "broader advice": it is a statement of what the IETF > believes to have been proven as best practice. Much of the advice in the > document ("systems might require a single port assignment, but rarely > require multiple ports") cannot be proven as a best practice. It is a > practice to consider, but it is not "best". > > ... > > The draft presumes that preservation of port numbers, even when > there is > in fact no significant scarcity, is more important than letting > Application and Security Area WGs determine what their ports > needs are. > > > There is no aspect of this doc that overrides the current assignment > process, which includes expert review for requests outside the IETF > (the bulk of the requests, FWIW) and RFC process for those inside WGs. > > > That statement is orthogonal with the statement I made. This draft keeps > hammering at the scarcity as a justification for giving advice; the RFC > says there is no scarcity; thus, this document updates the RFC. Removing > all discussion of scarcity and dropping the intended level of this > document to Informational would go a long way to fixing that problem. > > > ... > > The information about applications that use one fixed port and then > dynamic ports ignores experience that has revealed significant > problems. > > > It's still in widespread use in FTP, SIP, etc. The challenges of > doing so are already noted. > > > "Noted" but still pushed in the name of scarcity. A less opinionated > discussion of the problems that FTP and SIP have encountered, and a > comparison to protocols that don't have those problems because they use > fixed ports, would be more informational. > > > Even if there were real scarcity (which the BCP shows that there > isn't), > > > FWIW, because these rules have been informally encouraged for decades... > > > it is impossible to weigh the needs of port scarcity against the > need to > create less fragile protocols. > > > I'll certainly highlight better the issue of in-band identifiers and > protocol fragility. > > > Then why even do this at all? That is, if there really is no scarcity, > what value is this document? I have not heard application or security > developers say "we don't know where to find examples of protocols that > use ports in interesting ways, let's look for an RFC that lists them". > Once the scarcity argument is stripped out, and even if the firewalls > discussion is brought up to date (it uses examples that are about a > decade out of date), the meat of the document is "you can design your > protocol's use of ports however you want". This doesn't seem useful, and > still could be harmful if used as a blunt object during IANA review. > > --Paul Hoffman From nobody Tue May 27 16:17:20 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3178D1A079C for ; Tue, 27 May 2014 16:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L7dBXmuy64Z for ; Tue, 27 May 2014 16:17:17 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC53C1A02AF for ; Tue, 27 May 2014 16:17:17 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4RNFgQq024339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 16:15:42 -0700 (PDT) Message-ID: <53851C9E.8060002@isi.edu> Date: Tue, 27 May 2014 16:15:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Hoffman References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> In-Reply-To: <53850B87.6010604@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/XZKyzF81fHRgN0MgOh7a8_2Gi-A Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 23:17:19 -0000 Some more recent stats - these count only TCP ports assigned: total new 2000 3081 (na) 2001 3480 400 2002 3925 445 2003 4146 231 2004 4404 258 2005 4652 248 2006 4992 340 2007 5155 163 2008 5317 162 *expert review starts 2009 5456 139 2010 5558 102 2011 5710 152 2012 5764 54 *RFC6335 published 2013 5819 55 2014 5847 28 (to date, roughly on track for ~60) Note that we didn't actively change anything when RFC 6335 was published; it was not used to justify recommending declining requests. The number of RFC-related requests per year is very small - 5-10 at best, AFAIR. AFAICT, a lot of the reduction has helped keep a lot of junk out of the list, e.g., people who - in the absence of advice - ask for 10s-100s of ports at a time, or who don't realize that there may be existing services that would suffice. Joe From nobody Tue May 27 16:25:09 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F961A07AB for ; Tue, 27 May 2014 16:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pFuJYNBU-i2 for ; Tue, 27 May 2014 16:25:03 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C5B1A0671 for ; Tue, 27 May 2014 16:25:03 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4RNOWw5004756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 16:24:32 -0700 (PDT) Message-ID: <53851EB0.3050807@isi.edu> Date: Tue, 27 May 2014 16:24:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Hoffman References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <53851C9E.8060002@isi.edu> In-Reply-To: <53851C9E.8060002@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/9XCl6HlU6pnMJMar0Ds7i_cpP4M Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 23:25:05 -0000 PS - yes, these numbers are good news in terms of management of the space, but they could as easily have driven the other way without active feedback. On 5/27/2014 4:15 PM, Joe Touch wrote: > Some more recent stats - these count only TCP ports assigned: > > total new > 2000 3081 (na) > 2001 3480 400 > 2002 3925 445 > 2003 4146 231 > 2004 4404 258 > 2005 4652 248 > 2006 4992 340 > 2007 5155 163 > 2008 5317 162 *expert review starts > 2009 5456 139 > 2010 5558 102 > 2011 5710 152 > 2012 5764 54 *RFC6335 published > 2013 5819 55 > 2014 5847 28 (to date, roughly on track for ~60) > > Note that we didn't actively change anything when RFC 6335 was > published; it was not used to justify recommending declining requests. > > The number of RFC-related requests per year is very small - 5-10 at > best, AFAIR. > > AFAICT, a lot of the reduction has helped keep a lot of junk out of the > list, e.g., people who - in the absence of advice - ask for 10s-100s of > ports at a time, or who don't realize that there may be existing > services that would suffice. > > Joe > From nobody Tue May 27 16:46:28 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED371A07C7 for ; Tue, 27 May 2014 16:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bhlnyo-EVtK1 for ; Tue, 27 May 2014 16:46:22 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AD01A07BA for ; Tue, 27 May 2014 16:46:21 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4RNkG9c013285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 May 2014 19:46:17 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s4RNkG9c013285 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401234377; bh=KOLyhQxmNkSlPKlyBRlvvu/fOoI=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=S4tXDeHuSo7eI5rd6lxjebFfOQABkcPbVBmNCLjh7Zv3s5BhhmZcHLtoeOS+9nN42 GS7jU6hhugFa+jqeuD9rbszEzqTjnjukOeeCH0YsU+Q4uqkgIgZrTEYTJn7zvc4jor 9rKZV5r/G5xuNluNP84XeSA71PaXOzc+P+kmQcTg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s4RNkG9c013285 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd02.lss.emc.com (RSA Interceptor); Tue, 27 May 2014 19:45:54 -0400 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4RNjrks012940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 19:45:53 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Tue, 27 May 2014 19:45:52 -0400 From: "Black, David" To: Joe Touch , "tsvwg@ietf.org" Date: Tue, 27 May 2014 19:45:52 -0400 Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) Thread-Index: Ac952i7dBO9jlr3wS2yg36cfvCOfuQAIi4hQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C6631F3@MX15A.corp.emc.com> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5384DA4F.7000509@isi.edu> In-Reply-To: <5384DA4F.7000509@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/a8JZR4LrBVANj457nZtaInD33QA Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 23:46:25 -0000 Joe, I'm quoting only those items that I have comments on - everything else=20 is fine, including any text suggestions that I don't comment on. > > Also, I'm not sure that "connection" > > is the best word here, e.g., for UDP, but I'm not sure what to do > > without making this sentence wordy and unclear. >=20 > Association? Ok, it's better than "connection". > > such as the use of TLS or SSL [Hi95] [RFC5246]. > > > > Please send the SSL mention and reference to /dev/null before anyone in > > the Security Area notices ;-). The TLS reference will suffice. >=20 > The term SSL is still in widespread use - even the recent discussions of > heartbleed refer to both. Is there a good reason to not refer to SSL at > all? or should we say: >=20 > TLS (or its deprecated predcessor, SSL) >=20 > ? >=20 > > NB: [RFC6101] is better reference for SSL 3 than [Hi95]. >=20 > Will do. In that case, let's call SSL "historic" rather than "deprecated" and reference RFC 6101 ... which just happens to be an Historic RFC ;-). > > -- Section 7.3 > > > > Would a TCP port number assignment be > > needed useful if the corresponding UDP one were unavailable > > (assuming the proposed service needed only a TCP port)? > > > > This question seems backwards. If the proposed service only needs > > a TCP port, why reserve the UDP one? >=20 > TCP is indeed more typical. The question happens in the following case: >=20 > TCP yyyy - unassigned > UDP yyyy - assigned >=20 > If someone asks for a new assignment, IANA needs to understand whether > they could assign yyyy for TCP. Rephrasing suggestion: Would a TCP port number assignment be useful by itself? If so, a TCP port number can be assigned whose corresponding UDP port number is already (or can be subsequently) assigned to a different protocol. This is mostly editorial. > > -- Section 7.4 > > > > Given the current state of cybersecurity in the Internet, > > > > Please cite a reference for that. >=20 > I had stated it as common knowledge; if it needs a citation, it's better > to remove the statement IMO. RFCs are archive documents - the "current state" won't be "common knowledge= " 10-15 years from now. I guess you should remove it. > > This document reminds protocol designers that port numbers are not = a > > substitute for security, > > > > The single word "security" is a bit vague - what sort of security? >=20 > Using assigned numbers for port filtering isn't a substitute for > authentication, encryption, and integrity protection. I'll clarify in > the revision with more descriptive text, if that works... That'll work - I think you've written much of what's required in that response to me. Thanks, --David > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, May 27, 2014 2:33 PM > To: Black, David; tsvwg@ietf.org > Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th Ju= ne) >=20 > Hi, David, >=20 > Thanks for the detailed feedback. Some questions and alternate > suggestions below. I'll take the security performance issue to a > separate thread later today. >=20 > Joe >=20 > On 5/22/2014 4:05 PM, Black, David wrote: > > > > > > Some WGLC comments as an individual ... > > > > -- Section 4: > > > > System ports do not always require special (i.e., 'root') privilege. > > > > Nit "(i.e., 'root')" -> "(e.g., operating system superuser)" >=20 > How is this: >=20 > (i.e., privileged user, typically known as 'root') >=20 > ("Superuser" is somewhat antiquated, but the notion of privileged users > is still current AFAICT). >=20 > > For clarity, the remainder of this document refers to the port rang= es as > > System, User, and Dynamic. > > > > Following up on Lars's comment, please add a statement that these are > > the terms used in RFC 6335. >=20 > Will do. >=20 > > -- Section 5: > > > > The first purpose requires that each transport connection between a > > given pair of IP addresses use a different pair of ports, but does > > not require either coordination or registration of port use. > > > > Almost, but not quite - insert "that uses the same transport protocol" > > after "each transport connection". >=20 > Will do. >=20 > > Also, I'm not sure that "connection" > > is the best word here, e.g., for UDP, but I'm not sure what to do > > without making this sentence wordy and unclear. >=20 > Association? >=20 > > This is > > the primary reason for requesting assigned ports with IANA - to hav= e > > a common agreement between all endpoints on the Internet as to the > > meaning of a port. > > > > Insert "default" or "expected" before "meaning", e.g., in light of the > > example a couple of paragraphs earlier of running a web server on port > > 53 instead of port 80. >=20 > Will do. >=20 > > -- Section 6 > > > > o If more than one port is desired, consider revising the > > architecture until only one is needed, or, preferably, none. > > > > An example of how to get to "none" would be helpful. There are example= s > > in Section 7.1, so a forward reference may suffice. >=20 > Will do. >=20 > > -- Section 7.1 > > > > o Ports are not for performance. Performance enhancement can > > occur within separate connections. > > > > That's a bit cryptic. The first sentence should be expanded to convey = the > > misuse (e.g., ports for ordinary- and higher-performance variants of th= e > > same service?). >=20 > Will do. >=20 > > o Additional ports are not to replicate an existing service. Fo= r > > example, a device is configured using a typical web browser > > then it is a copy of HTTP port 80 and does not warrant a new > > assignment. > > > > Nit: Insert "if" before "a device" >=20 > Will do. >=20 > > Nit: "it is a copy of" -> "then the port used for configuration is a co= py of" > > or -> "then that device configuration service is a copy of the www > > service that is associated with" >=20 > "then that port"? >=20 > > such as the use of TLS or SSL [Hi95] [RFC5246]. > > > > Please send the SSL mention and reference to /dev/null before anyone in > > the Security Area notices ;-). The TLS reference will suffice. >=20 > The term SSL is still in widespread use - even the recent discussions of > heartbleed refer to both. Is there a good reason to not refer to SSL at > all? or should we say: >=20 > TLS (or its deprecated predcessor, SSL) >=20 > ? >=20 > > NB: [RFC6101] is better reference for SSL 3 than [Hi95]. >=20 > Will do. >=20 > > -- Section 7.2 > > > > Although > > automatic configuration protocols have been proposed and developed, > > system designers cannot yet rely on their presence. > > > > Should reference those protocols, e.g., STUN and TURN. >=20 > Will do. >=20 > > The current > > RTCWEB work looks like a counterexample to the "cannot yet rely" > > statement, e.g., see the TRAM WG charter: > > > > http://datatracker.ietf.org/wg/tram/charter/ >=20 > Any given system can declare reliance on other features -- that alone > doesn't mean they're in widespread use and generic designers should do > the same. >=20 > I can clarify this to say: >=20 > Although > automatic configuration protocols have been proposed and developed, > system designers cannot yet rely on their widespread presence. >=20 > > -- Section 7.3 > > > > Would a TCP port number assignment be > > needed useful if the corresponding UDP one were unavailable > > (assuming the proposed service needed only a TCP port)? > > > > This question seems backwards. If the proposed service only needs > > a TCP port, why reserve the UDP one? >=20 > TCP is indeed more typical. The question happens in the following case: >=20 > TCP yyyy - unassigned > UDP yyyy - assigned >=20 > If someone asks for a new assignment, IANA needs to understand whether > they could assign yyyy for TCP. >=20 > > Nit: "needed useful" -> "useful" >=20 > It should have said "needed and useful". >=20 > > Nit: "needed only" -> "only requires" >=20 > Will do. >=20 > > Even so, > > System port assignments have continued at an average rate of 3-4 pe= r > > year over the past 7 years (2007-2013), indicating that the desire > > to keep this distinction continues. > > > > Or that old habits die hard. I might actually add those words ;-). >=20 > If it were merely a habit, it wouldn't stand up to IESG review. >=20 > > Further, if > > System ports were no longer assigned, it would cost only 180 of the > > 1024 system values (17%), or 180 of the overall 49152 assigned > > values (<0.04%). > > > > Attach a date to the number 180, as it will almost certainly change > > before this draft is published as an RFC and change "assigned" to > > "System plus User". >=20 > I can, but at the rate it's been going it won't change much (I'm hoping > we'll be done in less than one year). >=20 > > -- Section 7.4 > > > > Given the current state of cybersecurity in the Internet, > > > > Please cite a reference for that. >=20 > I had stated it as common knowledge; if it needs a citation, it's better > to remove the statement IMO. >=20 > > Optional security can penalize performance, requiring additional > > round-trip exchanges before a connection can be established. As > > discussed earlier, ports are a critical resource and it is > > inappropriate to consume assignments to increase performance. > > > > I don't understand the point that this paragraph is trying to make. >=20 > I'll raise that as a separate thread, as it relates to some feedback > Pearl provided off-list. >=20 > > -- Section 7.6 > > > > I generally agree with Lars's concerns about the relationship of the > > material at the end of this section to RFC 5405; I'll leave it to him > > to work those out w/Joe. > > > > -- Section 8 Security Considerations > > > > There are additional security considerations in Sections 7.1, 7.3 > > and 7.4 that should be noted here. >=20 > Will do. >=20 > > This document reminds protocol designers that port numbers are not = a > > substitute for security, > > > > The single word "security" is a bit vague - what sort of security? >=20 > Using assigned numbers for port filtering isn't a substitute for > authentication, encryption, and integrity protection. I'll clarify in > the revision with more descriptive text, if that works... >=20 > > > > > > > > Thanks, > > --David > > > > > >> -----Original Message----- > >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhur= st > >> Sent: Thursday, May 22, 2014 2:36 AM > >> To: tsvwg@ietf.org > >> Subject: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th Jun= e) > >> > >> This email announces the start of a working group last call to > >> confirm publication of "Recommendations for Transport Port Uses". > >> > >> The TSV WG is requesting feedback on this document with the intention = to > >> proceed to publish this as a BCP. > >> > >> Please send any comments to the TSVWG list (tsvwg@ietf.org). > >> > >> The draft is available at: > >> http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04 > >> > >> The last call will run for TWO weeks, ending midnight 5th June. > >> > >> James, David, and Gorry > >> (TSVWG Chairs) > >> tsvwg-chairs@ietf.org > >> > >> > >> > > From nobody Tue May 27 16:57:26 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8611A07DB for ; Tue, 27 May 2014 16:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FkuIlFYUhPD for ; Tue, 27 May 2014 16:57:22 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217DD1A07D5 for ; Tue, 27 May 2014 16:57:22 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4RNusRx014461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 16:56:55 -0700 (PDT) Message-ID: <53852646.6090308@isi.edu> Date: Tue, 27 May 2014 16:56:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" , "tsvwg@ietf.org" References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5384DA4F.7000509@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C6631F3@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C6631F3@MX15A.corp.emc.com> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/nHfNQ5fv70EGLHZHo9YY6bLWLM4 Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 23:57:24 -0000 Hi, David, On 5/27/2014 4:45 PM, Black, David wrote: > Joe, > > I'm quoting only those items that I have comments on - everything else > is fine, including any text suggestions that I don't comment on. > >>> Also, I'm not sure that "connection" >>> is the best word here, e.g., for UDP, but I'm not sure what to do >>> without making this sentence wordy and unclear. >> >> Association? > > Ok, it's better than "connection". It's the best I have; other suggestions welcome. >>> such as the use of TLS or SSL [Hi95] [RFC5246]. >>> >>> Please send the SSL mention and reference to /dev/null before anyone in >>> the Security Area notices ;-). The TLS reference will suffice. >> >> The term SSL is still in widespread use - even the recent discussions of >> heartbleed refer to both. Is there a good reason to not refer to SSL at >> all? or should we say: >> >> TLS (or its deprecated predcessor, SSL) >> >> ? >> >>> NB: [RFC6101] is better reference for SSL 3 than [Hi95]. >> >> Will do. > > In that case, let's call SSL "historic" rather than "deprecated" and > reference RFC 6101 ... which just happens to be an Historic RFC ;-). Will do. >>> -- Section 7.3 >>> >>> Would a TCP port number assignment be >>> needed useful if the corresponding UDP one were unavailable >>> (assuming the proposed service needed only a TCP port)? >>> >>> This question seems backwards. If the proposed service only needs >>> a TCP port, why reserve the UDP one? >> >> TCP is indeed more typical. The question happens in the following case: >> >> TCP yyyy - unassigned >> UDP yyyy - assigned >> >> If someone asks for a new assignment, IANA needs to understand whether >> they could assign yyyy for TCP. > > Rephrasing suggestion: > > Would a TCP port number assignment be useful by itself? If so, a > TCP port number can be assigned whose corresponding UDP port > number is already (or can be subsequently) assigned to a different > protocol. > > This is mostly editorial. Agreed; will do. >>> -- Section 7.4 >>> >>> Given the current state of cybersecurity in the Internet, >>> >>> Please cite a reference for that. >> >> I had stated it as common knowledge; if it needs a citation, it's better >> to remove the statement IMO. > > RFCs are archive documents - the "current state" won't be "common knowledge" > 10-15 years from now. I guess you should remove it. Glad to remove it, though every RFC is a product of the time it is published anyway. >>> This document reminds protocol designers that port numbers are not a >>> substitute for security, >>> >>> The single word "security" is a bit vague - what sort of security? >> >> Using assigned numbers for port filtering isn't a substitute for >> authentication, encryption, and integrity protection. I'll clarify in >> the revision with more descriptive text, if that works... > > That'll work - I think you've written much of what's required in that > response to me. AOK - it needs a little additional text to make sense in context. Joe > > Thanks, > --David > > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 27, 2014 2:33 PM >> To: Black, David; tsvwg@ietf.org >> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) >> >> Hi, David, >> >> Thanks for the detailed feedback. Some questions and alternate >> suggestions below. I'll take the security performance issue to a >> separate thread later today. >> >> Joe >> >> On 5/22/2014 4:05 PM, Black, David wrote: >>> >>> >>> Some WGLC comments as an individual ... >>> >>> -- Section 4: >>> >>> System ports do not always require special (i.e., 'root') privilege. >>> >>> Nit "(i.e., 'root')" -> "(e.g., operating system superuser)" >> >> How is this: >> >> (i.e., privileged user, typically known as 'root') >> >> ("Superuser" is somewhat antiquated, but the notion of privileged users >> is still current AFAICT). >> >>> For clarity, the remainder of this document refers to the port ranges as >>> System, User, and Dynamic. >>> >>> Following up on Lars's comment, please add a statement that these are >>> the terms used in RFC 6335. >> >> Will do. >> >>> -- Section 5: >>> >>> The first purpose requires that each transport connection between a >>> given pair of IP addresses use a different pair of ports, but does >>> not require either coordination or registration of port use. >>> >>> Almost, but not quite - insert "that uses the same transport protocol" >>> after "each transport connection". >> >> Will do. >> >>> Also, I'm not sure that "connection" >>> is the best word here, e.g., for UDP, but I'm not sure what to do >>> without making this sentence wordy and unclear. >> >> Association? >> >>> This is >>> the primary reason for requesting assigned ports with IANA - to have >>> a common agreement between all endpoints on the Internet as to the >>> meaning of a port. >>> >>> Insert "default" or "expected" before "meaning", e.g., in light of the >>> example a couple of paragraphs earlier of running a web server on port >>> 53 instead of port 80. >> >> Will do. >> >>> -- Section 6 >>> >>> o If more than one port is desired, consider revising the >>> architecture until only one is needed, or, preferably, none. >>> >>> An example of how to get to "none" would be helpful. There are examples >>> in Section 7.1, so a forward reference may suffice. >> >> Will do. >> >>> -- Section 7.1 >>> >>> o Ports are not for performance. Performance enhancement can >>> occur within separate connections. >>> >>> That's a bit cryptic. The first sentence should be expanded to convey the >>> misuse (e.g., ports for ordinary- and higher-performance variants of the >>> same service?). >> >> Will do. >> >>> o Additional ports are not to replicate an existing service. For >>> example, a device is configured using a typical web browser >>> then it is a copy of HTTP port 80 and does not warrant a new >>> assignment. >>> >>> Nit: Insert "if" before "a device" >> >> Will do. >> >>> Nit: "it is a copy of" -> "then the port used for configuration is a copy of" >>> or -> "then that device configuration service is a copy of the www >>> service that is associated with" >> >> "then that port"? >> >>> such as the use of TLS or SSL [Hi95] [RFC5246]. >>> >>> Please send the SSL mention and reference to /dev/null before anyone in >>> the Security Area notices ;-). The TLS reference will suffice. >> >> The term SSL is still in widespread use - even the recent discussions of >> heartbleed refer to both. Is there a good reason to not refer to SSL at >> all? or should we say: >> >> TLS (or its deprecated predcessor, SSL) >> >> ? >> >>> NB: [RFC6101] is better reference for SSL 3 than [Hi95]. >> >> Will do. >> >>> -- Section 7.2 >>> >>> Although >>> automatic configuration protocols have been proposed and developed, >>> system designers cannot yet rely on their presence. >>> >>> Should reference those protocols, e.g., STUN and TURN. >> >> Will do. >> >>> The current >>> RTCWEB work looks like a counterexample to the "cannot yet rely" >>> statement, e.g., see the TRAM WG charter: >>> >>> http://datatracker.ietf.org/wg/tram/charter/ >> >> Any given system can declare reliance on other features -- that alone >> doesn't mean they're in widespread use and generic designers should do >> the same. >> >> I can clarify this to say: >> >> Although >> automatic configuration protocols have been proposed and developed, >> system designers cannot yet rely on their widespread presence. >> >>> -- Section 7.3 >>> >>> Would a TCP port number assignment be >>> needed useful if the corresponding UDP one were unavailable >>> (assuming the proposed service needed only a TCP port)? >>> >>> This question seems backwards. If the proposed service only needs >>> a TCP port, why reserve the UDP one? >> >> TCP is indeed more typical. The question happens in the following case: >> >> TCP yyyy - unassigned >> UDP yyyy - assigned >> >> If someone asks for a new assignment, IANA needs to understand whether >> they could assign yyyy for TCP. >> >>> Nit: "needed useful" -> "useful" >> >> It should have said "needed and useful". >> >>> Nit: "needed only" -> "only requires" >> >> Will do. >> >>> Even so, >>> System port assignments have continued at an average rate of 3-4 per >>> year over the past 7 years (2007-2013), indicating that the desire >>> to keep this distinction continues. >>> >>> Or that old habits die hard. I might actually add those words ;-). >> >> If it were merely a habit, it wouldn't stand up to IESG review. >> >>> Further, if >>> System ports were no longer assigned, it would cost only 180 of the >>> 1024 system values (17%), or 180 of the overall 49152 assigned >>> values (<0.04%). >>> >>> Attach a date to the number 180, as it will almost certainly change >>> before this draft is published as an RFC and change "assigned" to >>> "System plus User". >> >> I can, but at the rate it's been going it won't change much (I'm hoping >> we'll be done in less than one year). >> >>> -- Section 7.4 >>> >>> Given the current state of cybersecurity in the Internet, >>> >>> Please cite a reference for that. >> >> I had stated it as common knowledge; if it needs a citation, it's better >> to remove the statement IMO. >> >>> Optional security can penalize performance, requiring additional >>> round-trip exchanges before a connection can be established. As >>> discussed earlier, ports are a critical resource and it is >>> inappropriate to consume assignments to increase performance. >>> >>> I don't understand the point that this paragraph is trying to make. >> >> I'll raise that as a separate thread, as it relates to some feedback >> Pearl provided off-list. >> >>> -- Section 7.6 >>> >>> I generally agree with Lars's concerns about the relationship of the >>> material at the end of this section to RFC 5405; I'll leave it to him >>> to work those out w/Joe. >>> >>> -- Section 8 Security Considerations >>> >>> There are additional security considerations in Sections 7.1, 7.3 >>> and 7.4 that should be noted here. >> >> Will do. >> >>> This document reminds protocol designers that port numbers are not a >>> substitute for security, >>> >>> The single word "security" is a bit vague - what sort of security? >> >> Using assigned numbers for port filtering isn't a substitute for >> authentication, encryption, and integrity protection. I'll clarify in >> the revision with more descriptive text, if that works... >> >>> >>> >>> >>> Thanks, >>> --David >>> >>> >>>> -----Original Message----- >>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurst >>>> Sent: Thursday, May 22, 2014 2:36 AM >>>> To: tsvwg@ietf.org >>>> Subject: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) >>>> >>>> This email announces the start of a working group last call to >>>> confirm publication of "Recommendations for Transport Port Uses". >>>> >>>> The TSV WG is requesting feedback on this document with the intention to >>>> proceed to publish this as a BCP. >>>> >>>> Please send any comments to the TSVWG list (tsvwg@ietf.org). >>>> >>>> The draft is available at: >>>> http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04 >>>> >>>> The last call will run for TWO weeks, ending midnight 5th June. >>>> >>>> James, David, and Gorry >>>> (TSVWG Chairs) >>>> tsvwg-chairs@ietf.org >>>> >>>> >>>> >>> > From nobody Tue May 27 17:04:40 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0131A07F9 for ; Tue, 27 May 2014 17:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBhkUDj_87l2 for ; Tue, 27 May 2014 17:04:34 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5EE1A07D7 for ; Tue, 27 May 2014 17:04:33 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4S04Sw2030342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 May 2014 20:04:28 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s4S04Sw2030342 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401235469; bh=O4a5xsuOULwv02uxax0dYTR8RdY=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=C51bgkqk/3ApdDun9W7JepDHoOU5S/xzNbet87Du949m24W5xXbQZcHQj/lOcHAUl 0hyi/IR180xaw+PsQoxlWx0Vd9EgtgUCRsZy4PnsFQEclNSroP8UAElu10f5JiUhZ/ Nf/bY41saYaHm5LPwKP+vOdPfr1leyaDjMN1P/XA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s4S04Sw2030342 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor); Tue, 27 May 2014 20:04:15 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4S04Fe3011999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 20:04:15 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Tue, 27 May 2014 20:04:15 -0400 From: "Black, David" To: Joe Touch Date: Tue, 27 May 2014 20:04:14 -0400 Thread-Topic: port scarcity - WGLC for draft-ietf-tsvwg-port-use-04 Thread-Index: Ac96CFwGE1eJRBlxStW8I1QdcbriHQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C6631F9@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/MvHWjJy3McIGp_8v7V287Fy02jM Cc: "tsvwg@ietf.org" Subject: [tsvwg] port scarcity - WGLC for draft-ietf-tsvwg-port-use-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:04:35 -0000 Sm9lLA0KDQo8V0cgY2hhaXIgaGF0IE9GRj4NCg0KPiA+IEJ1dCwgcmVnYXJkbGVzcywgZ2l2ZW4g dGhhdCB5b3UgYWdyZWUgdGhhdCB0aGVyZSBpcyBubyBldmlkZW5jZSBmb3IgdGhlDQo+ID4gc2Nh cmNpdHksIHRoZSB3aG9sZSByZWFzb24gZm9yIHRoaXMgZG9jdW1lbnQgc2VlbXMgdG8gZmFsbCBh cGFydC4NCj4gDQo+IFNjYXJjaXR5IGlzIGEgcmVsYXRpdmUgbWVhc3VyZS4gVGhlcmUgYXJlIG9u bHkgMTYgYml0cyBvZiBwb3J0IHNwYWNlLA0KPiBhbmQgeWVzLCBpdCdzIG9ubHkgMTElIHVzZWQu IEJ1dCB3ZSd2ZSB0dXJuZWQgYXdheSBkb3plbnMgb2YgcmVxdWVzdHMNCj4gZm9yIDEwcy0xMDBz IG9mIHBvcnRzLCBhbmQgY3V0IGEgbGFyZ2UgbnVtYmVyIG9mIHJlcXVlc3RzIGZvciBtdWx0aXBs ZQ0KPiBwb3J0cyBkb3duIHRvIG9uZSBvciB0d28uDQoNCkFyZSB0aGVzZSBvdXQtb2YtbGluZSBy ZXF1ZXN0cyAobW9zdGx5IG5vbi1JRVRGLCBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5KQ0KdGhl IHByaW1hcnkgbW90aXZhdGlvbiBmb3IgdGhlIHNjYXJjaXR5IGRpc2N1c3Npb24/DQoNCklmIHNv LCBjb3VsZCB0aGUgc2NhcmNpdHkgZGlzY3Vzc2lvbiBiZSBzb21ld2hhdCBtb3JlIGZvY3VzZWQg b24gcmVxdWVzdHMNCnRoYXQgYXJlIGNsZWFybHkgYXNraW5nIGZvciBlbnRpcmVseSB0b28gbWFu eSBwb3J0cz8gIEl0IGZlZWxzIGxpa2Ugb25lIG9yDQp0d28gYXQgYSB0aW1lIGlzIG5vdCBhIG1h am9yIGNhdXNlIGZvciBjb25jZXJuLCBidXQgSSBjbGVhcmx5IHVuZGVyc3RhbmQgdGhlDQpwcm9i bGVtcyB3aXRoIHJlcXVlc3RzIGZvciAxMHMtMTAwcy4NCg0KUkZDIDYzMzUgYWxyZWFkeSBzYXlz IChzZWN0aW9uIDcuMik6DQoNCiAgIG8gIElBTkEgc3RyaXZlcyB0byBhc3NpZ24gb25seSBvbmUg YXNzaWduZWQgcG9ydCBudW1iZXIgcGVyIHNlcnZpY2UNCiAgICAgIG9yIGFwcGxpY2F0aW9uLg0K DQoJW05vdGUgb24gc2VjdXJpdHkgc25pcHBlZCAtIGJlbG9uZ3MgaW4gb3RoZXIgdGhyZWFkLl0N Cg0KICAgbyAgSUFOQSBzdHJpdmVzIHRvIGFzc2lnbiBvbmx5IG9uZSBhc3NpZ25lZCBwb3J0IG51 bWJlciBmb3IgYWxsDQogICAgICB2YXJpYW50cyBvZiBhIHNlcnZpY2UgKGUuZy4sIGZvciB1cGRh dGVkIHZlcnNpb25zIG9mIGEgc2VydmljZSkuDQoNClBlcmhhcHMgYSByZW1pbmRlciBvZiB0aGF0 IHBsdXMgZG9jdW1lbnRhdGlvbiBvZiB0aGUgcHJhY3RpY2VzIHRoYXQNCnRoZSBwb3J0IHJldmll d2VycyBhcmUgY3VycmVudGx5IGZvbGxvd2luZyB3b3VsZCBiZSBhIGdvb2Qgc3RhcnRpbmcNCnBv aW50Lg0KDQo8L1dHIGNoYWlyIGhhdCBPRkY+DQoNClRoYW5rcywNCi0tRGF2aWQNCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZSBUb3VjaA0KPiBTZW50OiBUdWVzZGF5LCBN YXkgMjcsIDIwMTQgNjoxOSBQTQ0KPiBUbzogUGF1bCBIb2ZmbWFuDQo+IENjOiB0c3Z3Z0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW3RzdndnXSBXR0xDIGZvciBkcmFmdC1pZXRmLXRzdndnLXBv cnQtdXNlLTA0ICh0byBlbmQgNnRoIEp1bmUpDQo+IA0KPiANCj4gDQo+IE9uIDUvMjcvMjAxNCAy OjQyIFBNLCBQYXVsIEhvZmZtYW4gd3JvdGU6DQo+ID4gT24gVHVlLCBNYXkgMjcsIDIwMTQgYXQg MTE6NDEgQU0sIEpvZSBUb3VjaCA8dG91Y2hAaXNpLmVkdQ0KPiA+IDxtYWlsdG86dG91Y2hAaXNp LmVkdT4+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgICBPbiA1LzI2LzIwMTQgMTo1MCBQ TSwgUGF1bCBIb2ZmbWFuIHdyb3RlOg0KPiA+DQo+ID4gICAgICAgICBUaGlzIGRyYWZ0LCB3aGVu IHRha2VuIGluIGxpZ2h0IG9mIFJGQyA2MzM1LCBpcyBjb21wbGV0ZWx5DQo+ID4gICAgICAgICB1 bm5lY2Vzc2FyeS4NCj4gPiAgICAgICAgIElmIGl0IGlzIG1vdmVkIGZvcndhcmQgYXQgdGhpcyB0 aW1lLCBpdCB3aWxsIGNhdXNlIGhhcm0gdG8gdGhlDQo+ID4gICAgICAgICBJbnRlcm5ldA0KPiA+ ICAgICAgICAgZm9yIGFic29sdXRlbHkgbm8gcHVycG9zZS4NCj4gPg0KPiA+ICAgICAgICAgVGhl cmUgaXMgbm8gZXZpZGVuY2UgdGhhdCB0aGF0IHBvcnQgbnVtYmVycyBhcmUgYWN0dWFsbHkgc2Nh cmNlLg0KPiA+DQo+ID4NCj4gPiAgICAgQWx0aG91Z2ggdGhhdCdzIHRydWUgKGFzIGFscmVhZHkg bm90ZWQgaW4gUkZDNjMzNSwgYW5kIHNob3VsZCBiZQ0KPiA+ICAgICBjaXRlZCBpbiB0aGlzIGRv YyB0b28pIGl0J3Mgb25seSBiZWNhdXNlIG9mIHRoZSAxOjEgZmVlZGJhY2sgdGhhdA0KPiA+ICAg ICB0aGUgcmV2aWV3IHByb2Nlc3MgaGFzIGJlZW4gcHJvdmlkaW5nLg0KPiA+DQo+ID4gSXMgdGhl cmUgYW55IGV2aWRlbmNlIHRvIHN1cHBvcnQgdGhlIHN0YXRlbWVudCB0aGF0IGZlZWRiYWNrIGhh cyBjaGFuZ2VkDQo+ID4gdGhpcyBmb3IgbmV3IElFVEYgcHJvdG9jb2xzPyBJZiBzbywgaXQgc2hv dWxkIGNlcnRhaW5seSBiZSBjaXRlZC4NCj4gDQo+IElBTkEgZGlkbid0IG1haW50YWluIGluZm9y bWF0aW9uIG9uIGFzc2lnbm1lbnRzIHBlciB5ZWFyOyBJJ3ZlIGdvdHRlbg0KPiB0aGVtIGZvciB0 aGUgdGltZSBzaW5jZSBJJ3ZlIGhlbHBlZCBtYW5hZ2UgdGhlIGFzc2lnbm1lbnRzLg0KPiANCj4g VGhlcmUgd2VyZSBhIGZldyBkaXN0aW5jdCBhc3NpZ25tZW50IHBlcmlvZHMgYW5kIGFzc29jaWF0 ZWQgcG9saWNpZXM6DQo+IA0KPiAJLSBwcmlvciB0byBJQ0FOTiwgSm9uIFBvc3RlbCBtYW5hZ2Vk IHRoZW0gbGFyZ2VseSBhcyB3ZSBkbyBub3csDQo+IAl0cmVhdGluZyB0aGVtIGFzIHNvbWV0aGlu ZyB0byBjb25zZXJ2ZSBhcyBtdWNoIGFzIHdlIGtuZXc7DQo+IAlzb21lIGFwcHMgd2VyZSBhc3Np Z25lZCByYW5nZXMgKG5vdGFibHkgWCBXaW5kb3dzKSBiZWNhdXNlDQo+IAl3ZSBkaWRuJ3Qga25v dyBiZXR0ZXIgYXQgdGhlIHRpbWUNCj4gDQo+IAktIGFmdGVyIElDQU5OICgxOTk4KSwgYnV0IGJl Zm9yZSB0aGUgZXhwZXJ0IHJldmlldyBwcm9jZXNzIHdhcw0KPiAJYWN0aXZlICgyMDA4KQ0KPiAN Cj4gCS0gYWN0aXZlIGV4cGVydCByZXZpZXcgcHJvY2VzcyAoMjAwOC1wcmVzZW50KQ0KPiANCj4g SGVyZSBpcyB0aGUgZGF0YSBmcm9tIHRoZSByZWNlbnQgeWVhcnMsIG1lYXN1cmVkIGluIHJlcXVl c3RzLiBOb3QgYWxsDQo+IHJlcXVlc3QgYXJlIGZvciBhIHNpbmdsZSBhc3NpZ25tZW50LiBBcyB5 b3UgY2FuIHNlZSwgdGhlIG51bWJlciBkcm9wcGVkDQo+IHJvdWdobHkgaW4gaGFsZiBzaW5jZSAy MDA4LiBJIGRvbid0IGhhdmUgbW9yZSByZWNlbnQgc3RhdGlzdGljczoNCj4gDQo+IFllYXIJc3Vi bWl0dGVkCXJlc29sdmVkCSUNCj4gMjAxMgkyMDAJICAgICAgICA4MAkgICAgICAgNDAuMDAlDQo+ IDIwMTEJMTg3CSAgICAgICAgODgJICAgICAgIDQ3LjA2JQ0KPiAyMDEwCTIxMAkgICAgICAgIDEx OAkgICAgICAgNTYuMTklDQo+IDIwMDkJMjA5CSAgICAgICAgMTQ5CSAgICAgICA3MS4yOSUNCj4g MjAwOAkyNTcJICAgICAgICAxNjYJICAgICAgIDY0LjU5JQ0KPiANCj4gSSd2ZSBiZWVuIHRyeWlu ZyB0byBnZXQgc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaGlzdG9yaWNhbCBhc3NpZ25tZW50 DQo+IHJhdGUsIGJ1dCBpdCdzIHNsb3ctZ29pbmcuIFRoZSByYXRlIG9mIGFzc2lnbm1lbnQgYXBw cm92YWxzIGhhcyBkcm9wcGVkDQo+IHNpbmNlIHdlIHN0YXJ0ZWQgcHV0dGluZyB0aGlzIGFkdmlj ZSBpbiBwbGFjZS4NCj4gDQo+IEhvd2V2ZXIsIGFnYWluLCB0aGlzIGlzIE5PVCBpbnRlbmRlZCB0 byBiZSBuZXcgYWR2aWNlOyB0aGlzIGlzIHNpbXBseQ0KPiB0aGUgc2FtZSBzdHlsZSBvZiBhZHZp Y2Ugd2UgaGF2ZSBiZWVuIGdpdmluZyBvbiBjYXNlLWJ5LWNhc2UgYmFzaXMgdG8NCj4gYXBwbGlj YW50cy4gSW4gdGhlIHZhc3QgbWFqb3JpdHkgb2YgY2FzZXMsIGFwcGxpY2FudHMgaGF2ZSBhcHBy ZWNpYXRlZA0KPiBnZXR0aW5nIHRoZSBmZWVkYmFjayBhbmQgaXQgaGFzIGxlZCB0byBiZXR0ZXIg cHJvdG9jb2wgZGVzaWduIElNTy4gVGhlcmUNCj4gYXJlIHNvbWUgY29ybmVyIGNhc2VzLCBhcyB0 aGVyZSB3b3VsZCBiZSB3aXRoICphbnkqIHByb2Nlc3MuDQo+IA0KPiA+IEJ1dCwgcmVnYXJkbGVz cywgZ2l2ZW4gdGhhdCB5b3UgYWdyZWUgdGhhdCB0aGVyZSBpcyBubyBldmlkZW5jZSBmb3IgdGhl DQo+ID4gc2NhcmNpdHksIHRoZSB3aG9sZSByZWFzb24gZm9yIHRoaXMgZG9jdW1lbnQgc2VlbXMg dG8gZmFsbCBhcGFydC4NCj4gDQo+IFNjYXJjaXR5IGlzIGEgcmVsYXRpdmUgbWVhc3VyZS4gVGhl cmUgYXJlIG9ubHkgMTYgYml0cyBvZiBwb3J0IHNwYWNlLA0KPiBhbmQgeWVzLCBpdCdzIG9ubHkg MTElIHVzZWQuIEJ1dCB3ZSd2ZSB0dXJuZWQgYXdheSBkb3plbnMgb2YgcmVxdWVzdHMNCj4gZm9y IDEwcy0xMDBzIG9mIHBvcnRzLCBhbmQgY3V0IGEgbGFyZ2UgbnVtYmVyIG9mIHJlcXVlc3RzIGZv ciBtdWx0aXBsZQ0KPiBwb3J0cyBkb3duIHRvIG9uZSBvciB0d28uDQo+IA0KPiA+IFRoZQ0KPiA+ IGFkdmljZSBvZiAieW91IHNob3VsZCBjb25zaWRlciBtdWx0aXBsZXhpbmcgb25lIG9uZSBwb3J0 IiBpcyBmaW5lLCBvZg0KPiA+IGNvdXJzZTsgdGhlIHRoZW1lIG9mIHRoZSBmaXJzdCBoYWxmIG9m IHRoZSBkb2N1bWVudCB0aGF0IHRoZSBhZHZpY2UNCj4gPiBjb21lcyBmcm9tIHNjYXJjaXR5IGlz IG5vdCBpZiB0aGVyZSBpcyBubyBzY2FyY2l0eS4NCj4gDQo+IFlvdXIgYXJndW1lbnQgc2VlbXMg dG8gc3RlbSBmcm9tIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhpcyBkb2MgaXMNCj4gY2xhaW1pbmcg dGhhdCBzb21ldGhpbmcgY2hhbmdlZCB0aGF0IG5lY2Vzc2l0YXRlcyBuZXcsIHVyZ2VudCBjb25z ZXJ2YXRpb24uDQo+IA0KPiBUaGUgcmVhbGl0eSBpcyB0aGF0IHRoZSBvbmx5IHJlYXNvbiB3ZSd2 ZSBiZWVuIGFibGUgdG8ga2VlcCBkb3duIHRvIDExJQ0KPiBvZiB1c2UgaXMgYmVjYXVzZSBvZiBv bmdvaW5nIGNvbnNlcnZhdGlvbi4gMTYgYml0cyBpcyBub3QgYSBsYXJnZSBzcGFjZS4NCj4gDQo+ ID4gICAgIFRoZSBpbnRlbnQgb2YgdGhpcyBkb2MgaXMgdG8gcHJvdmlkZSBicm9hZGVyIGFkdmlj ZSwgaW4gYSBzaW5nbGUNCj4gPiAgICAgcGxhY2UsIHRoYXQncyBiZWVuIHZldHRlZCBieSB0aGUg ZW50aXJlIHRyYW5zcG9ydCBjb21tdW5pdHkuDQo+ID4NCj4gPg0KPiA+IEEgQkNQIGlzIG5vdCAi YnJvYWRlciBhZHZpY2UiOiBpdCBpcyBhIHN0YXRlbWVudCBvZiB3aGF0IHRoZSBJRVRGDQo+ID4g YmVsaWV2ZXMgdG8gaGF2ZSBiZWVuIHByb3ZlbiBhcyBiZXN0IHByYWN0aWNlLiBNdWNoIG9mIHRo ZSBhZHZpY2UgaW4gdGhlDQo+ID4gZG9jdW1lbnQgKCJzeXN0ZW1zIG1pZ2h0IHJlcXVpcmUgYSBz aW5nbGUgcG9ydCBhc3NpZ25tZW50LCBidXQgcmFyZWx5DQo+ID4gcmVxdWlyZSBtdWx0aXBsZSBw b3J0cyIpIGNhbm5vdCBiZSBwcm92ZW4gYXMgYSBiZXN0IHByYWN0aWNlLiBJdCBpcyBhDQo+ID4g cHJhY3RpY2UgdG8gY29uc2lkZXIsIGJ1dCBpdCBpcyBub3QgImJlc3QiLg0KPiA+DQo+ID4gICAg IC4uLg0KPiA+DQo+ID4gICAgICAgICBUaGUgZHJhZnQgcHJlc3VtZXMgdGhhdCBwcmVzZXJ2YXRp b24gb2YgcG9ydCBudW1iZXJzLCBldmVuIHdoZW4NCj4gPiAgICAgICAgIHRoZXJlIGlzDQo+ID4g ICAgICAgICBpbiBmYWN0IG5vIHNpZ25pZmljYW50IHNjYXJjaXR5LCBpcyBtb3JlIGltcG9ydGFu dCB0aGFuIGxldHRpbmcNCj4gPiAgICAgICAgIEFwcGxpY2F0aW9uIGFuZCBTZWN1cml0eSBBcmVh IFdHcyBkZXRlcm1pbmUgd2hhdCB0aGVpciBwb3J0cw0KPiA+ICAgICAgICAgbmVlZHMgYXJlLg0K PiA+DQo+ID4NCj4gPiAgICAgVGhlcmUgaXMgbm8gYXNwZWN0IG9mIHRoaXMgZG9jIHRoYXQgb3Zl cnJpZGVzIHRoZSBjdXJyZW50IGFzc2lnbm1lbnQNCj4gPiAgICAgcHJvY2Vzcywgd2hpY2ggaW5j bHVkZXMgZXhwZXJ0IHJldmlldyBmb3IgcmVxdWVzdHMgb3V0c2lkZSB0aGUgSUVURg0KPiA+ICAg ICAodGhlIGJ1bGsgb2YgdGhlIHJlcXVlc3RzLCBGV0lXKSBhbmQgUkZDIHByb2Nlc3MgZm9yIHRo b3NlIGluc2lkZSBXR3MuDQo+ID4NCj4gPg0KPiA+IFRoYXQgc3RhdGVtZW50IGlzIG9ydGhvZ29u YWwgd2l0aCB0aGUgc3RhdGVtZW50IEkgbWFkZS4gVGhpcyBkcmFmdCBrZWVwcw0KPiA+IGhhbW1l cmluZyBhdCB0aGUgc2NhcmNpdHkgYXMgYSBqdXN0aWZpY2F0aW9uIGZvciBnaXZpbmcgYWR2aWNl OyB0aGUgUkZDDQo+ID4gc2F5cyB0aGVyZSBpcyBubyBzY2FyY2l0eTsgdGh1cywgdGhpcyBkb2N1 bWVudCB1cGRhdGVzIHRoZSBSRkMuIFJlbW92aW5nDQo+ID4gYWxsIGRpc2N1c3Npb24gb2Ygc2Nh cmNpdHkgYW5kIGRyb3BwaW5nIHRoZSBpbnRlbmRlZCBsZXZlbCBvZiB0aGlzDQo+ID4gZG9jdW1l bnQgdG8gSW5mb3JtYXRpb25hbCB3b3VsZCBnbyBhIGxvbmcgd2F5IHRvIGZpeGluZyB0aGF0IHBy b2JsZW0uDQo+ID4NCj4gPg0KPiA+ICAgICAuLi4NCj4gPg0KPiA+ICAgICAgICAgVGhlIGluZm9y bWF0aW9uIGFib3V0IGFwcGxpY2F0aW9ucyB0aGF0IHVzZSBvbmUgZml4ZWQgcG9ydCBhbmQgdGhl bg0KPiA+ICAgICAgICAgZHluYW1pYyBwb3J0cyBpZ25vcmVzIGV4cGVyaWVuY2UgdGhhdCBoYXMg cmV2ZWFsZWQgc2lnbmlmaWNhbnQNCj4gPiAgICAgICAgIHByb2JsZW1zLg0KPiA+DQo+ID4NCj4g PiAgICAgSXQncyBzdGlsbCBpbiB3aWRlc3ByZWFkIHVzZSBpbiBGVFAsIFNJUCwgZXRjLiBUaGUg Y2hhbGxlbmdlcyBvZg0KPiA+ICAgICBkb2luZyBzbyBhcmUgYWxyZWFkeSBub3RlZC4NCj4gPg0K PiA+DQo+ID4gIk5vdGVkIiBidXQgc3RpbGwgcHVzaGVkIGluIHRoZSBuYW1lIG9mIHNjYXJjaXR5 LiBBIGxlc3Mgb3BpbmlvbmF0ZWQNCj4gPiBkaXNjdXNzaW9uIG9mIHRoZSBwcm9ibGVtcyB0aGF0 IEZUUCBhbmQgU0lQIGhhdmUgZW5jb3VudGVyZWQsIGFuZCBhDQo+ID4gY29tcGFyaXNvbiB0byBw cm90b2NvbHMgdGhhdCBkb24ndCBoYXZlIHRob3NlIHByb2JsZW1zIGJlY2F1c2UgdGhleSB1c2UN Cj4gPiBmaXhlZCBwb3J0cywgd291bGQgYmUgbW9yZSBpbmZvcm1hdGlvbmFsLg0KPiA+DQo+ID4N Cj4gPiAgICAgICAgIEV2ZW4gaWYgdGhlcmUgd2VyZSByZWFsIHNjYXJjaXR5ICh3aGljaCB0aGUg QkNQIHNob3dzIHRoYXQgdGhlcmUNCj4gPiAgICAgICAgIGlzbid0KSwNCj4gPg0KPiA+DQo+ID4g ICAgIEZXSVcsIGJlY2F1c2UgdGhlc2UgcnVsZXMgaGF2ZSBiZWVuIGluZm9ybWFsbHkgZW5jb3Vy YWdlZCBmb3IgZGVjYWRlcy4uLg0KPiA+DQo+ID4NCj4gPiAgICAgICAgIGl0IGlzIGltcG9zc2li bGUgdG8gd2VpZ2ggdGhlIG5lZWRzIG9mIHBvcnQgc2NhcmNpdHkgYWdhaW5zdCB0aGUNCj4gPiAg ICAgICAgIG5lZWQgdG8NCj4gPiAgICAgICAgIGNyZWF0ZSBsZXNzIGZyYWdpbGUgcHJvdG9jb2xz Lg0KPiA+DQo+ID4NCj4gPiAgICAgSSdsbCBjZXJ0YWlubHkgaGlnaGxpZ2h0IGJldHRlciB0aGUg aXNzdWUgb2YgaW4tYmFuZCBpZGVudGlmaWVycyBhbmQNCj4gPiAgICAgcHJvdG9jb2wgZnJhZ2ls aXR5Lg0KPiA+DQo+ID4NCj4gPiBUaGVuIHdoeSBldmVuIGRvIHRoaXMgYXQgYWxsPyBUaGF0IGlz LCBpZiB0aGVyZSByZWFsbHkgaXMgbm8gc2NhcmNpdHksDQo+ID4gd2hhdCB2YWx1ZSBpcyB0aGlz IGRvY3VtZW50PyBJIGhhdmUgbm90IGhlYXJkIGFwcGxpY2F0aW9uIG9yIHNlY3VyaXR5DQo+ID4g ZGV2ZWxvcGVycyBzYXkgIndlIGRvbid0IGtub3cgd2hlcmUgdG8gZmluZCBleGFtcGxlcyBvZiBw cm90b2NvbHMgdGhhdA0KPiA+IHVzZSBwb3J0cyBpbiBpbnRlcmVzdGluZyB3YXlzLCBsZXQncyBs b29rIGZvciBhbiBSRkMgdGhhdCBsaXN0cyB0aGVtIi4NCj4gPiBPbmNlIHRoZSBzY2FyY2l0eSBh cmd1bWVudCBpcyBzdHJpcHBlZCBvdXQsIGFuZCBldmVuIGlmIHRoZSBmaXJld2FsbHMNCj4gPiBk aXNjdXNzaW9uIGlzIGJyb3VnaHQgdXAgdG8gZGF0ZSAoaXQgdXNlcyBleGFtcGxlcyB0aGF0IGFy ZSBhYm91dCBhDQo+ID4gZGVjYWRlIG91dCBvZiBkYXRlKSwgdGhlIG1lYXQgb2YgdGhlIGRvY3Vt ZW50IGlzICJ5b3UgY2FuIGRlc2lnbiB5b3VyDQo+ID4gcHJvdG9jb2wncyB1c2Ugb2YgcG9ydHMg aG93ZXZlciB5b3Ugd2FudCIuIFRoaXMgZG9lc24ndCBzZWVtIHVzZWZ1bCwgYW5kDQo+ID4gc3Rp bGwgY291bGQgYmUgaGFybWZ1bCBpZiB1c2VkIGFzIGEgYmx1bnQgb2JqZWN0IGR1cmluZyBJQU5B IHJldmlldy4NCj4gPg0KPiA+IC0tUGF1bCBIb2ZmbWFuDQo+IA0KDQo= From nobody Tue May 27 17:10:33 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14151A07F9 for ; Tue, 27 May 2014 17:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.348 X-Spam-Level: * X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GilnvOvRlts5 for ; Tue, 27 May 2014 17:10:29 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CAE1A07D4 for ; Tue, 27 May 2014 17:10:29 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4S09maj018060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 17:09:48 -0700 (PDT) Message-ID: <5385294C.1030008@isi.edu> Date: Tue, 27 May 2014 17:09:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE712076C6631F9@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C6631F9@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/v5Ywsv5YejzsKNaeYckTh-h1oHc Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] port scarcity - WGLC for draft-ietf-tsvwg-port-use-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:10:30 -0000 On 5/27/2014 5:04 PM, Black, David wrote: > Joe, > > > >>> But, regardless, given that you agree that there is no evidence for the >>> scarcity, the whole reason for this document seems to fall apart. >> >> Scarcity is a relative measure. There are only 16 bits of port space, >> and yes, it's only 11% used. But we've turned away dozens of requests >> for 10s-100s of ports, and cut a large number of requests for multiple >> ports down to one or two. > > Are these out-of-line requests (mostly non-IETF, if I understand correctly) > the primary motivation for the scarcity discussion? Yes. > If so, could the scarcity discussion be somewhat more focused on requests > that are clearly asking for entirely too many ports? It feels like one or > two at a time is not a major cause for concern, but I clearly understand the > problems with requests for 10s-100s. That's true, but it's also the case that a lot of applicants request ports that aren't needed at all. We don't recommend against any new protocol; we just ask whether existing services have been considered, and encourage designs that are easier to manage and debug (i.e., using a single port rather than one for each component of a complex system). > RFC 6335 already says (section 7.2): > > o IANA strives to assign only one assigned port number per service > or application. > > [Note on security snipped - belongs in other thread.] > > o IANA strives to assign only one assigned port number for all > variants of a service (e.g., for updated versions of a service). > > Perhaps a reminder of that plus documentation of the practices that > the port reviewers are currently following would be a good starting > point. That's basically how this document came into being, FWIW. It's certainly useful to point back to this advice to link together the two docs better. Joe > > > > Thanks, > --David > > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Tuesday, May 27, 2014 6:19 PM >> To: Paul Hoffman >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) >> >> >> >> On 5/27/2014 2:42 PM, Paul Hoffman wrote: >>> On Tue, May 27, 2014 at 11:41 AM, Joe Touch >> > wrote: >>> >>> >>> >>> On 5/26/2014 1:50 PM, Paul Hoffman wrote: >>> >>> This draft, when taken in light of RFC 6335, is completely >>> unnecessary. >>> If it is moved forward at this time, it will cause harm to the >>> Internet >>> for absolutely no purpose. >>> >>> There is no evidence that that port numbers are actually scarce. >>> >>> >>> Although that's true (as already noted in RFC6335, and should be >>> cited in this doc too) it's only because of the 1:1 feedback that >>> the review process has been providing. >>> >>> Is there any evidence to support the statement that feedback has changed >>> this for new IETF protocols? If so, it should certainly be cited. >> >> IANA didn't maintain information on assignments per year; I've gotten >> them for the time since I've helped manage the assignments. >> >> There were a few distinct assignment periods and associated policies: >> >> - prior to ICANN, Jon Postel managed them largely as we do now, >> treating them as something to conserve as much as we knew; >> some apps were assigned ranges (notably X Windows) because >> we didn't know better at the time >> >> - after ICANN (1998), but before the expert review process was >> active (2008) >> >> - active expert review process (2008-present) >> >> Here is the data from the recent years, measured in requests. Not all >> request are for a single assignment. As you can see, the number dropped >> roughly in half since 2008. I don't have more recent statistics: >> >> Year submitted resolved % >> 2012 200 80 40.00% >> 2011 187 88 47.06% >> 2010 210 118 56.19% >> 2009 209 149 71.29% >> 2008 257 166 64.59% >> >> I've been trying to get some information about the historical assignment >> rate, but it's slow-going. The rate of assignment approvals has dropped >> since we started putting this advice in place. >> >> However, again, this is NOT intended to be new advice; this is simply >> the same style of advice we have been giving on case-by-case basis to >> applicants. In the vast majority of cases, applicants have appreciated >> getting the feedback and it has led to better protocol design IMO. There >> are some corner cases, as there would be with *any* process. >> >>> But, regardless, given that you agree that there is no evidence for the >>> scarcity, the whole reason for this document seems to fall apart. >> >> Scarcity is a relative measure. There are only 16 bits of port space, >> and yes, it's only 11% used. But we've turned away dozens of requests >> for 10s-100s of ports, and cut a large number of requests for multiple >> ports down to one or two. >> >>> The >>> advice of "you should consider multiplexing one one port" is fine, of >>> course; the theme of the first half of the document that the advice >>> comes from scarcity is not if there is no scarcity. >> >> Your argument seems to stem from the impression that this doc is >> claiming that something changed that necessitates new, urgent conservation. >> >> The reality is that the only reason we've been able to keep down to 11% >> of use is because of ongoing conservation. 16 bits is not a large space. >> >>> The intent of this doc is to provide broader advice, in a single >>> place, that's been vetted by the entire transport community. >>> >>> >>> A BCP is not "broader advice": it is a statement of what the IETF >>> believes to have been proven as best practice. Much of the advice in the >>> document ("systems might require a single port assignment, but rarely >>> require multiple ports") cannot be proven as a best practice. It is a >>> practice to consider, but it is not "best". >>> >>> ... >>> >>> The draft presumes that preservation of port numbers, even when >>> there is >>> in fact no significant scarcity, is more important than letting >>> Application and Security Area WGs determine what their ports >>> needs are. >>> >>> >>> There is no aspect of this doc that overrides the current assignment >>> process, which includes expert review for requests outside the IETF >>> (the bulk of the requests, FWIW) and RFC process for those inside WGs. >>> >>> >>> That statement is orthogonal with the statement I made. This draft keeps >>> hammering at the scarcity as a justification for giving advice; the RFC >>> says there is no scarcity; thus, this document updates the RFC. Removing >>> all discussion of scarcity and dropping the intended level of this >>> document to Informational would go a long way to fixing that problem. >>> >>> >>> ... >>> >>> The information about applications that use one fixed port and then >>> dynamic ports ignores experience that has revealed significant >>> problems. >>> >>> >>> It's still in widespread use in FTP, SIP, etc. The challenges of >>> doing so are already noted. >>> >>> >>> "Noted" but still pushed in the name of scarcity. A less opinionated >>> discussion of the problems that FTP and SIP have encountered, and a >>> comparison to protocols that don't have those problems because they use >>> fixed ports, would be more informational. >>> >>> >>> Even if there were real scarcity (which the BCP shows that there >>> isn't), >>> >>> >>> FWIW, because these rules have been informally encouraged for decades... >>> >>> >>> it is impossible to weigh the needs of port scarcity against the >>> need to >>> create less fragile protocols. >>> >>> >>> I'll certainly highlight better the issue of in-band identifiers and >>> protocol fragility. >>> >>> >>> Then why even do this at all? That is, if there really is no scarcity, >>> what value is this document? I have not heard application or security >>> developers say "we don't know where to find examples of protocols that >>> use ports in interesting ways, let's look for an RFC that lists them". >>> Once the scarcity argument is stripped out, and even if the firewalls >>> discussion is brought up to date (it uses examples that are about a >>> decade out of date), the meat of the document is "you can design your >>> protocol's use of ports however you want". This doesn't seem useful, and >>> still could be harmful if used as a blunt object during IANA review. >>> >>> --Paul Hoffman >> > From nobody Tue May 27 17:41:31 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099741A0837 for ; Tue, 27 May 2014 17:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77lx3cylRMoC for ; Tue, 27 May 2014 17:41:16 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB681A0827 for ; Tue, 27 May 2014 17:41:16 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4S0fAJC028332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 May 2014 20:41:10 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s4S0fAJC028332 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401237670; bh=ZCxdicv47OBQ7B01A/UXSThBnus=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=JRxY/HL9/yYl+HnEUbyHy3M2BGe1b7ATnz+Jv/sxbxJBHFdp9fJR099jjT85X16p9 cDd6bkEtDwNP/h/kq8MEMSBBghzuI1tnxUdueDbTFRtyFI71g7aUXfNT2GFFNaQrfO K5EcFdWBiHg81LQsJfgkUB7YhtiuMh1z5vTJ8fzI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s4S0fAJC028332 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 27 May 2014 17:40:58 -0700 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4S0evXd004777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 20:40:58 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 27 May 2014 20:40:57 -0400 From: "Black, David" To: Joe Touch , Paul Hoffman Date: Tue, 27 May 2014 20:40:55 -0400 Thread-Topic: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) Thread-Index: Ac95956i0BBur0SkRa2ZMwSJVRAsUAAEUZzg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C663209@MX15A.corp.emc.com> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> In-Reply-To: <53850B87.6010604@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Gu33NGrBSA0Kt7GVO4MhCD-a2bE Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:41:26 -0000 Sm9lLA0KDQo8V0cgY2hhaXIgaGF0IE9GRj4NCg0KPiBJZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGUg YW5hbHlzaXMsIHlvdSBzaG91bGQgcHJlc2VudCBhIGNvdW50ZXJhcmd1bWVudC4NCg0KT2ssIEkn bGwgdHJ5IC4uLiA7LSkuDQoNCkl0IG1pZ2h0IGhlbHAgaWYgdGhpcyBoYWQgc29tZXdoYXQgbW9y ZSBvZiBhIGZsYXZvciBvZiBkb2N1bWVudGluZyB0aGUNCnJldmlldyBjcml0ZXJpYSB0aGF0IGFy ZSBjdXJyZW50bHkgdXNlZCwgYWx0aG91Z2ggSSBkbyB0aGluayBhdCBsZWFzdA0Kb25lICJTSE9V TEQgTk9UIiBpcyBsaWtlbHkgdG8gdHVybiB1cCBpbiB0aGUgZmluYWwgdGV4dC4NCg0KSSdkIGNl cnRhaW5seSBsaWtlIHRvIHNlZSBzb21lIFNlY3VyaXR5IEFyZWEgaW5wdXQgKGFuZCBwcm9iYWJs eSBhbHNvDQpPUFMsIGFzIGZpcmV3YWxscyBwbGF5IGEgcHJvbWluZW50IHJvbGUpLCBidXQgc3Bl YWtpbmcgZm9yIG15c2VsZiwNCkkgdGhpbmsgb2ZmZXJpbmcgc2VjdXJpdHkgYWR2aWNlIGlzIHdl bGwgd2l0aGluIHJlYXNvbiBoZXJlIC4uLg0KDQpHb2luZyBiYWNrIHRvIHRoZSB0aHJlZSBzY2Vu YXJpb3MgYXQgdGhlIHN0YXJ0IG9mIHRoaXMgdGhyZWFkLCB0aGUNCnByb3Bvc2FscyBmb3IgdGhl IGZpcnN0IHR3byBzZWVtIHJlYXNvbmFibGUgKElNSE8pOg0KDQoJLSBnaXZlbiBhIGN1cnJlbnQg bm9uLXNlY3VyZSBhc3NpZ25tZW50LCB3aGF0IGlmIGENCgl1c2VyIHJlcXVlc3RzIGEgKG5ldykg c2Vjb25kIHBvcnQgZm9yIHNlY3VyZSBhY2Nlc3M/DQoNCgkJdGhpcyBpcyBmaW5lLCBpZiBub3Qg YSBnb29kIGlkZWE7DQoNCgktIGdpdmVuIGEgY3VycmVudCBzZWN1cmUgYXNzaWdubWVudCwgd2hh dA0KCWlmIGEgdXNlciByZXF1ZXN0cyBhIChuZXcpIHNlY29uZCBwb3J0IGZvciBpbnNlY3VyZSBh Y2Nlc3M/DQoNCgkJaXQgc2VlbXMgbGlrZSBhIFNIT1VMRCBOT1QgcmVjb21tZW5kYXRpb24NCgkJ aXMgYXBwcm9wcmlhdGU7IHRoaXMgY3JlYXRlcyBuZXcgdnVsbmVyYWJpbGl0eTsNCg0KSSBwcmVz dW1lIHRoYXQgdGhlIGxhdHRlciByZWNvbW1lbmRhdGlvbiBlbnZpc2lvbnMgYSBzY2VuYXJpbyB3 aGVyZQ0KdGhlIHNlY3VyZSBwb3J0IGhhcyBiZWVuIGRlcGxveWVkIGFuZCB1c2VkIGZvciBhIHNp Z25pZmljYW50IHBlcmlvZA0Kb2YgdGltZS4gIEluIHRoYXQgY2FzZSwgSSB0aGluayBhICJTSE9V TEQgTk9UIiBpcyBvaywgYXMgSSdkIHdhbnQgdG8NCnNlZSBzb21lIGhlYXZ5LWR1dHkgc2VyaW91 cyBqdXN0aWZpY2F0aW9uIGZvciBhZGRpbmcgdGhlIGluc2VjdXJlDQpwb3J0LiAgVGhlIGRyYWZ0 IHNob3VsZCBzdGF0ZSB0aGF0IHByZXN1bXB0aW9uLCB0aG91Z2gsIGFzIGRlcGxveW1lbnQNCmRp ZmZpY3VsdGllcy9leHBlcmllbmNlIG1pZ2h0IHJlc3VsdCBpbiBzb21ldGhpbmcgY2xvc2VyIHRv IHRoZSB0aGlyZA0Kc2NlbmFyaW8uDQoNCgktIHNob3VsZCBhIHVzZXIgcmVxdWVzdCB0d28gcG9y dHMgZm9yIGEgbmV3IHNlcnZpY2UsIG9uZQ0KCXNlY3VyZSBhbmQgb25lIGluc2VjdXJlPw0KDQpJ IHN1c3BlY3QgdGhhdCB0aGUgYWR2aWNlIGZvciB0aGUgdGhpcyBvbmUgaXMgbGlrZWx5IHRvIGJl IGEgbG9uZw0KdmVyc2lvbiBvZiAiaXQgZGVwZW5kcyIgaW4gcHJhY3RpY2UuDQoNCgkJSU1PLCB0 aGUgc2VjdXJlIHBvcnQgaXMgZWFzeSwgaWYgb3RoZXJ3aXNlDQoJCXdhcnJhbnRlZCAobm90IGEg ZHVwbGljYXRlIG9mIGV4aXN0aW5nIHNlcnZpY2UsIGUuZy4pLA0KCQlidXQgdGhlIGluc2VjdXJl IG9uZSBzaW1pbGFybHkgY3JlYXRlcyBhIG5ldw0KCQl2dWxuZXJhYmlsaXR5LCBhbmQgYWdhaW4g SSB3b3VsZCBzYXkgU0hPVUxEIE5PVA0KCQlyZXF1ZXN0IGEgbmV3IGluc2VjdXJlIHBvcnQNCg0K SSBhZ3JlZSB3aXRoIHRoZSBzZWN1cmUgcG9ydCBiZWluZyBmaW5lLCBidXQgSSdtIG5vdCBjb21m b3J0YWJsZQ0Kd2l0aCBhIGJsYW5rZXQgIlNIT1VMRCBOT1QiIHJlY29tbWVuZGF0aW9uIGZvciB0 aGUgaW5zZWN1cmUgcG9ydC4NCg0KSSB0aGluayB0aGlzIGRlcGVuZHMgb24gdGhlIGRldGFpbHMg b2YgdGhlIHByb3RvY29sLiAgSSdkIGRlZmluaXRlbHkNCnNldCBhbiBleHBlY3RhdGlvbiB0aGF0 IHNvbGlkIGp1c3RpZmljYXRpb24gZm9yIHRoZSBuZXcgaW5zZWN1cmUNCnBvcnQgd2lsbCBiZSBl eHBlY3RlZCwgd2l0aCB0aGUgYXBwbGljYW50IGJlaW5nIHJlc3BvbnNpYmxlIGZvcg0KanVzdGlm eWluZyB3aHkgdXNlIG9mIHNlY3VyaXR5IGlzIG5vdCBtYW5kYXRvcnkgZm9yIHRoZSBwcm90b2Nv bC4NCklmIHRoYXQganVzdGlmaWNhdGlvbiBtYWtlcyB0aGUgY2FzZSwgdGhlbiB0aGUgZmlyZXdh bGwgY29udHJvbA0KcmF0aW9uYWxlIChiZWxvdykgZGVmaW5pdGVseSBzb3VuZHMgcmVhc29uYWJs ZSwgSU1ITy4NCg0KSSBqdXN0IGRvbid0IHRoaW5rIHRoZSBsZXZlbCBvZiByZXF1aXJlZCBqdXN0 aWZpY2F0aW9uIGlzIGdvaW5nDQp0byByaXNlIHRvIHRoYXQgc3VmZmljaWVudCB0byBvdmVycmlk ZSBhICJTSE9VTEQgTk9UIiBmb3IgZXZlcnkNCnNpbmdsZSBwcm90b2NvbCBkZXNpZ24gdGhhdCB3 ZSBoYXZlIHlldCB0byBlbnZpc2lvbi4gIEkgd2lzaCBteQ0KZm9yZXNpZ2h0IHdhcyAyMC8yMCA6 LSkuDQoNCgktIEdJVkVOIGEgcmVxdWVzdCBmb3IgYW4gaW5zZWN1cmUgYW5kIHNlY3VyZSBwb3J0 LCB3aGF0DQoJYXJlIGFwcHJvcHJpYXRlIGp1c3RpZmljYXRpb25zPw0KDQoJCUlNTywgc2VwYXJh dGUgZmlyZXdhbGwgY29udHJvbCBpcyBhIHN1ZmZpY2llbnQNCgkJcmVhc29uLg0KDQoJCWhvd2V2 ZXIsIHBlcmZvcm1hbmNlIHNob3VsZCBub3QgYmUgLSBpLmUuLCBpZg0KCQlib3RoIHBvcnRzIHdp bGwgdHlwaWNhbGx5IGhhdmUgdGhlIHNhbWUgZmlyZXdhbGwJDQoJCWNvbmZpZ3VyYXRpb24sIHRo ZW4gb25seSBvbmUgcG9ydCBpcyBuZWVkZWQNCgkJYW5kIHNlY3VyaXR5IHNob3VsZCBiZSBuZWdv dGlhdGVkIGFzIHByZXNlbnQvYWJzZW50DQoJCWluLWJhbmQuIFRoZSBwZXJmb3JtYW5jZSBpbXBh Y3Qgb2YgdGhhdCBuZWdvdGlhdGlvbg0KCQkoSU1PKSBzaG91bGQgbm90IGZhY3RvciBpbnRvIHdo ZXRoZXIgYW4gYWRkaXRpb25hbA0KCQlwb3J0IHNob3VsZCBiZSBhc3NpZ25lZC4NCg0KSSB0aGlu ayB0aGUgdGV4dCBvbiBwZXJmb3JtYW5jZSBzaG91bGQgYmUgZXhwbGljaXQgdGhhdCB0aGUNCnBl cmZvcm1hbmNlIGNvbmNlcm4gaXMgbmVnb3RpYXRpb24gcm91bmQgdHJpcCBhdm9pZGFuY2UuDQoN CjwvV0cgY2hhaXIgaGF0IE9GRj4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVd DQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAyNywgMjAxNCA2OjAzIFBNDQo+IFRvOiBQYXVsIEhvZmZt YW4NCj4gQ2M6IEJsYWNrLCBEYXZpZDsgdHN2d2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0 c3Z3Z10gYWRkaXRpb25hbCBwb3J0cyBmb3Igc2VjdXJpdHkgLSBSZTogV0dMQyBmb3IgZHJhZnQt aWV0Zi0NCj4gdHN2d2ctcG9ydC11c2UtMDQgKHRvIGVuZCA2dGggSnVuZSkNCj4gDQo+IA0KPiAN Cj4gT24gNS8yNy8yMDE0IDI6NDkgUE0sIFBhdWwgSG9mZm1hbiB3cm90ZToNCj4gPiBJcyB0aGlz IG5ldyBhZHZpY2UgYmFzZWQgb24gYW55IGFjdHVhbCBldmlkZW5jZSBvciBldmVuIGEgc2VjdXJp dHkgYW5hbHlzaXM/DQo+IA0KPiBJdCdzIGJhc2VkIG9uIDggeWVhcnMgb2YgcnVubmluZyB0aGUg cmV2aWV3IHRlYW0gYW5kIGRpc2N1c3Npb25zIHdpdGhpbg0KPiB0aGF0IHRlYW0uIEl0J3MgYmFz ZWQgb24gdGhlIGFuYWx5c2lzIHByb3ZpZGVkLg0KPiANCj4gSWYgeW91IGRpc2FncmVlIHdpdGgg dGhlIGFuYWx5c2lzLCB5b3Ugc2hvdWxkIHByZXNlbnQgYSBjb3VudGVyYXJndW1lbnQuDQo+IA0K PiA+IEZ1cnRoZXIsIGEgc3RhdGVtZW50IG9mICJTSE9VTEQgTk9UIHJlcXVlc3QiIHNvdW5kcyBh IGhlbGwgb2YgYSBsb3QgbW9yZQ0KPiA+IGxpa2UgYSBkZW1hbmQgdGhhbiBhZHZpY2UuDQo+IA0K PiBXaGF0IGV4YWN0bHkgY2FuIHdlICpkZW1hbmQqIG9mIGEgdXNlciBtYWtpbmcgYW4gYXBwbGlj YXRpb24gb3RoZXIgdGhhdA0KPiB0byBwcm92aWRlIGFkdmljZT8gSXQncyBub3QgYWR2aWNlIHRv IElBTkEgb3IgdGhlIHBvcnRzIHRlYW0gaW4gaG93IHRvDQo+IG1ha2UgYSBkZWNpc2lvbi4NCj4g DQo+ID4gVGhpcyBnZXRzIHRvIHRoZSBjcnV4IG9mIG15IGNvbmNlcm4gb2YgdGhlDQo+ID4gZG9j dW1lbnQ6IGl0IGZlZWwgbGlrZSB0aGUgYWR2aWNlIGlzIG1lYW50IHRvIGNvbWUgZnJvbSBvbiBo aWdoIChuYW1lbHksDQo+ID4gc29tZW9uZSB3aG8gY2FuIGJsb2NrIElBTkEgcmVxdWVzdHMpLCBu b3QgZnJpZW5kbHkgYWR2aWNlIGZyb20gb25lDQo+ID4gZGV2ZWxvcGVyIHRvIGFub3RoZXIuDQo+ IA0KPiBDYW4geW91IHByb3ZpZGUgYSByYXRpb25hbGUgZm9yIHRoYXQgY2xhaW0gb3RoZXIgdGhh biAiYmVjYXVzZSBKb2UgVG91Y2gNCj4gd3JvdGUgaXQiPw0KPiANCj4gPiBXZSB3ZW50IHRocm91 Z2ggdGhpcyBpbiB0aGUgZGlzY3Vzc2lvbiBhIGZldyB5ZWFycw0KPiA+IGFnbywgYW5kIGl0IHNl ZW1lZCB0aGVuIHRoYXQgVFNWV0cgZGlkbid0IGFncmVlIHRoYXQgc3VjaCBoZWF2eS1oYW5kZWQN Cj4gPiAiYWR2aWNlIiwgcGFydGljdWxhcmx5IHdpdGhvdXQgc3BlY2lmaWMganVzdGlmaWNhdGlv biwgd2FzIHRoZSB3YXkgdG8gZ28uDQo+IA0KPiBUU1ZXRyBhZ3JlZWQgdGhhdCBsaW1pdGluZyBJ QU5BIHdhcyBub3QgYXBwcm9wcmlhdGU7IHRoaXMgZG9jdW1lbnQNCj4gZG9lc24ndCBsaW1pdCBJ QU5BLg0KPiANCj4gQW5kIHNwZWNpZmljIGp1c3RpZmljYXRpb24gaXMgcHJvdmlkZWQgaW4gdGhl IGRpc2N1c3Npb24gSSBnYXZlLiBBZ2FpbiwNCj4gaWYgeW91IGRpc2FncmVlIHdpdGggdGhhdCBk aXNjdXNzaW9uLCBwbGVhc2UgZXhwbGFpbi4NCj4gDQo+IEUuZy4sIGRvIHlvdSBhY3R1YWxseSB0 aGluayBpdCdzIGdvb2Qgc2VjdXJpdHkgcHJhY3RpY2UgdG8gY3JlYXRlIG5ldywNCj4gaW5zZWN1 cmUgc2VydmljZXM/IElmIHNvLCBvbiB3aGF0IGJhc2lzIG9mIGdvb2Qgc2VjdXJpdHkgcHJhY3Rp Y2U/DQo+IA0KPiBKb2UNCg0K From nobody Tue May 27 19:00:13 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E809C1A084B for ; Tue, 27 May 2014 19:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYmsx8bYgue6 for ; Tue, 27 May 2014 19:00:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA671A01C6 for ; Tue, 27 May 2014 19:00:09 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s4S1xbhr016965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 18:59:42 -0700 (PDT) Message-ID: <53854308.8020705@isi.edu> Date: Tue, 27 May 2014 18:59:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" , Paul Hoffman References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C663209@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C663209@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/3Ek91LzNiTuH6Fw0svudq9e1JOw Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 02:00:11 -0000 On 5/27/2014 5:40 PM, Black, David wrote: > Joe, > > > >> If you disagree with the analysis, you should present a counterargument. > > Ok, I'll try ... ;-). > > It might help if this had somewhat more of a flavor of documenting the > review criteria that are currently used, although I do think at least > one "SHOULD NOT" is likely to turn up in the final text. > > I'd certainly like to see some Security Area input (and probably also > OPS, as firewalls play a prominent role), but speaking for myself, > I think offering security advice is well within reason here ... > > Going back to the three scenarios at the start of this thread, the > proposals for the first two seem reasonable (IMHO): > > - given a current non-secure assignment, what if a > user requests a (new) second port for secure access? > > this is fine, if not a good idea; > > - given a current secure assignment, what > if a user requests a (new) second port for insecure access? > > it seems like a SHOULD NOT recommendation > is appropriate; this creates new vulnerability; > > I presume that the latter recommendation envisions a scenario where > the secure port has been deployed and used for a significant period > of time. Yes. > In that case, I think a "SHOULD NOT" is ok, as I'd want to > see some heavy-duty serious justification for adding the insecure > port. The draft should state that presumption, though, as deployment > difficulties/experience might result in something closer to the third > scenario. Right - that's the point of the SHOULD NOT. It's not a MUST NOT. It just needs very heavy justification. > - should a user request two ports for a new service, one > secure and one insecure? > > I suspect that the advice for the this one is likely to be a long > version of "it depends" in practice. > > IMO, the secure port is easy, if otherwise > warranted (not a duplicate of existing service, e.g.), > but the insecure one similarly creates a new > vulnerability, and again I would say SHOULD NOT > request a new insecure port > > I agree with the secure port being fine, but I'm not comfortable > with a blanket "SHOULD NOT" recommendation for the insecure port. > > I think this depends on the details of the protocol. I'd definitely > set an expectation that solid justification for the new insecure > port will be expected, with the applicant being responsible for > justifying why use of security is not mandatory for the protocol. > If that justification makes the case, then the firewall control > rationale (below) definitely sounds reasonable, IMHO. Why isn't that a SHOULD NOT? Certainly a bit more text is in order, but it seems like we're in agreement - deep justification is needed. > I just don't think the level of required justification is going > to rise to that sufficient to override a "SHOULD NOT" for every > single protocol design that we have yet to envision. I wish my > foresight was 20/20 :-). FWIW, there aren't a lot of protocols that ask for secure and insecure at the same time. Those come mostly - incredibly - from IETF WGs, where they appear to be (IMO blindly) following past practice. My key concern is "why is the insecure port needed"? Most of the time the justification is pure performance - running security on the service will make it too slow, and this will allow faster performance inside an enterprise. That might be true, but it also needs to be justified in terms of the service being provided - that this is a high-throughput or high-transaction frequency system that needs high performance inside protected enterprises. > - GIVEN a request for an insecure and secure port, what > are appropriate justifications? > > IMO, separate firewall control is a sufficient > reason. > > however, performance should not be - i.e., if > both ports will typically have the same firewall > configuration, then only one port is needed > and security should be negotiated as present/absent > in-band. The performance impact of that negotiation > (IMO) should not factor into whether an additional > port should be assigned. > > I think the text on performance should be explicit that the > performance concern is negotiation round trip avoidance. There are a few different performance issues: - round-trip delays - throughput overhead (per byte) - message overhead (per message) Joe > > > Thanks, > --David > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 27, 2014 6:03 PM >> To: Paul Hoffman >> Cc: Black, David; tsvwg@ietf.org >> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf- >> tsvwg-port-use-04 (to end 6th June) >> >> >> >> On 5/27/2014 2:49 PM, Paul Hoffman wrote: >>> Is this new advice based on any actual evidence or even a security analysis? >> >> It's based on 8 years of running the review team and discussions within >> that team. It's based on the analysis provided. >> >> If you disagree with the analysis, you should present a counterargument. >> >>> Further, a statement of "SHOULD NOT request" sounds a hell of a lot more >>> like a demand than advice. >> >> What exactly can we *demand* of a user making an application other that >> to provide advice? It's not advice to IANA or the ports team in how to >> make a decision. >> >>> This gets to the crux of my concern of the >>> document: it feel like the advice is meant to come from on high (namely, >>> someone who can block IANA requests), not friendly advice from one >>> developer to another. >> >> Can you provide a rationale for that claim other than "because Joe Touch >> wrote it"? >> >>> We went through this in the discussion a few years >>> ago, and it seemed then that TSVWG didn't agree that such heavy-handed >>> "advice", particularly without specific justification, was the way to go. >> >> TSVWG agreed that limiting IANA was not appropriate; this document >> doesn't limit IANA. >> >> And specific justification is provided in the discussion I gave. Again, >> if you disagree with that discussion, please explain. >> >> E.g., do you actually think it's good security practice to create new, >> insecure services? If so, on what basis of good security practice? >> >> Joe > From nobody Tue May 27 19:18:19 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B281A02DE for ; Tue, 27 May 2014 19:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2QGsccERVZ2 for ; Tue, 27 May 2014 19:18:16 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BBC1A02DA for ; Tue, 27 May 2014 19:18:15 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so10274526pbb.19 for ; Tue, 27 May 2014 19:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XcXR00/W8K7F47aeNLh3uwSE76/MOEBA7evqKypUwIQ=; b=tu1uUGp0cv3yYj3IRvU80TkT8o2aUhFC2+dryzmb4PQko83TUFNEt6j9kvxMVpGScl 7F7eUtURAH7qRabcKh7SWZilYkD+ZCDKwYCYl9Tu1f+yLu4HX4Ihra661kWuZZc5Q9OY xMwb/6WoyaNhCeFK28a3hF7XSKAzF9HKPGECg1i4kou4pZ7MR8Tz3VIQ4emdRrzHe7Lo CibOino40Vv1gcL9uSTKbuYQmZptO22KUFcL+8JBmxPCFD0mqR9TCpl25yTMeVWpWcCO +Dgh9VEAWD+MrIXTAdY39O2OLaJA2AP6vU3pGjQ18J8ScvwkDR4ZoZV+Wg11QQW0fO3V Hqfw== X-Received: by 10.69.15.2 with SMTP id fk2mr41628371pbd.123.1401243491934; Tue, 27 May 2014 19:18:11 -0700 (PDT) Received: from [192.168.178.23] (178.200.69.111.dynamic.snap.net.nz. [111.69.200.178]) by mx.google.com with ESMTPSA id ck10sm81280977pac.0.2014.05.27.19.18.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 19:18:11 -0700 (PDT) Message-ID: <53854765.10403@gmail.com> Date: Wed, 28 May 2014 14:18:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <8D3D17ACE214DC429325B2B98F3AE712076C6631F9@MX15A.corp.emc.com> <5385294C.1030008@isi.edu> In-Reply-To: <5385294C.1030008@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/85ix14H0L1l9LNMejqadCzNegjM Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] port scarcity - WGLC for draft-ietf-tsvwg-port-use-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 02:18:17 -0000 On 28/05/2014 12:09, Joe Touch wrote: > > > On 5/27/2014 5:04 PM, Black, David wrote: >> Joe, >> >> >> >>>> But, regardless, given that you agree that there is no evidence for the >>>> scarcity, the whole reason for this document seems to fall apart. >>> >>> Scarcity is a relative measure. There are only 16 bits of port space, >>> and yes, it's only 11% used. But we've turned away dozens of requests >>> for 10s-100s of ports, and cut a large number of requests for multiple >>> ports down to one or two. >> >> Are these out-of-line requests (mostly non-IETF, if I understand >> correctly) >> the primary motivation for the scarcity discussion? > > Yes. > >> If so, could the scarcity discussion be somewhat more focused on requests >> that are clearly asking for entirely too many ports? It feels like >> one or >> two at a time is not a major cause for concern, but I clearly >> understand the >> problems with requests for 10s-100s. > > That's true, but it's also the case that a lot of applicants request > ports that aren't needed at all. We don't recommend against any new > protocol; we just ask whether existing services have been considered, > and encourage designs that are easier to manage and debug (i.e., using a > single port rather than one for each component of a complex system). > >> RFC 6335 already says (section 7.2): >> >> o IANA strives to assign only one assigned port number per service >> or application. >> >> [Note on security snipped - belongs in other thread.] >> >> o IANA strives to assign only one assigned port number for all >> variants of a service (e.g., for updated versions of a service). >> >> Perhaps a reminder of that plus documentation of the practices that >> the port reviewers are currently following would be a good starting >> point. > > That's basically how this document came into being, FWIW. It's certainly > useful to point back to this advice to link together the two docs better. As Joe said on a different sub-thread > Scarce is relative, of course. Right now I count 5847 TCP and 5570 UDP numbers, but the total range is 16 bits, and that's not considered a large range overall. Indeed. These are a *significant* fraction of 49151, so even if a naive extrapolation suggests 85 years to run, I think it would be irresponsible not to apply prudent stewardship. That will be more effective if we publish design advice as well as rules. (The Abstract and Introduction could usefully point out that this draft augments the advice already given in RFC 6335). Brian From nobody Tue May 27 23:03:08 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DB81A034D for ; Tue, 27 May 2014 23:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRynIUun4T-1 for ; Tue, 27 May 2014 23:03:04 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159341A0343 for ; Tue, 27 May 2014 23:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6207; q=dns/txt; s=iport; t=1401256981; x=1402466581; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=KR01PI9CH8NXbfol/dYIZq3ujT4YoStf9QNgqBtN5Wg=; b=Ke1+ZQZGcPR48DCH0dYcSggv4VFt5h1hhe8ujCkmmgrvUhTOt4COIHrb 1CqOmehacZRP5tPJDDrJHfBt8J48jekd7PP+bnnIeeiybl/kB5H9swFqi Dz8H3Mg9y1tLhcgml6ETQE/ITKADAFHV9MdgHyKrLcRb6h3fVHq3Vgt6s o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEADN7hVOtJssW/2dsb2JhbABZhxy/SAGBIHSCJQEBAQMBI0gNARAJAhIGCRYLAgIJAwIBAgE3DgYNAQcBAYg2CJRonCCkTxeOUgeCdYFLAQOZdJMngzo7 X-IronPort-AV: E=Sophos; i="4.98,925,1392163200"; d="scan'208,217"; a="65739719" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 28 May 2014 06:02:59 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.201.197]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4S62xl6029755; Wed, 28 May 2014 06:02:59 GMT Message-ID: <53857C12.1060000@cisco.com> Date: Wed, 28 May 2014 08:02:58 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Hoffman , "Black, David" References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C66303C@MX15A.corp.emc.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060502000009030508050001" Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/4uJhdvgfMINbM9EqVaSHXXSCH9M Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 06:03:06 -0000 This is a multi-part message in MIME format. --------------060502000009030508050001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, On 5/27/14, 6:17 PM, Paul Hoffman wrote: > > None, really. Most new protocols that need one or more ports are > pretty different than what has come before them. It is the > responsibility of the WGs to know the history of protocol design in > their field. Any guidance will inherently be opinionated. For example, > many people in the Apps area think FTP is a great example of the right > way to do ports, and many people in the Apps area think that it is a > great example of how to do it wrong. I am sure they are the miniscule exception for very practical reasons. I would say that each of the expert reviewers has a bit of a catalog of what to expect in requests for justifications, and we know where the arguments will usually lead. Some of this has now been codified in 6335 (discovery and versioning are examples). > > It might be useful for someone to try to collect a large body of > examples of port multiplexing and multiple port use, but only as long > as it stays unopinionated. Neither Joe nor I would be good candidate > editors for that. Any time a protocol supports more than one operation it is an example of multiplexing, and so the question becomes, “How disparate are those operations?” THAT, I'm afraid, is a value judgement, because the answer is often tied to an application architecture and not specifically to a network service. And there I agree with you that we as port reviewers have to be careful about our judgment versus that of those who are doing the coding. What is reasonable to do, and what we have been doing, is asking the question and seeing that the applicant has at least thought through the answer. A lot of the port reviewer job is doing just that- asking good questions. What is obvious to us is often not obvious to the applicant. I was reminded of this just recently by Joe when an applicant applied for a port, and it turned out they had a port assigned that had a reasonable description but was not in fact deployed. I had simply assumed they had deployed it. Doh. We got a free port back. Anyway, my point is that Joe's writing this draft from a wealth of experience. This having been said, I'll have my own comments on this draft in a separate note. Eliot --------------060502000009030508050001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,


On 5/27/14, 6:17 PM, Paul Hoffman wrote:

None, really. Most new protocols that need one or more ports are pretty different than what has come before them. It is the responsibility of the WGs to know the history of protocol design in their field. Any guidance will inherently be opinionated. For example, many people in the Apps area think FTP is a great example of the right way to do ports, and many people in the Apps area think that it is a great example of how to do it wrong.

I am sure they are the miniscule exception for very practical reasons.  I would say that each of the expert reviewers has a bit of a catalog of what to expect in requests for justifications, and we know where the arguments will usually lead.  Some of this has now been codified in 6335 (discovery and versioning are examples).


It might be useful for someone to try to collect a large body of examples of port multiplexing and multiple port use, but only as long as it stays unopinionated. Neither Joe nor I would be good candidate editors for that.

Any time a protocol supports more than one operation it is an example of multiplexing, and so the question becomes, “How disparate are those operations?”  THAT, I'm afraid, is a value judgement, because the answer is often tied to an application architecture and not specifically to a network service.  And there I agree with you that we as port reviewers have to be careful about our judgment versus that of those who are doing the coding.  What is reasonable to do, and what we have been doing, is asking the question and seeing that the applicant has at least thought through the answer.  A lot of the port reviewer job is doing just that- asking good questions.  What is obvious to us is often not obvious to the applicant.  I was reminded of this just recently by Joe when an applicant applied for a port, and it turned out they had a port assigned that had a reasonable description but was not in fact deployed.  I had simply assumed they had deployed it.  Doh.  We got a free port back.

Anyway, my point is that Joe's writing this draft from a wealth of experience.  This having been said, I'll have my own comments on this draft in a separate note.

Eliot


--------------060502000009030508050001-- From nobody Tue May 27 23:33:42 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9221E1A0546 for ; Tue, 27 May 2014 23:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2AHxWkA8xIb for ; Tue, 27 May 2014 23:33:38 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF971A0380 for ; Tue, 27 May 2014 23:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3617; q=dns/txt; s=iport; t=1401258814; x=1402468414; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=rru2HzUD9UMr2Y7K/lCE2M3rXuU2CeU3TTPXL3I/v7w=; b=YEY31ZjcJ+z13icJgJqgZtckZBOKLTmSYNPt1ZzKzGGPiLnvbcM548J1 qpB/pBeTM674cxUrMql5BnUqQgaKC8QwDqb1odZZ30L3PCKvWKAR1vHf0 gtTxm1qvkUHUJRDO7ed7qc49x2u9v2evDrfWjNJsGAl6RXvJHoc4yIvHQ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAPyBhVOtJssW/2dsb2JhbABZDoNLg0O/SAGBIXSCJQEBAQMBIw8BSwsLEggCBQwVAgIPAjgOBgEMCAEBiDYIsQOkUBeBKo0vCoJrgUsBA5l0kyeCeEI7 X-IronPort-AV: E=Sophos;i="4.98,926,1392163200"; d="scan'208";a="61000080" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 28 May 2014 06:33:32 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.201.197]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s4S6XWaB015582; Wed, 28 May 2014 06:33:32 GMT Message-ID: <5385833C.20505@cisco.com> Date: Wed, 28 May 2014 08:33:32 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, Joe Touch References: <537D9AC4.80602@erg.abdn.ac.uk> In-Reply-To: <537D9AC4.80602@erg.abdn.ac.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/t91g-dHvHjGhkIXX4ZTKLGctyDk Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 06:33:39 -0000 Dear Joe & TSVWG, I have the following comments about draft-ietf-tsvwg-port-use-04. Buried in this review is a question regarding HTTP in particular that IMHO both this WG and the apps area needs to seriously consider. When reviewing this document, I asked the question, “Does this text help me provide me guidance about how to design my services?” As such, while it's a very interesting history, I find that Section 3 fails that test. I am generally not a fan of repeating information in multiple documents, but if we are going to list port ranges, I would request that we indicate the authoritative source, which is RFC 6335 Section 6. The IETF is the policy authority for this information, not IANA. The following text in Section 6 of the draft needs serious review: > Others have noted "think twice about modifying TCP, then don't" > [RFC1263]. In this case, similar advice might be: > > o Think twice before asking for an assigned port, then try not > to. > > o If more than one port is desired, consider revising the > architecture until only one is needed, or, preferably, none. Developers SHOULD request ports to differentiate their services. The question is how many ports do they need to do that. Therefore, the analogy used to RFC1263 is inappropriate. In Section 7.1: > New services should support security or should consider > optional security. A new service should not need a port for an > insecure version; at best, this would be a performance issue > (see the first bullet), and at worst this presents a new > vulnerability. We should be considering a stronger statement than this with normative language that is in line with IETF consensus as documented in RFC 7258. But we have to be careful to not chase off applicants such that they squat or inappropriately warp their architecture. Therefore, I suggest phrasing that is similar to what is found in RFC 7258. Let me suggest two questions to be asked. The first comes right out of the RFC: > Is pervasive monitoring relevant to this work and if so, how has it > been considered? The second is more general: How have security considerations been taken into account? And throw a MUST around at least being able to answer those questions. Reviewers can then use their judgment as to the validity of the answers. Going to the next paragraph: > > o Ports are not for indicating different service versions. > Version differentiation should be handled in-band, e.g., using > a version number at the beginning of a connection or > transaction. This may not be possible with legacy assignments, > but all new assignments should incorporate support for version > indication. This point requires expansion. We are currently seeing a number of requests around HTTP in particular in which there is absolutely no difference between protocol being run on port 80 and what is being requested. The reason for the request, however, is that the applicant is offering some sort of server management function. The above guidance says that hosts should multiplex this function on port 80. As a matter of architecture, we need to decide what the real guidance should be in this case. Should it be require that web servers support such multiplexing? We certainly have the means through .well-known, for instance. And we have seen similar issues with other popular protocols. MySQL is a big hit at the moment. Eliot From nobody Wed May 28 08:20:00 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B561A09F1 for ; Wed, 28 May 2014 08:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYb4XWQvOhKf for ; Wed, 28 May 2014 08:18:25 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDD01A011D for ; Wed, 28 May 2014 08:18:21 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 28 May 2014 08:18:17 -0700 From: Pearl Liang To: Eliot Lear , "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , Joe Touch Date: Wed, 28 May 2014 08:18:16 -0700 Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) Thread-Index: Ac96iAzu0sIzzQaFQt+G2H47GaZXUw== Message-ID: References: <537D9AC4.80602@erg.abdn.ac.uk> <5385833C.20505@cisco.com> In-Reply-To: <5385833C.20505@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3484109897_11513130" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/F0w6_pNOgq4rGs4K-cvMym6sOfk X-Mailman-Approved-At: Wed, 28 May 2014 08:19:58 -0700 Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 15:18:27 -0000 --B_3484109897_11513130 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, I was thinking about that too - can we expand the texts regarding applications use the generic or redesigned HTTP in this document? ~pl On 5/27/14 11:33 PM, "Eliot Lear" wrote: >Dear Joe & TSVWG, > >I have the following comments about draft-ietf-tsvwg-port-use-04. >Buried in this review is a question regarding HTTP in particular that >IMHO both this WG and the apps area needs to seriously consider. > >When reviewing this document, I asked the question, =B3Does this text help >me provide me guidance about how to design my services?=B2 As such, while >it's a very interesting history, I find that Section 3 fails that test. > >I am generally not a fan of repeating information in multiple documents, >but if we are going to list port ranges, I would request that we >indicate the authoritative source, which is RFC 6335 Section 6. The >IETF is the policy authority for this information, not IANA. > >The following text in Section 6 of the draft needs serious review: > >> Others have noted "think twice about modifying TCP, then don't" >> [RFC1263]. In this case, similar advice might be: >> >> o Think twice before asking for an assigned port, then try not >> to. >> >> o If more than one port is desired, consider revising the >> architecture until only one is needed, or, preferably, none. > >Developers SHOULD request ports to differentiate their services. The >question is how many ports do they need to do that. Therefore, the >analogy used to RFC1263 is inappropriate. > >In Section 7.1: > > >> New services should support security or should consider >> optional security. A new service should not need a port for an >> insecure version; at best, this would be a performance issue >> (see the first bullet), and at worst this presents a new >> vulnerability. > >We should be considering a stronger statement than this with normative >language that is in line with IETF consensus as documented in RFC 7258. >But we have to be careful to not chase off applicants such that they >squat or inappropriately warp their architecture. Therefore, I suggest >phrasing that is similar to what is found in RFC 7258. Let me suggest >two questions to be asked. The first comes right out of the RFC: > >> Is pervasive monitoring relevant to this work and if so, how has it >> been considered? > >The second is more general: > >How have security considerations been taken into account? > >And throw a MUST around at least being able to answer those questions. >Reviewers can then use their judgment as to the validity of the answers. > >Going to the next paragraph: > >> >> o Ports are not for indicating different service versions. >> Version differentiation should be handled in-band, e.g., using >> a version number at the beginning of a connection or >> transaction. This may not be possible with legacy assignments, >> but all new assignments should incorporate support for version >> indication. > >This point requires expansion. We are currently seeing a number of >requests around HTTP in particular in which there is absolutely no >difference between protocol being run on port 80 and what is being >requested. The reason for the request, however, is that the applicant >is offering some sort of server management function. The above guidance >says that hosts should multiplex this function on port 80. As a matter >of architecture, we need to decide what the real guidance should be in >this case. Should it be require that web servers support such >multiplexing? We certainly have the means through .well-known, for >instance. > >And we have seen similar issues with other popular protocols. MySQL is >a big hit at the moment. > >Eliot > --B_3484109897_11513130 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITtQYJKoZIhvcNAQcCoIITpjCCE6ICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYEwggbxMIIF2aADAgECAhAMLkv5nQhscPoo31D/rbC0MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGeMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczENMAsGA1UECxMESUFOQTEUMBIG A1UEAxMLUGVhcmwgTGlhbmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8XGvf FNfD+o9rdi4/smO4ca3Km10vSC7ACMwISGnnCXV06iC2QCI6J+fFEh0aEVqmr2QkpkYNG9Tz FQogvKVdm/flqOdCYtOCiOyfGTyeWm9B5NTvwdLjZi7q6mTKGUKrsU/y9taKDvQEUL+oCcFS 4hYHeJ/Gp58awDUYzxeqeX9b4apULEqtv+gqVy4pdcAnuMYBEpxB6ks5KqG1xw4yL3kfA8qd PYIpQKIBW5yDsm/q83mvACBwnitLvdloFz+18HqIJiT5gHNMfj9zbvTC2EF/KrsOu3yyl7oq 4iq5FG3ukw8jVuJ4lByEnpCfPoRO4b5jaMl6vqlhL5edYBulAgMBAAGjggNkMIIDYDAfBgNV HSMEGDAWgBQVABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUV/t8ik0UQWj04TEFh1kc pPW8nxkwIAYDVR0RBBkwF4EVcGVhcmwubGlhbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0 cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSG Mmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIB xQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDov L3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOCAQEAqpa7gV+8c/xXFcaU2o6GN2faOkqhsGy/ItSa17RkOvYWDldiUfv0 3UMKQJWRE6UidyvfpzmJzmZCcD3bXRhnrEuByEb2lOvfT0lgUEiBTt7k5gxvNPGqUOBY4qk9 N6i7s88faHXs+daugs2INpkuAIF5Zo282bsZIynL3S74tIx9VTU9cJsYrigKbm/1tdhfMc85 rclJITwfBG3c4pkxWNXC6kG70HZ2EPonK8lJFPKzC3FqDh1XMdEIgzs9MPFn+O+cNkV4m1yU 5vcv5SlRK5PCjo84ompBEIDsDBWDCWm+WfojQDLG6/p46ScSi/gQgdxrn6L+HsifWT4/yt1k kDCCBs0wggW1oAMCAQICEAb9+QOWA63qAArrPye7uhswDQYJKoZIhvcNAQEFBQAwZTELMAkG A1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAw MDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNz dXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKV pYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2w cTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj /qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26C cz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X 8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDejCCA3YwDgYDVR0PAQH/ BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUF BwMEBggrBgEFBQcDCDCCAdIGA1UdIASCAckwggHFMIIBtAYKYIZIAYb9bAABBDCCAaQwOgYI KwYBBQUHAgEWLmh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5o dG0wggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBj AGMAZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQ AC8AQwBQAFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAg AEEAZwByAGUAZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBp AGwAaQB0AHkAIABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABo AGUAcgBlAGkAbgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wCwYJYIZIAYb9bAMVMBIG A1UdEwEB/wQIMAYBAf8CAQAweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcnQwgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0OBBYEFBUAEisTmLKZB+0e36K+Vw0rZwLNMB8GA1UdIwQYMBaAFEXroq/0ksuC MS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQBGUD7Jtygkpzgdtlspr1LPUukxR6tW XHvVDQtBs+/sdR90OPKyXGGinJXDUOSCuSPRujqGcq04eKx1XRcXNHJHhZRW0eu7NoR3zCSl 8wQZVann4+erYs37iy2QwsDStZS9Xk+xBdIOPRqpFFumhjFiqKgz5Js5p8T1zh14dpQlc+Qq q8+cdkvtX8JLFuRLcEwAiR78xXm8TBJX/l/hHrwCXaj++wc4Tw3GXZG5D2dFzdaD7eeSDY2x aYxP+1ngIw/Sqq4AfO6cQg7PkdcntxbuD8O9fAqg7iwIVYUiuOsYGk38KiGtSTGDR5V3cdyx G0tLHBCcdxTBnU8vWpUIKRAmMIIDtzCCAp+gAwIBAgIQDOfg5RfYRv6P5WD8G/AwOTANBgkq hkiG9w0BAQUFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJv b3QgQ0EwHhcNMDYxMTEwMDAwMDAwWhcNMzExMTEwMDAwMDAwWjBlMQswCQYDVQQGEwJVUzEV MBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYD VQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCtDhXO5EOAXLGH87dg+XESpa7cJpSIqvTO9SA5KFhgDPiA2qkVlTJhPLWx KISKityfCgyDF3qPkKyK53lTXDGEKvYPmDI2dsze3Tyoou9q+yHyUmHfnyDXH+Kx2f4YZNIS W1/5WBg1vEfNoTb5a3/UsDg+wRvDjDPZ2C8Y/igPs6eD1sNuRMBhNZYW/lmci3Zt1/GiSw0r /wty2p5g0I6QNcZ4VYcgoc/lbQrISXwxmDNsIumH0DJaoroTghHtORedmTpyoeb6pNnVFzF1 roV9Iq4/AUaG9ih5yLHa5FcXxH4cDrC0kqZWs72yl+2qp/C3xag/lRbQ/6GW6whfGHdPAgMB AAGjYzBhMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRF66Kv 9JLLgjEtUYunpyGd823IDzAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkq hkiG9w0BAQUFAAOCAQEAog683+Lt8ONyc3pklL/3cmbYMuRCdWKuh+vy1dneVrOfzM4UKLkN l2BcEkxY5NM9g0lFWJc1aRqoR+pWxnmrEthngYTffwk8lOa4JiwgvT2zKIn3X/8i4peEH+ll 74fg38FnSbNd67IJKusm7Xi+fT8r87cmNW1fiQG2SVufAQWbqz0lwcy2f8Lxb4bG+mRo64Et lOtCt/qMHt1i8b5QZ7dsvfPxH2sMNgcWfzd8qVttevESRmCD1ycEvkvOl77DZypoEd+A5wwz Zr8TDRRu838fYxAe+o0bJW1sj6W3YQGx0qMmoRBxna3iw/nDmVG3KwcIzi7mULKn+gpFL6Lw 8jGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZ MBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJ RCBDQS0xAhAMLkv5nQhscPoo31D/rbC0MAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU HLm7hOcyzOYlyt72ID0Ps6UKmoAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNTI4MTUxODE3WjANBgkqhkiG9w0BAQEFAASCAQAUaVxCP26D0Rv1aGfr 3A1oaiBIKCzCWA8cXgl6BZTLrWGiAruDr1PJkPUTl0q64JXJicTeF8406AV4TsfRWysjIeap oCrS1vcLl+FTn1B+7M6J3DBPWX0doUdi1Le+wgLs95/NmKir0jzZfjuuYOMH9TPmq9bh82AW zN9pIGktOif1f2YJMJXRE5swZL9TuVYk4CSe42ZDd6U8hhcy4n+CF/FA5sAyRtkJPPbWk9cY NVIfv/Pf5UHsv5zjTcUUg98YF72D8/sliCvOcZAMcuo7xxJAvB+Qqy05/eu7o5VmHtcXt2vd KMNqU6KLY9e2614WSB/en9rzd/0Fkjo/+GPE --B_3484109897_11513130-- From nobody Wed May 28 09:03:19 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E511A034B for ; Wed, 28 May 2014 09:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsVXsxKtthDM for ; Wed, 28 May 2014 09:03:15 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5181A0178 for ; Wed, 28 May 2014 09:03:15 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 28 May 2014 09:03:11 -0700 From: Pearl Liang To: Joe Touch , "Eggert, Lars" Date: Wed, 28 May 2014 09:03:12 -0700 Thread-Topic: [tsvwg] New Version Notification for draft-ietf-tsvwg-port-use-04.txt Thread-Index: Ac96jlLCTeby5dXVSLGY5qNaqUcFYA== Message-ID: References: <8EA0C0EA-7C81-41ED-85BA-4E9B8F690B77@netapp.com> <0EEE0BBC-C9D0-43F8-A162-0278F6B8173D@netapp.com> <5384BAFA.106@isi.edu> In-Reply-To: <5384BAFA.106@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3484112592_11723306" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/t9StnVmdHDjaK1_ZF8KyAZ2glWk Cc: tsvwg Subject: Re: [tsvwg] New Version Notification for draft-ietf-tsvwg-port-use-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:03:17 -0000 --B_3484112592_11723306 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 5/27/14 9:19 AM, "Joe Touch" wrote: >HI, all, > >First, I do need to do a scrub to make sure that this doc's core (not >the history part) ends up referring to "service names" and "service >numbers" as per RFC 6335. That said... > >On 5/26/2014 11:30 PM, Eggert, Lars wrote: >> Hi, >> >> On 2014-5-27, at 0:48, Pearl Liang wrote: >>> >>> - does the word 'SRV' apply to all service names regardless one with a >>> port number or without it? > >As Lars noted, all service names can be used in the DNS SRV mechanism, >however this doc ought to discuss the relationship in more detail... It'll be useful. > >>> - When and how a user decide to add a port number with the DNS SRV >>>service >>> name? In another word, why can a user simply register an DNS SRV >>>service >>> name without a port number? > >Service names assigned without a service number are useful only for >indices such as DNS SRV or mechanisms like TCP port names. The service >is assigned a dynamic port number and that number is advertised to >others via such methods. So, would it be possible to add a user port number to a registered SRV service name down the road at some point? ~pl > >Service names intended for DNS SRV may also include registration of >other SRV parameters (indicated as {key, value} pairs in associated TXT >records) - that's why IANA asks specifically about SRV use. > >Use in SRV records isn't strictly related to whether a service name has >an associated assigned port number; even though typical use would be >without an assigned number, it still might be useful to indicate SRV use >in the application for service names primarily used as SRVs because such >assigned numbers help with firewall traversal *and* SRV use could >indicate additional service parameter in TXT records. > >Joe > > > --B_3484112592_11723306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITtQYJKoZIhvcNAQcCoIITpjCCE6ICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYEwggbxMIIF2aADAgECAhAMLkv5nQhscPoo31D/rbC0MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGeMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczENMAsGA1UECxMESUFOQTEUMBIG A1UEAxMLUGVhcmwgTGlhbmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8XGvf FNfD+o9rdi4/smO4ca3Km10vSC7ACMwISGnnCXV06iC2QCI6J+fFEh0aEVqmr2QkpkYNG9Tz FQogvKVdm/flqOdCYtOCiOyfGTyeWm9B5NTvwdLjZi7q6mTKGUKrsU/y9taKDvQEUL+oCcFS 4hYHeJ/Gp58awDUYzxeqeX9b4apULEqtv+gqVy4pdcAnuMYBEpxB6ks5KqG1xw4yL3kfA8qd PYIpQKIBW5yDsm/q83mvACBwnitLvdloFz+18HqIJiT5gHNMfj9zbvTC2EF/KrsOu3yyl7oq 4iq5FG3ukw8jVuJ4lByEnpCfPoRO4b5jaMl6vqlhL5edYBulAgMBAAGjggNkMIIDYDAfBgNV HSMEGDAWgBQVABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUV/t8ik0UQWj04TEFh1kc pPW8nxkwIAYDVR0RBBkwF4EVcGVhcmwubGlhbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0 cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSG Mmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIB xQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDov L3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOCAQEAqpa7gV+8c/xXFcaU2o6GN2faOkqhsGy/ItSa17RkOvYWDldiUfv0 3UMKQJWRE6UidyvfpzmJzmZCcD3bXRhnrEuByEb2lOvfT0lgUEiBTt7k5gxvNPGqUOBY4qk9 N6i7s88faHXs+daugs2INpkuAIF5Zo282bsZIynL3S74tIx9VTU9cJsYrigKbm/1tdhfMc85 rclJITwfBG3c4pkxWNXC6kG70HZ2EPonK8lJFPKzC3FqDh1XMdEIgzs9MPFn+O+cNkV4m1yU 5vcv5SlRK5PCjo84ompBEIDsDBWDCWm+WfojQDLG6/p46ScSi/gQgdxrn6L+HsifWT4/yt1k kDCCBs0wggW1oAMCAQICEAb9+QOWA63qAArrPye7uhswDQYJKoZIhvcNAQEFBQAwZTELMAkG A1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAw MDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNz dXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKV pYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2w cTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj /qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26C cz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X 8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDejCCA3YwDgYDVR0PAQH/ BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUF BwMEBggrBgEFBQcDCDCCAdIGA1UdIASCAckwggHFMIIBtAYKYIZIAYb9bAABBDCCAaQwOgYI KwYBBQUHAgEWLmh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5o dG0wggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBj AGMAZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQ AC8AQwBQAFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAg AEEAZwByAGUAZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBp AGwAaQB0AHkAIABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABo AGUAcgBlAGkAbgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wCwYJYIZIAYb9bAMVMBIG A1UdEwEB/wQIMAYBAf8CAQAweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcnQwgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0OBBYEFBUAEisTmLKZB+0e36K+Vw0rZwLNMB8GA1UdIwQYMBaAFEXroq/0ksuC MS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQBGUD7Jtygkpzgdtlspr1LPUukxR6tW XHvVDQtBs+/sdR90OPKyXGGinJXDUOSCuSPRujqGcq04eKx1XRcXNHJHhZRW0eu7NoR3zCSl 8wQZVann4+erYs37iy2QwsDStZS9Xk+xBdIOPRqpFFumhjFiqKgz5Js5p8T1zh14dpQlc+Qq q8+cdkvtX8JLFuRLcEwAiR78xXm8TBJX/l/hHrwCXaj++wc4Tw3GXZG5D2dFzdaD7eeSDY2x aYxP+1ngIw/Sqq4AfO6cQg7PkdcntxbuD8O9fAqg7iwIVYUiuOsYGk38KiGtSTGDR5V3cdyx G0tLHBCcdxTBnU8vWpUIKRAmMIIDtzCCAp+gAwIBAgIQDOfg5RfYRv6P5WD8G/AwOTANBgkq hkiG9w0BAQUFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJv b3QgQ0EwHhcNMDYxMTEwMDAwMDAwWhcNMzExMTEwMDAwMDAwWjBlMQswCQYDVQQGEwJVUzEV MBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYD VQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCtDhXO5EOAXLGH87dg+XESpa7cJpSIqvTO9SA5KFhgDPiA2qkVlTJhPLWx KISKityfCgyDF3qPkKyK53lTXDGEKvYPmDI2dsze3Tyoou9q+yHyUmHfnyDXH+Kx2f4YZNIS W1/5WBg1vEfNoTb5a3/UsDg+wRvDjDPZ2C8Y/igPs6eD1sNuRMBhNZYW/lmci3Zt1/GiSw0r /wty2p5g0I6QNcZ4VYcgoc/lbQrISXwxmDNsIumH0DJaoroTghHtORedmTpyoeb6pNnVFzF1 roV9Iq4/AUaG9ih5yLHa5FcXxH4cDrC0kqZWs72yl+2qp/C3xag/lRbQ/6GW6whfGHdPAgMB AAGjYzBhMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRF66Kv 9JLLgjEtUYunpyGd823IDzAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkq hkiG9w0BAQUFAAOCAQEAog683+Lt8ONyc3pklL/3cmbYMuRCdWKuh+vy1dneVrOfzM4UKLkN l2BcEkxY5NM9g0lFWJc1aRqoR+pWxnmrEthngYTffwk8lOa4JiwgvT2zKIn3X/8i4peEH+ll 74fg38FnSbNd67IJKusm7Xi+fT8r87cmNW1fiQG2SVufAQWbqz0lwcy2f8Lxb4bG+mRo64Et lOtCt/qMHt1i8b5QZ7dsvfPxH2sMNgcWfzd8qVttevESRmCD1ycEvkvOl77DZypoEd+A5wwz Zr8TDRRu838fYxAe+o0bJW1sj6W3YQGx0qMmoRBxna3iw/nDmVG3KwcIzi7mULKn+gpFL6Lw 8jGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZ MBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJ RCBDQS0xAhAMLkv5nQhscPoo31D/rbC0MAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU IJ37i0AYLFZ8YhZZwfLg7yX8N1wwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNTI4MTYwMzEyWjANBgkqhkiG9w0BAQEFAASCAQC3SNozkded3eVFrYHh p6+/z2FZG93LvAWC3JTE5vBJwt+hPmCxy0+fTYFuvr30M7F7Av8A6SRAFvWE+L+a8PpZIy3n 6YMHqdPEOhNzzV6xvM/tTCaIAD3ByEqFhx14j4tTf5sN6n0rV/og/+vimfW+cZwRd0W6hCID BZ2UozyLkphvwDuGiWQMgscl6S5+JIUaGeJZPYnD143PXEwAiLmXOvtEOYeD3XTS8i8ceTLO 5g2aijbsZp8JyYeYPff4wI7lkOlH9JLsA4JznL/KMOC/Ipgq/jNVg3HCftjtQOGA6yPV1LUU fCepTI3FX2HlUH6LTwmREKjO7oNepJcrDyTk --B_3484112592_11723306-- From nobody Wed May 28 09:32:34 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D332B1A0366 for ; Wed, 28 May 2014 09:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-leFGwERpgf for ; Wed, 28 May 2014 09:32:30 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D2C1A0164 for ; Wed, 28 May 2014 09:32:29 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4SGWNgw025315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 May 2014 12:32:24 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s4SGWNgw025315 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401294744; bh=enyUfhtmMtYqG3cdZhSKunz/C94=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=V1r0tztQHjbhS/bHk8AG/zraj5/rZ3IsRvDzpBhmPBiM1Bpov8RE55kPbWYGa1ZST XQNBvWq8g5jQmq23vjBA8NnPBYOlF2w5XZH4jbUvENh41KJmTjkCoK0/ybRZ3FqSac X8pJnXsJXdA1ipoiZOCVh9fBRxW7cchaaolJtd44= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s4SGWNgw025315 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Wed, 28 May 2014 12:32:16 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4SGWFn5016131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 May 2014 12:32:16 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub33.corp.emc.com ([::1]) with mapi; Wed, 28 May 2014 12:32:15 -0400 From: "Black, David" To: Joe Touch , Paul Hoffman Date: Wed, 28 May 2014 12:32:14 -0400 Thread-Topic: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) Thread-Index: Ac96GIyN3KmxOBYaQUWCQQo5l0ncRAAZQE7w Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C66334F@MX15A.corp.emc.com> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C663209@MX15A.corp.emc.com> <53854308.8020705@isi.edu> In-Reply-To: <53854308.8020705@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/7C87X_QOM8qgeq0T67v-9GFViDY Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:32:33 -0000 PFdHIGNoYWlyIGhhdCBPRkY+DQoNCj4gPiAJLSBzaG91bGQgYSB1c2VyIHJlcXVlc3QgdHdvIHBv cnRzIGZvciBhIG5ldyBzZXJ2aWNlLCBvbmUNCj4gPiAJc2VjdXJlIGFuZCBvbmUgaW5zZWN1cmU/ DQo+ID4NCj4gPiBJIHN1c3BlY3QgdGhhdCB0aGUgYWR2aWNlIGZvciB0aGUgdGhpcyBvbmUgaXMg bGlrZWx5IHRvIGJlIGEgbG9uZw0KPiA+IHZlcnNpb24gb2YgIml0IGRlcGVuZHMiIGluIHByYWN0 aWNlLg0KPiA+DQo+ID4gCQlJTU8sIHRoZSBzZWN1cmUgcG9ydCBpcyBlYXN5LCBpZiBvdGhlcndp c2UNCj4gPiAJCXdhcnJhbnRlZCAobm90IGEgZHVwbGljYXRlIG9mIGV4aXN0aW5nIHNlcnZpY2Us IGUuZy4pLA0KPiA+IAkJYnV0IHRoZSBpbnNlY3VyZSBvbmUgc2ltaWxhcmx5IGNyZWF0ZXMgYSBu ZXcNCj4gPiAJCXZ1bG5lcmFiaWxpdHksIGFuZCBhZ2FpbiBJIHdvdWxkIHNheSBTSE9VTEQgTk9U DQo+ID4gCQlyZXF1ZXN0IGEgbmV3IGluc2VjdXJlIHBvcnQNCj4gPg0KPiA+IEkgYWdyZWUgd2l0 aCB0aGUgc2VjdXJlIHBvcnQgYmVpbmcgZmluZSwgYnV0IEknbSBub3QgY29tZm9ydGFibGUNCj4g PiB3aXRoIGEgYmxhbmtldCAiU0hPVUxEIE5PVCIgcmVjb21tZW5kYXRpb24gZm9yIHRoZSBpbnNl Y3VyZSBwb3J0Lg0KPiA+DQo+ID4gSSB0aGluayB0aGlzIGRlcGVuZHMgb24gdGhlIGRldGFpbHMg b2YgdGhlIHByb3RvY29sLiAgSSdkIGRlZmluaXRlbHkNCj4gPiBzZXQgYW4gZXhwZWN0YXRpb24g dGhhdCBzb2xpZCBqdXN0aWZpY2F0aW9uIGZvciB0aGUgbmV3IGluc2VjdXJlDQo+ID4gcG9ydCB3 aWxsIGJlIGV4cGVjdGVkLCB3aXRoIHRoZSBhcHBsaWNhbnQgYmVpbmcgcmVzcG9uc2libGUgZm9y DQo+ID4ganVzdGlmeWluZyB3aHkgdXNlIG9mIHNlY3VyaXR5IGlzIG5vdCBtYW5kYXRvcnkgZm9y IHRoZSBwcm90b2NvbC4NCj4gPiBJZiB0aGF0IGp1c3RpZmljYXRpb24gbWFrZXMgdGhlIGNhc2Us IHRoZW4gdGhlIGZpcmV3YWxsIGNvbnRyb2wNCj4gPiByYXRpb25hbGUgKGJlbG93KSBkZWZpbml0 ZWx5IHNvdW5kcyByZWFzb25hYmxlLCBJTUhPLg0KPiANCj4gV2h5IGlzbid0IHRoYXQgYSBTSE9V TEQgTk9UPyBDZXJ0YWlubHkgYSBiaXQgbW9yZSB0ZXh0IGlzIGluIG9yZGVyLCBidXQNCj4gaXQg c2VlbXMgbGlrZSB3ZSdyZSBpbiBhZ3JlZW1lbnQgLSBkZWVwIGp1c3RpZmljYXRpb24gaXMgbmVl ZGVkLg0KDQpXZSdyZSBkZWFsaW5nIHdpdGggYSBwcm9jZXNzIGFzIG9wcG9zZWQgdG8gYSBwcm90 b2NvbCBoZXJlLCBzbyB0aGUgZnVuY3Rpb25hbGl0eQ0Kb2Ygc29tZSBmdXR1cmUgcHJvdG9jb2wg dGhhdCB3aWxsIGFzayBmb3IgcG9ydHMgaXMgdW5rbm93biB0byB1cyBhdCB0aGUgbW9tZW50Lg0K DQpJIHRoaW5rIEknbSBtb3N0bHkgbG9va2luZyBmb3Igc29tZSBncmFkYXRpb24gd3J0IHRoZSBv dGhlciBTSE9VTEQgTk9UOg0KDQo+ID4gCS0gZ2l2ZW4gYSBjdXJyZW50IHNlY3VyZSBhc3NpZ25t ZW50LCB3aGF0DQo+ID4gCWlmIGEgdXNlciByZXF1ZXN0cyBhIChuZXcpIHNlY29uZCBwb3J0IGZv ciBpbnNlY3VyZSBhY2Nlc3M/DQo+ID4NCj4gPiAJCWl0IHNlZW1zIGxpa2UgYSBTSE9VTEQgTk9U IHJlY29tbWVuZGF0aW9uDQo+ID4gCQlpcyBhcHByb3ByaWF0ZTsgdGhpcyBjcmVhdGVzIG5ldyB2 dWxuZXJhYmlsaXR5Ow0KPiA+DQo+ID4gSSBwcmVzdW1lIHRoYXQgdGhlIGxhdHRlciByZWNvbW1l bmRhdGlvbiBlbnZpc2lvbnMgYSBzY2VuYXJpbyB3aGVyZQ0KPiA+IHRoZSBzZWN1cmUgcG9ydCBo YXMgYmVlbiBkZXBsb3llZCBhbmQgdXNlZCBmb3IgYSBzaWduaWZpY2FudCBwZXJpb2QNCj4gPiBv ZiB0aW1lLg0KPiANCj4gWWVzLg0KDQpJTUhPLCB0aGF0ICJydW5uaW5nIGNvZGUiIGRlcGxveW1l bnQgYW5kIHVzZSBleHBlcmllbmNlIHByb3ZpZGVzIGEgc29saWQNCnN0cm9uZyBmb3VuZGF0aW9u IGZvciBhICJTSE9VTEQgTk9UIiBieSBjb21wYXJpc29uIHRvIHRoZSAibmV3IHJlcXVlc3QNCmZv ciB0d28gcG9ydHMiIGNhc2UsIHdoZXJlIGEgIlNIT1VMRCBOT1QiIHN0cmlrZXMgbWUgYXMgcHJl LWV2YWx1YXRpbmcNCnByb3RvY29sIGRlc2lnbiBkZWNpc2lvbnMsIHNpZ2h0IHVuc2VlbiwgZm9y IHByb3RvY29scyB0aGF0IG5vYm9keSdzDQpldmVuIHRob3VnaHQgb2YsIHlldC4NCg0KPiA+IEkg anVzdCBkb24ndCB0aGluayB0aGUgbGV2ZWwgb2YgcmVxdWlyZWQganVzdGlmaWNhdGlvbiBpcyBn b2luZw0KPiA+IHRvIHJpc2UgdG8gdGhhdCBzdWZmaWNpZW50IHRvIG92ZXJyaWRlIGEgIlNIT1VM RCBOT1QiIGZvciBldmVyeQ0KPiA+IHNpbmdsZSBwcm90b2NvbCBkZXNpZ24gdGhhdCB3ZSBoYXZl IHlldCB0byBlbnZpc2lvbi4gIEkgd2lzaCBteQ0KPiA+IGZvcmVzaWdodCB3YXMgMjAvMjAgOi0p Lg0KPiANCj4gRldJVywgdGhlcmUgYXJlbid0IGEgbG90IG9mIHByb3RvY29scyB0aGF0IGFzayBm b3Igc2VjdXJlIGFuZCBpbnNlY3VyZQ0KPiBhdCB0aGUgc2FtZSB0aW1lLiBUaG9zZSBjb21lIG1v c3RseSAtIGluY3JlZGlibHkgLSBmcm9tIElFVEYgV0dzLCB3aGVyZQ0KPiB0aGV5IGFwcGVhciB0 byBiZSAoSU1PIGJsaW5kbHkpIGZvbGxvd2luZyBwYXN0IHByYWN0aWNlLg0KDQpIZXJlIEkgYWdy ZWUgLSB1c2Ugb2YgIndlJ3ZlIGFsd2F5cyBkb25lIGl0IHRoYXQgd2F5IiBhcyBhIHJhdGlvbmFs ZSBTSE9VTEQNCmJlIHN0cm9uZ2x5IGRpc2NvdXJhZ2VkOyBiZXlvbmQgdGhhdCwgSSdkIHN1Z2dl c3QgcG9pbnRpbmcgb3V0IHRoYXQgcmVxdWVzdHMNCmZvciBib3RoIHBvcnRzIGFyZSB2aWV3ZWQg d2l0aCBzaWduaWZpY2FudCBza2VwdGljaXNtIGJlY2F1c2UgdGhhdCByZWFzb24NCmhhcyBiZWVu IHRoZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgbWFueSBvZiB0aGVtLiAgSXQgd291bGQgYWxzbyBo ZWxwIHRvIA0KYWRkIGRpc2N1c3Npb24gb2YgImp1c3RpZmllZCBpbiB0ZXJtcyBvZiBzZXJ2aWNl IHByb3ZpZGVkIjoNCg0KPiBNeSBrZXkgY29uY2VybiBpcyAid2h5IGlzIHRoZSBpbnNlY3VyZSBw b3J0IG5lZWRlZCI/IE1vc3Qgb2YgdGhlIHRpbWUNCj4gdGhlIGp1c3RpZmljYXRpb24gaXMgcHVy ZSBwZXJmb3JtYW5jZSAtIHJ1bm5pbmcgc2VjdXJpdHkgb24gdGhlIHNlcnZpY2UNCj4gd2lsbCBt YWtlIGl0IHRvbyBzbG93LCBhbmQgdGhpcyB3aWxsIGFsbG93IGZhc3RlciBwZXJmb3JtYW5jZSBp bnNpZGUgYW4NCj4gZW50ZXJwcmlzZS4gVGhhdCBtaWdodCBiZSB0cnVlLCBidXQgaXQgYWxzbyBu ZWVkcyB0byBiZSBqdXN0aWZpZWQgaW4NCj4gdGVybXMgb2YgdGhlIHNlcnZpY2UgYmVpbmcgcHJv dmlkZWQgLSB0aGF0IHRoaXMgaXMgYSBoaWdoLXRocm91Z2hwdXQgb3INCj4gaGlnaC10cmFuc2Fj dGlvbiBmcmVxdWVuY3kgc3lzdGVtIHRoYXQgbmVlZHMgaGlnaCBwZXJmb3JtYW5jZSBpbnNpZGUN Cj4gcHJvdGVjdGVkIGVudGVycHJpc2VzLg0KDQo8L1dHIGNoYWlyIGhhdCBPRkY+IA0KDQpUaGFu a3MsDQotLURhdmlkDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBK b2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPiBTZW50OiBUdWVzZGF5LCBNYXkgMjcs IDIwMTQgMTA6MDAgUE0NCj4gVG86IEJsYWNrLCBEYXZpZDsgUGF1bCBIb2ZmbWFuDQo+IENjOiB0 c3Z3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3RzdndnXSBhZGRpdGlvbmFsIHBvcnRzIGZv ciBzZWN1cml0eSAtIFJlOiBXR0xDIGZvciBkcmFmdC1pZXRmLQ0KPiB0c3Z3Zy1wb3J0LXVzZS0w NCAodG8gZW5kIDZ0aCBKdW5lKQ0KPiANCj4gDQo+IA0KPiBPbiA1LzI3LzIwMTQgNTo0MCBQTSwg QmxhY2ssIERhdmlkIHdyb3RlOg0KPiA+IEpvZSwNCj4gPg0KPiA+IDxXRyBjaGFpciBoYXQgT0ZG Pg0KPiA+DQo+ID4+IElmIHlvdSBkaXNhZ3JlZSB3aXRoIHRoZSBhbmFseXNpcywgeW91IHNob3Vs ZCBwcmVzZW50IGEgY291bnRlcmFyZ3VtZW50Lg0KPiA+DQo+ID4gT2ssIEknbGwgdHJ5IC4uLiA7 LSkuDQo+ID4NCj4gPiBJdCBtaWdodCBoZWxwIGlmIHRoaXMgaGFkIHNvbWV3aGF0IG1vcmUgb2Yg YSBmbGF2b3Igb2YgZG9jdW1lbnRpbmcgdGhlDQo+ID4gcmV2aWV3IGNyaXRlcmlhIHRoYXQgYXJl IGN1cnJlbnRseSB1c2VkLCBhbHRob3VnaCBJIGRvIHRoaW5rIGF0IGxlYXN0DQo+ID4gb25lICJT SE9VTEQgTk9UIiBpcyBsaWtlbHkgdG8gdHVybiB1cCBpbiB0aGUgZmluYWwgdGV4dC4NCj4gPg0K PiA+IEknZCBjZXJ0YWlubHkgbGlrZSB0byBzZWUgc29tZSBTZWN1cml0eSBBcmVhIGlucHV0IChh bmQgcHJvYmFibHkgYWxzbw0KPiA+IE9QUywgYXMgZmlyZXdhbGxzIHBsYXkgYSBwcm9taW5lbnQg cm9sZSksIGJ1dCBzcGVha2luZyBmb3IgbXlzZWxmLA0KPiA+IEkgdGhpbmsgb2ZmZXJpbmcgc2Vj dXJpdHkgYWR2aWNlIGlzIHdlbGwgd2l0aGluIHJlYXNvbiBoZXJlIC4uLg0KPiA+DQo+ID4gR29p bmcgYmFjayB0byB0aGUgdGhyZWUgc2NlbmFyaW9zIGF0IHRoZSBzdGFydCBvZiB0aGlzIHRocmVh ZCwgdGhlDQo+ID4gcHJvcG9zYWxzIGZvciB0aGUgZmlyc3QgdHdvIHNlZW0gcmVhc29uYWJsZSAo SU1ITyk6DQo+ID4NCj4gPiAJLSBnaXZlbiBhIGN1cnJlbnQgbm9uLXNlY3VyZSBhc3NpZ25tZW50 LCB3aGF0IGlmIGENCj4gPiAJdXNlciByZXF1ZXN0cyBhIChuZXcpIHNlY29uZCBwb3J0IGZvciBz ZWN1cmUgYWNjZXNzPw0KPiA+DQo+ID4gCQl0aGlzIGlzIGZpbmUsIGlmIG5vdCBhIGdvb2QgaWRl YTsNCj4gPg0KPiA+IAktIGdpdmVuIGEgY3VycmVudCBzZWN1cmUgYXNzaWdubWVudCwgd2hhdA0K PiA+IAlpZiBhIHVzZXIgcmVxdWVzdHMgYSAobmV3KSBzZWNvbmQgcG9ydCBmb3IgaW5zZWN1cmUg YWNjZXNzPw0KPiA+DQo+ID4gCQlpdCBzZWVtcyBsaWtlIGEgU0hPVUxEIE5PVCByZWNvbW1lbmRh dGlvbg0KPiA+IAkJaXMgYXBwcm9wcmlhdGU7IHRoaXMgY3JlYXRlcyBuZXcgdnVsbmVyYWJpbGl0 eTsNCj4gPg0KPiA+IEkgcHJlc3VtZSB0aGF0IHRoZSBsYXR0ZXIgcmVjb21tZW5kYXRpb24gZW52 aXNpb25zIGEgc2NlbmFyaW8gd2hlcmUNCj4gPiB0aGUgc2VjdXJlIHBvcnQgaGFzIGJlZW4gZGVw bG95ZWQgYW5kIHVzZWQgZm9yIGEgc2lnbmlmaWNhbnQgcGVyaW9kDQo+ID4gb2YgdGltZS4NCj4g DQo+IFllcy4NCj4gDQo+ID4gSW4gdGhhdCBjYXNlLCBJIHRoaW5rIGEgIlNIT1VMRCBOT1QiIGlz IG9rLCBhcyBJJ2Qgd2FudCB0bw0KPiA+IHNlZSBzb21lIGhlYXZ5LWR1dHkgc2VyaW91cyBqdXN0 aWZpY2F0aW9uIGZvciBhZGRpbmcgdGhlIGluc2VjdXJlDQo+ID4gcG9ydC4gIFRoZSBkcmFmdCBz aG91bGQgc3RhdGUgdGhhdCBwcmVzdW1wdGlvbiwgdGhvdWdoLCBhcyBkZXBsb3ltZW50DQo+ID4g ZGlmZmljdWx0aWVzL2V4cGVyaWVuY2UgbWlnaHQgcmVzdWx0IGluIHNvbWV0aGluZyBjbG9zZXIg dG8gdGhlIHRoaXJkDQo+ID4gc2NlbmFyaW8uDQo+IA0KPiBSaWdodCAtIHRoYXQncyB0aGUgcG9p bnQgb2YgdGhlIFNIT1VMRCBOT1QuIEl0J3Mgbm90IGEgTVVTVCBOT1QuIEl0IGp1c3QNCj4gbmVl ZHMgdmVyeSBoZWF2eSBqdXN0aWZpY2F0aW9uLg0KPiANCj4gPiAJLSBzaG91bGQgYSB1c2VyIHJl cXVlc3QgdHdvIHBvcnRzIGZvciBhIG5ldyBzZXJ2aWNlLCBvbmUNCj4gPiAJc2VjdXJlIGFuZCBv bmUgaW5zZWN1cmU/DQo+ID4NCj4gPiBJIHN1c3BlY3QgdGhhdCB0aGUgYWR2aWNlIGZvciB0aGUg dGhpcyBvbmUgaXMgbGlrZWx5IHRvIGJlIGEgbG9uZw0KPiA+IHZlcnNpb24gb2YgIml0IGRlcGVu ZHMiIGluIHByYWN0aWNlLg0KPiA+DQo+ID4gCQlJTU8sIHRoZSBzZWN1cmUgcG9ydCBpcyBlYXN5 LCBpZiBvdGhlcndpc2UNCj4gPiAJCXdhcnJhbnRlZCAobm90IGEgZHVwbGljYXRlIG9mIGV4aXN0 aW5nIHNlcnZpY2UsIGUuZy4pLA0KPiA+IAkJYnV0IHRoZSBpbnNlY3VyZSBvbmUgc2ltaWxhcmx5 IGNyZWF0ZXMgYSBuZXcNCj4gPiAJCXZ1bG5lcmFiaWxpdHksIGFuZCBhZ2FpbiBJIHdvdWxkIHNh eSBTSE9VTEQgTk9UDQo+ID4gCQlyZXF1ZXN0IGEgbmV3IGluc2VjdXJlIHBvcnQNCj4gPg0KPiA+ IEkgYWdyZWUgd2l0aCB0aGUgc2VjdXJlIHBvcnQgYmVpbmcgZmluZSwgYnV0IEknbSBub3QgY29t Zm9ydGFibGUNCj4gPiB3aXRoIGEgYmxhbmtldCAiU0hPVUxEIE5PVCIgcmVjb21tZW5kYXRpb24g Zm9yIHRoZSBpbnNlY3VyZSBwb3J0Lg0KPiA+DQo+ID4gSSB0aGluayB0aGlzIGRlcGVuZHMgb24g dGhlIGRldGFpbHMgb2YgdGhlIHByb3RvY29sLiAgSSdkIGRlZmluaXRlbHkNCj4gPiBzZXQgYW4g ZXhwZWN0YXRpb24gdGhhdCBzb2xpZCBqdXN0aWZpY2F0aW9uIGZvciB0aGUgbmV3IGluc2VjdXJl DQo+ID4gcG9ydCB3aWxsIGJlIGV4cGVjdGVkLCB3aXRoIHRoZSBhcHBsaWNhbnQgYmVpbmcgcmVz cG9uc2libGUgZm9yDQo+ID4ganVzdGlmeWluZyB3aHkgdXNlIG9mIHNlY3VyaXR5IGlzIG5vdCBt YW5kYXRvcnkgZm9yIHRoZSBwcm90b2NvbC4NCj4gPiBJZiB0aGF0IGp1c3RpZmljYXRpb24gbWFr ZXMgdGhlIGNhc2UsIHRoZW4gdGhlIGZpcmV3YWxsIGNvbnRyb2wNCj4gPiByYXRpb25hbGUgKGJl bG93KSBkZWZpbml0ZWx5IHNvdW5kcyByZWFzb25hYmxlLCBJTUhPLg0KPiANCj4gV2h5IGlzbid0 IHRoYXQgYSBTSE9VTEQgTk9UPyBDZXJ0YWlubHkgYSBiaXQgbW9yZSB0ZXh0IGlzIGluIG9yZGVy LCBidXQNCj4gaXQgc2VlbXMgbGlrZSB3ZSdyZSBpbiBhZ3JlZW1lbnQgLSBkZWVwIGp1c3RpZmlj YXRpb24gaXMgbmVlZGVkLg0KPiANCj4gPiBJIGp1c3QgZG9uJ3QgdGhpbmsgdGhlIGxldmVsIG9m IHJlcXVpcmVkIGp1c3RpZmljYXRpb24gaXMgZ29pbmcNCj4gPiB0byByaXNlIHRvIHRoYXQgc3Vm ZmljaWVudCB0byBvdmVycmlkZSBhICJTSE9VTEQgTk9UIiBmb3IgZXZlcnkNCj4gPiBzaW5nbGUg cHJvdG9jb2wgZGVzaWduIHRoYXQgd2UgaGF2ZSB5ZXQgdG8gZW52aXNpb24uICBJIHdpc2ggbXkN Cj4gPiBmb3Jlc2lnaHQgd2FzIDIwLzIwIDotKS4NCj4gDQo+IEZXSVcsIHRoZXJlIGFyZW4ndCBh IGxvdCBvZiBwcm90b2NvbHMgdGhhdCBhc2sgZm9yIHNlY3VyZSBhbmQgaW5zZWN1cmUNCj4gYXQg dGhlIHNhbWUgdGltZS4gVGhvc2UgY29tZSBtb3N0bHkgLSBpbmNyZWRpYmx5IC0gZnJvbSBJRVRG IFdHcywgd2hlcmUNCj4gdGhleSBhcHBlYXIgdG8gYmUgKElNTyBibGluZGx5KSBmb2xsb3dpbmcg cGFzdCBwcmFjdGljZS4NCj4gDQo+IE15IGtleSBjb25jZXJuIGlzICJ3aHkgaXMgdGhlIGluc2Vj dXJlIHBvcnQgbmVlZGVkIj8gTW9zdCBvZiB0aGUgdGltZQ0KPiB0aGUganVzdGlmaWNhdGlvbiBp cyBwdXJlIHBlcmZvcm1hbmNlIC0gcnVubmluZyBzZWN1cml0eSBvbiB0aGUgc2VydmljZQ0KPiB3 aWxsIG1ha2UgaXQgdG9vIHNsb3csIGFuZCB0aGlzIHdpbGwgYWxsb3cgZmFzdGVyIHBlcmZvcm1h bmNlIGluc2lkZSBhbg0KPiBlbnRlcnByaXNlLiBUaGF0IG1pZ2h0IGJlIHRydWUsIGJ1dCBpdCBh bHNvIG5lZWRzIHRvIGJlIGp1c3RpZmllZCBpbg0KPiB0ZXJtcyBvZiB0aGUgc2VydmljZSBiZWlu ZyBwcm92aWRlZCAtIHRoYXQgdGhpcyBpcyBhIGhpZ2gtdGhyb3VnaHB1dCBvcg0KPiBoaWdoLXRy YW5zYWN0aW9uIGZyZXF1ZW5jeSBzeXN0ZW0gdGhhdCBuZWVkcyBoaWdoIHBlcmZvcm1hbmNlIGlu c2lkZQ0KPiBwcm90ZWN0ZWQgZW50ZXJwcmlzZXMuDQo+IA0KPiA+IAktIEdJVkVOIGEgcmVxdWVz dCBmb3IgYW4gaW5zZWN1cmUgYW5kIHNlY3VyZSBwb3J0LCB3aGF0DQo+ID4gCWFyZSBhcHByb3By aWF0ZSBqdXN0aWZpY2F0aW9ucz8NCj4gPg0KPiA+IAkJSU1PLCBzZXBhcmF0ZSBmaXJld2FsbCBj b250cm9sIGlzIGEgc3VmZmljaWVudA0KPiA+IAkJcmVhc29uLg0KPiA+DQo+ID4gCQlob3dldmVy LCBwZXJmb3JtYW5jZSBzaG91bGQgbm90IGJlIC0gaS5lLiwgaWYNCj4gPiAJCWJvdGggcG9ydHMg d2lsbCB0eXBpY2FsbHkgaGF2ZSB0aGUgc2FtZSBmaXJld2FsbA0KPiA+IAkJY29uZmlndXJhdGlv biwgdGhlbiBvbmx5IG9uZSBwb3J0IGlzIG5lZWRlZA0KPiA+IAkJYW5kIHNlY3VyaXR5IHNob3Vs ZCBiZSBuZWdvdGlhdGVkIGFzIHByZXNlbnQvYWJzZW50DQo+ID4gCQlpbi1iYW5kLiBUaGUgcGVy Zm9ybWFuY2UgaW1wYWN0IG9mIHRoYXQgbmVnb3RpYXRpb24NCj4gPiAJCShJTU8pIHNob3VsZCBu b3QgZmFjdG9yIGludG8gd2hldGhlciBhbiBhZGRpdGlvbmFsDQo+ID4gCQlwb3J0IHNob3VsZCBi ZSBhc3NpZ25lZC4NCj4gPg0KPiA+IEkgdGhpbmsgdGhlIHRleHQgb24gcGVyZm9ybWFuY2Ugc2hv dWxkIGJlIGV4cGxpY2l0IHRoYXQgdGhlDQo+ID4gcGVyZm9ybWFuY2UgY29uY2VybiBpcyBuZWdv dGlhdGlvbiByb3VuZCB0cmlwIGF2b2lkYW5jZS4NCj4gDQo+IFRoZXJlIGFyZSBhIGZldyBkaWZm ZXJlbnQgcGVyZm9ybWFuY2UgaXNzdWVzOg0KPiANCj4gCS0gcm91bmQtdHJpcCBkZWxheXMNCj4g CS0gdGhyb3VnaHB1dCBvdmVyaGVhZCAocGVyIGJ5dGUpDQo+IAktIG1lc3NhZ2Ugb3ZlcmhlYWQg KHBlciBtZXNzYWdlKQ0KPiANCj4gSm9lDQo+IA0KPiA+IDwvV0cgY2hhaXIgaGF0IE9GRj4NCj4g Pg0KPiA+IFRoYW5rcywNCj4gPiAtLURhdmlkDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gRnJvbTogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4g Pj4gU2VudDogVHVlc2RheSwgTWF5IDI3LCAyMDE0IDY6MDMgUE0NCj4gPj4gVG86IFBhdWwgSG9m Zm1hbg0KPiA+PiBDYzogQmxhY2ssIERhdmlkOyB0c3Z3Z0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0 OiBSZTogW3RzdndnXSBhZGRpdGlvbmFsIHBvcnRzIGZvciBzZWN1cml0eSAtIFJlOiBXR0xDIGZv ciBkcmFmdC0NCj4gaWV0Zi0NCj4gPj4gdHN2d2ctcG9ydC11c2UtMDQgKHRvIGVuZCA2dGggSnVu ZSkNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gNS8yNy8yMDE0IDI6NDkgUE0sIFBhdWwgSG9m Zm1hbiB3cm90ZToNCj4gPj4+IElzIHRoaXMgbmV3IGFkdmljZSBiYXNlZCBvbiBhbnkgYWN0dWFs IGV2aWRlbmNlIG9yIGV2ZW4gYSBzZWN1cml0eQ0KPiBhbmFseXNpcz8NCj4gPj4NCj4gPj4gSXQn cyBiYXNlZCBvbiA4IHllYXJzIG9mIHJ1bm5pbmcgdGhlIHJldmlldyB0ZWFtIGFuZCBkaXNjdXNz aW9ucyB3aXRoaW4NCj4gPj4gdGhhdCB0ZWFtLiBJdCdzIGJhc2VkIG9uIHRoZSBhbmFseXNpcyBw cm92aWRlZC4NCj4gPj4NCj4gPj4gSWYgeW91IGRpc2FncmVlIHdpdGggdGhlIGFuYWx5c2lzLCB5 b3Ugc2hvdWxkIHByZXNlbnQgYSBjb3VudGVyYXJndW1lbnQuDQo+ID4+DQo+ID4+PiBGdXJ0aGVy LCBhIHN0YXRlbWVudCBvZiAiU0hPVUxEIE5PVCByZXF1ZXN0IiBzb3VuZHMgYSBoZWxsIG9mIGEg bG90IG1vcmUNCj4gPj4+IGxpa2UgYSBkZW1hbmQgdGhhbiBhZHZpY2UuDQo+ID4+DQo+ID4+IFdo YXQgZXhhY3RseSBjYW4gd2UgKmRlbWFuZCogb2YgYSB1c2VyIG1ha2luZyBhbiBhcHBsaWNhdGlv biBvdGhlciB0aGF0DQo+ID4+IHRvIHByb3ZpZGUgYWR2aWNlPyBJdCdzIG5vdCBhZHZpY2UgdG8g SUFOQSBvciB0aGUgcG9ydHMgdGVhbSBpbiBob3cgdG8NCj4gPj4gbWFrZSBhIGRlY2lzaW9uLg0K PiA+Pg0KPiA+Pj4gVGhpcyBnZXRzIHRvIHRoZSBjcnV4IG9mIG15IGNvbmNlcm4gb2YgdGhlDQo+ ID4+PiBkb2N1bWVudDogaXQgZmVlbCBsaWtlIHRoZSBhZHZpY2UgaXMgbWVhbnQgdG8gY29tZSBm cm9tIG9uIGhpZ2ggKG5hbWVseSwNCj4gPj4+IHNvbWVvbmUgd2hvIGNhbiBibG9jayBJQU5BIHJl cXVlc3RzKSwgbm90IGZyaWVuZGx5IGFkdmljZSBmcm9tIG9uZQ0KPiA+Pj4gZGV2ZWxvcGVyIHRv IGFub3RoZXIuDQo+ID4+DQo+ID4+IENhbiB5b3UgcHJvdmlkZSBhIHJhdGlvbmFsZSBmb3IgdGhh dCBjbGFpbSBvdGhlciB0aGFuICJiZWNhdXNlIEpvZSBUb3VjaA0KPiA+PiB3cm90ZSBpdCI/DQo+ ID4+DQo+ID4+PiBXZSB3ZW50IHRocm91Z2ggdGhpcyBpbiB0aGUgZGlzY3Vzc2lvbiBhIGZldyB5 ZWFycw0KPiA+Pj4gYWdvLCBhbmQgaXQgc2VlbWVkIHRoZW4gdGhhdCBUU1ZXRyBkaWRuJ3QgYWdy ZWUgdGhhdCBzdWNoIGhlYXZ5LWhhbmRlZA0KPiA+Pj4gImFkdmljZSIsIHBhcnRpY3VsYXJseSB3 aXRob3V0IHNwZWNpZmljIGp1c3RpZmljYXRpb24sIHdhcyB0aGUgd2F5IHRvIGdvLg0KPiA+Pg0K PiA+PiBUU1ZXRyBhZ3JlZWQgdGhhdCBsaW1pdGluZyBJQU5BIHdhcyBub3QgYXBwcm9wcmlhdGU7 IHRoaXMgZG9jdW1lbnQNCj4gPj4gZG9lc24ndCBsaW1pdCBJQU5BLg0KPiA+Pg0KPiA+PiBBbmQg c3BlY2lmaWMganVzdGlmaWNhdGlvbiBpcyBwcm92aWRlZCBpbiB0aGUgZGlzY3Vzc2lvbiBJIGdh dmUuIEFnYWluLA0KPiA+PiBpZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGF0IGRpc2N1c3Npb24sIHBs ZWFzZSBleHBsYWluLg0KPiA+Pg0KPiA+PiBFLmcuLCBkbyB5b3UgYWN0dWFsbHkgdGhpbmsgaXQn cyBnb29kIHNlY3VyaXR5IHByYWN0aWNlIHRvIGNyZWF0ZSBuZXcsDQo+ID4+IGluc2VjdXJlIHNl cnZpY2VzPyBJZiBzbywgb24gd2hhdCBiYXNpcyBvZiBnb29kIHNlY3VyaXR5IHByYWN0aWNlPw0K PiA+Pg0KPiA+PiBKb2UNCj4gPg0KDQo= From nobody Wed May 28 09:41:53 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E616A1A0496 for ; Wed, 28 May 2014 09:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQ1RF0lsXNlf for ; Wed, 28 May 2014 09:41:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46B31A0A79 for ; Wed, 28 May 2014 09:41:49 -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 s4SGdAKF022529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 09:39:13 -0700 (PDT) Message-ID: <5386112D.9050207@isi.edu> Date: Wed, 28 May 2014 09:39:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Eliot Lear , gorry@erg.abdn.ac.uk, tsvwg@ietf.org References: <537D9AC4.80602@erg.abdn.ac.uk> <5385833C.20505@cisco.com> In-Reply-To: <5385833C.20505@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/e0_iea40JbJ80-NH0GRALQSgLSg Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:41:52 -0000 Hi, Eliot, Thanks for the detailed comments. My view is below... Joe On 5/27/2014 11:33 PM, Eliot Lear wrote: > Dear Joe & TSVWG, > > I have the following comments about draft-ietf-tsvwg-port-use-04. > Buried in this review is a question regarding HTTP in particular that > IMHO both this WG and the apps area needs to seriously consider. > > When reviewing this document, I asked the question, “Does this text help > me provide me guidance about how to design my services?” As such, while > it's a very interesting history, I find that Section 3 fails that test. The purpose of this document is advice to users on how to use service numbers and service names, i.e., how to deal with aspects of service design that affect service assignment. It isn't a course in service design. That would take a book. > I am generally not a fan of repeating information in multiple documents, > but if we are going to list port ranges, I would request that we > indicate the authoritative source, which is RFC 6335 Section 6. The > IETF is the policy authority for this information, not IANA. Agreed; this will be fixed in the next version. > The following text in Section 6 of the draft needs serious review: > >> Others have noted "think twice about modifying TCP, then don't" >> [RFC1263]. In this case, similar advice might be: >> >> o Think twice before asking for an assigned port, then try not >> to. >> >> o If more than one port is desired, consider revising the >> architecture until only one is needed, or, preferably, none. > > Developers SHOULD request ports to differentiate their services. Not necessarily. A service that *can* operate effectively on dynamic ports should do so. > The > question is how many ports do they need to do that. Therefore, the > analogy used to RFC1263 is inappropriate. I disagree. Assigned ports have a real cost in system configuration complexity as well as consuming a global community resource, which is why the "similar" advice is appropriate here IMO. > In Section 7.1: > > >> New services should support security or should consider >> optional security. A new service should not need a port for an >> insecure version; at best, this would be a performance issue >> (see the first bullet), and at worst this presents a new >> vulnerability. > > We should be considering a stronger statement than this with normative > language that is in line with IETF consensus as documented in RFC 7258. Security includes a breadth of issues including resistance to interference, masquerading, content observation, and meta-information tracking. For the purposes of this document, we should be clear that "security" typically refers to the first 3, but not the last. In fact, using assigned ports is the antithesis of avoiding monitoring - you're advertising to the world the service type. Regardless, IMO it's inappropriate to create RFC 2119-level requirements justified by a BCP that has *NO* RFC 2119 recommendations. > But we have to be careful to not chase off applicants such that they > squat or inappropriately warp their architecture. This has always occurred and will always occur. Although I don't want to chase them off, appeasing them is like "adjusting laws for the benefit of the lawless". > Therefore, I suggest > phrasing that is similar to what is found in RFC 7258. Let me suggest > two questions to be asked. The first comes right out of the RFC: > >> Is pervasive monitoring relevant to this work and if so, how has it >> been considered? I don't intend to do this for every RFC until a "Pervasive montitoring" section is required for submission. Otherwise, we will end up derailing *every* RFC with *every* BCP that's *ever* been issued. This document has nothing to do with avoiding monitoring or enabling it, so this issue is IMO out of scope. > The second is more general: > > How have security considerations been taken into account? See Section 8, which will be expanded to include pointers to considerations addressed elsewhere in the doc. > And throw a MUST around at least being able to answer those questions. There are no MUSTs in RFC 7258. > Reviewers can then use their judgment as to the validity of the answers. > > Going to the next paragraph: > >> >> o Ports are not for indicating different service versions. >> Version differentiation should be handled in-band, e.g., using >> a version number at the beginning of a connection or >> transaction. This may not be possible with legacy assignments, >> but all new assignments should incorporate support for version >> indication. > > This point requires expansion. We are currently seeing a number of > requests around HTTP in particular in which there is absolutely no > difference between protocol being run on port 80 and what is being > requested. The reason for the request, however, is that the applicant > is offering some sort of server management function. The above guidance > says that hosts should multiplex this function on port 80. As a matter > of architecture, we need to decide what the real guidance should be in > this case. Should it be require that web servers support such > multiplexing? We certainly have the means through .well-known, for > instance. In 1999 HTTP 1.1 added the Host header field, and TLS was extended to support this in its SNI for this very purpose. The issue with HTTP is that it both a presentation layer and an application layer at the same time. When used as a presentation layer, other protocols can be designed on top and that easily warrants a new port. When used as an application layer, the "no duplicate" rule applies. I.e., server management by custom protocols warrants a new port. Servers managed by unmodified web clients should use port 80 or 443. Otherwise, every web server instance would warrant a new port - and that would easily overwhelm the number of available ports. This is we should not assign multiple ports to the same service (even though this was done in the past, e.g., 8080). > And we have seen similar issues with other popular protocols. MySQL is > a big hit at the moment. The MySQL issues are different. That is one of a number of protocols that different groups are extending, and each group wants a separate port for their extensions. My view of these has been that any *independently useful* service qualifies, but that extensions that aren't stand-alone aren't services - they're extensions - and extensible services should be extended within their assigned port. Joe From nobody Wed May 28 09:43:22 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809FE1A0B82 for ; Wed, 28 May 2014 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAVs3vp7OvMZ for ; Wed, 28 May 2014 09:43:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA931A0A7D for ; Wed, 28 May 2014 09:43:18 -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 s4SGgS6k023675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 09:42:28 -0700 (PDT) Message-ID: <538611F4.8000905@isi.edu> Date: Wed, 28 May 2014 09:42:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" , Paul Hoffman References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C663209@MX15A.corp.emc.com> <53854308.8020705@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C66334F@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C66334F@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/dCm4iLJeNs295r1v5BRFCni_ghA Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:43:20 -0000 On 5/28/2014 9:32 AM, Black, David wrote: > > >>> - should a user request two ports for a new service, one >>> secure and one insecure? >>> >>> I suspect that the advice for the this one is likely to be a long >>> version of "it depends" in practice. >>> >>> IMO, the secure port is easy, if otherwise >>> warranted (not a duplicate of existing service, e.g.), >>> but the insecure one similarly creates a new >>> vulnerability, and again I would say SHOULD NOT >>> request a new insecure port >>> >>> I agree with the secure port being fine, but I'm not comfortable >>> with a blanket "SHOULD NOT" recommendation for the insecure port. >>> >>> I think this depends on the details of the protocol. I'd definitely >>> set an expectation that solid justification for the new insecure >>> port will be expected, with the applicant being responsible for >>> justifying why use of security is not mandatory for the protocol. >>> If that justification makes the case, then the firewall control >>> rationale (below) definitely sounds reasonable, IMHO. >> >> Why isn't that a SHOULD NOT? Certainly a bit more text is in order, but >> it seems like we're in agreement - deep justification is needed. > > We're dealing with a process as opposed to a protocol here, so the functionality > of some future protocol that will ask for ports is unknown to us at the moment. > > I think I'm mostly looking for some gradation wrt the other SHOULD NOT: > >>> - given a current secure assignment, what >>> if a user requests a (new) second port for insecure access? >>> >>> it seems like a SHOULD NOT recommendation >>> is appropriate; this creates new vulnerability; >>> >>> I presume that the latter recommendation envisions a scenario where >>> the secure port has been deployed and used for a significant period >>> of time. >> >> Yes. > > IMHO, that "running code" deployment and use experience provides a solid > strong foundation for a "SHOULD NOT" by comparison to the "new request > for two ports" case, where a "SHOULD NOT" strikes me as pre-evaluating > protocol design decisions, sight unseen, for protocols that nobody's > even thought of, yet. In both cases we're assessing an event in the future - as with *every* RFC 2119 recommendation. The SHOULD NOT isn't pre-evaluating - it's saying that there are enough concerns with this path that strong justification is needed - just like *every* SHOULD or SHOULD NOT exception. >>> I just don't think the level of required justification is going >>> to rise to that sufficient to override a "SHOULD NOT" for every >>> single protocol design that we have yet to envision. I wish my >>> foresight was 20/20 :-). >> >> FWIW, there aren't a lot of protocols that ask for secure and insecure >> at the same time. Those come mostly - incredibly - from IETF WGs, where >> they appear to be (IMO blindly) following past practice. > > Here I agree - use of "we've always done it that way" as a rationale SHOULD > be strongly discouraged; beyond that, I'd suggest pointing out that requests > for both ports are viewed with significant skepticism because that reason > has been the primary rationale for many of them. It would also help to > add discussion of "justified in terms of service provided": AOK. Rather than SHOULD NOT, I'll go with "extreme skepticism" (although I ask others on the list to weigh-in on this - IMO, "extreme skepticism for exceptions" is precisely what SHOULD NOT implies). Joe >> My key concern is "why is the insecure port needed"? Most of the time >> the justification is pure performance - running security on the service >> will make it too slow, and this will allow faster performance inside an >> enterprise. That might be true, but it also needs to be justified in >> terms of the service being provided - that this is a high-throughput or >> high-transaction frequency system that needs high performance inside >> protected enterprises. > > > > Thanks, > --David > > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 27, 2014 10:00 PM >> To: Black, David; Paul Hoffman >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf- >> tsvwg-port-use-04 (to end 6th June) >> >> >> >> On 5/27/2014 5:40 PM, Black, David wrote: >>> Joe, >>> >>> >>> >>>> If you disagree with the analysis, you should present a counterargument. >>> >>> Ok, I'll try ... ;-). >>> >>> It might help if this had somewhat more of a flavor of documenting the >>> review criteria that are currently used, although I do think at least >>> one "SHOULD NOT" is likely to turn up in the final text. >>> >>> I'd certainly like to see some Security Area input (and probably also >>> OPS, as firewalls play a prominent role), but speaking for myself, >>> I think offering security advice is well within reason here ... >>> >>> Going back to the three scenarios at the start of this thread, the >>> proposals for the first two seem reasonable (IMHO): >>> >>> - given a current non-secure assignment, what if a >>> user requests a (new) second port for secure access? >>> >>> this is fine, if not a good idea; >>> >>> - given a current secure assignment, what >>> if a user requests a (new) second port for insecure access? >>> >>> it seems like a SHOULD NOT recommendation >>> is appropriate; this creates new vulnerability; >>> >>> I presume that the latter recommendation envisions a scenario where >>> the secure port has been deployed and used for a significant period >>> of time. >> >> Yes. >> >>> In that case, I think a "SHOULD NOT" is ok, as I'd want to >>> see some heavy-duty serious justification for adding the insecure >>> port. The draft should state that presumption, though, as deployment >>> difficulties/experience might result in something closer to the third >>> scenario. >> >> Right - that's the point of the SHOULD NOT. It's not a MUST NOT. It just >> needs very heavy justification. >> >>> - should a user request two ports for a new service, one >>> secure and one insecure? >>> >>> I suspect that the advice for the this one is likely to be a long >>> version of "it depends" in practice. >>> >>> IMO, the secure port is easy, if otherwise >>> warranted (not a duplicate of existing service, e.g.), >>> but the insecure one similarly creates a new >>> vulnerability, and again I would say SHOULD NOT >>> request a new insecure port >>> >>> I agree with the secure port being fine, but I'm not comfortable >>> with a blanket "SHOULD NOT" recommendation for the insecure port. >>> >>> I think this depends on the details of the protocol. I'd definitely >>> set an expectation that solid justification for the new insecure >>> port will be expected, with the applicant being responsible for >>> justifying why use of security is not mandatory for the protocol. >>> If that justification makes the case, then the firewall control >>> rationale (below) definitely sounds reasonable, IMHO. >> >> Why isn't that a SHOULD NOT? Certainly a bit more text is in order, but >> it seems like we're in agreement - deep justification is needed. >> >>> I just don't think the level of required justification is going >>> to rise to that sufficient to override a "SHOULD NOT" for every >>> single protocol design that we have yet to envision. I wish my >>> foresight was 20/20 :-). >> >> FWIW, there aren't a lot of protocols that ask for secure and insecure >> at the same time. Those come mostly - incredibly - from IETF WGs, where >> they appear to be (IMO blindly) following past practice. >> >> My key concern is "why is the insecure port needed"? Most of the time >> the justification is pure performance - running security on the service >> will make it too slow, and this will allow faster performance inside an >> enterprise. That might be true, but it also needs to be justified in >> terms of the service being provided - that this is a high-throughput or >> high-transaction frequency system that needs high performance inside >> protected enterprises. >> >>> - GIVEN a request for an insecure and secure port, what >>> are appropriate justifications? >>> >>> IMO, separate firewall control is a sufficient >>> reason. >>> >>> however, performance should not be - i.e., if >>> both ports will typically have the same firewall >>> configuration, then only one port is needed >>> and security should be negotiated as present/absent >>> in-band. The performance impact of that negotiation >>> (IMO) should not factor into whether an additional >>> port should be assigned. >>> >>> I think the text on performance should be explicit that the >>> performance concern is negotiation round trip avoidance. >> >> There are a few different performance issues: >> >> - round-trip delays >> - throughput overhead (per byte) >> - message overhead (per message) >> >> Joe >> >>> >>> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: Joe Touch [mailto:touch@isi.edu] >>>> Sent: Tuesday, May 27, 2014 6:03 PM >>>> To: Paul Hoffman >>>> Cc: Black, David; tsvwg@ietf.org >>>> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft- >> ietf- >>>> tsvwg-port-use-04 (to end 6th June) >>>> >>>> >>>> >>>> On 5/27/2014 2:49 PM, Paul Hoffman wrote: >>>>> Is this new advice based on any actual evidence or even a security >> analysis? >>>> >>>> It's based on 8 years of running the review team and discussions within >>>> that team. It's based on the analysis provided. >>>> >>>> If you disagree with the analysis, you should present a counterargument. >>>> >>>>> Further, a statement of "SHOULD NOT request" sounds a hell of a lot more >>>>> like a demand than advice. >>>> >>>> What exactly can we *demand* of a user making an application other that >>>> to provide advice? It's not advice to IANA or the ports team in how to >>>> make a decision. >>>> >>>>> This gets to the crux of my concern of the >>>>> document: it feel like the advice is meant to come from on high (namely, >>>>> someone who can block IANA requests), not friendly advice from one >>>>> developer to another. >>>> >>>> Can you provide a rationale for that claim other than "because Joe Touch >>>> wrote it"? >>>> >>>>> We went through this in the discussion a few years >>>>> ago, and it seemed then that TSVWG didn't agree that such heavy-handed >>>>> "advice", particularly without specific justification, was the way to go. >>>> >>>> TSVWG agreed that limiting IANA was not appropriate; this document >>>> doesn't limit IANA. >>>> >>>> And specific justification is provided in the discussion I gave. Again, >>>> if you disagree with that discussion, please explain. >>>> >>>> E.g., do you actually think it's good security practice to create new, >>>> insecure services? If so, on what basis of good security practice? >>>> >>>> Joe >>> > From nobody Wed May 28 09:46:04 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EA51A0164 for ; Wed, 28 May 2014 09:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEk0dOnkHchp for ; Wed, 28 May 2014 09:46:01 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C1E1A0157 for ; Wed, 28 May 2014 09:46:01 -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 s4SGiXcT024175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 09:44:33 -0700 (PDT) Message-ID: <53861271.1070705@isi.edu> Date: Wed, 28 May 2014 09:44:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pearl Liang , Eliot Lear , "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" References: <537D9AC4.80602@erg.abdn.ac.uk> <5385833C.20505@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/0F4GLvjeoMm_Z8zFRNMKm4rmSak Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:46:03 -0000 On 5/28/2014 8:18 AM, Pearl Liang wrote: > Hi, > > I was thinking about that too - can we expand the texts regarding > applications use the generic or redesigned HTTP in this document? There are some hazards with some advice in this document. As much as we don't want to scare away squatters unnecessarily, we also don't want to give directions for end-runs. It is certainly useful to discuss the HTTP issue with more text, but I would suggest we should avoid going into too much detail with examples as a result. Joe > ~pl > > On 5/27/14 11:33 PM, "Eliot Lear" wrote: > >> Dear Joe & TSVWG, >> >> I have the following comments about draft-ietf-tsvwg-port-use-04. >> Buried in this review is a question regarding HTTP in particular that >> IMHO both this WG and the apps area needs to seriously consider. >> >> When reviewing this document, I asked the question, ³Does this text help >> me provide me guidance about how to design my services?² As such, while >> it's a very interesting history, I find that Section 3 fails that test. >> >> I am generally not a fan of repeating information in multiple documents, >> but if we are going to list port ranges, I would request that we >> indicate the authoritative source, which is RFC 6335 Section 6. The >> IETF is the policy authority for this information, not IANA. >> >> The following text in Section 6 of the draft needs serious review: >> >>> Others have noted "think twice about modifying TCP, then don't" >>> [RFC1263]. In this case, similar advice might be: >>> >>> o Think twice before asking for an assigned port, then try not >>> to. >>> >>> o If more than one port is desired, consider revising the >>> architecture until only one is needed, or, preferably, none. >> >> Developers SHOULD request ports to differentiate their services. The >> question is how many ports do they need to do that. Therefore, the >> analogy used to RFC1263 is inappropriate. >> >> In Section 7.1: >> >> >>> New services should support security or should consider >>> optional security. A new service should not need a port for an >>> insecure version; at best, this would be a performance issue >>> (see the first bullet), and at worst this presents a new >>> vulnerability. >> >> We should be considering a stronger statement than this with normative >> language that is in line with IETF consensus as documented in RFC 7258. >> But we have to be careful to not chase off applicants such that they >> squat or inappropriately warp their architecture. Therefore, I suggest >> phrasing that is similar to what is found in RFC 7258. Let me suggest >> two questions to be asked. The first comes right out of the RFC: >> >>> Is pervasive monitoring relevant to this work and if so, how has it >>> been considered? >> >> The second is more general: >> >> How have security considerations been taken into account? >> >> And throw a MUST around at least being able to answer those questions. >> Reviewers can then use their judgment as to the validity of the answers. >> >> Going to the next paragraph: >> >>> >>> o Ports are not for indicating different service versions. >>> Version differentiation should be handled in-band, e.g., using >>> a version number at the beginning of a connection or >>> transaction. This may not be possible with legacy assignments, >>> but all new assignments should incorporate support for version >>> indication. >> >> This point requires expansion. We are currently seeing a number of >> requests around HTTP in particular in which there is absolutely no >> difference between protocol being run on port 80 and what is being >> requested. The reason for the request, however, is that the applicant >> is offering some sort of server management function. The above guidance >> says that hosts should multiplex this function on port 80. As a matter >> of architecture, we need to decide what the real guidance should be in >> this case. Should it be require that web servers support such >> multiplexing? We certainly have the means through .well-known, for >> instance. >> >> And we have seen similar issues with other popular protocols. MySQL is >> a big hit at the moment. >> >> Eliot >> From nobody Wed May 28 09:49:35 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93401A09E2 for ; Wed, 28 May 2014 09:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs3vl8di8gkB for ; Wed, 28 May 2014 09:49:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196031A6EF2 for ; Wed, 28 May 2014 09:49:29 -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 s4SGm9uE025398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 09:48:09 -0700 (PDT) Message-ID: <53861349.7080302@isi.edu> Date: Wed, 28 May 2014 09:48:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pearl Liang , "Eggert, Lars" References: <8EA0C0EA-7C81-41ED-85BA-4E9B8F690B77@netapp.com> <0EEE0BBC-C9D0-43F8-A162-0278F6B8173D@netapp.com> <5384BAFA.106@isi.edu> In-Reply-To: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/4RUyTdpq4hHEYJ86iS_geGrMvKs Cc: tsvwg Subject: Re: [tsvwg] New Version Notification for draft-ietf-tsvwg-port-use-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:49:34 -0000 On 5/28/2014 9:03 AM, Pearl Liang wrote: > > On 5/27/14 9:19 AM, "Joe Touch" wrote: > >> HI, all, >> >> First, I do need to do a scrub to make sure that this doc's core (not >> the history part) ends up referring to "service names" and "service >> numbers" as per RFC 6335. That said... >> >> On 5/26/2014 11:30 PM, Eggert, Lars wrote: >>> Hi, >>> >>> On 2014-5-27, at 0:48, Pearl Liang wrote: >>>> >>>> - does the word 'SRV' apply to all service names regardless one with a >>>> port number or without it? >> >> As Lars noted, all service names can be used in the DNS SRV mechanism, >> however this doc ought to discuss the relationship in more detail... > > It'll be useful. > >> >>>> - When and how a user decide to add a port number with the DNS SRV >>>> service >>>> name? In another word, why can a user simply register an DNS SRV >>>> service >>>> name without a port number? >> >> Service names assigned without a service number are useful only for >> indices such as DNS SRV or mechanisms like TCP port names. The service >> is assigned a dynamic port number and that number is advertised to >> others via such methods. > > So, would it be possible to add a user port number to a registered SRV > service name down the road at some point? Yes, subject to the same hurdles as any new numeric assignment. Joe From nobody Thu May 29 07:15:38 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B661A093E; Thu, 29 May 2014 07:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI6HaO3Mvsn8; Thu, 29 May 2014 07:15:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 989F11A098D; Thu, 29 May 2014 07:15:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140529141523.21352.11775.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 07:15:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/mrRZjw7qtl-KkHMG7j5JTIgGqgE Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-prpolicies-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:15:25 -0000 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. Title : Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol Authors : Michael Tuexen Robin Seggelmann Randall R. Stewart Salvatore Loreto Filename : draft-ietf-tsvwg-sctp-prpolicies-03.txt Pages : 8 Date : 2014-05-29 Abstract: This document defines two additional policies for the Partial Reliability Extension of the Stream Control Transmission Protocol (PR-SCTP) allowing to limit the number of retransmissions or to prioritize user messages for more efficient send buffer usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-prpolicies-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 29 07:20:09 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4AF1A6F56 for ; Thu, 29 May 2014 07:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykeM1M-8wHsh for ; Thu, 29 May 2014 07:19:52 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D591A6F44 for ; Thu, 29 May 2014 07:19:51 -0700 (PDT) Received: from [192.168.1.200] (p508F0AE5.dip0.t-ipconnect.de [80.143.10.229]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 752921C0E9801 for ; Thu, 29 May 2014 16:19:46 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: <20140529141523.21352.11775.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 16:19:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140529141523.21352.11775.idtracker@ietfa.amsl.com> To: tsvwg WG X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/YGiysC7WNM7tdycxYdnET0Rmpkg Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-prpolicies-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:19:55 -0000 Dear all, please note that the intended status of this ID has changed from = Informational to Proposed Standard. This is due to the feedback we got that made clear = that the usage of RFC 2129 language is necessary to make sure that users get = the service they require. The other changes are clarifications. Best regards Michael On 29 May 2014, at 16:15, internet-drafts@ietf.org wrote: >=20 > 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 : Additional Policies for the Partial = Reliability Extension of the Stream Control Transmission Protocol > Authors : Michael Tuexen > Robin Seggelmann > Randall R. Stewart > Salvatore Loreto > Filename : draft-ietf-tsvwg-sctp-prpolicies-03.txt > Pages : 8 > Date : 2014-05-29 >=20 > Abstract: > This document defines two additional policies for the Partial > Reliability Extension of the Stream Control Transmission Protocol > (PR-SCTP) allowing to limit the number of retransmissions or to > prioritize user messages for more efficient send buffer usage. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-prpolicies-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 From nobody Thu May 29 08:35:24 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8751A6F79 for ; Thu, 29 May 2014 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZRXth1i65BK for ; Thu, 29 May 2014 08:35:18 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EB81A6F71 for ; Thu, 29 May 2014 08:35:17 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4TFZ9uS016991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 11:35:10 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s4TFZ9uS016991 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401377711; bh=gssK5ZJ1cLhxfHLcglcHGTE3dc4=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=GyvUT9Z2MdUyL0iPiUF4kx7T0Pp/tubll35huBAbCeq72sknG3f1sOwG7cS5MfVvg cBu6GI1ieL0Heezs/+HbJX6xXY3iBU1jO33gu+FpChJmYWufO+W8RKD1tUL5ncwBQA aZbngt7oUKd1Ff0QbXpX0MXQwoYRVkh6JgRM0XyU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s4TFZ9uS016991 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 29 May 2014 08:34:55 -0700 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4TFYrJ3018644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 11:34:55 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Thu, 29 May 2014 11:34:53 -0400 From: "Black, David" To: Joe Touch Date: Thu, 29 May 2014 11:34:51 -0400 Thread-Topic: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) Thread-Index: Ac96k+x9hujYTea+SBuGVxrW+PpbzQAtV95Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C66364B@MX15A.corp.emc.com> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C663209@MX15A.corp.emc.com> <53854308.8020705@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C66334F@MX15A.corp.emc.com> <538611F4.8000905@isi.edu> In-Reply-To: <538611F4.8000905@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/oROfoVsOgSgzThzBEWgDOtQx8DA Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:35:22 -0000 PFdHIGNoYWlyIGhhdCBPRkY+DQoNCj4gPiBJIHRoaW5rIEknbSBtb3N0bHkgbG9va2luZyBmb3Ig c29tZSBncmFkYXRpb24gd3J0IHRoZSBvdGhlciBTSE9VTEQgTk9UOg0KPiA+DQo+ID4+PiAgIC0g Z2l2ZW4gYSBjdXJyZW50IHNlY3VyZSBhc3NpZ25tZW50LCB3aGF0DQo+ID4+PiAgIGlmIGEgdXNl ciByZXF1ZXN0cyBhIChuZXcpIHNlY29uZCBwb3J0IGZvciBpbnNlY3VyZSBhY2Nlc3M/DQo+ID4+ Pg0KPiA+Pj4gICAgICAgICAgIGl0IHNlZW1zIGxpa2UgYSBTSE9VTEQgTk9UIHJlY29tbWVuZGF0 aW9uDQo+ID4+PiAgICAgICAgICAgaXMgYXBwcm9wcmlhdGU7IHRoaXMgY3JlYXRlcyBuZXcgdnVs bmVyYWJpbGl0eTsNCj4gPj4+DQo+ID4+PiBJIHByZXN1bWUgdGhhdCB0aGUgbGF0dGVyIHJlY29t bWVuZGF0aW9uIGVudmlzaW9ucyBhIHNjZW5hcmlvIHdoZXJlDQo+ID4+PiB0aGUgc2VjdXJlIHBv cnQgaGFzIGJlZW4gZGVwbG95ZWQgYW5kIHVzZWQgZm9yIGEgc2lnbmlmaWNhbnQgcGVyaW9kDQo+ ID4+PiBvZiB0aW1lLg0KPiA+Pg0KPiA+PiBZZXMuDQo+ID4NCj4gPiBJTUhPLCB0aGF0ICJydW5u aW5nIGNvZGUiIGRlcGxveW1lbnQgYW5kIHVzZSBleHBlcmllbmNlIHByb3ZpZGVzIGEgc29saWQN Cj4gPiBzdHJvbmcgZm91bmRhdGlvbiBmb3IgYSAiU0hPVUxEIE5PVCIgYnkgY29tcGFyaXNvbiB0 byB0aGUgIm5ldyByZXF1ZXN0DQo+ID4gZm9yIHR3byBwb3J0cyIgY2FzZSwgd2hlcmUgYSAiU0hP VUxEIE5PVCIgc3RyaWtlcyBtZSBhcyBwcmUtZXZhbHVhdGluZw0KPiA+IHByb3RvY29sIGRlc2ln biBkZWNpc2lvbnMsIHNpZ2h0IHVuc2VlbiwgZm9yIHByb3RvY29scyB0aGF0IG5vYm9keSdzDQo+ ID4gZXZlbiB0aG91Z2h0IG9mLCB5ZXQuDQo+DQo+IEluIGJvdGggY2FzZXMgd2UncmUgYXNzZXNz aW5nIGFuIGV2ZW50IGluIHRoZSBmdXR1cmUgLSBhcyB3aXRoICpldmVyeSoNCj4gUkZDIDIxMTkg cmVjb21tZW5kYXRpb24uIFRoZSBTSE9VTEQgTk9UIGlzbid0IHByZS1ldmFsdWF0aW5nIC0gaXQn cw0KPiBzYXlpbmcgdGhhdCB0aGVyZSBhcmUgZW5vdWdoIGNvbmNlcm5zIHdpdGggdGhpcyBwYXRo IHRoYXQgc3Ryb25nDQo+IGp1c3RpZmljYXRpb24gaXMgbmVlZGVkIC0ganVzdCBsaWtlICpldmVy eSogU0hPVUxEIG9yIFNIT1VMRCBOT1QgZXhjZXB0aW9uLg0KDQpJIGRyYXcgYSBkaXN0aW5jdGlv biBiZXR3ZWVuIHRoZSAiYWRkIGFuIGluc2VjdXJlIHBvcnQiIGNhc2UsIHdoZXJlIHdlIGF0DQps ZWFzdCBoYXZlICJydW5uaW5nIGNvZGUiIGZvciB0aGUgcHJvdG9jb2wgYW5kIHRoZSAibmV3IHJl cXVlc3QgZm9yIHR3byBwb3J0cyINCmNhc2Ugd2hlcmUgdGhlcmUgaXMgbm8gInJ1bm5pbmcgY29k ZSIgZm9yIHRoZSBwcm90b2NvbCBhbmQgdGhlIGluaXRpYWwgInJvdWdoDQpjb25zZW5zdXMiIChh c3N1bWluZyB0aGF0IHRoaXMgaXMgZnJvbSBhbiBJRVRGIFdHKSBydW5zIHRoZSBvdGhlciB3YXkg KGkuZS4sDQp0b3dhcmRzIHR3byBwb3J0cykuDQoNCj4gPj4+IEkganVzdCBkb24ndCB0aGluayB0 aGUgbGV2ZWwgb2YgcmVxdWlyZWQganVzdGlmaWNhdGlvbiBpcyBnb2luZw0KPiA+Pj4gdG8gcmlz ZSB0byB0aGF0IHN1ZmZpY2llbnQgdG8gb3ZlcnJpZGUgYSAiU0hPVUxEIE5PVCIgZm9yIGV2ZXJ5 DQo+ID4+PiBzaW5nbGUgcHJvdG9jb2wgZGVzaWduIHRoYXQgd2UgaGF2ZSB5ZXQgdG8gZW52aXNp b24uICBJIHdpc2ggbXkNCj4gPj4+IGZvcmVzaWdodCB3YXMgMjAvMjAgOi0pLg0KPiA+Pg0KPiA+ PiBGV0lXLCB0aGVyZSBhcmVuJ3QgYSBsb3Qgb2YgcHJvdG9jb2xzIHRoYXQgYXNrIGZvciBzZWN1 cmUgYW5kIGluc2VjdXJlDQo+ID4+IGF0IHRoZSBzYW1lIHRpbWUuIFRob3NlIGNvbWUgbW9zdGx5 IC0gaW5jcmVkaWJseSAtIGZyb20gSUVURiBXR3MsIHdoZXJlDQo+ID4+IHRoZXkgYXBwZWFyIHRv IGJlIChJTU8gYmxpbmRseSkgZm9sbG93aW5nIHBhc3QgcHJhY3RpY2UuDQo+ID4NCj4gPiBIZXJl IEkgYWdyZWUgLSB1c2Ugb2YgIndlJ3ZlIGFsd2F5cyBkb25lIGl0IHRoYXQgd2F5IiBhcyBhIHJh dGlvbmFsZSBTSE9VTEQNCj4gPiBiZSBzdHJvbmdseSBkaXNjb3VyYWdlZDsgYmV5b25kIHRoYXQs IEknZCBzdWdnZXN0IHBvaW50aW5nIG91dCB0aGF0IHJlcXVlc3RzDQo+ID4gZm9yIGJvdGggcG9y dHMgYXJlIHZpZXdlZCB3aXRoIHNpZ25pZmljYW50IHNrZXB0aWNpc20gYmVjYXVzZSB0aGF0IHJl YXNvbg0KPiA+IGhhcyBiZWVuIHRoZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgbWFueSBvZiB0aGVt LiAgSXQgd291bGQgYWxzbyBoZWxwIHRvDQo+ID4gYWRkIGRpc2N1c3Npb24gb2YgImp1c3RpZmll ZCBpbiB0ZXJtcyBvZiBzZXJ2aWNlIHByb3ZpZGVkIjoNCj4NCj4gQU9LLiBSYXRoZXIgdGhhbiBT SE9VTEQgTk9ULCBJJ2xsIGdvIHdpdGggImV4dHJlbWUgc2tlcHRpY2lzbSIgKGFsdGhvdWdoDQo+ IEkgYXNrIG90aGVycyBvbiB0aGUgbGlzdCB0byB3ZWlnaC1pbiBvbiB0aGlzIC0gSU1PLCAiZXh0 cmVtZSBza2VwdGljaXNtDQo+IGZvciBleGNlcHRpb25zIiBpcyBwcmVjaXNlbHkgd2hhdCBTSE9V TEQgTk9UIGltcGxpZXMpLg0KDQpGb3IgY2xhcml0eSwgSSB0aGluayB0aGUgImV4dHJlbWUgc2tl cHRpY2lzbSIgc2hvdWxkIGJlIGZvY3VzZWQgb24gcmVsaWFuY2UNCnVwb24gIndlJ3ZlIGFsd2F5 cyBkb25lIGl0IHRoYXQgd2F5IiBhcyB0aGUgcmF0aW9uYWxlLCBhcyBvcHBvc2VkIHRvIGJyb2Fk bHkNCm9uIGFsbCByZXF1ZXN0cyBmb3IgdHdvIHBvcnRzLiAgSU1ITywgdGhlIGxhdHRlciBvdWdo dCB0byBjb21lIGFjcm9zcyBhcyBhDQpyZXF1aXJlbWVudCB0byAic2hvdyB5b3VyIHdvcmsiIGFz IG9wcG9zZWQgdG8gc3Ryb25nIGRpc2NvdXJhZ2VtZW50IG9mIGFsbA0KcmVxdWVzdHMgZm9yIHR3 byBwb3J0cy4gIEluZGVwZW5kZW50IG9mIHRoZSBwcmVjaXNlIHdvcmRpbmcgaW4gUkZDIDIxMTks IEkNCndvdWxkIGV4cGVjdCAiU0hPVUxEIE5PVCIgdG8gYmUgcmVhZCBhcyBzdHJvbmcgZGlzY291 cmFnZW1lbnQgYnkgYSBzaWduaWZpY2FudA0KcG9ydGlvbiBvZiB0aGUgaW50ZW5kZWQgYXVkaWVu Y2UuDQoNCjwvV0cgY2hhaXIgaGF0IE9GRj4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlz aS5lZHVdDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDI4LCAyMDE0IDEyOjQyIFBNDQo+IFRvOiBC bGFjaywgRGF2aWQ7IFBhdWwgSG9mZm1hbg0KPiBDYzogdHN2d2dAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFt0c3Z3Z10gYWRkaXRpb25hbCBwb3J0cyBmb3Igc2VjdXJpdHkgLSBSZTogV0dMQyBm b3IgZHJhZnQtaWV0Zi0NCj4gdHN2d2ctcG9ydC11c2UtMDQgKHRvIGVuZCA2dGggSnVuZSkNCj4N Cj4NCj4NCj4gT24gNS8yOC8yMDE0IDk6MzIgQU0sIEJsYWNrLCBEYXZpZCB3cm90ZToNCj4gPiA8 V0cgY2hhaXIgaGF0IE9GRj4NCj4gPg0KPiA+Pj4gICAtIHNob3VsZCBhIHVzZXIgcmVxdWVzdCB0 d28gcG9ydHMgZm9yIGEgbmV3IHNlcnZpY2UsIG9uZQ0KPiA+Pj4gICBzZWN1cmUgYW5kIG9uZSBp bnNlY3VyZT8NCj4gPj4+DQo+ID4+PiBJIHN1c3BlY3QgdGhhdCB0aGUgYWR2aWNlIGZvciB0aGUg dGhpcyBvbmUgaXMgbGlrZWx5IHRvIGJlIGEgbG9uZw0KPiA+Pj4gdmVyc2lvbiBvZiAiaXQgZGVw ZW5kcyIgaW4gcHJhY3RpY2UuDQo+ID4+Pg0KPiA+Pj4gICAgICAgICAgIElNTywgdGhlIHNlY3Vy ZSBwb3J0IGlzIGVhc3ksIGlmIG90aGVyd2lzZQ0KPiA+Pj4gICAgICAgICAgIHdhcnJhbnRlZCAo bm90IGEgZHVwbGljYXRlIG9mIGV4aXN0aW5nIHNlcnZpY2UsIGUuZy4pLA0KPiA+Pj4gICAgICAg ICAgIGJ1dCB0aGUgaW5zZWN1cmUgb25lIHNpbWlsYXJseSBjcmVhdGVzIGEgbmV3DQo+ID4+PiAg ICAgICAgICAgdnVsbmVyYWJpbGl0eSwgYW5kIGFnYWluIEkgd291bGQgc2F5IFNIT1VMRCBOT1QN Cj4gPj4+ICAgICAgICAgICByZXF1ZXN0IGEgbmV3IGluc2VjdXJlIHBvcnQNCj4gPj4+DQo+ID4+ PiBJIGFncmVlIHdpdGggdGhlIHNlY3VyZSBwb3J0IGJlaW5nIGZpbmUsIGJ1dCBJJ20gbm90IGNv bWZvcnRhYmxlDQo+ID4+PiB3aXRoIGEgYmxhbmtldCAiU0hPVUxEIE5PVCIgcmVjb21tZW5kYXRp b24gZm9yIHRoZSBpbnNlY3VyZSBwb3J0Lg0KPiA+Pj4NCj4gPj4+IEkgdGhpbmsgdGhpcyBkZXBl bmRzIG9uIHRoZSBkZXRhaWxzIG9mIHRoZSBwcm90b2NvbC4gIEknZCBkZWZpbml0ZWx5DQo+ID4+ PiBzZXQgYW4gZXhwZWN0YXRpb24gdGhhdCBzb2xpZCBqdXN0aWZpY2F0aW9uIGZvciB0aGUgbmV3 IGluc2VjdXJlDQo+ID4+PiBwb3J0IHdpbGwgYmUgZXhwZWN0ZWQsIHdpdGggdGhlIGFwcGxpY2Fu dCBiZWluZyByZXNwb25zaWJsZSBmb3INCj4gPj4+IGp1c3RpZnlpbmcgd2h5IHVzZSBvZiBzZWN1 cml0eSBpcyBub3QgbWFuZGF0b3J5IGZvciB0aGUgcHJvdG9jb2wuDQo+ID4+PiBJZiB0aGF0IGp1 c3RpZmljYXRpb24gbWFrZXMgdGhlIGNhc2UsIHRoZW4gdGhlIGZpcmV3YWxsIGNvbnRyb2wNCj4g Pj4+IHJhdGlvbmFsZSAoYmVsb3cpIGRlZmluaXRlbHkgc291bmRzIHJlYXNvbmFibGUsIElNSE8u DQo+ID4+DQo+ID4+IFdoeSBpc24ndCB0aGF0IGEgU0hPVUxEIE5PVD8gQ2VydGFpbmx5IGEgYml0 IG1vcmUgdGV4dCBpcyBpbiBvcmRlciwgYnV0DQo+ID4+IGl0IHNlZW1zIGxpa2Ugd2UncmUgaW4g YWdyZWVtZW50IC0gZGVlcCBqdXN0aWZpY2F0aW9uIGlzIG5lZWRlZC4NCj4gPg0KPiA+IFdlJ3Jl IGRlYWxpbmcgd2l0aCBhIHByb2Nlc3MgYXMgb3Bwb3NlZCB0byBhIHByb3RvY29sIGhlcmUsIHNv IHRoZQ0KPiBmdW5jdGlvbmFsaXR5DQo+ID4gb2Ygc29tZSBmdXR1cmUgcHJvdG9jb2wgdGhhdCB3 aWxsIGFzayBmb3IgcG9ydHMgaXMgdW5rbm93biB0byB1cyBhdCB0aGUNCj4gbW9tZW50Lg0KPiA+ DQo+ID4gSSB0aGluayBJJ20gbW9zdGx5IGxvb2tpbmcgZm9yIHNvbWUgZ3JhZGF0aW9uIHdydCB0 aGUgb3RoZXIgU0hPVUxEIE5PVDoNCj4gPg0KPiA+Pj4gICAtIGdpdmVuIGEgY3VycmVudCBzZWN1 cmUgYXNzaWdubWVudCwgd2hhdA0KPiA+Pj4gICBpZiBhIHVzZXIgcmVxdWVzdHMgYSAobmV3KSBz ZWNvbmQgcG9ydCBmb3IgaW5zZWN1cmUgYWNjZXNzPw0KPiA+Pj4NCj4gPj4+ICAgICAgICAgICBp dCBzZWVtcyBsaWtlIGEgU0hPVUxEIE5PVCByZWNvbW1lbmRhdGlvbg0KPiA+Pj4gICAgICAgICAg IGlzIGFwcHJvcHJpYXRlOyB0aGlzIGNyZWF0ZXMgbmV3IHZ1bG5lcmFiaWxpdHk7DQo+ID4+Pg0K PiA+Pj4gSSBwcmVzdW1lIHRoYXQgdGhlIGxhdHRlciByZWNvbW1lbmRhdGlvbiBlbnZpc2lvbnMg YSBzY2VuYXJpbyB3aGVyZQ0KPiA+Pj4gdGhlIHNlY3VyZSBwb3J0IGhhcyBiZWVuIGRlcGxveWVk IGFuZCB1c2VkIGZvciBhIHNpZ25pZmljYW50IHBlcmlvZA0KPiA+Pj4gb2YgdGltZS4NCj4gPj4N Cj4gPj4gWWVzLg0KPiA+DQo+ID4gSU1ITywgdGhhdCAicnVubmluZyBjb2RlIiBkZXBsb3ltZW50 IGFuZCB1c2UgZXhwZXJpZW5jZSBwcm92aWRlcyBhIHNvbGlkDQo+ID4gc3Ryb25nIGZvdW5kYXRp b24gZm9yIGEgIlNIT1VMRCBOT1QiIGJ5IGNvbXBhcmlzb24gdG8gdGhlICJuZXcgcmVxdWVzdA0K PiA+IGZvciB0d28gcG9ydHMiIGNhc2UsIHdoZXJlIGEgIlNIT1VMRCBOT1QiIHN0cmlrZXMgbWUg YXMgcHJlLWV2YWx1YXRpbmcNCj4gPiBwcm90b2NvbCBkZXNpZ24gZGVjaXNpb25zLCBzaWdodCB1 bnNlZW4sIGZvciBwcm90b2NvbHMgdGhhdCBub2JvZHkncw0KPiA+IGV2ZW4gdGhvdWdodCBvZiwg eWV0Lg0KPg0KPiBJbiBib3RoIGNhc2VzIHdlJ3JlIGFzc2Vzc2luZyBhbiBldmVudCBpbiB0aGUg ZnV0dXJlIC0gYXMgd2l0aCAqZXZlcnkqDQo+IFJGQyAyMTE5IHJlY29tbWVuZGF0aW9uLiBUaGUg U0hPVUxEIE5PVCBpc24ndCBwcmUtZXZhbHVhdGluZyAtIGl0J3MNCj4gc2F5aW5nIHRoYXQgdGhl cmUgYXJlIGVub3VnaCBjb25jZXJucyB3aXRoIHRoaXMgcGF0aCB0aGF0IHN0cm9uZw0KPiBqdXN0 aWZpY2F0aW9uIGlzIG5lZWRlZCAtIGp1c3QgbGlrZSAqZXZlcnkqIFNIT1VMRCBvciBTSE9VTEQg Tk9UIGV4Y2VwdGlvbi4NCj4NCj4gPj4+IEkganVzdCBkb24ndCB0aGluayB0aGUgbGV2ZWwgb2Yg cmVxdWlyZWQganVzdGlmaWNhdGlvbiBpcyBnb2luZw0KPiA+Pj4gdG8gcmlzZSB0byB0aGF0IHN1 ZmZpY2llbnQgdG8gb3ZlcnJpZGUgYSAiU0hPVUxEIE5PVCIgZm9yIGV2ZXJ5DQo+ID4+PiBzaW5n bGUgcHJvdG9jb2wgZGVzaWduIHRoYXQgd2UgaGF2ZSB5ZXQgdG8gZW52aXNpb24uICBJIHdpc2gg bXkNCj4gPj4+IGZvcmVzaWdodCB3YXMgMjAvMjAgOi0pLg0KPiA+Pg0KPiA+PiBGV0lXLCB0aGVy ZSBhcmVuJ3QgYSBsb3Qgb2YgcHJvdG9jb2xzIHRoYXQgYXNrIGZvciBzZWN1cmUgYW5kIGluc2Vj dXJlDQo+ID4+IGF0IHRoZSBzYW1lIHRpbWUuIFRob3NlIGNvbWUgbW9zdGx5IC0gaW5jcmVkaWJs eSAtIGZyb20gSUVURiBXR3MsIHdoZXJlDQo+ID4+IHRoZXkgYXBwZWFyIHRvIGJlIChJTU8gYmxp bmRseSkgZm9sbG93aW5nIHBhc3QgcHJhY3RpY2UuDQo+ID4NCj4gPiBIZXJlIEkgYWdyZWUgLSB1 c2Ugb2YgIndlJ3ZlIGFsd2F5cyBkb25lIGl0IHRoYXQgd2F5IiBhcyBhIHJhdGlvbmFsZSBTSE9V TEQNCj4gPiBiZSBzdHJvbmdseSBkaXNjb3VyYWdlZDsgYmV5b25kIHRoYXQsIEknZCBzdWdnZXN0 IHBvaW50aW5nIG91dCB0aGF0IHJlcXVlc3RzDQo+ID4gZm9yIGJvdGggcG9ydHMgYXJlIHZpZXdl ZCB3aXRoIHNpZ25pZmljYW50IHNrZXB0aWNpc20gYmVjYXVzZSB0aGF0IHJlYXNvbg0KPiA+IGhh cyBiZWVuIHRoZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgbWFueSBvZiB0aGVtLiAgSXQgd291bGQg YWxzbyBoZWxwIHRvDQo+ID4gYWRkIGRpc2N1c3Npb24gb2YgImp1c3RpZmllZCBpbiB0ZXJtcyBv ZiBzZXJ2aWNlIHByb3ZpZGVkIjoNCj4NCj4gQU9LLiBSYXRoZXIgdGhhbiBTSE9VTEQgTk9ULCBJ J2xsIGdvIHdpdGggImV4dHJlbWUgc2tlcHRpY2lzbSIgKGFsdGhvdWdoDQo+IEkgYXNrIG90aGVy cyBvbiB0aGUgbGlzdCB0byB3ZWlnaC1pbiBvbiB0aGlzIC0gSU1PLCAiZXh0cmVtZSBza2VwdGlj aXNtDQo+IGZvciBleGNlcHRpb25zIiBpcyBwcmVjaXNlbHkgd2hhdCBTSE9VTEQgTk9UIGltcGxp ZXMpLg0KPg0KPiBKb2UNCj4NCj4gPj4gTXkga2V5IGNvbmNlcm4gaXMgIndoeSBpcyB0aGUgaW5z ZWN1cmUgcG9ydCBuZWVkZWQiPyBNb3N0IG9mIHRoZSB0aW1lDQo+ID4+IHRoZSBqdXN0aWZpY2F0 aW9uIGlzIHB1cmUgcGVyZm9ybWFuY2UgLSBydW5uaW5nIHNlY3VyaXR5IG9uIHRoZSBzZXJ2aWNl DQo+ID4+IHdpbGwgbWFrZSBpdCB0b28gc2xvdywgYW5kIHRoaXMgd2lsbCBhbGxvdyBmYXN0ZXIg cGVyZm9ybWFuY2UgaW5zaWRlIGFuDQo+ID4+IGVudGVycHJpc2UuIFRoYXQgbWlnaHQgYmUgdHJ1 ZSwgYnV0IGl0IGFsc28gbmVlZHMgdG8gYmUganVzdGlmaWVkIGluDQo+ID4+IHRlcm1zIG9mIHRo ZSBzZXJ2aWNlIGJlaW5nIHByb3ZpZGVkIC0gdGhhdCB0aGlzIGlzIGEgaGlnaC10aHJvdWdocHV0 IG9yDQo+ID4+IGhpZ2gtdHJhbnNhY3Rpb24gZnJlcXVlbmN5IHN5c3RlbSB0aGF0IG5lZWRzIGhp Z2ggcGVyZm9ybWFuY2UgaW5zaWRlDQo+ID4+IHByb3RlY3RlZCBlbnRlcnByaXNlcy4NCj4gPg0K PiA+IDwvV0cgY2hhaXIgaGF0IE9GRj4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiAtLURhdmlkDQo+ ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBKb2Ug VG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPiA+PiBTZW50OiBUdWVzZGF5LCBNYXkgMjcs IDIwMTQgMTA6MDAgUE0NCj4gPj4gVG86IEJsYWNrLCBEYXZpZDsgUGF1bCBIb2ZmbWFuDQo+ID4+ IENjOiB0c3Z3Z0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3RzdndnXSBhZGRpdGlvbmFs IHBvcnRzIGZvciBzZWN1cml0eSAtIFJlOiBXR0xDIGZvciBkcmFmdC0NCj4gaWV0Zi0NCj4gPj4g dHN2d2ctcG9ydC11c2UtMDQgKHRvIGVuZCA2dGggSnVuZSkNCj4gPj4NCj4gPj4NCj4gPj4NCj4g Pj4gT24gNS8yNy8yMDE0IDU6NDAgUE0sIEJsYWNrLCBEYXZpZCB3cm90ZToNCj4gPj4+IEpvZSwN Cj4gPj4+DQo+ID4+PiA8V0cgY2hhaXIgaGF0IE9GRj4NCj4gPj4+DQo+ID4+Pj4gSWYgeW91IGRp c2FncmVlIHdpdGggdGhlIGFuYWx5c2lzLCB5b3Ugc2hvdWxkIHByZXNlbnQgYSBjb3VudGVyYXJn dW1lbnQuDQo+ID4+Pg0KPiA+Pj4gT2ssIEknbGwgdHJ5IC4uLiA7LSkuDQo+ID4+Pg0KPiA+Pj4g SXQgbWlnaHQgaGVscCBpZiB0aGlzIGhhZCBzb21ld2hhdCBtb3JlIG9mIGEgZmxhdm9yIG9mIGRv Y3VtZW50aW5nIHRoZQ0KPiA+Pj4gcmV2aWV3IGNyaXRlcmlhIHRoYXQgYXJlIGN1cnJlbnRseSB1 c2VkLCBhbHRob3VnaCBJIGRvIHRoaW5rIGF0IGxlYXN0DQo+ID4+PiBvbmUgIlNIT1VMRCBOT1Qi IGlzIGxpa2VseSB0byB0dXJuIHVwIGluIHRoZSBmaW5hbCB0ZXh0Lg0KPiA+Pj4NCj4gPj4+IEkn ZCBjZXJ0YWlubHkgbGlrZSB0byBzZWUgc29tZSBTZWN1cml0eSBBcmVhIGlucHV0IChhbmQgcHJv YmFibHkgYWxzbw0KPiA+Pj4gT1BTLCBhcyBmaXJld2FsbHMgcGxheSBhIHByb21pbmVudCByb2xl KSwgYnV0IHNwZWFraW5nIGZvciBteXNlbGYsDQo+ID4+PiBJIHRoaW5rIG9mZmVyaW5nIHNlY3Vy aXR5IGFkdmljZSBpcyB3ZWxsIHdpdGhpbiByZWFzb24gaGVyZSAuLi4NCj4gPj4+DQo+ID4+PiBH b2luZyBiYWNrIHRvIHRoZSB0aHJlZSBzY2VuYXJpb3MgYXQgdGhlIHN0YXJ0IG9mIHRoaXMgdGhy ZWFkLCB0aGUNCj4gPj4+IHByb3Bvc2FscyBmb3IgdGhlIGZpcnN0IHR3byBzZWVtIHJlYXNvbmFi bGUgKElNSE8pOg0KPiA+Pj4NCj4gPj4+ICAgLSBnaXZlbiBhIGN1cnJlbnQgbm9uLXNlY3VyZSBh c3NpZ25tZW50LCB3aGF0IGlmIGENCj4gPj4+ICAgdXNlciByZXF1ZXN0cyBhIChuZXcpIHNlY29u ZCBwb3J0IGZvciBzZWN1cmUgYWNjZXNzPw0KPiA+Pj4NCj4gPj4+ICAgICAgICAgICB0aGlzIGlz IGZpbmUsIGlmIG5vdCBhIGdvb2QgaWRlYTsNCj4gPj4+DQo+ID4+PiAgIC0gZ2l2ZW4gYSBjdXJy ZW50IHNlY3VyZSBhc3NpZ25tZW50LCB3aGF0DQo+ID4+PiAgIGlmIGEgdXNlciByZXF1ZXN0cyBh IChuZXcpIHNlY29uZCBwb3J0IGZvciBpbnNlY3VyZSBhY2Nlc3M/DQo+ID4+Pg0KPiA+Pj4gICAg ICAgICAgIGl0IHNlZW1zIGxpa2UgYSBTSE9VTEQgTk9UIHJlY29tbWVuZGF0aW9uDQo+ID4+PiAg ICAgICAgICAgaXMgYXBwcm9wcmlhdGU7IHRoaXMgY3JlYXRlcyBuZXcgdnVsbmVyYWJpbGl0eTsN Cj4gPj4+DQo+ID4+PiBJIHByZXN1bWUgdGhhdCB0aGUgbGF0dGVyIHJlY29tbWVuZGF0aW9uIGVu dmlzaW9ucyBhIHNjZW5hcmlvIHdoZXJlDQo+ID4+PiB0aGUgc2VjdXJlIHBvcnQgaGFzIGJlZW4g ZGVwbG95ZWQgYW5kIHVzZWQgZm9yIGEgc2lnbmlmaWNhbnQgcGVyaW9kDQo+ID4+PiBvZiB0aW1l Lg0KPiA+Pg0KPiA+PiBZZXMuDQo+ID4+DQo+ID4+PiBJbiB0aGF0IGNhc2UsIEkgdGhpbmsgYSAi U0hPVUxEIE5PVCIgaXMgb2ssIGFzIEknZCB3YW50IHRvDQo+ID4+PiBzZWUgc29tZSBoZWF2eS1k dXR5IHNlcmlvdXMganVzdGlmaWNhdGlvbiBmb3IgYWRkaW5nIHRoZSBpbnNlY3VyZQ0KPiA+Pj4g cG9ydC4gIFRoZSBkcmFmdCBzaG91bGQgc3RhdGUgdGhhdCBwcmVzdW1wdGlvbiwgdGhvdWdoLCBh cyBkZXBsb3ltZW50DQo+ID4+PiBkaWZmaWN1bHRpZXMvZXhwZXJpZW5jZSBtaWdodCByZXN1bHQg aW4gc29tZXRoaW5nIGNsb3NlciB0byB0aGUgdGhpcmQNCj4gPj4+IHNjZW5hcmlvLg0KPiA+Pg0K PiA+PiBSaWdodCAtIHRoYXQncyB0aGUgcG9pbnQgb2YgdGhlIFNIT1VMRCBOT1QuIEl0J3Mgbm90 IGEgTVVTVCBOT1QuIEl0IGp1c3QNCj4gPj4gbmVlZHMgdmVyeSBoZWF2eSBqdXN0aWZpY2F0aW9u Lg0KPiA+Pg0KPiA+Pj4gICAtIHNob3VsZCBhIHVzZXIgcmVxdWVzdCB0d28gcG9ydHMgZm9yIGEg bmV3IHNlcnZpY2UsIG9uZQ0KPiA+Pj4gICBzZWN1cmUgYW5kIG9uZSBpbnNlY3VyZT8NCj4gPj4+ DQo+ID4+PiBJIHN1c3BlY3QgdGhhdCB0aGUgYWR2aWNlIGZvciB0aGUgdGhpcyBvbmUgaXMgbGlr ZWx5IHRvIGJlIGEgbG9uZw0KPiA+Pj4gdmVyc2lvbiBvZiAiaXQgZGVwZW5kcyIgaW4gcHJhY3Rp Y2UuDQo+ID4+Pg0KPiA+Pj4gICAgICAgICAgIElNTywgdGhlIHNlY3VyZSBwb3J0IGlzIGVhc3ks IGlmIG90aGVyd2lzZQ0KPiA+Pj4gICAgICAgICAgIHdhcnJhbnRlZCAobm90IGEgZHVwbGljYXRl IG9mIGV4aXN0aW5nIHNlcnZpY2UsIGUuZy4pLA0KPiA+Pj4gICAgICAgICAgIGJ1dCB0aGUgaW5z ZWN1cmUgb25lIHNpbWlsYXJseSBjcmVhdGVzIGEgbmV3DQo+ID4+PiAgICAgICAgICAgdnVsbmVy YWJpbGl0eSwgYW5kIGFnYWluIEkgd291bGQgc2F5IFNIT1VMRCBOT1QNCj4gPj4+ICAgICAgICAg ICByZXF1ZXN0IGEgbmV3IGluc2VjdXJlIHBvcnQNCj4gPj4+DQo+ID4+PiBJIGFncmVlIHdpdGgg dGhlIHNlY3VyZSBwb3J0IGJlaW5nIGZpbmUsIGJ1dCBJJ20gbm90IGNvbWZvcnRhYmxlDQo+ID4+ PiB3aXRoIGEgYmxhbmtldCAiU0hPVUxEIE5PVCIgcmVjb21tZW5kYXRpb24gZm9yIHRoZSBpbnNl Y3VyZSBwb3J0Lg0KPiA+Pj4NCj4gPj4+IEkgdGhpbmsgdGhpcyBkZXBlbmRzIG9uIHRoZSBkZXRh aWxzIG9mIHRoZSBwcm90b2NvbC4gIEknZCBkZWZpbml0ZWx5DQo+ID4+PiBzZXQgYW4gZXhwZWN0 YXRpb24gdGhhdCBzb2xpZCBqdXN0aWZpY2F0aW9uIGZvciB0aGUgbmV3IGluc2VjdXJlDQo+ID4+ PiBwb3J0IHdpbGwgYmUgZXhwZWN0ZWQsIHdpdGggdGhlIGFwcGxpY2FudCBiZWluZyByZXNwb25z aWJsZSBmb3INCj4gPj4+IGp1c3RpZnlpbmcgd2h5IHVzZSBvZiBzZWN1cml0eSBpcyBub3QgbWFu ZGF0b3J5IGZvciB0aGUgcHJvdG9jb2wuDQo+ID4+PiBJZiB0aGF0IGp1c3RpZmljYXRpb24gbWFr ZXMgdGhlIGNhc2UsIHRoZW4gdGhlIGZpcmV3YWxsIGNvbnRyb2wNCj4gPj4+IHJhdGlvbmFsZSAo YmVsb3cpIGRlZmluaXRlbHkgc291bmRzIHJlYXNvbmFibGUsIElNSE8uDQo+ID4+DQo+ID4+IFdo eSBpc24ndCB0aGF0IGEgU0hPVUxEIE5PVD8gQ2VydGFpbmx5IGEgYml0IG1vcmUgdGV4dCBpcyBp biBvcmRlciwgYnV0DQo+ID4+IGl0IHNlZW1zIGxpa2Ugd2UncmUgaW4gYWdyZWVtZW50IC0gZGVl cCBqdXN0aWZpY2F0aW9uIGlzIG5lZWRlZC4NCj4gPj4NCj4gPj4+IEkganVzdCBkb24ndCB0aGlu ayB0aGUgbGV2ZWwgb2YgcmVxdWlyZWQganVzdGlmaWNhdGlvbiBpcyBnb2luZw0KPiA+Pj4gdG8g cmlzZSB0byB0aGF0IHN1ZmZpY2llbnQgdG8gb3ZlcnJpZGUgYSAiU0hPVUxEIE5PVCIgZm9yIGV2 ZXJ5DQo+ID4+PiBzaW5nbGUgcHJvdG9jb2wgZGVzaWduIHRoYXQgd2UgaGF2ZSB5ZXQgdG8gZW52 aXNpb24uICBJIHdpc2ggbXkNCj4gPj4+IGZvcmVzaWdodCB3YXMgMjAvMjAgOi0pLg0KPiA+Pg0K PiA+PiBGV0lXLCB0aGVyZSBhcmVuJ3QgYSBsb3Qgb2YgcHJvdG9jb2xzIHRoYXQgYXNrIGZvciBz ZWN1cmUgYW5kIGluc2VjdXJlDQo+ID4+IGF0IHRoZSBzYW1lIHRpbWUuIFRob3NlIGNvbWUgbW9z dGx5IC0gaW5jcmVkaWJseSAtIGZyb20gSUVURiBXR3MsIHdoZXJlDQo+ID4+IHRoZXkgYXBwZWFy IHRvIGJlIChJTU8gYmxpbmRseSkgZm9sbG93aW5nIHBhc3QgcHJhY3RpY2UuDQo+ID4+DQo+ID4+ IE15IGtleSBjb25jZXJuIGlzICJ3aHkgaXMgdGhlIGluc2VjdXJlIHBvcnQgbmVlZGVkIj8gTW9z dCBvZiB0aGUgdGltZQ0KPiA+PiB0aGUganVzdGlmaWNhdGlvbiBpcyBwdXJlIHBlcmZvcm1hbmNl IC0gcnVubmluZyBzZWN1cml0eSBvbiB0aGUgc2VydmljZQ0KPiA+PiB3aWxsIG1ha2UgaXQgdG9v IHNsb3csIGFuZCB0aGlzIHdpbGwgYWxsb3cgZmFzdGVyIHBlcmZvcm1hbmNlIGluc2lkZSBhbg0K PiA+PiBlbnRlcnByaXNlLiBUaGF0IG1pZ2h0IGJlIHRydWUsIGJ1dCBpdCBhbHNvIG5lZWRzIHRv IGJlIGp1c3RpZmllZCBpbg0KPiA+PiB0ZXJtcyBvZiB0aGUgc2VydmljZSBiZWluZyBwcm92aWRl ZCAtIHRoYXQgdGhpcyBpcyBhIGhpZ2gtdGhyb3VnaHB1dCBvcg0KPiA+PiBoaWdoLXRyYW5zYWN0 aW9uIGZyZXF1ZW5jeSBzeXN0ZW0gdGhhdCBuZWVkcyBoaWdoIHBlcmZvcm1hbmNlIGluc2lkZQ0K PiA+PiBwcm90ZWN0ZWQgZW50ZXJwcmlzZXMuDQo+ID4+DQo+ID4+PiAgIC0gR0lWRU4gYSByZXF1 ZXN0IGZvciBhbiBpbnNlY3VyZSBhbmQgc2VjdXJlIHBvcnQsIHdoYXQNCj4gPj4+ICAgYXJlIGFw cHJvcHJpYXRlIGp1c3RpZmljYXRpb25zPw0KPiA+Pj4NCj4gPj4+ICAgICAgICAgICBJTU8sIHNl cGFyYXRlIGZpcmV3YWxsIGNvbnRyb2wgaXMgYSBzdWZmaWNpZW50DQo+ID4+PiAgICAgICAgICAg cmVhc29uLg0KPiA+Pj4NCj4gPj4+ICAgICAgICAgICBob3dldmVyLCBwZXJmb3JtYW5jZSBzaG91 bGQgbm90IGJlIC0gaS5lLiwgaWYNCj4gPj4+ICAgICAgICAgICBib3RoIHBvcnRzIHdpbGwgdHlw aWNhbGx5IGhhdmUgdGhlIHNhbWUgZmlyZXdhbGwNCj4gPj4+ICAgICAgICAgICBjb25maWd1cmF0 aW9uLCB0aGVuIG9ubHkgb25lIHBvcnQgaXMgbmVlZGVkDQo+ID4+PiAgICAgICAgICAgYW5kIHNl Y3VyaXR5IHNob3VsZCBiZSBuZWdvdGlhdGVkIGFzIHByZXNlbnQvYWJzZW50DQo+ID4+PiAgICAg ICAgICAgaW4tYmFuZC4gVGhlIHBlcmZvcm1hbmNlIGltcGFjdCBvZiB0aGF0IG5lZ290aWF0aW9u DQo+ID4+PiAgICAgICAgICAgKElNTykgc2hvdWxkIG5vdCBmYWN0b3IgaW50byB3aGV0aGVyIGFu IGFkZGl0aW9uYWwNCj4gPj4+ICAgICAgICAgICBwb3J0IHNob3VsZCBiZSBhc3NpZ25lZC4NCj4g Pj4+DQo+ID4+PiBJIHRoaW5rIHRoZSB0ZXh0IG9uIHBlcmZvcm1hbmNlIHNob3VsZCBiZSBleHBs aWNpdCB0aGF0IHRoZQ0KPiA+Pj4gcGVyZm9ybWFuY2UgY29uY2VybiBpcyBuZWdvdGlhdGlvbiBy b3VuZCB0cmlwIGF2b2lkYW5jZS4NCj4gPj4NCj4gPj4gVGhlcmUgYXJlIGEgZmV3IGRpZmZlcmVu dCBwZXJmb3JtYW5jZSBpc3N1ZXM6DQo+ID4+DQo+ID4+ICAgIC0gcm91bmQtdHJpcCBkZWxheXMN Cj4gPj4gICAgLSB0aHJvdWdocHV0IG92ZXJoZWFkIChwZXIgYnl0ZSkNCj4gPj4gICAgLSBtZXNz YWdlIG92ZXJoZWFkIChwZXIgbWVzc2FnZSkNCj4gPj4NCj4gPj4gSm9lDQo+ID4+DQo+ID4+PiA8 L1dHIGNoYWlyIGhhdCBPRkY+DQo+ID4+Pg0KPiA+Pj4gVGhhbmtzLA0KPiA+Pj4gLS1EYXZpZA0K PiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IEpv ZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+ID4+Pj4gU2VudDogVHVlc2RheSwgTWF5 IDI3LCAyMDE0IDY6MDMgUE0NCj4gPj4+PiBUbzogUGF1bCBIb2ZmbWFuDQo+ID4+Pj4gQ2M6IEJs YWNrLCBEYXZpZDsgdHN2d2dAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogW3RzdndnXSBh ZGRpdGlvbmFsIHBvcnRzIGZvciBzZWN1cml0eSAtIFJlOiBXR0xDIGZvciBkcmFmdC0NCj4gPj4g aWV0Zi0NCj4gPj4+PiB0c3Z3Zy1wb3J0LXVzZS0wNCAodG8gZW5kIDZ0aCBKdW5lKQ0KPiA+Pj4+ DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IE9uIDUvMjcvMjAxNCAyOjQ5IFBNLCBQYXVsIEhvZmZt YW4gd3JvdGU6DQo+ID4+Pj4+IElzIHRoaXMgbmV3IGFkdmljZSBiYXNlZCBvbiBhbnkgYWN0dWFs IGV2aWRlbmNlIG9yIGV2ZW4gYSBzZWN1cml0eQ0KPiA+PiBhbmFseXNpcz8NCj4gPj4+Pg0KPiA+ Pj4+IEl0J3MgYmFzZWQgb24gOCB5ZWFycyBvZiBydW5uaW5nIHRoZSByZXZpZXcgdGVhbSBhbmQg ZGlzY3Vzc2lvbnMgd2l0aGluDQo+ID4+Pj4gdGhhdCB0ZWFtLiBJdCdzIGJhc2VkIG9uIHRoZSBh bmFseXNpcyBwcm92aWRlZC4NCj4gPj4+Pg0KPiA+Pj4+IElmIHlvdSBkaXNhZ3JlZSB3aXRoIHRo ZSBhbmFseXNpcywgeW91IHNob3VsZCBwcmVzZW50IGEgY291bnRlcmFyZ3VtZW50Lg0KPiA+Pj4+ DQo+ID4+Pj4+IEZ1cnRoZXIsIGEgc3RhdGVtZW50IG9mICJTSE9VTEQgTk9UIHJlcXVlc3QiIHNv dW5kcyBhIGhlbGwgb2YgYSBsb3QgbW9yZQ0KPiA+Pj4+PiBsaWtlIGEgZGVtYW5kIHRoYW4gYWR2 aWNlLg0KPiA+Pj4+DQo+ID4+Pj4gV2hhdCBleGFjdGx5IGNhbiB3ZSAqZGVtYW5kKiBvZiBhIHVz ZXIgbWFraW5nIGFuIGFwcGxpY2F0aW9uIG90aGVyIHRoYXQNCj4gPj4+PiB0byBwcm92aWRlIGFk dmljZT8gSXQncyBub3QgYWR2aWNlIHRvIElBTkEgb3IgdGhlIHBvcnRzIHRlYW0gaW4gaG93IHRv DQo+ID4+Pj4gbWFrZSBhIGRlY2lzaW9uLg0KPiA+Pj4+DQo+ID4+Pj4+IFRoaXMgZ2V0cyB0byB0 aGUgY3J1eCBvZiBteSBjb25jZXJuIG9mIHRoZQ0KPiA+Pj4+PiBkb2N1bWVudDogaXQgZmVlbCBs aWtlIHRoZSBhZHZpY2UgaXMgbWVhbnQgdG8gY29tZSBmcm9tIG9uIGhpZ2ggKG5hbWVseSwNCj4g Pj4+Pj4gc29tZW9uZSB3aG8gY2FuIGJsb2NrIElBTkEgcmVxdWVzdHMpLCBub3QgZnJpZW5kbHkg YWR2aWNlIGZyb20gb25lDQo+ID4+Pj4+IGRldmVsb3BlciB0byBhbm90aGVyLg0KPiA+Pj4+DQo+ ID4+Pj4gQ2FuIHlvdSBwcm92aWRlIGEgcmF0aW9uYWxlIGZvciB0aGF0IGNsYWltIG90aGVyIHRo YW4gImJlY2F1c2UgSm9lIFRvdWNoDQo+ID4+Pj4gd3JvdGUgaXQiPw0KPiA+Pj4+DQo+ID4+Pj4+ IFdlIHdlbnQgdGhyb3VnaCB0aGlzIGluIHRoZSBkaXNjdXNzaW9uIGEgZmV3IHllYXJzDQo+ID4+ Pj4+IGFnbywgYW5kIGl0IHNlZW1lZCB0aGVuIHRoYXQgVFNWV0cgZGlkbid0IGFncmVlIHRoYXQg c3VjaCBoZWF2eS1oYW5kZWQNCj4gPj4+Pj4gImFkdmljZSIsIHBhcnRpY3VsYXJseSB3aXRob3V0 IHNwZWNpZmljIGp1c3RpZmljYXRpb24sIHdhcyB0aGUgd2F5IHRvDQo+IGdvLg0KPiA+Pj4+DQo+ ID4+Pj4gVFNWV0cgYWdyZWVkIHRoYXQgbGltaXRpbmcgSUFOQSB3YXMgbm90IGFwcHJvcHJpYXRl OyB0aGlzIGRvY3VtZW50DQo+ID4+Pj4gZG9lc24ndCBsaW1pdCBJQU5BLg0KPiA+Pj4+DQo+ID4+ Pj4gQW5kIHNwZWNpZmljIGp1c3RpZmljYXRpb24gaXMgcHJvdmlkZWQgaW4gdGhlIGRpc2N1c3Np b24gSSBnYXZlLiBBZ2FpbiwNCj4gPj4+PiBpZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGF0IGRpc2N1 c3Npb24sIHBsZWFzZSBleHBsYWluLg0KPiA+Pj4+DQo+ID4+Pj4gRS5nLiwgZG8geW91IGFjdHVh bGx5IHRoaW5rIGl0J3MgZ29vZCBzZWN1cml0eSBwcmFjdGljZSB0byBjcmVhdGUgbmV3LA0KPiA+ Pj4+IGluc2VjdXJlIHNlcnZpY2VzPyBJZiBzbywgb24gd2hhdCBiYXNpcyBvZiBnb29kIHNlY3Vy aXR5IHByYWN0aWNlPw0KPiA+Pj4+DQo+ID4+Pj4gSm9lDQo+ID4+Pg0KPiA+DQoNCg== From nobody Thu May 29 08:57:57 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9229B1A0441 for ; Thu, 29 May 2014 08:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOAF81iaY9jI for ; Thu, 29 May 2014 08:57:48 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E441A0426 for ; Thu, 29 May 2014 08:57:48 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4TFvQ5Q023833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 May 2014 08:57:28 -0700 (PDT) Message-ID: <538758E6.2080208@isi.edu> Date: Thu, 29 May 2014 08:57:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C663209@MX15A.corp.emc.com> <53854308.8020705@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C66334F@MX15A.corp.emc.com> <538611F4.8000905@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C66364B@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C66364B@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/s167fALy_5DeShwHd9zpoRPfGo0 Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:57:51 -0000 On 5/29/2014 8:34 AM, Black, David wrote: > ... > I draw a distinction between the "add an insecure port" case, where we at > least have "running code" for the protocol and the "new request for two ports" > case where there is no "running code" for the protocol and the initial "rough > consensus" (assuming that this is from an IETF WG) runs the other way (i.e., > towards two ports). The former is certainly more potentially dangerous than the latter. >>>>> I just don't think the level of required justification is going >>>>> to rise to that sufficient to override a "SHOULD NOT" for every >>>>> single protocol design that we have yet to envision. I wish my >>>>> foresight was 20/20 :-). >>>> >>>> FWIW, there aren't a lot of protocols that ask for secure and insecure >>>> at the same time. Those come mostly - incredibly - from IETF WGs, where >>>> they appear to be (IMO blindly) following past practice. >>> >>> Here I agree - use of "we've always done it that way" as a rationale SHOULD >>> be strongly discouraged; beyond that, I'd suggest pointing out that requests >>> for both ports are viewed with significant skepticism because that reason >>> has been the primary rationale for many of them. It would also help to >>> add discussion of "justified in terms of service provided": >> >> AOK. Rather than SHOULD NOT, I'll go with "extreme skepticism" (although >> I ask others on the list to weigh-in on this - IMO, "extreme skepticism >> for exceptions" is precisely what SHOULD NOT implies). > > For clarity, I think the "extreme skepticism" should be focused on reliance > upon "we've always done it that way" as the rationale, as opposed to broadly > on all requests for two ports. IMHO, the latter ought to come across as a > requirement to "show your work" as opposed to strong discouragement of all > requests for two ports. Independent of the precise wording in RFC 2119, I > would expect "SHOULD NOT" to be read as strong discouragement by a significant > portion of the intended audience. The problem with "show your work" is that there is no other RFC2119 language for that, which means it will have no teeth when the request comes for the WG. I.e., in the case where WG rough consensus seeks two ports, that itself will be seen as sufficient unless this BCP says otherwise. Maybe we could say "SHOULD NOT ask for two ports", but add "unless (as with any SHOULD-level recommendation) sufficient direct rationale for an exception is provided"? Joe > > > Thanks, > --David > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Wednesday, May 28, 2014 12:42 PM >> To: Black, David; Paul Hoffman >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf- >> tsvwg-port-use-04 (to end 6th June) >> >> >> >> On 5/28/2014 9:32 AM, Black, David wrote: >>> >>> >>>>> - should a user request two ports for a new service, one >>>>> secure and one insecure? >>>>> >>>>> I suspect that the advice for the this one is likely to be a long >>>>> version of "it depends" in practice. >>>>> >>>>> IMO, the secure port is easy, if otherwise >>>>> warranted (not a duplicate of existing service, e.g.), >>>>> but the insecure one similarly creates a new >>>>> vulnerability, and again I would say SHOULD NOT >>>>> request a new insecure port >>>>> >>>>> I agree with the secure port being fine, but I'm not comfortable >>>>> with a blanket "SHOULD NOT" recommendation for the insecure port. >>>>> >>>>> I think this depends on the details of the protocol. I'd definitely >>>>> set an expectation that solid justification for the new insecure >>>>> port will be expected, with the applicant being responsible for >>>>> justifying why use of security is not mandatory for the protocol. >>>>> If that justification makes the case, then the firewall control >>>>> rationale (below) definitely sounds reasonable, IMHO. >>>> >>>> Why isn't that a SHOULD NOT? Certainly a bit more text is in order, but >>>> it seems like we're in agreement - deep justification is needed. >>> >>> We're dealing with a process as opposed to a protocol here, so the >> functionality >>> of some future protocol that will ask for ports is unknown to us at the >> moment. >>> >>> I think I'm mostly looking for some gradation wrt the other SHOULD NOT: >>> >>>>> - given a current secure assignment, what >>>>> if a user requests a (new) second port for insecure access? >>>>> >>>>> it seems like a SHOULD NOT recommendation >>>>> is appropriate; this creates new vulnerability; >>>>> >>>>> I presume that the latter recommendation envisions a scenario where >>>>> the secure port has been deployed and used for a significant period >>>>> of time. >>>> >>>> Yes. >>> >>> IMHO, that "running code" deployment and use experience provides a solid >>> strong foundation for a "SHOULD NOT" by comparison to the "new request >>> for two ports" case, where a "SHOULD NOT" strikes me as pre-evaluating >>> protocol design decisions, sight unseen, for protocols that nobody's >>> even thought of, yet. >> >> In both cases we're assessing an event in the future - as with *every* >> RFC 2119 recommendation. The SHOULD NOT isn't pre-evaluating - it's >> saying that there are enough concerns with this path that strong >> justification is needed - just like *every* SHOULD or SHOULD NOT exception. >> >>>>> I just don't think the level of required justification is going >>>>> to rise to that sufficient to override a "SHOULD NOT" for every >>>>> single protocol design that we have yet to envision. I wish my >>>>> foresight was 20/20 :-). >>>> >>>> FWIW, there aren't a lot of protocols that ask for secure and insecure >>>> at the same time. Those come mostly - incredibly - from IETF WGs, where >>>> they appear to be (IMO blindly) following past practice. >>> >>> Here I agree - use of "we've always done it that way" as a rationale SHOULD >>> be strongly discouraged; beyond that, I'd suggest pointing out that requests >>> for both ports are viewed with significant skepticism because that reason >>> has been the primary rationale for many of them. It would also help to >>> add discussion of "justified in terms of service provided": >> >> AOK. Rather than SHOULD NOT, I'll go with "extreme skepticism" (although >> I ask others on the list to weigh-in on this - IMO, "extreme skepticism >> for exceptions" is precisely what SHOULD NOT implies). >> >> Joe >> >>>> My key concern is "why is the insecure port needed"? Most of the time >>>> the justification is pure performance - running security on the service >>>> will make it too slow, and this will allow faster performance inside an >>>> enterprise. That might be true, but it also needs to be justified in >>>> terms of the service being provided - that this is a high-throughput or >>>> high-transaction frequency system that needs high performance inside >>>> protected enterprises. >>> >>> >>> >>> Thanks, >>> --David >>> >>> >>>> -----Original Message----- >>>> From: Joe Touch [mailto:touch@isi.edu] >>>> Sent: Tuesday, May 27, 2014 10:00 PM >>>> To: Black, David; Paul Hoffman >>>> Cc: tsvwg@ietf.org >>>> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft- >> ietf- >>>> tsvwg-port-use-04 (to end 6th June) >>>> >>>> >>>> >>>> On 5/27/2014 5:40 PM, Black, David wrote: >>>>> Joe, >>>>> >>>>> >>>>> >>>>>> If you disagree with the analysis, you should present a counterargument. >>>>> >>>>> Ok, I'll try ... ;-). >>>>> >>>>> It might help if this had somewhat more of a flavor of documenting the >>>>> review criteria that are currently used, although I do think at least >>>>> one "SHOULD NOT" is likely to turn up in the final text. >>>>> >>>>> I'd certainly like to see some Security Area input (and probably also >>>>> OPS, as firewalls play a prominent role), but speaking for myself, >>>>> I think offering security advice is well within reason here ... >>>>> >>>>> Going back to the three scenarios at the start of this thread, the >>>>> proposals for the first two seem reasonable (IMHO): >>>>> >>>>> - given a current non-secure assignment, what if a >>>>> user requests a (new) second port for secure access? >>>>> >>>>> this is fine, if not a good idea; >>>>> >>>>> - given a current secure assignment, what >>>>> if a user requests a (new) second port for insecure access? >>>>> >>>>> it seems like a SHOULD NOT recommendation >>>>> is appropriate; this creates new vulnerability; >>>>> >>>>> I presume that the latter recommendation envisions a scenario where >>>>> the secure port has been deployed and used for a significant period >>>>> of time. >>>> >>>> Yes. >>>> >>>>> In that case, I think a "SHOULD NOT" is ok, as I'd want to >>>>> see some heavy-duty serious justification for adding the insecure >>>>> port. The draft should state that presumption, though, as deployment >>>>> difficulties/experience might result in something closer to the third >>>>> scenario. >>>> >>>> Right - that's the point of the SHOULD NOT. It's not a MUST NOT. It just >>>> needs very heavy justification. >>>> >>>>> - should a user request two ports for a new service, one >>>>> secure and one insecure? >>>>> >>>>> I suspect that the advice for the this one is likely to be a long >>>>> version of "it depends" in practice. >>>>> >>>>> IMO, the secure port is easy, if otherwise >>>>> warranted (not a duplicate of existing service, e.g.), >>>>> but the insecure one similarly creates a new >>>>> vulnerability, and again I would say SHOULD NOT >>>>> request a new insecure port >>>>> >>>>> I agree with the secure port being fine, but I'm not comfortable >>>>> with a blanket "SHOULD NOT" recommendation for the insecure port. >>>>> >>>>> I think this depends on the details of the protocol. I'd definitely >>>>> set an expectation that solid justification for the new insecure >>>>> port will be expected, with the applicant being responsible for >>>>> justifying why use of security is not mandatory for the protocol. >>>>> If that justification makes the case, then the firewall control >>>>> rationale (below) definitely sounds reasonable, IMHO. >>>> >>>> Why isn't that a SHOULD NOT? Certainly a bit more text is in order, but >>>> it seems like we're in agreement - deep justification is needed. >>>> >>>>> I just don't think the level of required justification is going >>>>> to rise to that sufficient to override a "SHOULD NOT" for every >>>>> single protocol design that we have yet to envision. I wish my >>>>> foresight was 20/20 :-). >>>> >>>> FWIW, there aren't a lot of protocols that ask for secure and insecure >>>> at the same time. Those come mostly - incredibly - from IETF WGs, where >>>> they appear to be (IMO blindly) following past practice. >>>> >>>> My key concern is "why is the insecure port needed"? Most of the time >>>> the justification is pure performance - running security on the service >>>> will make it too slow, and this will allow faster performance inside an >>>> enterprise. That might be true, but it also needs to be justified in >>>> terms of the service being provided - that this is a high-throughput or >>>> high-transaction frequency system that needs high performance inside >>>> protected enterprises. >>>> >>>>> - GIVEN a request for an insecure and secure port, what >>>>> are appropriate justifications? >>>>> >>>>> IMO, separate firewall control is a sufficient >>>>> reason. >>>>> >>>>> however, performance should not be - i.e., if >>>>> both ports will typically have the same firewall >>>>> configuration, then only one port is needed >>>>> and security should be negotiated as present/absent >>>>> in-band. The performance impact of that negotiation >>>>> (IMO) should not factor into whether an additional >>>>> port should be assigned. >>>>> >>>>> I think the text on performance should be explicit that the >>>>> performance concern is negotiation round trip avoidance. >>>> >>>> There are a few different performance issues: >>>> >>>> - round-trip delays >>>> - throughput overhead (per byte) >>>> - message overhead (per message) >>>> >>>> Joe >>>> >>>>> >>>>> >>>>> Thanks, >>>>> --David >>>>> >>>>>> -----Original Message----- >>>>>> From: Joe Touch [mailto:touch@isi.edu] >>>>>> Sent: Tuesday, May 27, 2014 6:03 PM >>>>>> To: Paul Hoffman >>>>>> Cc: Black, David; tsvwg@ietf.org >>>>>> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft- >>>> ietf- >>>>>> tsvwg-port-use-04 (to end 6th June) >>>>>> >>>>>> >>>>>> >>>>>> On 5/27/2014 2:49 PM, Paul Hoffman wrote: >>>>>>> Is this new advice based on any actual evidence or even a security >>>> analysis? >>>>>> >>>>>> It's based on 8 years of running the review team and discussions within >>>>>> that team. It's based on the analysis provided. >>>>>> >>>>>> If you disagree with the analysis, you should present a counterargument. >>>>>> >>>>>>> Further, a statement of "SHOULD NOT request" sounds a hell of a lot more >>>>>>> like a demand than advice. >>>>>> >>>>>> What exactly can we *demand* of a user making an application other that >>>>>> to provide advice? It's not advice to IANA or the ports team in how to >>>>>> make a decision. >>>>>> >>>>>>> This gets to the crux of my concern of the >>>>>>> document: it feel like the advice is meant to come from on high (namely, >>>>>>> someone who can block IANA requests), not friendly advice from one >>>>>>> developer to another. >>>>>> >>>>>> Can you provide a rationale for that claim other than "because Joe Touch >>>>>> wrote it"? >>>>>> >>>>>>> We went through this in the discussion a few years >>>>>>> ago, and it seemed then that TSVWG didn't agree that such heavy-handed >>>>>>> "advice", particularly without specific justification, was the way to >> go. >>>>>> >>>>>> TSVWG agreed that limiting IANA was not appropriate; this document >>>>>> doesn't limit IANA. >>>>>> >>>>>> And specific justification is provided in the discussion I gave. Again, >>>>>> if you disagree with that discussion, please explain. >>>>>> >>>>>> E.g., do you actually think it's good security practice to create new, >>>>>> insecure services? If so, on what basis of good security practice? >>>>>> >>>>>> Joe >>>>> >>> > From nobody Thu May 29 10:39:24 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45871A0450 for ; Thu, 29 May 2014 10:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2CkllxYZ7PB for ; Thu, 29 May 2014 10:39:20 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFDB71A0254 for ; Thu, 29 May 2014 10:39:19 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4THdDpU015983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 13:39:14 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s4THdDpU015983 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401385154; bh=pamAR2xRV+xBFTzAbNnKZOgLnW4=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=mUCvWtnuqOg9sKpxmtrKUQx/Rh2kl/Hdkl0+D4AdzS8i30Cv42OElIgSILCIaxuJe +EAnFMZ53kBFaESxdVapr6/jpLVyLcQyfMRyaP7wqA3sx7/vUc42mXUbSdHjYDlIr2 s0JD8SNZeJWd9HN7KtuCwbOng54q5MPDANY+bITo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s4THdDpU015983 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Thu, 29 May 2014 13:39:04 -0400 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4THd3iG018659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 13:39:04 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Thu, 29 May 2014 13:39:03 -0400 From: "Black, David" To: Joe Touch Date: Thu, 29 May 2014 13:39:01 -0400 Thread-Topic: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) Thread-Index: Ac97Vr5+PVurOC0YR424j3YUxfdatwACmapA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C663684@MX15A.corp.emc.com> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C663209@MX15A.corp.emc.com> <53854308.8020705@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C66334F@MX15A.corp.emc.com> <538611F4.8000905@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C66364B@MX15A.corp.emc.com> <538758E6.2080208@isi.edu> In-Reply-To: <538758E6.2080208@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/hH0UKQO-05GcPmNNvFTFQ8KipjE Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:39:23 -0000 PFdHIGNoYWlyIGhhdCBPRkY+DQoNCj4gPiBGb3IgY2xhcml0eSwgSSB0aGluayB0aGUgImV4dHJl bWUgc2tlcHRpY2lzbSIgc2hvdWxkIGJlIGZvY3VzZWQgb24gcmVsaWFuY2UNCj4gPiB1cG9uICJ3 ZSd2ZSBhbHdheXMgZG9uZSBpdCB0aGF0IHdheSIgYXMgdGhlIHJhdGlvbmFsZSwgYXMgb3Bwb3Nl ZCB0byBicm9hZGx5DQo+ID4gb24gYWxsIHJlcXVlc3RzIGZvciB0d28gcG9ydHMuICBJTUhPLCB0 aGUgbGF0dGVyIG91Z2h0IHRvIGNvbWUgYWNyb3NzIGFzIGENCj4gPiByZXF1aXJlbWVudCB0byAi c2hvdyB5b3VyIHdvcmsiIGFzIG9wcG9zZWQgdG8gc3Ryb25nIGRpc2NvdXJhZ2VtZW50IG9mIGFs bA0KPiA+IHJlcXVlc3RzIGZvciB0d28gcG9ydHMuICBJbmRlcGVuZGVudCBvZiB0aGUgcHJlY2lz ZSB3b3JkaW5nIGluIFJGQyAyMTE5LCBJDQo+ID4gd291bGQgZXhwZWN0ICJTSE9VTEQgTk9UIiB0 byBiZSByZWFkIGFzIHN0cm9uZyBkaXNjb3VyYWdlbWVudCBieSBhIHNpZ25pZmljYW50DQo+ID4g cG9ydGlvbiBvZiB0aGUgaW50ZW5kZWQgYXVkaWVuY2UuDQo+DQo+IFRoZSBwcm9ibGVtIHdpdGgg InNob3cgeW91ciB3b3JrIiBpcyB0aGF0IHRoZXJlIGlzIG5vIG90aGVyIFJGQzIxMTkNCj4gbGFu Z3VhZ2UgZm9yIHRoYXQsIHdoaWNoIG1lYW5zIGl0IHdpbGwgaGF2ZSBubyB0ZWV0aCB3aGVuIHRo ZSByZXF1ZXN0DQo+IGNvbWVzIGZvciB0aGUgV0cuDQo+DQo+IEkuZS4sIGluIHRoZSBjYXNlIHdo ZXJlIFdHIHJvdWdoIGNvbnNlbnN1cyBzZWVrcyB0d28gcG9ydHMsIHRoYXQgaXRzZWxmDQo+IHdp bGwgYmUgc2VlbiBhcyBzdWZmaWNpZW50IHVubGVzcyB0aGlzIEJDUCBzYXlzIG90aGVyd2lzZS4N Cj4NCj4gTWF5YmUgd2UgY291bGQgc2F5ICJTSE9VTEQgTk9UIGFzayBmb3IgdHdvIHBvcnRzIiwg YnV0IGFkZCAidW5sZXNzIChhcw0KPiB3aXRoIGFueSBTSE9VTEQtbGV2ZWwgcmVjb21tZW5kYXRp b24pIHN1ZmZpY2llbnQgZGlyZWN0IHJhdGlvbmFsZSBmb3IgYW4NCj4gZXhjZXB0aW9uIGlzIHBy b3ZpZGVkIj8NCg0KRWxpb3QgZGVzY3JpYmVkIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoOg0KDQo+ IExldCBtZSBzdWdnZXN0DQo+IHR3byBxdWVzdGlvbnMgdG8gYmUgYXNrZWQuICBUaGUgZmlyc3Qg Y29tZXMgcmlnaHQgb3V0IG9mIHRoZSBSRkM6DQo+DQo+ID4gSXMgcGVydmFzaXZlIG1vbml0b3Jp bmcgcmVsZXZhbnQgdG8gdGhpcyB3b3JrIGFuZCBpZiBzbywgaG93IGhhcyBpdA0KPiA+IGJlZW4g Y29uc2lkZXJlZD8NCj4NCj4gVGhlIHNlY29uZCBpcyBtb3JlIGdlbmVyYWw6DQo+DQo+IEhvdyBo YXZlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGJlZW4gdGFrZW4gaW50byBhY2NvdW50Pw0KPg0K PiBBbmQgdGhyb3cgYSBNVVNUIGFyb3VuZCBhdCBsZWFzdCBiZWluZyBhYmxlIHRvIGFuc3dlciB0 aG9zZSBxdWVzdGlvbnMuDQo+IFJldmlld2VycyBjYW4gdGhlbiB1c2UgdGhlaXIganVkZ21lbnQg YXMgdG8gdGhlIHZhbGlkaXR5IG9mIHRoZSBhbnN3ZXJzLg0KDQpCZXlvbmQgRWxpb3QncyBzcGVj aWZpYyBxdWVzdGlvbnMgKHdoaWNoIGFyZSBnb29kLCBJTUhPKSwgSSBsaWtlIHRoZSBpZGVhDQpv ZiBhcHBseWluZyAyMTE5IGtleXdvcmRzIHRvIHRoZSBwb3J0IGFzc2lnbm1lbnQgcHJvY2VzcyBh cyBvcHBvc2VkIHRvIHRoZQ0KcHJvdG9jb2wgZGVzaWduLiAgTW9yZW92ZXIsIEknbSBjb21mb3J0 YWJsZSB3aXRoIHVzaW5nICJNVVNUIiBmb3IgcG9ydA0KYXNzaWdubWVudCBwcm9jZXNzIHJlcXVp cmVtZW50cy4NCg0KQXBwbHlpbmcgdGhhdCBpZGVhIHRvIHRoaXMgZGlzY3Vzc2lvbiwgdGhlIHR3 byBrZXkgcG9pbnRzIGNvdWxkIGJlOg0KDQotIFdoZW4gcmVxdWVzdGluZyBib3RoIGEgc2VjdXJl IGFuZCBhbiBpbnNlY3VyZSBwb3J0LCBzdHJvbmcNCiAgICAgICAganVzdGlmaWNhdGlvbiBNVVNU IGJlIHByb3ZpZGVkIGZvciB0aGUgaW5zZWN1cmUgcG9ydC4NCg0KLSBQcmVjZWRlbnQgKGNpdGlu ZyBvdGhlciBwcm90b2NvbHMgdGhhdCB1c2UgYW4gaW5zZWN1cmUgcG9ydCkgaXMgbm90DQogICAg ICAgIHN0cm9uZyBqdXN0aWZpY2F0aW9uIGJ5IGl0c2VsZi4gIEEgc3Ryb25nIGNhc2UgZm9yIHV0 aWxpdHkgb2YgdGhlDQogICAgICAgIGluc2VjdXJlIHNlcnZpY2UgaXMgUkVRVUlSRUQgZm9yIGFw cHJvdmFsIG9mIHRoZSBpbnNlY3VyZSBwb3J0Lg0KDQpUaGUgYWJvdmUgdXNlIG9mICJNVVNUIiBh bmQgIlJFUVVJUkVEIiBtYWtlIGl0IGNsZWFyIHdoYXQgdGhlIFdHIGhhcyB0byBkbw0KaWYgdGhl eSB3YW50IHRvIGdvIGRvd24gdGhpcyBwYXRoLg0KDQpJbiBhZGRpdGlvbiwgc28gd2UgZG9uJ3Qg bG9zZSBpdDoNCg0KLSBSZXF1ZXN0cyBmb3IgbGFyZ2UgbnVtYmVycyBvZiBwb3J0cyAoZS5nLiwg MTBzLTEwMHMpIFNIT1VMRCBOT1QgYmUgbWFkZSwNCiAgICAgICAgYXMgdGhleSB3aWxsIGJlIHJl amVjdGVkLg0KDQpJbiBjb250cmFzdCB0byBhc2tpbmcgZm9yIGEgc2VjdXJlIGFuZCBhbiBpbnNl Y3VyZSBwb3J0LCB0aGlzIGlzIGEgY2FzZQ0Kd2hlcmUgYSAiU0hPVUxEIE5PVCIgb24gcHJvdG9j b2wgZGVzaWduIGlzIGFwcHJvcHJpYXRlLCBJTUhPLg0KDQo8L1dHIGNoYWlyIGhhdCBPRkY+DQoN ClRoYW5rcywNCi0tRGF2aWQNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFRodXJzZGF5LCBN YXkgMjksIDIwMTQgMTE6NTcgQU0NCj4gVG86IEJsYWNrLCBEYXZpZA0KPiBDYzogdHN2d2dAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0c3Z3Z10gYWRkaXRpb25hbCBwb3J0cyBmb3Igc2VjdXJp dHkgLSBSZTogV0dMQyBmb3IgZHJhZnQtaWV0Zi0NCj4gdHN2d2ctcG9ydC11c2UtMDQgKHRvIGVu ZCA2dGggSnVuZSkNCj4NCj4NCj4NCj4gT24gNS8yOS8yMDE0IDg6MzQgQU0sIEJsYWNrLCBEYXZp ZCB3cm90ZToNCj4gPiA8V0cgY2hhaXIgaGF0IE9GRj4NCj4gLi4uDQo+ID4gSSBkcmF3IGEgZGlz dGluY3Rpb24gYmV0d2VlbiB0aGUgImFkZCBhbiBpbnNlY3VyZSBwb3J0IiBjYXNlLCB3aGVyZSB3 ZSBhdA0KPiA+IGxlYXN0IGhhdmUgInJ1bm5pbmcgY29kZSIgZm9yIHRoZSBwcm90b2NvbCBhbmQg dGhlICJuZXcgcmVxdWVzdCBmb3IgdHdvDQo+IHBvcnRzIg0KPiA+IGNhc2Ugd2hlcmUgdGhlcmUg aXMgbm8gInJ1bm5pbmcgY29kZSIgZm9yIHRoZSBwcm90b2NvbCBhbmQgdGhlIGluaXRpYWwNCj4g InJvdWdoDQo+ID4gY29uc2Vuc3VzIiAoYXNzdW1pbmcgdGhhdCB0aGlzIGlzIGZyb20gYW4gSUVU RiBXRykgcnVucyB0aGUgb3RoZXIgd2F5IChpLmUuLA0KPiA+IHRvd2FyZHMgdHdvIHBvcnRzKS4N Cj4NCj4gVGhlIGZvcm1lciBpcyBjZXJ0YWlubHkgbW9yZSBwb3RlbnRpYWxseSBkYW5nZXJvdXMg dGhhbiB0aGUgbGF0dGVyLg0KPg0KPiA+Pj4+PiBJIGp1c3QgZG9uJ3QgdGhpbmsgdGhlIGxldmVs IG9mIHJlcXVpcmVkIGp1c3RpZmljYXRpb24gaXMgZ29pbmcNCj4gPj4+Pj4gdG8gcmlzZSB0byB0 aGF0IHN1ZmZpY2llbnQgdG8gb3ZlcnJpZGUgYSAiU0hPVUxEIE5PVCIgZm9yIGV2ZXJ5DQo+ID4+ Pj4+IHNpbmdsZSBwcm90b2NvbCBkZXNpZ24gdGhhdCB3ZSBoYXZlIHlldCB0byBlbnZpc2lvbi4g IEkgd2lzaCBteQ0KPiA+Pj4+PiBmb3Jlc2lnaHQgd2FzIDIwLzIwIDotKS4NCj4gPj4+Pg0KPiA+ Pj4+IEZXSVcsIHRoZXJlIGFyZW4ndCBhIGxvdCBvZiBwcm90b2NvbHMgdGhhdCBhc2sgZm9yIHNl Y3VyZSBhbmQgaW5zZWN1cmUNCj4gPj4+PiBhdCB0aGUgc2FtZSB0aW1lLiBUaG9zZSBjb21lIG1v c3RseSAtIGluY3JlZGlibHkgLSBmcm9tIElFVEYgV0dzLCB3aGVyZQ0KPiA+Pj4+IHRoZXkgYXBw ZWFyIHRvIGJlIChJTU8gYmxpbmRseSkgZm9sbG93aW5nIHBhc3QgcHJhY3RpY2UuDQo+ID4+Pg0K PiA+Pj4gSGVyZSBJIGFncmVlIC0gdXNlIG9mICJ3ZSd2ZSBhbHdheXMgZG9uZSBpdCB0aGF0IHdh eSIgYXMgYSByYXRpb25hbGUNCj4gU0hPVUxEDQo+ID4+PiBiZSBzdHJvbmdseSBkaXNjb3VyYWdl ZDsgYmV5b25kIHRoYXQsIEknZCBzdWdnZXN0IHBvaW50aW5nIG91dCB0aGF0DQo+IHJlcXVlc3Rz DQo+ID4+PiBmb3IgYm90aCBwb3J0cyBhcmUgdmlld2VkIHdpdGggc2lnbmlmaWNhbnQgc2tlcHRp Y2lzbSBiZWNhdXNlIHRoYXQgcmVhc29uDQo+ID4+PiBoYXMgYmVlbiB0aGUgcHJpbWFyeSByYXRp b25hbGUgZm9yIG1hbnkgb2YgdGhlbS4gIEl0IHdvdWxkIGFsc28gaGVscCB0bw0KPiA+Pj4gYWRk IGRpc2N1c3Npb24gb2YgImp1c3RpZmllZCBpbiB0ZXJtcyBvZiBzZXJ2aWNlIHByb3ZpZGVkIjoN Cj4gPj4NCj4gPj4gQU9LLiBSYXRoZXIgdGhhbiBTSE9VTEQgTk9ULCBJJ2xsIGdvIHdpdGggImV4 dHJlbWUgc2tlcHRpY2lzbSIgKGFsdGhvdWdoDQo+ID4+IEkgYXNrIG90aGVycyBvbiB0aGUgbGlz dCB0byB3ZWlnaC1pbiBvbiB0aGlzIC0gSU1PLCAiZXh0cmVtZSBza2VwdGljaXNtDQo+ID4+IGZv ciBleGNlcHRpb25zIiBpcyBwcmVjaXNlbHkgd2hhdCBTSE9VTEQgTk9UIGltcGxpZXMpLg0KPiA+ DQo+ID4gRm9yIGNsYXJpdHksIEkgdGhpbmsgdGhlICJleHRyZW1lIHNrZXB0aWNpc20iIHNob3Vs ZCBiZSBmb2N1c2VkIG9uIHJlbGlhbmNlDQo+ID4gdXBvbiAid2UndmUgYWx3YXlzIGRvbmUgaXQg dGhhdCB3YXkiIGFzIHRoZSByYXRpb25hbGUsIGFzIG9wcG9zZWQgdG8gYnJvYWRseQ0KPiA+IG9u IGFsbCByZXF1ZXN0cyBmb3IgdHdvIHBvcnRzLiAgSU1ITywgdGhlIGxhdHRlciBvdWdodCB0byBj b21lIGFjcm9zcyBhcyBhDQo+ID4gcmVxdWlyZW1lbnQgdG8gInNob3cgeW91ciB3b3JrIiBhcyBv cHBvc2VkIHRvIHN0cm9uZyBkaXNjb3VyYWdlbWVudCBvZiBhbGwNCj4gPiByZXF1ZXN0cyBmb3Ig dHdvIHBvcnRzLiAgSW5kZXBlbmRlbnQgb2YgdGhlIHByZWNpc2Ugd29yZGluZyBpbiBSRkMgMjEx OSwgSQ0KPiA+IHdvdWxkIGV4cGVjdCAiU0hPVUxEIE5PVCIgdG8gYmUgcmVhZCBhcyBzdHJvbmcg ZGlzY291cmFnZW1lbnQgYnkgYQ0KPiBzaWduaWZpY2FudA0KPiA+IHBvcnRpb24gb2YgdGhlIGlu dGVuZGVkIGF1ZGllbmNlLg0KPg0KPiBUaGUgcHJvYmxlbSB3aXRoICJzaG93IHlvdXIgd29yayIg aXMgdGhhdCB0aGVyZSBpcyBubyBvdGhlciBSRkMyMTE5DQo+IGxhbmd1YWdlIGZvciB0aGF0LCB3 aGljaCBtZWFucyBpdCB3aWxsIGhhdmUgbm8gdGVldGggd2hlbiB0aGUgcmVxdWVzdA0KPiBjb21l cyBmb3IgdGhlIFdHLg0KPg0KPiBJLmUuLCBpbiB0aGUgY2FzZSB3aGVyZSBXRyByb3VnaCBjb25z ZW5zdXMgc2Vla3MgdHdvIHBvcnRzLCB0aGF0IGl0c2VsZg0KPiB3aWxsIGJlIHNlZW4gYXMgc3Vm ZmljaWVudCB1bmxlc3MgdGhpcyBCQ1Agc2F5cyBvdGhlcndpc2UuDQo+DQo+IE1heWJlIHdlIGNv dWxkIHNheSAiU0hPVUxEIE5PVCBhc2sgZm9yIHR3byBwb3J0cyIsIGJ1dCBhZGQgInVubGVzcyAo YXMNCj4gd2l0aCBhbnkgU0hPVUxELWxldmVsIHJlY29tbWVuZGF0aW9uKSBzdWZmaWNpZW50IGRp cmVjdCByYXRpb25hbGUgZm9yIGFuDQo+IGV4Y2VwdGlvbiBpcyBwcm92aWRlZCI/DQo+DQo+IEpv ZQ0KPg0KPiA+IDwvV0cgY2hhaXIgaGF0IE9GRj4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiAtLURh dmlkDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogSm9l IFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBNYXkg MjgsIDIwMTQgMTI6NDIgUE0NCj4gPj4gVG86IEJsYWNrLCBEYXZpZDsgUGF1bCBIb2ZmbWFuDQo+ ID4+IENjOiB0c3Z3Z0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3RzdndnXSBhZGRpdGlv bmFsIHBvcnRzIGZvciBzZWN1cml0eSAtIFJlOiBXR0xDIGZvciBkcmFmdC0NCj4gaWV0Zi0NCj4g Pj4gdHN2d2ctcG9ydC11c2UtMDQgKHRvIGVuZCA2dGggSnVuZSkNCj4gPj4NCj4gPj4NCj4gPj4N Cj4gPj4gT24gNS8yOC8yMDE0IDk6MzIgQU0sIEJsYWNrLCBEYXZpZCB3cm90ZToNCj4gPj4+IDxX RyBjaGFpciBoYXQgT0ZGPg0KPiA+Pj4NCj4gPj4+Pj4gICAgLSBzaG91bGQgYSB1c2VyIHJlcXVl c3QgdHdvIHBvcnRzIGZvciBhIG5ldyBzZXJ2aWNlLCBvbmUNCj4gPj4+Pj4gICAgc2VjdXJlIGFu ZCBvbmUgaW5zZWN1cmU/DQo+ID4+Pj4+DQo+ID4+Pj4+IEkgc3VzcGVjdCB0aGF0IHRoZSBhZHZp Y2UgZm9yIHRoZSB0aGlzIG9uZSBpcyBsaWtlbHkgdG8gYmUgYSBsb25nDQo+ID4+Pj4+IHZlcnNp b24gb2YgIml0IGRlcGVuZHMiIGluIHByYWN0aWNlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAg ICAgIElNTywgdGhlIHNlY3VyZSBwb3J0IGlzIGVhc3ksIGlmIG90aGVyd2lzZQ0KPiA+Pj4+PiAg ICAgICAgICAgIHdhcnJhbnRlZCAobm90IGEgZHVwbGljYXRlIG9mIGV4aXN0aW5nIHNlcnZpY2Us IGUuZy4pLA0KPiA+Pj4+PiAgICAgICAgICAgIGJ1dCB0aGUgaW5zZWN1cmUgb25lIHNpbWlsYXJs eSBjcmVhdGVzIGEgbmV3DQo+ID4+Pj4+ICAgICAgICAgICAgdnVsbmVyYWJpbGl0eSwgYW5kIGFn YWluIEkgd291bGQgc2F5IFNIT1VMRCBOT1QNCj4gPj4+Pj4gICAgICAgICAgICByZXF1ZXN0IGEg bmV3IGluc2VjdXJlIHBvcnQNCj4gPj4+Pj4NCj4gPj4+Pj4gSSBhZ3JlZSB3aXRoIHRoZSBzZWN1 cmUgcG9ydCBiZWluZyBmaW5lLCBidXQgSSdtIG5vdCBjb21mb3J0YWJsZQ0KPiA+Pj4+PiB3aXRo IGEgYmxhbmtldCAiU0hPVUxEIE5PVCIgcmVjb21tZW5kYXRpb24gZm9yIHRoZSBpbnNlY3VyZSBw b3J0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIHRoaW5rIHRoaXMgZGVwZW5kcyBvbiB0aGUgZGV0YWls cyBvZiB0aGUgcHJvdG9jb2wuICBJJ2QgZGVmaW5pdGVseQ0KPiA+Pj4+PiBzZXQgYW4gZXhwZWN0 YXRpb24gdGhhdCBzb2xpZCBqdXN0aWZpY2F0aW9uIGZvciB0aGUgbmV3IGluc2VjdXJlDQo+ID4+ Pj4+IHBvcnQgd2lsbCBiZSBleHBlY3RlZCwgd2l0aCB0aGUgYXBwbGljYW50IGJlaW5nIHJlc3Bv bnNpYmxlIGZvcg0KPiA+Pj4+PiBqdXN0aWZ5aW5nIHdoeSB1c2Ugb2Ygc2VjdXJpdHkgaXMgbm90 IG1hbmRhdG9yeSBmb3IgdGhlIHByb3RvY29sLg0KPiA+Pj4+PiBJZiB0aGF0IGp1c3RpZmljYXRp b24gbWFrZXMgdGhlIGNhc2UsIHRoZW4gdGhlIGZpcmV3YWxsIGNvbnRyb2wNCj4gPj4+Pj4gcmF0 aW9uYWxlIChiZWxvdykgZGVmaW5pdGVseSBzb3VuZHMgcmVhc29uYWJsZSwgSU1ITy4NCj4gPj4+ Pg0KPiA+Pj4+IFdoeSBpc24ndCB0aGF0IGEgU0hPVUxEIE5PVD8gQ2VydGFpbmx5IGEgYml0IG1v cmUgdGV4dCBpcyBpbiBvcmRlciwgYnV0DQo+ID4+Pj4gaXQgc2VlbXMgbGlrZSB3ZSdyZSBpbiBh Z3JlZW1lbnQgLSBkZWVwIGp1c3RpZmljYXRpb24gaXMgbmVlZGVkLg0KPiA+Pj4NCj4gPj4+IFdl J3JlIGRlYWxpbmcgd2l0aCBhIHByb2Nlc3MgYXMgb3Bwb3NlZCB0byBhIHByb3RvY29sIGhlcmUs IHNvIHRoZQ0KPiA+PiBmdW5jdGlvbmFsaXR5DQo+ID4+PiBvZiBzb21lIGZ1dHVyZSBwcm90b2Nv bCB0aGF0IHdpbGwgYXNrIGZvciBwb3J0cyBpcyB1bmtub3duIHRvIHVzIGF0IHRoZQ0KPiA+PiBt b21lbnQuDQo+ID4+Pg0KPiA+Pj4gSSB0aGluayBJJ20gbW9zdGx5IGxvb2tpbmcgZm9yIHNvbWUg Z3JhZGF0aW9uIHdydCB0aGUgb3RoZXIgU0hPVUxEIE5PVDoNCj4gPj4+DQo+ID4+Pj4+ICAgIC0g Z2l2ZW4gYSBjdXJyZW50IHNlY3VyZSBhc3NpZ25tZW50LCB3aGF0DQo+ID4+Pj4+ICAgIGlmIGEg dXNlciByZXF1ZXN0cyBhIChuZXcpIHNlY29uZCBwb3J0IGZvciBpbnNlY3VyZSBhY2Nlc3M/DQo+ ID4+Pj4+DQo+ID4+Pj4+ICAgICAgICAgICAgaXQgc2VlbXMgbGlrZSBhIFNIT1VMRCBOT1QgcmVj b21tZW5kYXRpb24NCj4gPj4+Pj4gICAgICAgICAgICBpcyBhcHByb3ByaWF0ZTsgdGhpcyBjcmVh dGVzIG5ldyB2dWxuZXJhYmlsaXR5Ow0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIHByZXN1bWUgdGhhdCB0 aGUgbGF0dGVyIHJlY29tbWVuZGF0aW9uIGVudmlzaW9ucyBhIHNjZW5hcmlvIHdoZXJlDQo+ID4+ Pj4+IHRoZSBzZWN1cmUgcG9ydCBoYXMgYmVlbiBkZXBsb3llZCBhbmQgdXNlZCBmb3IgYSBzaWdu aWZpY2FudCBwZXJpb2QNCj4gPj4+Pj4gb2YgdGltZS4NCj4gPj4+Pg0KPiA+Pj4+IFllcy4NCj4g Pj4+DQo+ID4+PiBJTUhPLCB0aGF0ICJydW5uaW5nIGNvZGUiIGRlcGxveW1lbnQgYW5kIHVzZSBl eHBlcmllbmNlIHByb3ZpZGVzIGEgc29saWQNCj4gPj4+IHN0cm9uZyBmb3VuZGF0aW9uIGZvciBh ICJTSE9VTEQgTk9UIiBieSBjb21wYXJpc29uIHRvIHRoZSAibmV3IHJlcXVlc3QNCj4gPj4+IGZv ciB0d28gcG9ydHMiIGNhc2UsIHdoZXJlIGEgIlNIT1VMRCBOT1QiIHN0cmlrZXMgbWUgYXMgcHJl LWV2YWx1YXRpbmcNCj4gPj4+IHByb3RvY29sIGRlc2lnbiBkZWNpc2lvbnMsIHNpZ2h0IHVuc2Vl biwgZm9yIHByb3RvY29scyB0aGF0IG5vYm9keSdzDQo+ID4+PiBldmVuIHRob3VnaHQgb2YsIHll dC4NCj4gPj4NCj4gPj4gSW4gYm90aCBjYXNlcyB3ZSdyZSBhc3Nlc3NpbmcgYW4gZXZlbnQgaW4g dGhlIGZ1dHVyZSAtIGFzIHdpdGggKmV2ZXJ5Kg0KPiA+PiBSRkMgMjExOSByZWNvbW1lbmRhdGlv bi4gVGhlIFNIT1VMRCBOT1QgaXNuJ3QgcHJlLWV2YWx1YXRpbmcgLSBpdCdzDQo+ID4+IHNheWlu ZyB0aGF0IHRoZXJlIGFyZSBlbm91Z2ggY29uY2VybnMgd2l0aCB0aGlzIHBhdGggdGhhdCBzdHJv bmcNCj4gPj4ganVzdGlmaWNhdGlvbiBpcyBuZWVkZWQgLSBqdXN0IGxpa2UgKmV2ZXJ5KiBTSE9V TEQgb3IgU0hPVUxEIE5PVCBleGNlcHRpb24uDQo+ID4+DQo+ID4+Pj4+IEkganVzdCBkb24ndCB0 aGluayB0aGUgbGV2ZWwgb2YgcmVxdWlyZWQganVzdGlmaWNhdGlvbiBpcyBnb2luZw0KPiA+Pj4+ PiB0byByaXNlIHRvIHRoYXQgc3VmZmljaWVudCB0byBvdmVycmlkZSBhICJTSE9VTEQgTk9UIiBm b3IgZXZlcnkNCj4gPj4+Pj4gc2luZ2xlIHByb3RvY29sIGRlc2lnbiB0aGF0IHdlIGhhdmUgeWV0 IHRvIGVudmlzaW9uLiAgSSB3aXNoIG15DQo+ID4+Pj4+IGZvcmVzaWdodCB3YXMgMjAvMjAgOi0p Lg0KPiA+Pj4+DQo+ID4+Pj4gRldJVywgdGhlcmUgYXJlbid0IGEgbG90IG9mIHByb3RvY29scyB0 aGF0IGFzayBmb3Igc2VjdXJlIGFuZCBpbnNlY3VyZQ0KPiA+Pj4+IGF0IHRoZSBzYW1lIHRpbWUu IFRob3NlIGNvbWUgbW9zdGx5IC0gaW5jcmVkaWJseSAtIGZyb20gSUVURiBXR3MsIHdoZXJlDQo+ ID4+Pj4gdGhleSBhcHBlYXIgdG8gYmUgKElNTyBibGluZGx5KSBmb2xsb3dpbmcgcGFzdCBwcmFj dGljZS4NCj4gPj4+DQo+ID4+PiBIZXJlIEkgYWdyZWUgLSB1c2Ugb2YgIndlJ3ZlIGFsd2F5cyBk b25lIGl0IHRoYXQgd2F5IiBhcyBhIHJhdGlvbmFsZQ0KPiBTSE9VTEQNCj4gPj4+IGJlIHN0cm9u Z2x5IGRpc2NvdXJhZ2VkOyBiZXlvbmQgdGhhdCwgSSdkIHN1Z2dlc3QgcG9pbnRpbmcgb3V0IHRo YXQNCj4gcmVxdWVzdHMNCj4gPj4+IGZvciBib3RoIHBvcnRzIGFyZSB2aWV3ZWQgd2l0aCBzaWdu aWZpY2FudCBza2VwdGljaXNtIGJlY2F1c2UgdGhhdCByZWFzb24NCj4gPj4+IGhhcyBiZWVuIHRo ZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgbWFueSBvZiB0aGVtLiAgSXQgd291bGQgYWxzbyBoZWxw IHRvDQo+ID4+PiBhZGQgZGlzY3Vzc2lvbiBvZiAianVzdGlmaWVkIGluIHRlcm1zIG9mIHNlcnZp Y2UgcHJvdmlkZWQiOg0KPiA+Pg0KPiA+PiBBT0suIFJhdGhlciB0aGFuIFNIT1VMRCBOT1QsIEkn bGwgZ28gd2l0aCAiZXh0cmVtZSBza2VwdGljaXNtIiAoYWx0aG91Z2gNCj4gPj4gSSBhc2sgb3Ro ZXJzIG9uIHRoZSBsaXN0IHRvIHdlaWdoLWluIG9uIHRoaXMgLSBJTU8sICJleHRyZW1lIHNrZXB0 aWNpc20NCj4gPj4gZm9yIGV4Y2VwdGlvbnMiIGlzIHByZWNpc2VseSB3aGF0IFNIT1VMRCBOT1Qg aW1wbGllcykuDQo+ID4+DQo+ID4+IEpvZQ0KPiA+Pg0KPiA+Pj4+IE15IGtleSBjb25jZXJuIGlz ICJ3aHkgaXMgdGhlIGluc2VjdXJlIHBvcnQgbmVlZGVkIj8gTW9zdCBvZiB0aGUgdGltZQ0KPiA+ Pj4+IHRoZSBqdXN0aWZpY2F0aW9uIGlzIHB1cmUgcGVyZm9ybWFuY2UgLSBydW5uaW5nIHNlY3Vy aXR5IG9uIHRoZSBzZXJ2aWNlDQo+ID4+Pj4gd2lsbCBtYWtlIGl0IHRvbyBzbG93LCBhbmQgdGhp cyB3aWxsIGFsbG93IGZhc3RlciBwZXJmb3JtYW5jZSBpbnNpZGUgYW4NCj4gPj4+PiBlbnRlcnBy aXNlLiBUaGF0IG1pZ2h0IGJlIHRydWUsIGJ1dCBpdCBhbHNvIG5lZWRzIHRvIGJlIGp1c3RpZmll ZCBpbg0KPiA+Pj4+IHRlcm1zIG9mIHRoZSBzZXJ2aWNlIGJlaW5nIHByb3ZpZGVkIC0gdGhhdCB0 aGlzIGlzIGEgaGlnaC10aHJvdWdocHV0IG9yDQo+ID4+Pj4gaGlnaC10cmFuc2FjdGlvbiBmcmVx dWVuY3kgc3lzdGVtIHRoYXQgbmVlZHMgaGlnaCBwZXJmb3JtYW5jZSBpbnNpZGUNCj4gPj4+PiBw cm90ZWN0ZWQgZW50ZXJwcmlzZXMuDQo+ID4+Pg0KPiA+Pj4gPC9XRyBjaGFpciBoYXQgT0ZGPg0K PiA+Pj4NCj4gPj4+IFRoYW5rcywNCj4gPj4+IC0tRGF2aWQNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogSm9lIFRvdWNoIFttYWls dG86dG91Y2hAaXNpLmVkdV0NCj4gPj4+PiBTZW50OiBUdWVzZGF5LCBNYXkgMjcsIDIwMTQgMTA6 MDAgUE0NCj4gPj4+PiBUbzogQmxhY2ssIERhdmlkOyBQYXVsIEhvZmZtYW4NCj4gPj4+PiBDYzog dHN2d2dAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogW3RzdndnXSBhZGRpdGlvbmFsIHBv cnRzIGZvciBzZWN1cml0eSAtIFJlOiBXR0xDIGZvciBkcmFmdC0NCj4gPj4gaWV0Zi0NCj4gPj4+ PiB0c3Z3Zy1wb3J0LXVzZS0wNCAodG8gZW5kIDZ0aCBKdW5lKQ0KPiA+Pj4+DQo+ID4+Pj4NCj4g Pj4+Pg0KPiA+Pj4+IE9uIDUvMjcvMjAxNCA1OjQwIFBNLCBCbGFjaywgRGF2aWQgd3JvdGU6DQo+ ID4+Pj4+IEpvZSwNCj4gPj4+Pj4NCj4gPj4+Pj4gPFdHIGNoYWlyIGhhdCBPRkY+DQo+ID4+Pj4+ DQo+ID4+Pj4+PiBJZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGUgYW5hbHlzaXMsIHlvdSBzaG91bGQg cHJlc2VudCBhDQo+IGNvdW50ZXJhcmd1bWVudC4NCj4gPj4+Pj4NCj4gPj4+Pj4gT2ssIEknbGwg dHJ5IC4uLiA7LSkuDQo+ID4+Pj4+DQo+ID4+Pj4+IEl0IG1pZ2h0IGhlbHAgaWYgdGhpcyBoYWQg c29tZXdoYXQgbW9yZSBvZiBhIGZsYXZvciBvZiBkb2N1bWVudGluZyB0aGUNCj4gPj4+Pj4gcmV2 aWV3IGNyaXRlcmlhIHRoYXQgYXJlIGN1cnJlbnRseSB1c2VkLCBhbHRob3VnaCBJIGRvIHRoaW5r IGF0IGxlYXN0DQo+ID4+Pj4+IG9uZSAiU0hPVUxEIE5PVCIgaXMgbGlrZWx5IHRvIHR1cm4gdXAg aW4gdGhlIGZpbmFsIHRleHQuDQo+ID4+Pj4+DQo+ID4+Pj4+IEknZCBjZXJ0YWlubHkgbGlrZSB0 byBzZWUgc29tZSBTZWN1cml0eSBBcmVhIGlucHV0IChhbmQgcHJvYmFibHkgYWxzbw0KPiA+Pj4+ PiBPUFMsIGFzIGZpcmV3YWxscyBwbGF5IGEgcHJvbWluZW50IHJvbGUpLCBidXQgc3BlYWtpbmcg Zm9yIG15c2VsZiwNCj4gPj4+Pj4gSSB0aGluayBvZmZlcmluZyBzZWN1cml0eSBhZHZpY2UgaXMg d2VsbCB3aXRoaW4gcmVhc29uIGhlcmUgLi4uDQo+ID4+Pj4+DQo+ID4+Pj4+IEdvaW5nIGJhY2sg dG8gdGhlIHRocmVlIHNjZW5hcmlvcyBhdCB0aGUgc3RhcnQgb2YgdGhpcyB0aHJlYWQsIHRoZQ0K PiA+Pj4+PiBwcm9wb3NhbHMgZm9yIHRoZSBmaXJzdCB0d28gc2VlbSByZWFzb25hYmxlIChJTUhP KToNCj4gPj4+Pj4NCj4gPj4+Pj4gICAgLSBnaXZlbiBhIGN1cnJlbnQgbm9uLXNlY3VyZSBhc3Np Z25tZW50LCB3aGF0IGlmIGENCj4gPj4+Pj4gICAgdXNlciByZXF1ZXN0cyBhIChuZXcpIHNlY29u ZCBwb3J0IGZvciBzZWN1cmUgYWNjZXNzPw0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAgICAgIHRo aXMgaXMgZmluZSwgaWYgbm90IGEgZ29vZCBpZGVhOw0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAtIGdp dmVuIGEgY3VycmVudCBzZWN1cmUgYXNzaWdubWVudCwgd2hhdA0KPiA+Pj4+PiAgICBpZiBhIHVz ZXIgcmVxdWVzdHMgYSAobmV3KSBzZWNvbmQgcG9ydCBmb3IgaW5zZWN1cmUgYWNjZXNzPw0KPiA+ Pj4+Pg0KPiA+Pj4+PiAgICAgICAgICAgIGl0IHNlZW1zIGxpa2UgYSBTSE9VTEQgTk9UIHJlY29t bWVuZGF0aW9uDQo+ID4+Pj4+ICAgICAgICAgICAgaXMgYXBwcm9wcmlhdGU7IHRoaXMgY3JlYXRl cyBuZXcgdnVsbmVyYWJpbGl0eTsNCj4gPj4+Pj4NCj4gPj4+Pj4gSSBwcmVzdW1lIHRoYXQgdGhl IGxhdHRlciByZWNvbW1lbmRhdGlvbiBlbnZpc2lvbnMgYSBzY2VuYXJpbyB3aGVyZQ0KPiA+Pj4+ PiB0aGUgc2VjdXJlIHBvcnQgaGFzIGJlZW4gZGVwbG95ZWQgYW5kIHVzZWQgZm9yIGEgc2lnbmlm aWNhbnQgcGVyaW9kDQo+ID4+Pj4+IG9mIHRpbWUuDQo+ID4+Pj4NCj4gPj4+PiBZZXMuDQo+ID4+ Pj4NCj4gPj4+Pj4gSW4gdGhhdCBjYXNlLCBJIHRoaW5rIGEgIlNIT1VMRCBOT1QiIGlzIG9rLCBh cyBJJ2Qgd2FudCB0bw0KPiA+Pj4+PiBzZWUgc29tZSBoZWF2eS1kdXR5IHNlcmlvdXMganVzdGlm aWNhdGlvbiBmb3IgYWRkaW5nIHRoZSBpbnNlY3VyZQ0KPiA+Pj4+PiBwb3J0LiAgVGhlIGRyYWZ0 IHNob3VsZCBzdGF0ZSB0aGF0IHByZXN1bXB0aW9uLCB0aG91Z2gsIGFzIGRlcGxveW1lbnQNCj4g Pj4+Pj4gZGlmZmljdWx0aWVzL2V4cGVyaWVuY2UgbWlnaHQgcmVzdWx0IGluIHNvbWV0aGluZyBj bG9zZXIgdG8gdGhlIHRoaXJkDQo+ID4+Pj4+IHNjZW5hcmlvLg0KPiA+Pj4+DQo+ID4+Pj4gUmln aHQgLSB0aGF0J3MgdGhlIHBvaW50IG9mIHRoZSBTSE9VTEQgTk9ULiBJdCdzIG5vdCBhIE1VU1Qg Tk9ULiBJdCBqdXN0DQo+ID4+Pj4gbmVlZHMgdmVyeSBoZWF2eSBqdXN0aWZpY2F0aW9uLg0KPiA+ Pj4+DQo+ID4+Pj4+ICAgIC0gc2hvdWxkIGEgdXNlciByZXF1ZXN0IHR3byBwb3J0cyBmb3IgYSBu ZXcgc2VydmljZSwgb25lDQo+ID4+Pj4+ICAgIHNlY3VyZSBhbmQgb25lIGluc2VjdXJlPw0KPiA+ Pj4+Pg0KPiA+Pj4+PiBJIHN1c3BlY3QgdGhhdCB0aGUgYWR2aWNlIGZvciB0aGUgdGhpcyBvbmUg aXMgbGlrZWx5IHRvIGJlIGEgbG9uZw0KPiA+Pj4+PiB2ZXJzaW9uIG9mICJpdCBkZXBlbmRzIiBp biBwcmFjdGljZS4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgICAgICBJTU8sIHRoZSBzZWN1cmUg cG9ydCBpcyBlYXN5LCBpZiBvdGhlcndpc2UNCj4gPj4+Pj4gICAgICAgICAgICB3YXJyYW50ZWQg KG5vdCBhIGR1cGxpY2F0ZSBvZiBleGlzdGluZyBzZXJ2aWNlLCBlLmcuKSwNCj4gPj4+Pj4gICAg ICAgICAgICBidXQgdGhlIGluc2VjdXJlIG9uZSBzaW1pbGFybHkgY3JlYXRlcyBhIG5ldw0KPiA+ Pj4+PiAgICAgICAgICAgIHZ1bG5lcmFiaWxpdHksIGFuZCBhZ2FpbiBJIHdvdWxkIHNheSBTSE9V TEQgTk9UDQo+ID4+Pj4+ICAgICAgICAgICAgcmVxdWVzdCBhIG5ldyBpbnNlY3VyZSBwb3J0DQo+ ID4+Pj4+DQo+ID4+Pj4+IEkgYWdyZWUgd2l0aCB0aGUgc2VjdXJlIHBvcnQgYmVpbmcgZmluZSwg YnV0IEknbSBub3QgY29tZm9ydGFibGUNCj4gPj4+Pj4gd2l0aCBhIGJsYW5rZXQgIlNIT1VMRCBO T1QiIHJlY29tbWVuZGF0aW9uIGZvciB0aGUgaW5zZWN1cmUgcG9ydC4NCj4gPj4+Pj4NCj4gPj4+ Pj4gSSB0aGluayB0aGlzIGRlcGVuZHMgb24gdGhlIGRldGFpbHMgb2YgdGhlIHByb3RvY29sLiAg SSdkIGRlZmluaXRlbHkNCj4gPj4+Pj4gc2V0IGFuIGV4cGVjdGF0aW9uIHRoYXQgc29saWQganVz dGlmaWNhdGlvbiBmb3IgdGhlIG5ldyBpbnNlY3VyZQ0KPiA+Pj4+PiBwb3J0IHdpbGwgYmUgZXhw ZWN0ZWQsIHdpdGggdGhlIGFwcGxpY2FudCBiZWluZyByZXNwb25zaWJsZSBmb3INCj4gPj4+Pj4g anVzdGlmeWluZyB3aHkgdXNlIG9mIHNlY3VyaXR5IGlzIG5vdCBtYW5kYXRvcnkgZm9yIHRoZSBw cm90b2NvbC4NCj4gPj4+Pj4gSWYgdGhhdCBqdXN0aWZpY2F0aW9uIG1ha2VzIHRoZSBjYXNlLCB0 aGVuIHRoZSBmaXJld2FsbCBjb250cm9sDQo+ID4+Pj4+IHJhdGlvbmFsZSAoYmVsb3cpIGRlZmlu aXRlbHkgc291bmRzIHJlYXNvbmFibGUsIElNSE8uDQo+ID4+Pj4NCj4gPj4+PiBXaHkgaXNuJ3Qg dGhhdCBhIFNIT1VMRCBOT1Q/IENlcnRhaW5seSBhIGJpdCBtb3JlIHRleHQgaXMgaW4gb3JkZXIs IGJ1dA0KPiA+Pj4+IGl0IHNlZW1zIGxpa2Ugd2UncmUgaW4gYWdyZWVtZW50IC0gZGVlcCBqdXN0 aWZpY2F0aW9uIGlzIG5lZWRlZC4NCj4gPj4+Pg0KPiA+Pj4+PiBJIGp1c3QgZG9uJ3QgdGhpbmsg dGhlIGxldmVsIG9mIHJlcXVpcmVkIGp1c3RpZmljYXRpb24gaXMgZ29pbmcNCj4gPj4+Pj4gdG8g cmlzZSB0byB0aGF0IHN1ZmZpY2llbnQgdG8gb3ZlcnJpZGUgYSAiU0hPVUxEIE5PVCIgZm9yIGV2 ZXJ5DQo+ID4+Pj4+IHNpbmdsZSBwcm90b2NvbCBkZXNpZ24gdGhhdCB3ZSBoYXZlIHlldCB0byBl bnZpc2lvbi4gIEkgd2lzaCBteQ0KPiA+Pj4+PiBmb3Jlc2lnaHQgd2FzIDIwLzIwIDotKS4NCj4g Pj4+Pg0KPiA+Pj4+IEZXSVcsIHRoZXJlIGFyZW4ndCBhIGxvdCBvZiBwcm90b2NvbHMgdGhhdCBh c2sgZm9yIHNlY3VyZSBhbmQgaW5zZWN1cmUNCj4gPj4+PiBhdCB0aGUgc2FtZSB0aW1lLiBUaG9z ZSBjb21lIG1vc3RseSAtIGluY3JlZGlibHkgLSBmcm9tIElFVEYgV0dzLCB3aGVyZQ0KPiA+Pj4+ IHRoZXkgYXBwZWFyIHRvIGJlIChJTU8gYmxpbmRseSkgZm9sbG93aW5nIHBhc3QgcHJhY3RpY2Uu DQo+ID4+Pj4NCj4gPj4+PiBNeSBrZXkgY29uY2VybiBpcyAid2h5IGlzIHRoZSBpbnNlY3VyZSBw b3J0IG5lZWRlZCI/IE1vc3Qgb2YgdGhlIHRpbWUNCj4gPj4+PiB0aGUganVzdGlmaWNhdGlvbiBp cyBwdXJlIHBlcmZvcm1hbmNlIC0gcnVubmluZyBzZWN1cml0eSBvbiB0aGUgc2VydmljZQ0KPiA+ Pj4+IHdpbGwgbWFrZSBpdCB0b28gc2xvdywgYW5kIHRoaXMgd2lsbCBhbGxvdyBmYXN0ZXIgcGVy Zm9ybWFuY2UgaW5zaWRlIGFuDQo+ID4+Pj4gZW50ZXJwcmlzZS4gVGhhdCBtaWdodCBiZSB0cnVl LCBidXQgaXQgYWxzbyBuZWVkcyB0byBiZSBqdXN0aWZpZWQgaW4NCj4gPj4+PiB0ZXJtcyBvZiB0 aGUgc2VydmljZSBiZWluZyBwcm92aWRlZCAtIHRoYXQgdGhpcyBpcyBhIGhpZ2gtdGhyb3VnaHB1 dCBvcg0KPiA+Pj4+IGhpZ2gtdHJhbnNhY3Rpb24gZnJlcXVlbmN5IHN5c3RlbSB0aGF0IG5lZWRz IGhpZ2ggcGVyZm9ybWFuY2UgaW5zaWRlDQo+ID4+Pj4gcHJvdGVjdGVkIGVudGVycHJpc2VzLg0K PiA+Pj4+DQo+ID4+Pj4+ICAgIC0gR0lWRU4gYSByZXF1ZXN0IGZvciBhbiBpbnNlY3VyZSBhbmQg c2VjdXJlIHBvcnQsIHdoYXQNCj4gPj4+Pj4gICAgYXJlIGFwcHJvcHJpYXRlIGp1c3RpZmljYXRp b25zPw0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAgICAgIElNTywgc2VwYXJhdGUgZmlyZXdhbGwg Y29udHJvbCBpcyBhIHN1ZmZpY2llbnQNCj4gPj4+Pj4gICAgICAgICAgICByZWFzb24uDQo+ID4+ Pj4+DQo+ID4+Pj4+ICAgICAgICAgICAgaG93ZXZlciwgcGVyZm9ybWFuY2Ugc2hvdWxkIG5vdCBi ZSAtIGkuZS4sIGlmDQo+ID4+Pj4+ICAgICAgICAgICAgYm90aCBwb3J0cyB3aWxsIHR5cGljYWxs eSBoYXZlIHRoZSBzYW1lIGZpcmV3YWxsDQo+ID4+Pj4+ICAgICAgICAgICAgY29uZmlndXJhdGlv biwgdGhlbiBvbmx5IG9uZSBwb3J0IGlzIG5lZWRlZA0KPiA+Pj4+PiAgICAgICAgICAgIGFuZCBz ZWN1cml0eSBzaG91bGQgYmUgbmVnb3RpYXRlZCBhcyBwcmVzZW50L2Fic2VudA0KPiA+Pj4+PiAg ICAgICAgICAgIGluLWJhbmQuIFRoZSBwZXJmb3JtYW5jZSBpbXBhY3Qgb2YgdGhhdCBuZWdvdGlh dGlvbg0KPiA+Pj4+PiAgICAgICAgICAgIChJTU8pIHNob3VsZCBub3QgZmFjdG9yIGludG8gd2hl dGhlciBhbiBhZGRpdGlvbmFsDQo+ID4+Pj4+ICAgICAgICAgICAgcG9ydCBzaG91bGQgYmUgYXNz aWduZWQuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgdGhpbmsgdGhlIHRleHQgb24gcGVyZm9ybWFuY2Ug c2hvdWxkIGJlIGV4cGxpY2l0IHRoYXQgdGhlDQo+ID4+Pj4+IHBlcmZvcm1hbmNlIGNvbmNlcm4g aXMgbmVnb3RpYXRpb24gcm91bmQgdHJpcCBhdm9pZGFuY2UuDQo+ID4+Pj4NCj4gPj4+PiBUaGVy ZSBhcmUgYSBmZXcgZGlmZmVyZW50IHBlcmZvcm1hbmNlIGlzc3VlczoNCj4gPj4+Pg0KPiA+Pj4+ ICAgICAtIHJvdW5kLXRyaXAgZGVsYXlzDQo+ID4+Pj4gICAgIC0gdGhyb3VnaHB1dCBvdmVyaGVh ZCAocGVyIGJ5dGUpDQo+ID4+Pj4gICAgIC0gbWVzc2FnZSBvdmVyaGVhZCAocGVyIG1lc3NhZ2Up DQo+ID4+Pj4NCj4gPj4+PiBKb2UNCj4gPj4+Pg0KPiA+Pj4+PiA8L1dHIGNoYWlyIGhhdCBPRkY+ DQo+ID4+Pj4+DQo+ID4+Pj4+IFRoYW5rcywNCj4gPj4+Pj4gLS1EYXZpZA0KPiA+Pj4+Pg0KPiA+ Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+ID4+Pj4+PiBTZW50OiBUdWVzZGF5LCBNYXkgMjcs IDIwMTQgNjowMyBQTQ0KPiA+Pj4+Pj4gVG86IFBhdWwgSG9mZm1hbg0KPiA+Pj4+Pj4gQ2M6IEJs YWNrLCBEYXZpZDsgdHN2d2dAaWV0Zi5vcmcNCj4gPj4+Pj4+IFN1YmplY3Q6IFJlOiBbdHN2d2dd IGFkZGl0aW9uYWwgcG9ydHMgZm9yIHNlY3VyaXR5IC0gUmU6IFdHTEMgZm9yDQo+IGRyYWZ0LQ0K PiA+Pj4+IGlldGYtDQo+ID4+Pj4+PiB0c3Z3Zy1wb3J0LXVzZS0wNCAodG8gZW5kIDZ0aCBKdW5l KQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gNS8yNy8yMDE0IDI6 NDkgUE0sIFBhdWwgSG9mZm1hbiB3cm90ZToNCj4gPj4+Pj4+PiBJcyB0aGlzIG5ldyBhZHZpY2Ug YmFzZWQgb24gYW55IGFjdHVhbCBldmlkZW5jZSBvciBldmVuIGEgc2VjdXJpdHkNCj4gPj4+PiBh bmFseXNpcz8NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJdCdzIGJhc2VkIG9uIDggeWVhcnMgb2YgcnVu bmluZyB0aGUgcmV2aWV3IHRlYW0gYW5kIGRpc2N1c3Npb25zIHdpdGhpbg0KPiA+Pj4+Pj4gdGhh dCB0ZWFtLiBJdCdzIGJhc2VkIG9uIHRoZSBhbmFseXNpcyBwcm92aWRlZC4NCj4gPj4+Pj4+DQo+ ID4+Pj4+PiBJZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGUgYW5hbHlzaXMsIHlvdSBzaG91bGQgcHJl c2VudCBhDQo+IGNvdW50ZXJhcmd1bWVudC4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gRnVydGhlciwg YSBzdGF0ZW1lbnQgb2YgIlNIT1VMRCBOT1QgcmVxdWVzdCIgc291bmRzIGEgaGVsbCBvZiBhIGxv dA0KPiBtb3JlDQo+ID4+Pj4+Pj4gbGlrZSBhIGRlbWFuZCB0aGFuIGFkdmljZS4NCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBXaGF0IGV4YWN0bHkgY2FuIHdlICpkZW1hbmQqIG9mIGEgdXNlciBtYWtpbmcg YW4gYXBwbGljYXRpb24gb3RoZXIgdGhhdA0KPiA+Pj4+Pj4gdG8gcHJvdmlkZSBhZHZpY2U/IEl0 J3Mgbm90IGFkdmljZSB0byBJQU5BIG9yIHRoZSBwb3J0cyB0ZWFtIGluIGhvdyB0bw0KPiA+Pj4+ Pj4gbWFrZSBhIGRlY2lzaW9uLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGlzIGdldHMgdG8gdGhl IGNydXggb2YgbXkgY29uY2VybiBvZiB0aGUNCj4gPj4+Pj4+PiBkb2N1bWVudDogaXQgZmVlbCBs aWtlIHRoZSBhZHZpY2UgaXMgbWVhbnQgdG8gY29tZSBmcm9tIG9uIGhpZ2gNCj4gKG5hbWVseSwN Cj4gPj4+Pj4+PiBzb21lb25lIHdobyBjYW4gYmxvY2sgSUFOQSByZXF1ZXN0cyksIG5vdCBmcmll bmRseSBhZHZpY2UgZnJvbSBvbmUNCj4gPj4+Pj4+PiBkZXZlbG9wZXIgdG8gYW5vdGhlci4NCj4g Pj4+Pj4+DQo+ID4+Pj4+PiBDYW4geW91IHByb3ZpZGUgYSByYXRpb25hbGUgZm9yIHRoYXQgY2xh aW0gb3RoZXIgdGhhbiAiYmVjYXVzZSBKb2UNCj4gVG91Y2gNCj4gPj4+Pj4+IHdyb3RlIGl0Ij8N Cj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gV2Ugd2VudCB0aHJvdWdoIHRoaXMgaW4gdGhlIGRpc2N1c3Np b24gYSBmZXcgeWVhcnMNCj4gPj4+Pj4+PiBhZ28sIGFuZCBpdCBzZWVtZWQgdGhlbiB0aGF0IFRT VldHIGRpZG4ndCBhZ3JlZSB0aGF0IHN1Y2ggaGVhdnktaGFuZGVkDQo+ID4+Pj4+Pj4gImFkdmlj ZSIsIHBhcnRpY3VsYXJseSB3aXRob3V0IHNwZWNpZmljIGp1c3RpZmljYXRpb24sIHdhcyB0aGUg d2F5IHRvDQo+ID4+IGdvLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRTVldHIGFncmVlZCB0aGF0IGxp bWl0aW5nIElBTkEgd2FzIG5vdCBhcHByb3ByaWF0ZTsgdGhpcyBkb2N1bWVudA0KPiA+Pj4+Pj4g ZG9lc24ndCBsaW1pdCBJQU5BLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEFuZCBzcGVjaWZpYyBqdXN0 aWZpY2F0aW9uIGlzIHByb3ZpZGVkIGluIHRoZSBkaXNjdXNzaW9uIEkgZ2F2ZS4gQWdhaW4sDQo+ ID4+Pj4+PiBpZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGF0IGRpc2N1c3Npb24sIHBsZWFzZSBleHBs YWluLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEUuZy4sIGRvIHlvdSBhY3R1YWxseSB0aGluayBpdCdz IGdvb2Qgc2VjdXJpdHkgcHJhY3RpY2UgdG8gY3JlYXRlIG5ldywNCj4gPj4+Pj4+IGluc2VjdXJl IHNlcnZpY2VzPyBJZiBzbywgb24gd2hhdCBiYXNpcyBvZiBnb29kIHNlY3VyaXR5IHByYWN0aWNl Pw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEpvZQ0KPiA+Pj4+Pg0KPiA+Pj4NCj4gPg0KDQo= From nobody Thu May 29 11:11:03 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCE11A048E for ; Thu, 29 May 2014 11:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGbHdpjRqfte for ; Thu, 29 May 2014 11:10:59 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F8C1A01C3 for ; Thu, 29 May 2014 11:10:59 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4TIAcjq008838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 May 2014 11:10:38 -0700 (PDT) Message-ID: <5387781E.4090600@isi.edu> Date: Thu, 29 May 2014 11:10:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C663209@MX15A.corp.emc.com> <53854308.8020705@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C66334F@MX15A.corp.emc.com> <538611F4.8000905@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C66364B@MX15A.corp.emc.com> <538758E6.2080208@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C663684@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C663684@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/wo-lZDBSwHvZReOYoO4DSmJY1dI Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:11:01 -0000 On 5/29/2014 10:39 AM, Black, David wrote: > ... >> Maybe we could say "SHOULD NOT ask for two ports", but add "unless (as >> with any SHOULD-level recommendation) sufficient direct rationale for an >> exception is provided"? > > Eliot described an alternative approach: > >> Let me suggest >> two questions to be asked. The first comes right out of the RFC: >> >>> Is pervasive monitoring relevant to this work and if so, how has it >>> been considered? >> >> The second is more general: >> >> How have security considerations been taken into account? The first is related to a BCP with no RFC2119 requirements; it doesn't seem appropriate to demand it be separately addressed, as a result. The latter is already required. >> And throw a MUST around at least being able to answer those questions. >> Reviewers can then use their judgment as to the validity of the answers. > > Beyond Eliot's specific questions (which are good, IMHO), I like the idea > of applying 2119 keywords to the port assignment process as opposed to the > protocol design. That would be an update to RFC6335. This document is intended as guidance for protocol designers. > Moreover, I'm comfortable with using "MUST" for port > assignment process requirements. Sure - we did in RFC6335. > Applying that idea to this discussion, the two key points could be: > > - When requesting both a secure and an insecure port, strong > justification MUST be provided for the insecure port. > > - Precedent (citing other protocols that use an insecure port) is not > strong justification by itself. A strong case for utility of the > insecure service is REQUIRED for approval of the insecure port. > > The above use of "MUST" and "REQUIRED" make it clear what the WG has to do > if they want to go down this path. That's fine. I don't quite see the difference between that an "SHOULD NOT ask for two ports", but if you're more comfortable with the above. > In addition, so we don't lose it: > > - Requests for large numbers of ports (e.g., 10s-100s) SHOULD NOT be made, > as they will be rejected. It'd just as soon say that: Each port requested MUST be justified as independently necessary. That would go in the following section, whose advice I think is still valid in that context: Others have noted "think twice about modifying TCP, then don't" [RFC1263]. In this case, similar advice might be: o Think twice before asking for an assigned port, then try not to. o If more than one port is desired, consider revising the architecture until only one is needed, or, preferably, none. We have a couple of SHOULD NOTs still in the doc; some that need to be cleaned up (UDP section, security), others that seem valid. > In contrast to asking for a secure and an insecure port, this is a case > where a "SHOULD NOT" on protocol design is appropriate, IMHO. > > > > Thanks, > --David > > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Thursday, May 29, 2014 11:57 AM >> To: Black, David >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf- >> tsvwg-port-use-04 (to end 6th June) >> >> >> >> On 5/29/2014 8:34 AM, Black, David wrote: >>> >> ... >>> I draw a distinction between the "add an insecure port" case, where we at >>> least have "running code" for the protocol and the "new request for two >> ports" >>> case where there is no "running code" for the protocol and the initial >> "rough >>> consensus" (assuming that this is from an IETF WG) runs the other way (i.e., >>> towards two ports). >> >> The former is certainly more potentially dangerous than the latter. >> >>>>>>> I just don't think the level of required justification is going >>>>>>> to rise to that sufficient to override a "SHOULD NOT" for every >>>>>>> single protocol design that we have yet to envision. I wish my >>>>>>> foresight was 20/20 :-). >>>>>> >>>>>> FWIW, there aren't a lot of protocols that ask for secure and insecure >>>>>> at the same time. Those come mostly - incredibly - from IETF WGs, where >>>>>> they appear to be (IMO blindly) following past practice. >>>>> >>>>> Here I agree - use of "we've always done it that way" as a rationale >> SHOULD >>>>> be strongly discouraged; beyond that, I'd suggest pointing out that >> requests >>>>> for both ports are viewed with significant skepticism because that reason >>>>> has been the primary rationale for many of them. It would also help to >>>>> add discussion of "justified in terms of service provided": >>>> >>>> AOK. Rather than SHOULD NOT, I'll go with "extreme skepticism" (although >>>> I ask others on the list to weigh-in on this - IMO, "extreme skepticism >>>> for exceptions" is precisely what SHOULD NOT implies). >>> >>> For clarity, I think the "extreme skepticism" should be focused on reliance >>> upon "we've always done it that way" as the rationale, as opposed to broadly >>> on all requests for two ports. IMHO, the latter ought to come across as a >>> requirement to "show your work" as opposed to strong discouragement of all >>> requests for two ports. Independent of the precise wording in RFC 2119, I >>> would expect "SHOULD NOT" to be read as strong discouragement by a >> significant >>> portion of the intended audience. >> >> The problem with "show your work" is that there is no other RFC2119 >> language for that, which means it will have no teeth when the request >> comes for the WG. >> >> I.e., in the case where WG rough consensus seeks two ports, that itself >> will be seen as sufficient unless this BCP says otherwise. >> >> Maybe we could say "SHOULD NOT ask for two ports", but add "unless (as >> with any SHOULD-level recommendation) sufficient direct rationale for an >> exception is provided"? >> >> Joe >> >>> >>> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: Joe Touch [mailto:touch@isi.edu] >>>> Sent: Wednesday, May 28, 2014 12:42 PM >>>> To: Black, David; Paul Hoffman >>>> Cc: tsvwg@ietf.org >>>> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft- >> ietf- >>>> tsvwg-port-use-04 (to end 6th June) >>>> >>>> >>>> >>>> On 5/28/2014 9:32 AM, Black, David wrote: >>>>> >>>>> >>>>>>> - should a user request two ports for a new service, one >>>>>>> secure and one insecure? >>>>>>> >>>>>>> I suspect that the advice for the this one is likely to be a long >>>>>>> version of "it depends" in practice. >>>>>>> >>>>>>> IMO, the secure port is easy, if otherwise >>>>>>> warranted (not a duplicate of existing service, e.g.), >>>>>>> but the insecure one similarly creates a new >>>>>>> vulnerability, and again I would say SHOULD NOT >>>>>>> request a new insecure port >>>>>>> >>>>>>> I agree with the secure port being fine, but I'm not comfortable >>>>>>> with a blanket "SHOULD NOT" recommendation for the insecure port. >>>>>>> >>>>>>> I think this depends on the details of the protocol. I'd definitely >>>>>>> set an expectation that solid justification for the new insecure >>>>>>> port will be expected, with the applicant being responsible for >>>>>>> justifying why use of security is not mandatory for the protocol. >>>>>>> If that justification makes the case, then the firewall control >>>>>>> rationale (below) definitely sounds reasonable, IMHO. >>>>>> >>>>>> Why isn't that a SHOULD NOT? Certainly a bit more text is in order, but >>>>>> it seems like we're in agreement - deep justification is needed. >>>>> >>>>> We're dealing with a process as opposed to a protocol here, so the >>>> functionality >>>>> of some future protocol that will ask for ports is unknown to us at the >>>> moment. >>>>> >>>>> I think I'm mostly looking for some gradation wrt the other SHOULD NOT: >>>>> >>>>>>> - given a current secure assignment, what >>>>>>> if a user requests a (new) second port for insecure access? >>>>>>> >>>>>>> it seems like a SHOULD NOT recommendation >>>>>>> is appropriate; this creates new vulnerability; >>>>>>> >>>>>>> I presume that the latter recommendation envisions a scenario where >>>>>>> the secure port has been deployed and used for a significant period >>>>>>> of time. >>>>>> >>>>>> Yes. >>>>> >>>>> IMHO, that "running code" deployment and use experience provides a solid >>>>> strong foundation for a "SHOULD NOT" by comparison to the "new request >>>>> for two ports" case, where a "SHOULD NOT" strikes me as pre-evaluating >>>>> protocol design decisions, sight unseen, for protocols that nobody's >>>>> even thought of, yet. >>>> >>>> In both cases we're assessing an event in the future - as with *every* >>>> RFC 2119 recommendation. The SHOULD NOT isn't pre-evaluating - it's >>>> saying that there are enough concerns with this path that strong >>>> justification is needed - just like *every* SHOULD or SHOULD NOT exception. >>>> >>>>>>> I just don't think the level of required justification is going >>>>>>> to rise to that sufficient to override a "SHOULD NOT" for every >>>>>>> single protocol design that we have yet to envision. I wish my >>>>>>> foresight was 20/20 :-). >>>>>> >>>>>> FWIW, there aren't a lot of protocols that ask for secure and insecure >>>>>> at the same time. Those come mostly - incredibly - from IETF WGs, where >>>>>> they appear to be (IMO blindly) following past practice. >>>>> >>>>> Here I agree - use of "we've always done it that way" as a rationale >> SHOULD >>>>> be strongly discouraged; beyond that, I'd suggest pointing out that >> requests >>>>> for both ports are viewed with significant skepticism because that reason >>>>> has been the primary rationale for many of them. It would also help to >>>>> add discussion of "justified in terms of service provided": >>>> >>>> AOK. Rather than SHOULD NOT, I'll go with "extreme skepticism" (although >>>> I ask others on the list to weigh-in on this - IMO, "extreme skepticism >>>> for exceptions" is precisely what SHOULD NOT implies). >>>> >>>> Joe >>>> >>>>>> My key concern is "why is the insecure port needed"? Most of the time >>>>>> the justification is pure performance - running security on the service >>>>>> will make it too slow, and this will allow faster performance inside an >>>>>> enterprise. That might be true, but it also needs to be justified in >>>>>> terms of the service being provided - that this is a high-throughput or >>>>>> high-transaction frequency system that needs high performance inside >>>>>> protected enterprises. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> --David >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Joe Touch [mailto:touch@isi.edu] >>>>>> Sent: Tuesday, May 27, 2014 10:00 PM >>>>>> To: Black, David; Paul Hoffman >>>>>> Cc: tsvwg@ietf.org >>>>>> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft- >>>> ietf- >>>>>> tsvwg-port-use-04 (to end 6th June) >>>>>> >>>>>> >>>>>> >>>>>> On 5/27/2014 5:40 PM, Black, David wrote: >>>>>>> Joe, >>>>>>> >>>>>>> >>>>>>> >>>>>>>> If you disagree with the analysis, you should present a >> counterargument. >>>>>>> >>>>>>> Ok, I'll try ... ;-). >>>>>>> >>>>>>> It might help if this had somewhat more of a flavor of documenting the >>>>>>> review criteria that are currently used, although I do think at least >>>>>>> one "SHOULD NOT" is likely to turn up in the final text. >>>>>>> >>>>>>> I'd certainly like to see some Security Area input (and probably also >>>>>>> OPS, as firewalls play a prominent role), but speaking for myself, >>>>>>> I think offering security advice is well within reason here ... >>>>>>> >>>>>>> Going back to the three scenarios at the start of this thread, the >>>>>>> proposals for the first two seem reasonable (IMHO): >>>>>>> >>>>>>> - given a current non-secure assignment, what if a >>>>>>> user requests a (new) second port for secure access? >>>>>>> >>>>>>> this is fine, if not a good idea; >>>>>>> >>>>>>> - given a current secure assignment, what >>>>>>> if a user requests a (new) second port for insecure access? >>>>>>> >>>>>>> it seems like a SHOULD NOT recommendation >>>>>>> is appropriate; this creates new vulnerability; >>>>>>> >>>>>>> I presume that the latter recommendation envisions a scenario where >>>>>>> the secure port has been deployed and used for a significant period >>>>>>> of time. >>>>>> >>>>>> Yes. >>>>>> >>>>>>> In that case, I think a "SHOULD NOT" is ok, as I'd want to >>>>>>> see some heavy-duty serious justification for adding the insecure >>>>>>> port. The draft should state that presumption, though, as deployment >>>>>>> difficulties/experience might result in something closer to the third >>>>>>> scenario. >>>>>> >>>>>> Right - that's the point of the SHOULD NOT. It's not a MUST NOT. It just >>>>>> needs very heavy justification. >>>>>> >>>>>>> - should a user request two ports for a new service, one >>>>>>> secure and one insecure? >>>>>>> >>>>>>> I suspect that the advice for the this one is likely to be a long >>>>>>> version of "it depends" in practice. >>>>>>> >>>>>>> IMO, the secure port is easy, if otherwise >>>>>>> warranted (not a duplicate of existing service, e.g.), >>>>>>> but the insecure one similarly creates a new >>>>>>> vulnerability, and again I would say SHOULD NOT >>>>>>> request a new insecure port >>>>>>> >>>>>>> I agree with the secure port being fine, but I'm not comfortable >>>>>>> with a blanket "SHOULD NOT" recommendation for the insecure port. >>>>>>> >>>>>>> I think this depends on the details of the protocol. I'd definitely >>>>>>> set an expectation that solid justification for the new insecure >>>>>>> port will be expected, with the applicant being responsible for >>>>>>> justifying why use of security is not mandatory for the protocol. >>>>>>> If that justification makes the case, then the firewall control >>>>>>> rationale (below) definitely sounds reasonable, IMHO. >>>>>> >>>>>> Why isn't that a SHOULD NOT? Certainly a bit more text is in order, but >>>>>> it seems like we're in agreement - deep justification is needed. >>>>>> >>>>>>> I just don't think the level of required justification is going >>>>>>> to rise to that sufficient to override a "SHOULD NOT" for every >>>>>>> single protocol design that we have yet to envision. I wish my >>>>>>> foresight was 20/20 :-). >>>>>> >>>>>> FWIW, there aren't a lot of protocols that ask for secure and insecure >>>>>> at the same time. Those come mostly - incredibly - from IETF WGs, where >>>>>> they appear to be (IMO blindly) following past practice. >>>>>> >>>>>> My key concern is "why is the insecure port needed"? Most of the time >>>>>> the justification is pure performance - running security on the service >>>>>> will make it too slow, and this will allow faster performance inside an >>>>>> enterprise. That might be true, but it also needs to be justified in >>>>>> terms of the service being provided - that this is a high-throughput or >>>>>> high-transaction frequency system that needs high performance inside >>>>>> protected enterprises. >>>>>> >>>>>>> - GIVEN a request for an insecure and secure port, what >>>>>>> are appropriate justifications? >>>>>>> >>>>>>> IMO, separate firewall control is a sufficient >>>>>>> reason. >>>>>>> >>>>>>> however, performance should not be - i.e., if >>>>>>> both ports will typically have the same firewall >>>>>>> configuration, then only one port is needed >>>>>>> and security should be negotiated as present/absent >>>>>>> in-band. The performance impact of that negotiation >>>>>>> (IMO) should not factor into whether an additional >>>>>>> port should be assigned. >>>>>>> >>>>>>> I think the text on performance should be explicit that the >>>>>>> performance concern is negotiation round trip avoidance. >>>>>> >>>>>> There are a few different performance issues: >>>>>> >>>>>> - round-trip delays >>>>>> - throughput overhead (per byte) >>>>>> - message overhead (per message) >>>>>> >>>>>> Joe >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> --David >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Joe Touch [mailto:touch@isi.edu] >>>>>>>> Sent: Tuesday, May 27, 2014 6:03 PM >>>>>>>> To: Paul Hoffman >>>>>>>> Cc: Black, David; tsvwg@ietf.org >>>>>>>> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for >> draft- >>>>>> ietf- >>>>>>>> tsvwg-port-use-04 (to end 6th June) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 5/27/2014 2:49 PM, Paul Hoffman wrote: >>>>>>>>> Is this new advice based on any actual evidence or even a security >>>>>> analysis? >>>>>>>> >>>>>>>> It's based on 8 years of running the review team and discussions within >>>>>>>> that team. It's based on the analysis provided. >>>>>>>> >>>>>>>> If you disagree with the analysis, you should present a >> counterargument. >>>>>>>> >>>>>>>>> Further, a statement of "SHOULD NOT request" sounds a hell of a lot >> more >>>>>>>>> like a demand than advice. >>>>>>>> >>>>>>>> What exactly can we *demand* of a user making an application other that >>>>>>>> to provide advice? It's not advice to IANA or the ports team in how to >>>>>>>> make a decision. >>>>>>>> >>>>>>>>> This gets to the crux of my concern of the >>>>>>>>> document: it feel like the advice is meant to come from on high >> (namely, >>>>>>>>> someone who can block IANA requests), not friendly advice from one >>>>>>>>> developer to another. >>>>>>>> >>>>>>>> Can you provide a rationale for that claim other than "because Joe >> Touch >>>>>>>> wrote it"? >>>>>>>> >>>>>>>>> We went through this in the discussion a few years >>>>>>>>> ago, and it seemed then that TSVWG didn't agree that such heavy-handed >>>>>>>>> "advice", particularly without specific justification, was the way to >>>> go. >>>>>>>> >>>>>>>> TSVWG agreed that limiting IANA was not appropriate; this document >>>>>>>> doesn't limit IANA. >>>>>>>> >>>>>>>> And specific justification is provided in the discussion I gave. Again, >>>>>>>> if you disagree with that discussion, please explain. >>>>>>>> >>>>>>>> E.g., do you actually think it's good security practice to create new, >>>>>>>> insecure services? If so, on what basis of good security practice? >>>>>>>> >>>>>>>> Joe >>>>>>> >>>>> >>> > From nobody Thu May 29 11:59:22 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67A51A0A7D for ; Thu, 29 May 2014 11:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2hgkikwa2la for ; Thu, 29 May 2014 11:58:59 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BA41A0A7C for ; Thu, 29 May 2014 11:58:58 -0700 (PDT) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4TIwpXA031867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 14:58:54 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s4TIwpXA031867 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401389934; bh=r7q4KSVwGbAfCB/QYYGDh7+HjCs=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=MMOdE2G9Z3qhwJ8Pihg4rPwx8ZmZV6myfda4guBzisc5wl6MfKXZtIwafZPwYgNv8 shE2/sZTNdBgsHJvBneRvLJPCpIP6S7Irons+qIS278ny3GKnM0OEEchOL9idBbus1 G7JdNm2F72MbDmDRtViY6tTQk8iflznJ8OK6YCIM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s4TIwpXA031867 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd04.lss.emc.com (RSA Interceptor); Thu, 29 May 2014 11:58:45 -0700 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4TIwi81003861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 14:58:45 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 29 May 2014 14:58:44 -0400 From: "Black, David" To: Joe Touch Date: Thu, 29 May 2014 14:58:42 -0400 Thread-Topic: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) Thread-Index: Ac97aVlAQDiHuhPrRRySEIoD+My8jgABCYog Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C6636C5@MX15A.corp.emc.com> References: <537D9AC4.80602@erg.abdn.ac.uk> <8D3D17ACE214DC429325B2B98F3AE712076C662E04@MX15A.corp.emc.com> <5385026F.5000908@isi.edu> <53850B87.6010604@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C663209@MX15A.corp.emc.com> <53854308.8020705@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C66334F@MX15A.corp.emc.com> <538611F4.8000905@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C66364B@MX15A.corp.emc.com> <538758E6.2080208@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712076C663684@MX15A.corp.emc.com> <5387781E.4090600@isi.edu> In-Reply-To: <5387781E.4090600@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/a8ilFORnEq-hAghYRaopu70lDks Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:59:10 -0000 PFdHIGNoYWlyIGhhdCBPRkY+DQoNCj4gPiBJIGxpa2UgdGhlIGlkZWENCj4gPiBvZiBhcHBseWlu ZyAyMTE5IGtleXdvcmRzIHRvIHRoZSBwb3J0IGFzc2lnbm1lbnQgcHJvY2VzcyBhcyBvcHBvc2Vk IHRvIHRoZQ0KPiA+IHByb3RvY29sIGRlc2lnbi4NCj4NCj4gVGhhdCB3b3VsZCBiZSBhbiB1cGRh dGUgdG8gUkZDNjMzNS4NCj4NCj4gVGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCBhcyBndWlkYW5j ZSBmb3IgcHJvdG9jb2wgZGVzaWduZXJzLg0KDQpXZWxsLCBwcm90b2NvbCBkZXNpZ25lcnMgYXJl IGdvaW5nIHRvIGJlIGludm9sdmVkIGluIGFwcGx5aW5nIGZvciBwb3J0DQphc3NpZ25tZW50cywg c28gdGhlIHNjb3BlIG9mIGd1aWRhbmNlIGV4dGVuZHMgdG8gdXNlIG9mIHRoYXQgcHJvY2Vzcy4N Cg0KUHJlZmVyYWJseSwgYW4gdXBkYXRlIHRvIFJGQyA2MzM1IGNhbiBiZSBhdm9pZGVkIGJ5IG1h a2luZyBhbnkgdXNlIG9mIDIxMTkNCmtleXdvcmRzIGNvbnNpc3RlbnQgd2l0aCBSRkMgNjMzNSdz IHJlcXVpcmVtZW50cy4gIEluZGVwZW5kZW50IG9mIHdoZXRoZXINCnRoYXQgaGFwcGVucywgdGhl IHRvcGljIG9mIHdoZXRoZXIgdGhpcyBkcmFmdCB1cGRhdGVzIDYzMzUgYW5kIHRoZSBwcmVjaXNl DQpzcGVjaWZpY3Mgb2Ygd2hhdCBpcyBiZWluZyB1cGRhdGVkIG91Z2h0IHRvIGJlIHNlY29uZGFy eSB0byBmaWd1cmluZyBvdXQNCndoYXQgdGhpcyBkcmFmdCBzaG91bGQgc2F5IGFuZCB3aHksIElN SE8uDQoNCj4gPiBNb3Jlb3ZlciwgSSdtIGNvbWZvcnRhYmxlIHdpdGggdXNpbmcgIk1VU1QiIGZv ciBwb3J0DQo+ID4gYXNzaWdubWVudCBwcm9jZXNzIHJlcXVpcmVtZW50cy4NCj4NCj4gU3VyZSAt IHdlIGRpZCBpbiBSRkM2MzM1Lg0KPg0KPiA+IEFwcGx5aW5nIHRoYXQgaWRlYSB0byB0aGlzIGRp c2N1c3Npb24sIHRoZSB0d28ga2V5IHBvaW50cyBjb3VsZCBiZToNCj4gPg0KPiA+IC0gV2hlbiBy ZXF1ZXN0aW5nIGJvdGggYSBzZWN1cmUgYW5kIGFuIGluc2VjdXJlIHBvcnQsIHN0cm9uZw0KPiA+ ICAgICAgICAgIGp1c3RpZmljYXRpb24gTVVTVCBiZSBwcm92aWRlZCBmb3IgdGhlIGluc2VjdXJl IHBvcnQuDQo+ICA+DQo+ID4gLSBQcmVjZWRlbnQgKGNpdGluZyBvdGhlciBwcm90b2NvbHMgdGhh dCB1c2UgYW4gaW5zZWN1cmUgcG9ydCkgaXMgbm90DQo+ID4gICAgICAgICAgc3Ryb25nIGp1c3Rp ZmljYXRpb24gYnkgaXRzZWxmLiAgQSBzdHJvbmcgY2FzZSBmb3IgdXRpbGl0eSBvZiB0aGUNCj4g PiAgICAgICAgICBpbnNlY3VyZSBzZXJ2aWNlIGlzIFJFUVVJUkVEIGZvciBhcHByb3ZhbCBvZiB0 aGUgaW5zZWN1cmUgcG9ydC4NCj4gPg0KPiA+IFRoZSBhYm92ZSB1c2Ugb2YgIk1VU1QiIGFuZCAi UkVRVUlSRUQiIG1ha2UgaXQgY2xlYXIgd2hhdCB0aGUgV0cgaGFzIHRvIGRvDQo+ID4gaWYgdGhl eSB3YW50IHRvIGdvIGRvd24gdGhpcyBwYXRoLg0KPg0KPiBUaGF0J3MgZmluZS4gSSBkb24ndCBx dWl0ZSBzZWUgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGF0IGFuICJTSE9VTEQNCj4gTk9UIGFz ayBmb3IgdHdvIHBvcnRzIiwgYnV0IGlmIHlvdSdyZSBtb3JlIGNvbWZvcnRhYmxlIHdpdGggdGhl IGFib3ZlLg0KDQpZZXMsIHBsZWFzZS4NCg0KSSB0aGluayB0aGlzIGlzIG9uIGZpcm1lciBncm91 bmQgZm9jdXNpbmcgb24gcHJvY2VzcyByYXRoZXIgdGhhbiBkZXNpZ24gb2YNCnlldC10by1iZS1l bnZpc2lvbmVkIHByb3RvY29scy4gIEluIGFkZGl0aW9uLCBhICJTSE9VTEQgTk9UIiBvbiBhIHBy b2Nlc3MNCnRvcGljIGlzIGVhc3kgdG8gKG1pcy0pcmVhZCBhcyAiRG9uJ3QgZXZlbiBib3RoZXIg dHJ5aW5nIHRoaXMsIHlvdSdsbCBvbmx5DQpzdWNjZWVkIGluIGFubm95aW5nIHRoZSBwZW9wbGUg d2hvc2UgYXBwcm92YWwgeW91IG5lZWQuIg0KDQpUaGFua3MgaW4gYWR2YW5jZSBmb3IgbG9va2lu ZyBhdCB0aGUgb3RoZXIgaW5zdGFuY2VzIG9mICJTSE9VTEQgTk9UIiBmb3INCnNpbWlsYXIgY29u Y2VybnMuDQoNCjwvV0cgY2hhaXIgaGF0IE9GRj4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNo QGlzaS5lZHVdDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgMjoxMSBQTQ0KPiBUbzog QmxhY2ssIERhdmlkDQo+IENjOiB0c3Z3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Rzdndn XSBhZGRpdGlvbmFsIHBvcnRzIGZvciBzZWN1cml0eSAtIFJlOiBXR0xDIGZvciBkcmFmdC1pZXRm LQ0KPiB0c3Z3Zy1wb3J0LXVzZS0wNCAodG8gZW5kIDZ0aCBKdW5lKQ0KPg0KPg0KPg0KPiBPbiA1 LzI5LzIwMTQgMTA6MzkgQU0sIEJsYWNrLCBEYXZpZCB3cm90ZToNCj4gPiA8V0cgY2hhaXIgaGF0 IE9GRj4NCj4gLi4uDQo+ID4+IE1heWJlIHdlIGNvdWxkIHNheSAiU0hPVUxEIE5PVCBhc2sgZm9y IHR3byBwb3J0cyIsIGJ1dCBhZGQgInVubGVzcyAoYXMNCj4gPj4gd2l0aCBhbnkgU0hPVUxELWxl dmVsIHJlY29tbWVuZGF0aW9uKSBzdWZmaWNpZW50IGRpcmVjdCByYXRpb25hbGUgZm9yIGFuDQo+ ID4+IGV4Y2VwdGlvbiBpcyBwcm92aWRlZCI/DQo+ID4NCj4gPiBFbGlvdCBkZXNjcmliZWQgYW4g YWx0ZXJuYXRpdmUgYXBwcm9hY2g6DQo+ID4NCj4gPj4gTGV0IG1lIHN1Z2dlc3QNCj4gPj4gdHdv IHF1ZXN0aW9ucyB0byBiZSBhc2tlZC4gIFRoZSBmaXJzdCBjb21lcyByaWdodCBvdXQgb2YgdGhl IFJGQzoNCj4gPj4NCj4gPj4+IElzIHBlcnZhc2l2ZSBtb25pdG9yaW5nIHJlbGV2YW50IHRvIHRo aXMgd29yayBhbmQgaWYgc28sIGhvdyBoYXMgaXQNCj4gPj4+IGJlZW4gY29uc2lkZXJlZD8NCj4g Pj4NCj4gPj4gVGhlIHNlY29uZCBpcyBtb3JlIGdlbmVyYWw6DQo+ID4+DQo+ID4+IEhvdyBoYXZl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGJlZW4gdGFrZW4gaW50byBhY2NvdW50Pw0KPg0KPiBU aGUgZmlyc3QgaXMgcmVsYXRlZCB0byBhIEJDUCB3aXRoIG5vIFJGQzIxMTkgcmVxdWlyZW1lbnRz OyBpdCBkb2Vzbid0DQo+IHNlZW0gYXBwcm9wcmlhdGUgdG8gZGVtYW5kIGl0IGJlIHNlcGFyYXRl bHkgYWRkcmVzc2VkLCBhcyBhIHJlc3VsdC4NCj4NCj4gVGhlIGxhdHRlciBpcyBhbHJlYWR5IHJl cXVpcmVkLg0KPg0KPiA+PiBBbmQgdGhyb3cgYSBNVVNUIGFyb3VuZCBhdCBsZWFzdCBiZWluZyBh YmxlIHRvIGFuc3dlciB0aG9zZSBxdWVzdGlvbnMuDQo+ID4+IFJldmlld2VycyBjYW4gdGhlbiB1 c2UgdGhlaXIganVkZ21lbnQgYXMgdG8gdGhlIHZhbGlkaXR5IG9mIHRoZSBhbnN3ZXJzLg0KPiA+ DQo+ID4gQmV5b25kIEVsaW90J3Mgc3BlY2lmaWMgcXVlc3Rpb25zICh3aGljaCBhcmUgZ29vZCwg SU1ITyksIEkgbGlrZSB0aGUgaWRlYQ0KPiA+IG9mIGFwcGx5aW5nIDIxMTkga2V5d29yZHMgdG8g dGhlIHBvcnQgYXNzaWdubWVudCBwcm9jZXNzIGFzIG9wcG9zZWQgdG8gdGhlDQo+ID4gcHJvdG9j b2wgZGVzaWduLg0KPg0KPiBUaGF0IHdvdWxkIGJlIGFuIHVwZGF0ZSB0byBSRkM2MzM1Lg0KPg0K PiBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkIGFzIGd1aWRhbmNlIGZvciBwcm90b2NvbCBkZXNp Z25lcnMuDQo+DQo+ID4gTW9yZW92ZXIsIEknbSBjb21mb3J0YWJsZSB3aXRoIHVzaW5nICJNVVNU IiBmb3IgcG9ydA0KPiA+IGFzc2lnbm1lbnQgcHJvY2VzcyByZXF1aXJlbWVudHMuDQo+DQo+IFN1 cmUgLSB3ZSBkaWQgaW4gUkZDNjMzNS4NCj4NCj4gPiBBcHBseWluZyB0aGF0IGlkZWEgdG8gdGhp cyBkaXNjdXNzaW9uLCB0aGUgdHdvIGtleSBwb2ludHMgY291bGQgYmU6DQo+ID4NCj4gPiAtIFdo ZW4gcmVxdWVzdGluZyBib3RoIGEgc2VjdXJlIGFuZCBhbiBpbnNlY3VyZSBwb3J0LCBzdHJvbmcN Cj4gPiAgICAgICAgICBqdXN0aWZpY2F0aW9uIE1VU1QgYmUgcHJvdmlkZWQgZm9yIHRoZSBpbnNl Y3VyZSBwb3J0Lg0KPiAgPg0KPiA+IC0gUHJlY2VkZW50IChjaXRpbmcgb3RoZXIgcHJvdG9jb2xz IHRoYXQgdXNlIGFuIGluc2VjdXJlIHBvcnQpIGlzIG5vdA0KPiA+ICAgICAgICAgIHN0cm9uZyBq dXN0aWZpY2F0aW9uIGJ5IGl0c2VsZi4gIEEgc3Ryb25nIGNhc2UgZm9yIHV0aWxpdHkgb2YgdGhl DQo+ID4gICAgICAgICAgaW5zZWN1cmUgc2VydmljZSBpcyBSRVFVSVJFRCBmb3IgYXBwcm92YWwg b2YgdGhlIGluc2VjdXJlIHBvcnQuDQo+ID4NCj4gPiBUaGUgYWJvdmUgdXNlIG9mICJNVVNUIiBh bmQgIlJFUVVJUkVEIiBtYWtlIGl0IGNsZWFyIHdoYXQgdGhlIFdHIGhhcyB0byBkbw0KPiA+IGlm IHRoZXkgd2FudCB0byBnbyBkb3duIHRoaXMgcGF0aC4NCj4NCj4gVGhhdCdzIGZpbmUuIEkgZG9u J3QgcXVpdGUgc2VlIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhhdCBhbiAiU0hPVUxEDQo+IE5P VCBhc2sgZm9yIHR3byBwb3J0cyIsIGJ1dCBpZiB5b3UncmUgbW9yZSBjb21mb3J0YWJsZSB3aXRo IHRoZSBhYm92ZS4NCj4NCj4gPiBJbiBhZGRpdGlvbiwgc28gd2UgZG9uJ3QgbG9zZSBpdDoNCj4g Pg0KPiA+IC0gUmVxdWVzdHMgZm9yIGxhcmdlIG51bWJlcnMgb2YgcG9ydHMgKGUuZy4sIDEwcy0x MDBzKSBTSE9VTEQgTk9UIGJlIG1hZGUsDQo+ID4gICAgICAgICAgYXMgdGhleSB3aWxsIGJlIHJl amVjdGVkLg0KPg0KPiBJdCdkIGp1c3QgYXMgc29vbiBzYXkgdGhhdDoNCj4NCj4gICAgICAgRWFj aCBwb3J0IHJlcXVlc3RlZCBNVVNUIGJlIGp1c3RpZmllZCBhcw0KPiAgICAgICBpbmRlcGVuZGVu dGx5IG5lY2Vzc2FyeS4NCj4NCj4gVGhhdCB3b3VsZCBnbyBpbiB0aGUgZm9sbG93aW5nIHNlY3Rp b24sIHdob3NlIGFkdmljZSBJIHRoaW5rIGlzIHN0aWxsDQo+IHZhbGlkIGluIHRoYXQgY29udGV4 dDoNCj4NCj4gICAgIE90aGVycyBoYXZlIG5vdGVkICJ0aGluayB0d2ljZSBhYm91dCBtb2RpZnlp bmcgVENQLCB0aGVuIGRvbid0Ig0KPiAgICAgW1JGQzEyNjNdLiBJbiB0aGlzIGNhc2UsIHNpbWls YXIgYWR2aWNlIG1pZ2h0IGJlOg0KPg0KPiAgICAgICAgbyAgVGhpbmsgdHdpY2UgYmVmb3JlIGFz a2luZyBmb3IgYW4gYXNzaWduZWQgcG9ydCwgdGhlbiB0cnkgbm90DQo+ICAgICAgICAgICB0by4N Cj4NCj4gICAgICAgIG8gIElmIG1vcmUgdGhhbiBvbmUgcG9ydCBpcyBkZXNpcmVkLCBjb25zaWRl ciByZXZpc2luZyB0aGUNCj4gICAgICAgICAgIGFyY2hpdGVjdHVyZSB1bnRpbCBvbmx5IG9uZSBp cyBuZWVkZWQsIG9yLCBwcmVmZXJhYmx5LCBub25lLg0KPg0KPiBXZSBoYXZlIGEgY291cGxlIG9m IFNIT1VMRCBOT1RzIHN0aWxsIGluIHRoZSBkb2M7IHNvbWUgdGhhdCBuZWVkIHRvIGJlDQo+IGNs ZWFuZWQgdXAgKFVEUCBzZWN0aW9uLCBzZWN1cml0eSksIG90aGVycyB0aGF0IHNlZW0gdmFsaWQu DQo+DQo+ID4gSW4gY29udHJhc3QgdG8gYXNraW5nIGZvciBhIHNlY3VyZSBhbmQgYW4gaW5zZWN1 cmUgcG9ydCwgdGhpcyBpcyBhIGNhc2UNCj4gPiB3aGVyZSBhICJTSE9VTEQgTk9UIiBvbiBwcm90 b2NvbCBkZXNpZ24gaXMgYXBwcm9wcmlhdGUsIElNSE8uDQo+ID4NCj4gPiA8L1dHIGNoYWlyIGhh dCBPRkY+DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gLS1EYXZpZA0KPiA+DQo+ID4NCj4gPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogSm9lIFRvdWNoIFttYWlsdG86dG91 Y2hAaXNpLmVkdV0NCj4gPj4gU2VudDogVGh1cnNkYXksIE1heSAyOSwgMjAxNCAxMTo1NyBBTQ0K PiA+PiBUbzogQmxhY2ssIERhdmlkDQo+ID4+IENjOiB0c3Z3Z0BpZXRmLm9yZw0KPiA+PiBTdWJq ZWN0OiBSZTogW3RzdndnXSBhZGRpdGlvbmFsIHBvcnRzIGZvciBzZWN1cml0eSAtIFJlOiBXR0xD IGZvciBkcmFmdC0NCj4gaWV0Zi0NCj4gPj4gdHN2d2ctcG9ydC11c2UtMDQgKHRvIGVuZCA2dGgg SnVuZSkNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gNS8yOS8yMDE0IDg6MzQgQU0sIEJsYWNr LCBEYXZpZCB3cm90ZToNCj4gPj4+IDxXRyBjaGFpciBoYXQgT0ZGPg0KPiA+PiAuLi4NCj4gPj4+ IEkgZHJhdyBhIGRpc3RpbmN0aW9uIGJldHdlZW4gdGhlICJhZGQgYW4gaW5zZWN1cmUgcG9ydCIg Y2FzZSwgd2hlcmUgd2UgYXQNCj4gPj4+IGxlYXN0IGhhdmUgInJ1bm5pbmcgY29kZSIgZm9yIHRo ZSBwcm90b2NvbCBhbmQgdGhlICJuZXcgcmVxdWVzdCBmb3IgdHdvDQo+ID4+IHBvcnRzIg0KPiA+ Pj4gY2FzZSB3aGVyZSB0aGVyZSBpcyBubyAicnVubmluZyBjb2RlIiBmb3IgdGhlIHByb3RvY29s IGFuZCB0aGUgaW5pdGlhbA0KPiA+PiAicm91Z2gNCj4gPj4+IGNvbnNlbnN1cyIgKGFzc3VtaW5n IHRoYXQgdGhpcyBpcyBmcm9tIGFuIElFVEYgV0cpIHJ1bnMgdGhlIG90aGVyIHdheQ0KPiAoaS5l LiwNCj4gPj4+IHRvd2FyZHMgdHdvIHBvcnRzKS4NCj4gPj4NCj4gPj4gVGhlIGZvcm1lciBpcyBj ZXJ0YWlubHkgbW9yZSBwb3RlbnRpYWxseSBkYW5nZXJvdXMgdGhhbiB0aGUgbGF0dGVyLg0KPiA+ Pg0KPiA+Pj4+Pj4+IEkganVzdCBkb24ndCB0aGluayB0aGUgbGV2ZWwgb2YgcmVxdWlyZWQganVz dGlmaWNhdGlvbiBpcyBnb2luZw0KPiA+Pj4+Pj4+IHRvIHJpc2UgdG8gdGhhdCBzdWZmaWNpZW50 IHRvIG92ZXJyaWRlIGEgIlNIT1VMRCBOT1QiIGZvciBldmVyeQ0KPiA+Pj4+Pj4+IHNpbmdsZSBw cm90b2NvbCBkZXNpZ24gdGhhdCB3ZSBoYXZlIHlldCB0byBlbnZpc2lvbi4gIEkgd2lzaCBteQ0K PiA+Pj4+Pj4+IGZvcmVzaWdodCB3YXMgMjAvMjAgOi0pLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEZX SVcsIHRoZXJlIGFyZW4ndCBhIGxvdCBvZiBwcm90b2NvbHMgdGhhdCBhc2sgZm9yIHNlY3VyZSBh bmQgaW5zZWN1cmUNCj4gPj4+Pj4+IGF0IHRoZSBzYW1lIHRpbWUuIFRob3NlIGNvbWUgbW9zdGx5 IC0gaW5jcmVkaWJseSAtIGZyb20gSUVURiBXR3MsIHdoZXJlDQo+ID4+Pj4+PiB0aGV5IGFwcGVh ciB0byBiZSAoSU1PIGJsaW5kbHkpIGZvbGxvd2luZyBwYXN0IHByYWN0aWNlLg0KPiA+Pj4+Pg0K PiA+Pj4+PiBIZXJlIEkgYWdyZWUgLSB1c2Ugb2YgIndlJ3ZlIGFsd2F5cyBkb25lIGl0IHRoYXQg d2F5IiBhcyBhIHJhdGlvbmFsZQ0KPiA+PiBTSE9VTEQNCj4gPj4+Pj4gYmUgc3Ryb25nbHkgZGlz Y291cmFnZWQ7IGJleW9uZCB0aGF0LCBJJ2Qgc3VnZ2VzdCBwb2ludGluZyBvdXQgdGhhdA0KPiA+ PiByZXF1ZXN0cw0KPiA+Pj4+PiBmb3IgYm90aCBwb3J0cyBhcmUgdmlld2VkIHdpdGggc2lnbmlm aWNhbnQgc2tlcHRpY2lzbSBiZWNhdXNlIHRoYXQNCj4gcmVhc29uDQo+ID4+Pj4+IGhhcyBiZWVu IHRoZSBwcmltYXJ5IHJhdGlvbmFsZSBmb3IgbWFueSBvZiB0aGVtLiAgSXQgd291bGQgYWxzbyBo ZWxwIHRvDQo+ID4+Pj4+IGFkZCBkaXNjdXNzaW9uIG9mICJqdXN0aWZpZWQgaW4gdGVybXMgb2Yg c2VydmljZSBwcm92aWRlZCI6DQo+ID4+Pj4NCj4gPj4+PiBBT0suIFJhdGhlciB0aGFuIFNIT1VM RCBOT1QsIEknbGwgZ28gd2l0aCAiZXh0cmVtZSBza2VwdGljaXNtIiAoYWx0aG91Z2gNCj4gPj4+ PiBJIGFzayBvdGhlcnMgb24gdGhlIGxpc3QgdG8gd2VpZ2gtaW4gb24gdGhpcyAtIElNTywgImV4 dHJlbWUgc2tlcHRpY2lzbQ0KPiA+Pj4+IGZvciBleGNlcHRpb25zIiBpcyBwcmVjaXNlbHkgd2hh dCBTSE9VTEQgTk9UIGltcGxpZXMpLg0KPiA+Pj4NCj4gPj4+IEZvciBjbGFyaXR5LCBJIHRoaW5r IHRoZSAiZXh0cmVtZSBza2VwdGljaXNtIiBzaG91bGQgYmUgZm9jdXNlZCBvbg0KPiByZWxpYW5j ZQ0KPiA+Pj4gdXBvbiAid2UndmUgYWx3YXlzIGRvbmUgaXQgdGhhdCB3YXkiIGFzIHRoZSByYXRp b25hbGUsIGFzIG9wcG9zZWQgdG8NCj4gYnJvYWRseQ0KPiA+Pj4gb24gYWxsIHJlcXVlc3RzIGZv ciB0d28gcG9ydHMuICBJTUhPLCB0aGUgbGF0dGVyIG91Z2h0IHRvIGNvbWUgYWNyb3NzIGFzIGEN Cj4gPj4+IHJlcXVpcmVtZW50IHRvICJzaG93IHlvdXIgd29yayIgYXMgb3Bwb3NlZCB0byBzdHJv bmcgZGlzY291cmFnZW1lbnQgb2YgYWxsDQo+ID4+PiByZXF1ZXN0cyBmb3IgdHdvIHBvcnRzLiAg SW5kZXBlbmRlbnQgb2YgdGhlIHByZWNpc2Ugd29yZGluZyBpbiBSRkMgMjExOSwgSQ0KPiA+Pj4g d291bGQgZXhwZWN0ICJTSE9VTEQgTk9UIiB0byBiZSByZWFkIGFzIHN0cm9uZyBkaXNjb3VyYWdl bWVudCBieSBhDQo+ID4+IHNpZ25pZmljYW50DQo+ID4+PiBwb3J0aW9uIG9mIHRoZSBpbnRlbmRl ZCBhdWRpZW5jZS4NCj4gPj4NCj4gPj4gVGhlIHByb2JsZW0gd2l0aCAic2hvdyB5b3VyIHdvcmsi IGlzIHRoYXQgdGhlcmUgaXMgbm8gb3RoZXIgUkZDMjExOQ0KPiA+PiBsYW5ndWFnZSBmb3IgdGhh dCwgd2hpY2ggbWVhbnMgaXQgd2lsbCBoYXZlIG5vIHRlZXRoIHdoZW4gdGhlIHJlcXVlc3QNCj4g Pj4gY29tZXMgZm9yIHRoZSBXRy4NCj4gPj4NCj4gPj4gSS5lLiwgaW4gdGhlIGNhc2Ugd2hlcmUg V0cgcm91Z2ggY29uc2Vuc3VzIHNlZWtzIHR3byBwb3J0cywgdGhhdCBpdHNlbGYNCj4gPj4gd2ls bCBiZSBzZWVuIGFzIHN1ZmZpY2llbnQgdW5sZXNzIHRoaXMgQkNQIHNheXMgb3RoZXJ3aXNlLg0K PiA+Pg0KPiA+PiBNYXliZSB3ZSBjb3VsZCBzYXkgIlNIT1VMRCBOT1QgYXNrIGZvciB0d28gcG9y dHMiLCBidXQgYWRkICJ1bmxlc3MgKGFzDQo+ID4+IHdpdGggYW55IFNIT1VMRC1sZXZlbCByZWNv bW1lbmRhdGlvbikgc3VmZmljaWVudCBkaXJlY3QgcmF0aW9uYWxlIGZvciBhbg0KPiA+PiBleGNl cHRpb24gaXMgcHJvdmlkZWQiPw0KPiA+Pg0KPiA+PiBKb2UNCj4gPj4NCj4gPj4+IDwvV0cgY2hh aXIgaGF0IE9GRj4NCj4gPj4+DQo+ID4+PiBUaGFua3MsDQo+ID4+PiAtLURhdmlkDQo+ID4+Pg0K PiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogSm9lIFRvdWNo IFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4gPj4+PiBTZW50OiBXZWRuZXNkYXksIE1heSAyOCwg MjAxNCAxMjo0MiBQTQ0KPiA+Pj4+IFRvOiBCbGFjaywgRGF2aWQ7IFBhdWwgSG9mZm1hbg0KPiA+ Pj4+IENjOiB0c3Z3Z0BpZXRmLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbdHN2d2ddIGFkZGl0 aW9uYWwgcG9ydHMgZm9yIHNlY3VyaXR5IC0gUmU6IFdHTEMgZm9yIGRyYWZ0LQ0KPiA+PiBpZXRm LQ0KPiA+Pj4+IHRzdndnLXBvcnQtdXNlLTA0ICh0byBlbmQgNnRoIEp1bmUpDQo+ID4+Pj4NCj4g Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gT24gNS8yOC8yMDE0IDk6MzIgQU0sIEJsYWNrLCBEYXZpZCB3 cm90ZToNCj4gPj4+Pj4gPFdHIGNoYWlyIGhhdCBPRkY+DQo+ID4+Pj4+DQo+ID4+Pj4+Pj4gICAg IC0gc2hvdWxkIGEgdXNlciByZXF1ZXN0IHR3byBwb3J0cyBmb3IgYSBuZXcgc2VydmljZSwgb25l DQo+ID4+Pj4+Pj4gICAgIHNlY3VyZSBhbmQgb25lIGluc2VjdXJlPw0KPiA+Pj4+Pj4+DQo+ID4+ Pj4+Pj4gSSBzdXNwZWN0IHRoYXQgdGhlIGFkdmljZSBmb3IgdGhlIHRoaXMgb25lIGlzIGxpa2Vs eSB0byBiZSBhIGxvbmcNCj4gPj4+Pj4+PiB2ZXJzaW9uIG9mICJpdCBkZXBlbmRzIiBpbiBwcmFj dGljZS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICAgICAgICAgIElNTywgdGhlIHNlY3VyZSBw b3J0IGlzIGVhc3ksIGlmIG90aGVyd2lzZQ0KPiA+Pj4+Pj4+ICAgICAgICAgICAgIHdhcnJhbnRl ZCAobm90IGEgZHVwbGljYXRlIG9mIGV4aXN0aW5nIHNlcnZpY2UsIGUuZy4pLA0KPiA+Pj4+Pj4+ ICAgICAgICAgICAgIGJ1dCB0aGUgaW5zZWN1cmUgb25lIHNpbWlsYXJseSBjcmVhdGVzIGEgbmV3 DQo+ID4+Pj4+Pj4gICAgICAgICAgICAgdnVsbmVyYWJpbGl0eSwgYW5kIGFnYWluIEkgd291bGQg c2F5IFNIT1VMRCBOT1QNCj4gPj4+Pj4+PiAgICAgICAgICAgICByZXF1ZXN0IGEgbmV3IGluc2Vj dXJlIHBvcnQNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEkgYWdyZWUgd2l0aCB0aGUgc2VjdXJlIHBv cnQgYmVpbmcgZmluZSwgYnV0IEknbSBub3QgY29tZm9ydGFibGUNCj4gPj4+Pj4+PiB3aXRoIGEg YmxhbmtldCAiU0hPVUxEIE5PVCIgcmVjb21tZW5kYXRpb24gZm9yIHRoZSBpbnNlY3VyZSBwb3J0 Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSSB0aGluayB0aGlzIGRlcGVuZHMgb24gdGhlIGRldGFp bHMgb2YgdGhlIHByb3RvY29sLiAgSSdkIGRlZmluaXRlbHkNCj4gPj4+Pj4+PiBzZXQgYW4gZXhw ZWN0YXRpb24gdGhhdCBzb2xpZCBqdXN0aWZpY2F0aW9uIGZvciB0aGUgbmV3IGluc2VjdXJlDQo+ ID4+Pj4+Pj4gcG9ydCB3aWxsIGJlIGV4cGVjdGVkLCB3aXRoIHRoZSBhcHBsaWNhbnQgYmVpbmcg cmVzcG9uc2libGUgZm9yDQo+ID4+Pj4+Pj4ganVzdGlmeWluZyB3aHkgdXNlIG9mIHNlY3VyaXR5 IGlzIG5vdCBtYW5kYXRvcnkgZm9yIHRoZSBwcm90b2NvbC4NCj4gPj4+Pj4+PiBJZiB0aGF0IGp1 c3RpZmljYXRpb24gbWFrZXMgdGhlIGNhc2UsIHRoZW4gdGhlIGZpcmV3YWxsIGNvbnRyb2wNCj4g Pj4+Pj4+PiByYXRpb25hbGUgKGJlbG93KSBkZWZpbml0ZWx5IHNvdW5kcyByZWFzb25hYmxlLCBJ TUhPLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFdoeSBpc24ndCB0aGF0IGEgU0hPVUxEIE5PVD8gQ2Vy dGFpbmx5IGEgYml0IG1vcmUgdGV4dCBpcyBpbiBvcmRlciwgYnV0DQo+ID4+Pj4+PiBpdCBzZWVt cyBsaWtlIHdlJ3JlIGluIGFncmVlbWVudCAtIGRlZXAganVzdGlmaWNhdGlvbiBpcyBuZWVkZWQu DQo+ID4+Pj4+DQo+ID4+Pj4+IFdlJ3JlIGRlYWxpbmcgd2l0aCBhIHByb2Nlc3MgYXMgb3Bwb3Nl ZCB0byBhIHByb3RvY29sIGhlcmUsIHNvIHRoZQ0KPiA+Pj4+IGZ1bmN0aW9uYWxpdHkNCj4gPj4+ Pj4gb2Ygc29tZSBmdXR1cmUgcHJvdG9jb2wgdGhhdCB3aWxsIGFzayBmb3IgcG9ydHMgaXMgdW5r bm93biB0byB1cyBhdCB0aGUNCj4gPj4+PiBtb21lbnQuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgdGhp bmsgSSdtIG1vc3RseSBsb29raW5nIGZvciBzb21lIGdyYWRhdGlvbiB3cnQgdGhlIG90aGVyIFNI T1VMRCBOT1Q6DQo+ID4+Pj4+DQo+ID4+Pj4+Pj4gICAgIC0gZ2l2ZW4gYSBjdXJyZW50IHNlY3Vy ZSBhc3NpZ25tZW50LCB3aGF0DQo+ID4+Pj4+Pj4gICAgIGlmIGEgdXNlciByZXF1ZXN0cyBhIChu ZXcpIHNlY29uZCBwb3J0IGZvciBpbnNlY3VyZSBhY2Nlc3M/DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ PiAgICAgICAgICAgICBpdCBzZWVtcyBsaWtlIGEgU0hPVUxEIE5PVCByZWNvbW1lbmRhdGlvbg0K PiA+Pj4+Pj4+ICAgICAgICAgICAgIGlzIGFwcHJvcHJpYXRlOyB0aGlzIGNyZWF0ZXMgbmV3IHZ1 bG5lcmFiaWxpdHk7DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBJIHByZXN1bWUgdGhhdCB0aGUgbGF0 dGVyIHJlY29tbWVuZGF0aW9uIGVudmlzaW9ucyBhIHNjZW5hcmlvIHdoZXJlDQo+ID4+Pj4+Pj4g dGhlIHNlY3VyZSBwb3J0IGhhcyBiZWVuIGRlcGxveWVkIGFuZCB1c2VkIGZvciBhIHNpZ25pZmlj YW50IHBlcmlvZA0KPiA+Pj4+Pj4+IG9mIHRpbWUuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gWWVzLg0K PiA+Pj4+Pg0KPiA+Pj4+PiBJTUhPLCB0aGF0ICJydW5uaW5nIGNvZGUiIGRlcGxveW1lbnQgYW5k IHVzZSBleHBlcmllbmNlIHByb3ZpZGVzIGEgc29saWQNCj4gPj4+Pj4gc3Ryb25nIGZvdW5kYXRp b24gZm9yIGEgIlNIT1VMRCBOT1QiIGJ5IGNvbXBhcmlzb24gdG8gdGhlICJuZXcgcmVxdWVzdA0K PiA+Pj4+PiBmb3IgdHdvIHBvcnRzIiBjYXNlLCB3aGVyZSBhICJTSE9VTEQgTk9UIiBzdHJpa2Vz IG1lIGFzIHByZS1ldmFsdWF0aW5nDQo+ID4+Pj4+IHByb3RvY29sIGRlc2lnbiBkZWNpc2lvbnMs IHNpZ2h0IHVuc2VlbiwgZm9yIHByb3RvY29scyB0aGF0IG5vYm9keSdzDQo+ID4+Pj4+IGV2ZW4g dGhvdWdodCBvZiwgeWV0Lg0KPiA+Pj4+DQo+ID4+Pj4gSW4gYm90aCBjYXNlcyB3ZSdyZSBhc3Nl c3NpbmcgYW4gZXZlbnQgaW4gdGhlIGZ1dHVyZSAtIGFzIHdpdGggKmV2ZXJ5Kg0KPiA+Pj4+IFJG QyAyMTE5IHJlY29tbWVuZGF0aW9uLiBUaGUgU0hPVUxEIE5PVCBpc24ndCBwcmUtZXZhbHVhdGlu ZyAtIGl0J3MNCj4gPj4+PiBzYXlpbmcgdGhhdCB0aGVyZSBhcmUgZW5vdWdoIGNvbmNlcm5zIHdp dGggdGhpcyBwYXRoIHRoYXQgc3Ryb25nDQo+ID4+Pj4ganVzdGlmaWNhdGlvbiBpcyBuZWVkZWQg LSBqdXN0IGxpa2UgKmV2ZXJ5KiBTSE9VTEQgb3IgU0hPVUxEIE5PVA0KPiBleGNlcHRpb24uDQo+ ID4+Pj4NCj4gPj4+Pj4+PiBJIGp1c3QgZG9uJ3QgdGhpbmsgdGhlIGxldmVsIG9mIHJlcXVpcmVk IGp1c3RpZmljYXRpb24gaXMgZ29pbmcNCj4gPj4+Pj4+PiB0byByaXNlIHRvIHRoYXQgc3VmZmlj aWVudCB0byBvdmVycmlkZSBhICJTSE9VTEQgTk9UIiBmb3IgZXZlcnkNCj4gPj4+Pj4+PiBzaW5n bGUgcHJvdG9jb2wgZGVzaWduIHRoYXQgd2UgaGF2ZSB5ZXQgdG8gZW52aXNpb24uICBJIHdpc2gg bXkNCj4gPj4+Pj4+PiBmb3Jlc2lnaHQgd2FzIDIwLzIwIDotKS4NCj4gPj4+Pj4+DQo+ID4+Pj4+ PiBGV0lXLCB0aGVyZSBhcmVuJ3QgYSBsb3Qgb2YgcHJvdG9jb2xzIHRoYXQgYXNrIGZvciBzZWN1 cmUgYW5kIGluc2VjdXJlDQo+ID4+Pj4+PiBhdCB0aGUgc2FtZSB0aW1lLiBUaG9zZSBjb21lIG1v c3RseSAtIGluY3JlZGlibHkgLSBmcm9tIElFVEYgV0dzLCB3aGVyZQ0KPiA+Pj4+Pj4gdGhleSBh cHBlYXIgdG8gYmUgKElNTyBibGluZGx5KSBmb2xsb3dpbmcgcGFzdCBwcmFjdGljZS4NCj4gPj4+ Pj4NCj4gPj4+Pj4gSGVyZSBJIGFncmVlIC0gdXNlIG9mICJ3ZSd2ZSBhbHdheXMgZG9uZSBpdCB0 aGF0IHdheSIgYXMgYSByYXRpb25hbGUNCj4gPj4gU0hPVUxEDQo+ID4+Pj4+IGJlIHN0cm9uZ2x5 IGRpc2NvdXJhZ2VkOyBiZXlvbmQgdGhhdCwgSSdkIHN1Z2dlc3QgcG9pbnRpbmcgb3V0IHRoYXQN Cj4gPj4gcmVxdWVzdHMNCj4gPj4+Pj4gZm9yIGJvdGggcG9ydHMgYXJlIHZpZXdlZCB3aXRoIHNp Z25pZmljYW50IHNrZXB0aWNpc20gYmVjYXVzZSB0aGF0DQo+IHJlYXNvbg0KPiA+Pj4+PiBoYXMg YmVlbiB0aGUgcHJpbWFyeSByYXRpb25hbGUgZm9yIG1hbnkgb2YgdGhlbS4gIEl0IHdvdWxkIGFs c28gaGVscCB0bw0KPiA+Pj4+PiBhZGQgZGlzY3Vzc2lvbiBvZiAianVzdGlmaWVkIGluIHRlcm1z IG9mIHNlcnZpY2UgcHJvdmlkZWQiOg0KPiA+Pj4+DQo+ID4+Pj4gQU9LLiBSYXRoZXIgdGhhbiBT SE9VTEQgTk9ULCBJJ2xsIGdvIHdpdGggImV4dHJlbWUgc2tlcHRpY2lzbSIgKGFsdGhvdWdoDQo+ ID4+Pj4gSSBhc2sgb3RoZXJzIG9uIHRoZSBsaXN0IHRvIHdlaWdoLWluIG9uIHRoaXMgLSBJTU8s ICJleHRyZW1lIHNrZXB0aWNpc20NCj4gPj4+PiBmb3IgZXhjZXB0aW9ucyIgaXMgcHJlY2lzZWx5 IHdoYXQgU0hPVUxEIE5PVCBpbXBsaWVzKS4NCj4gPj4+Pg0KPiA+Pj4+IEpvZQ0KPiA+Pj4+DQo+ ID4+Pj4+PiBNeSBrZXkgY29uY2VybiBpcyAid2h5IGlzIHRoZSBpbnNlY3VyZSBwb3J0IG5lZWRl ZCI/IE1vc3Qgb2YgdGhlIHRpbWUNCj4gPj4+Pj4+IHRoZSBqdXN0aWZpY2F0aW9uIGlzIHB1cmUg cGVyZm9ybWFuY2UgLSBydW5uaW5nIHNlY3VyaXR5IG9uIHRoZSBzZXJ2aWNlDQo+ID4+Pj4+PiB3 aWxsIG1ha2UgaXQgdG9vIHNsb3csIGFuZCB0aGlzIHdpbGwgYWxsb3cgZmFzdGVyIHBlcmZvcm1h bmNlIGluc2lkZSBhbg0KPiA+Pj4+Pj4gZW50ZXJwcmlzZS4gVGhhdCBtaWdodCBiZSB0cnVlLCBi dXQgaXQgYWxzbyBuZWVkcyB0byBiZSBqdXN0aWZpZWQgaW4NCj4gPj4+Pj4+IHRlcm1zIG9mIHRo ZSBzZXJ2aWNlIGJlaW5nIHByb3ZpZGVkIC0gdGhhdCB0aGlzIGlzIGEgaGlnaC10aHJvdWdocHV0 IG9yDQo+ID4+Pj4+PiBoaWdoLXRyYW5zYWN0aW9uIGZyZXF1ZW5jeSBzeXN0ZW0gdGhhdCBuZWVk cyBoaWdoIHBlcmZvcm1hbmNlIGluc2lkZQ0KPiA+Pj4+Pj4gcHJvdGVjdGVkIGVudGVycHJpc2Vz Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiA8L1dHIGNoYWlyIGhhdCBPRkY+DQo+ID4+Pj4+DQo+ID4+Pj4+ IFRoYW5rcywNCj4gPj4+Pj4gLS1EYXZpZA0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+IEZyb206IEpvZSBUb3VjaCBbbWFpbHRv OnRvdWNoQGlzaS5lZHVdDQo+ID4+Pj4+PiBTZW50OiBUdWVzZGF5LCBNYXkgMjcsIDIwMTQgMTA6 MDAgUE0NCj4gPj4+Pj4+IFRvOiBCbGFjaywgRGF2aWQ7IFBhdWwgSG9mZm1hbg0KPiA+Pj4+Pj4g Q2M6IHRzdndnQGlldGYub3JnDQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW3RzdndnXSBhZGRpdGlv bmFsIHBvcnRzIGZvciBzZWN1cml0eSAtIFJlOiBXR0xDIGZvcg0KPiBkcmFmdC0NCj4gPj4+PiBp ZXRmLQ0KPiA+Pj4+Pj4gdHN2d2ctcG9ydC11c2UtMDQgKHRvIGVuZCA2dGggSnVuZSkNCj4gPj4+ Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IE9uIDUvMjcvMjAxNCA1OjQwIFBNLCBC bGFjaywgRGF2aWQgd3JvdGU6DQo+ID4+Pj4+Pj4gSm9lLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g PFdHIGNoYWlyIGhhdCBPRkY+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gSWYgeW91IGRpc2FncmVl IHdpdGggdGhlIGFuYWx5c2lzLCB5b3Ugc2hvdWxkIHByZXNlbnQgYQ0KPiA+PiBjb3VudGVyYXJn dW1lbnQuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBPaywgSSdsbCB0cnkgLi4uIDstKS4NCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+IEl0IG1pZ2h0IGhlbHAgaWYgdGhpcyBoYWQgc29tZXdoYXQgbW9yZSBv ZiBhIGZsYXZvciBvZiBkb2N1bWVudGluZyB0aGUNCj4gPj4+Pj4+PiByZXZpZXcgY3JpdGVyaWEg dGhhdCBhcmUgY3VycmVudGx5IHVzZWQsIGFsdGhvdWdoIEkgZG8gdGhpbmsgYXQgbGVhc3QNCj4g Pj4+Pj4+PiBvbmUgIlNIT1VMRCBOT1QiIGlzIGxpa2VseSB0byB0dXJuIHVwIGluIHRoZSBmaW5h bCB0ZXh0Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSSdkIGNlcnRhaW5seSBsaWtlIHRvIHNlZSBz b21lIFNlY3VyaXR5IEFyZWEgaW5wdXQgKGFuZCBwcm9iYWJseSBhbHNvDQo+ID4+Pj4+Pj4gT1BT LCBhcyBmaXJld2FsbHMgcGxheSBhIHByb21pbmVudCByb2xlKSwgYnV0IHNwZWFraW5nIGZvciBt eXNlbGYsDQo+ID4+Pj4+Pj4gSSB0aGluayBvZmZlcmluZyBzZWN1cml0eSBhZHZpY2UgaXMgd2Vs bCB3aXRoaW4gcmVhc29uIGhlcmUgLi4uDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBHb2luZyBiYWNr IHRvIHRoZSB0aHJlZSBzY2VuYXJpb3MgYXQgdGhlIHN0YXJ0IG9mIHRoaXMgdGhyZWFkLCB0aGUN Cj4gPj4+Pj4+PiBwcm9wb3NhbHMgZm9yIHRoZSBmaXJzdCB0d28gc2VlbSByZWFzb25hYmxlIChJ TUhPKToNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICAtIGdpdmVuIGEgY3VycmVudCBub24tc2Vj dXJlIGFzc2lnbm1lbnQsIHdoYXQgaWYgYQ0KPiA+Pj4+Pj4+ICAgICB1c2VyIHJlcXVlc3RzIGEg KG5ldykgc2Vjb25kIHBvcnQgZm9yIHNlY3VyZSBhY2Nlc3M/DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ PiAgICAgICAgICAgICB0aGlzIGlzIGZpbmUsIGlmIG5vdCBhIGdvb2QgaWRlYTsNCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+ICAgICAtIGdpdmVuIGEgY3VycmVudCBzZWN1cmUgYXNzaWdubWVudCwgd2hh dA0KPiA+Pj4+Pj4+ICAgICBpZiBhIHVzZXIgcmVxdWVzdHMgYSAobmV3KSBzZWNvbmQgcG9ydCBm b3IgaW5zZWN1cmUgYWNjZXNzPw0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgICAgICAgICAgaXQg c2VlbXMgbGlrZSBhIFNIT1VMRCBOT1QgcmVjb21tZW5kYXRpb24NCj4gPj4+Pj4+PiAgICAgICAg ICAgICBpcyBhcHByb3ByaWF0ZTsgdGhpcyBjcmVhdGVzIG5ldyB2dWxuZXJhYmlsaXR5Ow0KPiA+ Pj4+Pj4+DQo+ID4+Pj4+Pj4gSSBwcmVzdW1lIHRoYXQgdGhlIGxhdHRlciByZWNvbW1lbmRhdGlv biBlbnZpc2lvbnMgYSBzY2VuYXJpbyB3aGVyZQ0KPiA+Pj4+Pj4+IHRoZSBzZWN1cmUgcG9ydCBo YXMgYmVlbiBkZXBsb3llZCBhbmQgdXNlZCBmb3IgYSBzaWduaWZpY2FudCBwZXJpb2QNCj4gPj4+ Pj4+PiBvZiB0aW1lLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFllcy4NCj4gPj4+Pj4+DQo+ID4+Pj4+ Pj4gSW4gdGhhdCBjYXNlLCBJIHRoaW5rIGEgIlNIT1VMRCBOT1QiIGlzIG9rLCBhcyBJJ2Qgd2Fu dCB0bw0KPiA+Pj4+Pj4+IHNlZSBzb21lIGhlYXZ5LWR1dHkgc2VyaW91cyBqdXN0aWZpY2F0aW9u IGZvciBhZGRpbmcgdGhlIGluc2VjdXJlDQo+ID4+Pj4+Pj4gcG9ydC4gIFRoZSBkcmFmdCBzaG91 bGQgc3RhdGUgdGhhdCBwcmVzdW1wdGlvbiwgdGhvdWdoLCBhcyBkZXBsb3ltZW50DQo+ID4+Pj4+ Pj4gZGlmZmljdWx0aWVzL2V4cGVyaWVuY2UgbWlnaHQgcmVzdWx0IGluIHNvbWV0aGluZyBjbG9z ZXIgdG8gdGhlIHRoaXJkDQo+ID4+Pj4+Pj4gc2NlbmFyaW8uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g UmlnaHQgLSB0aGF0J3MgdGhlIHBvaW50IG9mIHRoZSBTSE9VTEQgTk9ULiBJdCdzIG5vdCBhIE1V U1QgTk9ULiBJdA0KPiBqdXN0DQo+ID4+Pj4+PiBuZWVkcyB2ZXJ5IGhlYXZ5IGp1c3RpZmljYXRp b24uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICAtIHNob3VsZCBhIHVzZXIgcmVxdWVzdCB0d28g cG9ydHMgZm9yIGEgbmV3IHNlcnZpY2UsIG9uZQ0KPiA+Pj4+Pj4+ICAgICBzZWN1cmUgYW5kIG9u ZSBpbnNlY3VyZT8NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEkgc3VzcGVjdCB0aGF0IHRoZSBhZHZp Y2UgZm9yIHRoZSB0aGlzIG9uZSBpcyBsaWtlbHkgdG8gYmUgYSBsb25nDQo+ID4+Pj4+Pj4gdmVy c2lvbiBvZiAiaXQgZGVwZW5kcyIgaW4gcHJhY3RpY2UuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAg ICAgICAgICAgICBJTU8sIHRoZSBzZWN1cmUgcG9ydCBpcyBlYXN5LCBpZiBvdGhlcndpc2UNCj4g Pj4+Pj4+PiAgICAgICAgICAgICB3YXJyYW50ZWQgKG5vdCBhIGR1cGxpY2F0ZSBvZiBleGlzdGlu ZyBzZXJ2aWNlLCBlLmcuKSwNCj4gPj4+Pj4+PiAgICAgICAgICAgICBidXQgdGhlIGluc2VjdXJl IG9uZSBzaW1pbGFybHkgY3JlYXRlcyBhIG5ldw0KPiA+Pj4+Pj4+ICAgICAgICAgICAgIHZ1bG5l cmFiaWxpdHksIGFuZCBhZ2FpbiBJIHdvdWxkIHNheSBTSE9VTEQgTk9UDQo+ID4+Pj4+Pj4gICAg ICAgICAgICAgcmVxdWVzdCBhIG5ldyBpbnNlY3VyZSBwb3J0DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ PiBJIGFncmVlIHdpdGggdGhlIHNlY3VyZSBwb3J0IGJlaW5nIGZpbmUsIGJ1dCBJJ20gbm90IGNv bWZvcnRhYmxlDQo+ID4+Pj4+Pj4gd2l0aCBhIGJsYW5rZXQgIlNIT1VMRCBOT1QiIHJlY29tbWVu ZGF0aW9uIGZvciB0aGUgaW5zZWN1cmUgcG9ydC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEkgdGhp bmsgdGhpcyBkZXBlbmRzIG9uIHRoZSBkZXRhaWxzIG9mIHRoZSBwcm90b2NvbC4gIEknZCBkZWZp bml0ZWx5DQo+ID4+Pj4+Pj4gc2V0IGFuIGV4cGVjdGF0aW9uIHRoYXQgc29saWQganVzdGlmaWNh dGlvbiBmb3IgdGhlIG5ldyBpbnNlY3VyZQ0KPiA+Pj4+Pj4+IHBvcnQgd2lsbCBiZSBleHBlY3Rl ZCwgd2l0aCB0aGUgYXBwbGljYW50IGJlaW5nIHJlc3BvbnNpYmxlIGZvcg0KPiA+Pj4+Pj4+IGp1 c3RpZnlpbmcgd2h5IHVzZSBvZiBzZWN1cml0eSBpcyBub3QgbWFuZGF0b3J5IGZvciB0aGUgcHJv dG9jb2wuDQo+ID4+Pj4+Pj4gSWYgdGhhdCBqdXN0aWZpY2F0aW9uIG1ha2VzIHRoZSBjYXNlLCB0 aGVuIHRoZSBmaXJld2FsbCBjb250cm9sDQo+ID4+Pj4+Pj4gcmF0aW9uYWxlIChiZWxvdykgZGVm aW5pdGVseSBzb3VuZHMgcmVhc29uYWJsZSwgSU1ITy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBXaHkg aXNuJ3QgdGhhdCBhIFNIT1VMRCBOT1Q/IENlcnRhaW5seSBhIGJpdCBtb3JlIHRleHQgaXMgaW4g b3JkZXIsIGJ1dA0KPiA+Pj4+Pj4gaXQgc2VlbXMgbGlrZSB3ZSdyZSBpbiBhZ3JlZW1lbnQgLSBk ZWVwIGp1c3RpZmljYXRpb24gaXMgbmVlZGVkLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiBJIGp1c3Qg ZG9uJ3QgdGhpbmsgdGhlIGxldmVsIG9mIHJlcXVpcmVkIGp1c3RpZmljYXRpb24gaXMgZ29pbmcN Cj4gPj4+Pj4+PiB0byByaXNlIHRvIHRoYXQgc3VmZmljaWVudCB0byBvdmVycmlkZSBhICJTSE9V TEQgTk9UIiBmb3IgZXZlcnkNCj4gPj4+Pj4+PiBzaW5nbGUgcHJvdG9jb2wgZGVzaWduIHRoYXQg d2UgaGF2ZSB5ZXQgdG8gZW52aXNpb24uICBJIHdpc2ggbXkNCj4gPj4+Pj4+PiBmb3Jlc2lnaHQg d2FzIDIwLzIwIDotKS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBGV0lXLCB0aGVyZSBhcmVuJ3QgYSBs b3Qgb2YgcHJvdG9jb2xzIHRoYXQgYXNrIGZvciBzZWN1cmUgYW5kIGluc2VjdXJlDQo+ID4+Pj4+ PiBhdCB0aGUgc2FtZSB0aW1lLiBUaG9zZSBjb21lIG1vc3RseSAtIGluY3JlZGlibHkgLSBmcm9t IElFVEYgV0dzLCB3aGVyZQ0KPiA+Pj4+Pj4gdGhleSBhcHBlYXIgdG8gYmUgKElNTyBibGluZGx5 KSBmb2xsb3dpbmcgcGFzdCBwcmFjdGljZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBNeSBrZXkgY29u Y2VybiBpcyAid2h5IGlzIHRoZSBpbnNlY3VyZSBwb3J0IG5lZWRlZCI/IE1vc3Qgb2YgdGhlIHRp bWUNCj4gPj4+Pj4+IHRoZSBqdXN0aWZpY2F0aW9uIGlzIHB1cmUgcGVyZm9ybWFuY2UgLSBydW5u aW5nIHNlY3VyaXR5IG9uIHRoZSBzZXJ2aWNlDQo+ID4+Pj4+PiB3aWxsIG1ha2UgaXQgdG9vIHNs b3csIGFuZCB0aGlzIHdpbGwgYWxsb3cgZmFzdGVyIHBlcmZvcm1hbmNlIGluc2lkZSBhbg0KPiA+ Pj4+Pj4gZW50ZXJwcmlzZS4gVGhhdCBtaWdodCBiZSB0cnVlLCBidXQgaXQgYWxzbyBuZWVkcyB0 byBiZSBqdXN0aWZpZWQgaW4NCj4gPj4+Pj4+IHRlcm1zIG9mIHRoZSBzZXJ2aWNlIGJlaW5nIHBy b3ZpZGVkIC0gdGhhdCB0aGlzIGlzIGEgaGlnaC10aHJvdWdocHV0IG9yDQo+ID4+Pj4+PiBoaWdo LXRyYW5zYWN0aW9uIGZyZXF1ZW5jeSBzeXN0ZW0gdGhhdCBuZWVkcyBoaWdoIHBlcmZvcm1hbmNl IGluc2lkZQ0KPiA+Pj4+Pj4gcHJvdGVjdGVkIGVudGVycHJpc2VzLg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+PiAgICAgLSBHSVZFTiBhIHJlcXVlc3QgZm9yIGFuIGluc2VjdXJlIGFuZCBzZWN1cmUgcG9y dCwgd2hhdA0KPiA+Pj4+Pj4+ICAgICBhcmUgYXBwcm9wcmlhdGUganVzdGlmaWNhdGlvbnM/DQo+ ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAgICAgICAgICAgICBJTU8sIHNlcGFyYXRlIGZpcmV3YWxsIGNv bnRyb2wgaXMgYSBzdWZmaWNpZW50DQo+ID4+Pj4+Pj4gICAgICAgICAgICAgcmVhc29uLg0KPiA+ Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgICAgICAgICAgaG93ZXZlciwgcGVyZm9ybWFuY2Ugc2hvdWxk IG5vdCBiZSAtIGkuZS4sIGlmDQo+ID4+Pj4+Pj4gICAgICAgICAgICAgYm90aCBwb3J0cyB3aWxs IHR5cGljYWxseSBoYXZlIHRoZSBzYW1lIGZpcmV3YWxsDQo+ID4+Pj4+Pj4gICAgICAgICAgICAg Y29uZmlndXJhdGlvbiwgdGhlbiBvbmx5IG9uZSBwb3J0IGlzIG5lZWRlZA0KPiA+Pj4+Pj4+ICAg ICAgICAgICAgIGFuZCBzZWN1cml0eSBzaG91bGQgYmUgbmVnb3RpYXRlZCBhcyBwcmVzZW50L2Fi c2VudA0KPiA+Pj4+Pj4+ICAgICAgICAgICAgIGluLWJhbmQuIFRoZSBwZXJmb3JtYW5jZSBpbXBh Y3Qgb2YgdGhhdCBuZWdvdGlhdGlvbg0KPiA+Pj4+Pj4+ICAgICAgICAgICAgIChJTU8pIHNob3Vs ZCBub3QgZmFjdG9yIGludG8gd2hldGhlciBhbiBhZGRpdGlvbmFsDQo+ID4+Pj4+Pj4gICAgICAg ICAgICAgcG9ydCBzaG91bGQgYmUgYXNzaWduZWQuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBJIHRo aW5rIHRoZSB0ZXh0IG9uIHBlcmZvcm1hbmNlIHNob3VsZCBiZSBleHBsaWNpdCB0aGF0IHRoZQ0K PiA+Pj4+Pj4+IHBlcmZvcm1hbmNlIGNvbmNlcm4gaXMgbmVnb3RpYXRpb24gcm91bmQgdHJpcCBh dm9pZGFuY2UuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlcmUgYXJlIGEgZmV3IGRpZmZlcmVudCBw ZXJmb3JtYW5jZSBpc3N1ZXM6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICAtIHJvdW5kLXRyaXAg ZGVsYXlzDQo+ID4+Pj4+PiAgICAgIC0gdGhyb3VnaHB1dCBvdmVyaGVhZCAocGVyIGJ5dGUpDQo+ ID4+Pj4+PiAgICAgIC0gbWVzc2FnZSBvdmVyaGVhZCAocGVyIG1lc3NhZ2UpDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gSm9lDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IDwvV0cgY2hhaXIgaGF0IE9GRj4NCj4g Pj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoYW5rcywNCj4gPj4+Pj4+PiAtLURhdmlkDQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+Pj4gRnJvbTog Sm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4gPj4+Pj4+Pj4gU2VudDogVHVlc2Rh eSwgTWF5IDI3LCAyMDE0IDY6MDMgUE0NCj4gPj4+Pj4+Pj4gVG86IFBhdWwgSG9mZm1hbg0KPiA+ Pj4+Pj4+PiBDYzogQmxhY2ssIERhdmlkOyB0c3Z3Z0BpZXRmLm9yZw0KPiA+Pj4+Pj4+PiBTdWJq ZWN0OiBSZTogW3RzdndnXSBhZGRpdGlvbmFsIHBvcnRzIGZvciBzZWN1cml0eSAtIFJlOiBXR0xD IGZvcg0KPiA+PiBkcmFmdC0NCj4gPj4+Pj4+IGlldGYtDQo+ID4+Pj4+Pj4+IHRzdndnLXBvcnQt dXNlLTA0ICh0byBlbmQgNnRoIEp1bmUpDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+IE9uIDUvMjcvMjAxNCAyOjQ5IFBNLCBQYXVsIEhvZmZtYW4gd3JvdGU6 DQo+ID4+Pj4+Pj4+PiBJcyB0aGlzIG5ldyBhZHZpY2UgYmFzZWQgb24gYW55IGFjdHVhbCBldmlk ZW5jZSBvciBldmVuIGEgc2VjdXJpdHkNCj4gPj4+Pj4+IGFuYWx5c2lzPw0KPiA+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+PiBJdCdzIGJhc2VkIG9uIDggeWVhcnMgb2YgcnVubmluZyB0aGUgcmV2aWV3IHRl YW0gYW5kIGRpc2N1c3Npb25zDQo+IHdpdGhpbg0KPiA+Pj4+Pj4+PiB0aGF0IHRlYW0uIEl0J3Mg YmFzZWQgb24gdGhlIGFuYWx5c2lzIHByb3ZpZGVkLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBJ ZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGUgYW5hbHlzaXMsIHlvdSBzaG91bGQgcHJlc2VudCBhDQo+ ID4+IGNvdW50ZXJhcmd1bWVudC4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEZ1cnRoZXIsIGEg c3RhdGVtZW50IG9mICJTSE9VTEQgTk9UIHJlcXVlc3QiIHNvdW5kcyBhIGhlbGwgb2YgYSBsb3QN Cj4gPj4gbW9yZQ0KPiA+Pj4+Pj4+Pj4gbGlrZSBhIGRlbWFuZCB0aGFuIGFkdmljZS4NCj4gPj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4gV2hhdCBleGFjdGx5IGNhbiB3ZSAqZGVtYW5kKiBvZiBhIHVzZXIg bWFraW5nIGFuIGFwcGxpY2F0aW9uIG90aGVyDQo+IHRoYXQNCj4gPj4+Pj4+Pj4gdG8gcHJvdmlk ZSBhZHZpY2U/IEl0J3Mgbm90IGFkdmljZSB0byBJQU5BIG9yIHRoZSBwb3J0cyB0ZWFtIGluIGhv dw0KPiB0bw0KPiA+Pj4+Pj4+PiBtYWtlIGEgZGVjaXNpb24uDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+PiBUaGlzIGdldHMgdG8gdGhlIGNydXggb2YgbXkgY29uY2VybiBvZiB0aGUNCj4gPj4+Pj4+ Pj4+IGRvY3VtZW50OiBpdCBmZWVsIGxpa2UgdGhlIGFkdmljZSBpcyBtZWFudCB0byBjb21lIGZy b20gb24gaGlnaA0KPiA+PiAobmFtZWx5LA0KPiA+Pj4+Pj4+Pj4gc29tZW9uZSB3aG8gY2FuIGJs b2NrIElBTkEgcmVxdWVzdHMpLCBub3QgZnJpZW5kbHkgYWR2aWNlIGZyb20gb25lDQo+ID4+Pj4+ Pj4+PiBkZXZlbG9wZXIgdG8gYW5vdGhlci4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gQ2FuIHlv dSBwcm92aWRlIGEgcmF0aW9uYWxlIGZvciB0aGF0IGNsYWltIG90aGVyIHRoYW4gImJlY2F1c2Ug Sm9lDQo+ID4+IFRvdWNoDQo+ID4+Pj4+Pj4+IHdyb3RlIGl0Ij8NCj4gPj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+IFdlIHdlbnQgdGhyb3VnaCB0aGlzIGluIHRoZSBkaXNjdXNzaW9uIGEgZmV3IHllYXJz DQo+ID4+Pj4+Pj4+PiBhZ28sIGFuZCBpdCBzZWVtZWQgdGhlbiB0aGF0IFRTVldHIGRpZG4ndCBh Z3JlZSB0aGF0IHN1Y2ggaGVhdnktDQo+IGhhbmRlZA0KPiA+Pj4+Pj4+Pj4gImFkdmljZSIsIHBh cnRpY3VsYXJseSB3aXRob3V0IHNwZWNpZmljIGp1c3RpZmljYXRpb24sIHdhcyB0aGUgd2F5DQo+ IHRvDQo+ID4+Pj4gZ28uDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFRTVldHIGFncmVlZCB0aGF0 IGxpbWl0aW5nIElBTkEgd2FzIG5vdCBhcHByb3ByaWF0ZTsgdGhpcyBkb2N1bWVudA0KPiA+Pj4+ Pj4+PiBkb2Vzbid0IGxpbWl0IElBTkEuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEFuZCBzcGVj aWZpYyBqdXN0aWZpY2F0aW9uIGlzIHByb3ZpZGVkIGluIHRoZSBkaXNjdXNzaW9uIEkgZ2F2ZS4N Cj4gQWdhaW4sDQo+ID4+Pj4+Pj4+IGlmIHlvdSBkaXNhZ3JlZSB3aXRoIHRoYXQgZGlzY3Vzc2lv biwgcGxlYXNlIGV4cGxhaW4uDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEUuZy4sIGRvIHlvdSBh Y3R1YWxseSB0aGluayBpdCdzIGdvb2Qgc2VjdXJpdHkgcHJhY3RpY2UgdG8gY3JlYXRlDQo+IG5l dywNCj4gPj4+Pj4+Pj4gaW5zZWN1cmUgc2VydmljZXM/IElmIHNvLCBvbiB3aGF0IGJhc2lzIG9m IGdvb2Qgc2VjdXJpdHkgcHJhY3RpY2U/DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEpvZQ0KPiA+ Pj4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pg0KPiA+DQoNCg== From nobody Thu May 29 12:47:45 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAE11A0549 for ; Thu, 29 May 2014 12:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYigABsxGv_M for ; Thu, 29 May 2014 12:47:41 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1768F1A04B1 for ; Thu, 29 May 2014 12:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5625; q=dns/txt; s=iport; t=1401392857; x=1402602457; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=v39J5fK11MfiNpfnjffgIC6AqtNvX2wejacXZd8jHeI=; b=coVjWz39zSlGC2Ffj2+BQPZKJrgu9VDpwMIfwLiXBzM6lGEqjOMa2I8r uqWZenLRltyQ+9fnaAxRMN/88cEMUXzBtgO0lBHjbWwF/VZOjJPutWfa3 Nd4NkHdXkoG8ZuGU5TX+ez+Ne7h4ZP/qVNT1Iet6cEmpZI/HfG3ALMmnx 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAAOOh1OtJssW/2dsb2JhbABZDoNLg0O/SwGBJHSCJQEBAQMBI1URCxIIAgUWCwICCQMCAQIBNw4GAQwIAQEQiCYIslOlGxeBKo0vgnWBSwEDlXOEApMpgnhCOw X-IronPort-AV: E=Sophos;i="4.98,935,1392163200"; d="scan'208";a="62833279" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 29 May 2014 19:47:35 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.215.7]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4TJlY5r011868; Thu, 29 May 2014 19:47:35 GMT Message-ID: <53878ED6.6040904@cisco.com> Date: Thu, 29 May 2014 21:47:34 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Touch , gorry@erg.abdn.ac.uk, tsvwg@ietf.org References: <537D9AC4.80602@erg.abdn.ac.uk> <5385833C.20505@cisco.com> <5386112D.9050207@isi.edu> In-Reply-To: <5386112D.9050207@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/Q4TdHRsEiPNMfuezvU-EmzyBJQA Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 19:47:43 -0000 Hi Joe, On 5/28/14, 6:39 PM, Joe Touch wrote: >> Developers SHOULD request ports to differentiate their services. > > Not necessarily. A service that *can* operate effectively on dynamic > ports should do so. Fair enough, but my point is that the tone of the document is wrong. Yes, these are scarce resources, but they are resources that should be made use of in appropriate circumstances. > >> The >> question is how many ports do they need to do that. Therefore, the >> analogy used to RFC1263 is inappropriate. > > I disagree. Assigned ports have a real cost in system configuration > complexity as well as consuming a global community resource, which is > why the "similar" advice is appropriate here IMO. Yes, they consume a global resource. Typically, however, it's the other way around with regard to system configuration complexity, right? We get requests all the time in order to avoid configuration. > >> In Section 7.1: >> >> >>> New services should support security or should consider >>> optional security. A new service should not need a port >>> for an >>> insecure version; at best, this would be a performance issue >>> (see the first bullet), and at worst this presents a new >>> vulnerability. >> >> We should be considering a stronger statement than this with normative >> language that is in line with IETF consensus as documented in RFC 7258. > > Security includes a breadth of issues including resistance to > interference, masquerading, content observation, and meta-information > tracking. > > For the purposes of this document, we should be clear that "security" > typically refers to the first 3, but not the last. In fact, using > assigned ports is the antithesis of avoiding monitoring - you're > advertising to the world the service type. Yes. > > Regardless, IMO it's inappropriate to create RFC 2119-level > requirements justified by a BCP that has *NO* RFC 2119 recommendations. > >> But we have to be careful to not chase off applicants such that they >> squat or inappropriately warp their architecture. > > This has always occurred and will always occur. Although I don't want > to chase them off, appeasing them is like "adjusting laws for the > benefit of the lawless". This is a tonal issue. We are here to provide a service to those who need it. The document contains a checklist that makes clear that if you don't answer each of those questions correctly, no port for you. There are times when it is entirely appropriate to request a new port. It's those people I don't want scared off. > >> Therefore, I suggest >> phrasing that is similar to what is found in RFC 7258. Let me suggest >> two questions to be asked. The first comes right out of the RFC: >> >>> Is pervasive monitoring relevant to this work and if so, how has it >>> been considered? > > I don't intend to do this for every RFC until a "Pervasive > montitoring" section is required for submission. Otherwise, we will > end up derailing *every* RFC with *every* BCP that's *ever* been issued. But in considering this draft WE have to consider pervasive monitoring, and it is fair game to ask the question whether or not we should up the requirement for at least a justification as to why they're not encrypting. But maybe that's a 6335bis? > >> Reviewers can then use their judgment as to the validity of the answers. >> >> Going to the next paragraph: >> >>> >>> o Ports are not for indicating different service versions. >>> Version differentiation should be handled in-band, e.g., >>> using >>> a version number at the beginning of a connection or >>> transaction. This may not be possible with legacy >>> assignments, >>> but all new assignments should incorporate support for >>> version >>> indication. >> >> This point requires expansion. We are currently seeing a number of >> requests around HTTP in particular in which there is absolutely no >> difference between protocol being run on port 80 and what is being >> requested. The reason for the request, however, is that the applicant >> is offering some sort of server management function. The above guidance >> says that hosts should multiplex this function on port 80. As a matter >> of architecture, we need to decide what the real guidance should be in >> this case. Should it be require that web servers support such >> multiplexing? We certainly have the means through .well-known, for >> instance. > > In 1999 HTTP 1.1 added the Host header field, and TLS was extended to > support this in its SNI for this very purpose. > > The issue with HTTP is that it both a presentation layer and an > application layer at the same time. When used as a presentation layer, > other protocols can be designed on top and that easily warrants a new > port. When used as an application layer, the "no duplicate" rule applies. > > I.e., server management by custom protocols warrants a new port. > Servers managed by unmodified web clients should use port 80 or 443. > > Otherwise, every web server instance would warrant a new port - and > that would easily overwhelm the number of available ports. This is we > should not assign multiple ports to the same service (even though this > was done in the past, e.g., 8080). I think the issue here really is that one cannot assume the ability to multiplex the service on port 80 or 443. One cannot require the use of .well-known on port 80 or 443. Eliot From nobody Thu May 29 13:45:01 2014 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CC01A00EA for ; Thu, 29 May 2014 13:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wai6iz3s-s6p for ; Thu, 29 May 2014 13:44:56 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6B31A03EA for ; Thu, 29 May 2014 13:44:56 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4TKiXN4000510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 May 2014 13:44:33 -0700 (PDT) Message-ID: <53879C31.1010906@isi.edu> Date: Thu, 29 May 2014 13:44:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Eliot Lear , gorry@erg.abdn.ac.uk, tsvwg@ietf.org References: <537D9AC4.80602@erg.abdn.ac.uk> <5385833C.20505@cisco.com> <5386112D.9050207@isi.edu> <53878ED6.6040904@cisco.com> In-Reply-To: <53878ED6.6040904@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/SLepvD6nZq5Y1vHBYpR855TAc68 Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:44:58 -0000 On 5/29/2014 12:47 PM, Eliot Lear wrote: > Hi Joe, > > On 5/28/14, 6:39 PM, Joe Touch wrote: > >>> Developers SHOULD request ports to differentiate their services. >> >> Not necessarily. A service that *can* operate effectively on dynamic >> ports should do so. > > Fair enough, but my point is that the tone of the document is wrong. > Yes, these are scarce resources, but they are resources that should be > made use of in appropriate circumstances. Point taken. I'll revise, both with the details of the current use and tracking, as well as the general principle of conservation but not at the expense of obfuscation. >>> The >>> question is how many ports do they need to do that. Therefore, the >>> analogy used to RFC1263 is inappropriate. >> >> I disagree. Assigned ports have a real cost in system configuration >> complexity as well as consuming a global community resource, which is >> why the "similar" advice is appropriate here IMO. > > Yes, they consume a global resource. Typically, however, it's the other > way around with regard to system configuration complexity, right? We > get requests all the time in order to avoid configuration. Config complexity is decreased by separating independent services on separate ports, but increased by factoring a single service on multiple ports. E.g., it's more complex to configure and debug a system that relies on multiple ports being opened on a firewall. Again, good points to raise in the doc. >>> In Section 7.1: >>> >>> >>>> New services should support security or should consider >>>> optional security. A new service should not need a port >>>> for an >>>> insecure version; at best, this would be a performance issue >>>> (see the first bullet), and at worst this presents a new >>>> vulnerability. >>> >>> We should be considering a stronger statement than this with normative >>> language that is in line with IETF consensus as documented in RFC 7258. >> >> Security includes a breadth of issues including resistance to >> interference, masquerading, content observation, and meta-information >> tracking. >> >> For the purposes of this document, we should be clear that "security" >> typically refers to the first 3, but not the last. In fact, using >> assigned ports is the antithesis of avoiding monitoring - you're >> advertising to the world the service type. > > Yes. >> >> Regardless, IMO it's inappropriate to create RFC 2119-level >> requirements justified by a BCP that has *NO* RFC 2119 recommendations. >> >>> But we have to be careful to not chase off applicants such that they >>> squat or inappropriately warp their architecture. >> >> This has always occurred and will always occur. Although I don't want >> to chase them off, appeasing them is like "adjusting laws for the >> benefit of the lawless". > > This is a tonal issue. We are here to provide a service to those who > need it. The document contains a checklist that makes clear that if you > don't answer each of those questions correctly, no port for you. There > are times when it is entirely appropriate to request a new port. It's > those people I don't want scared off. Good point - I'll check for that tone throughout, and throw in a few encouraging words, esp. in the abstract and intro. >>> Therefore, I suggest >>> phrasing that is similar to what is found in RFC 7258. Let me suggest >>> two questions to be asked. The first comes right out of the RFC: >>> >>>> Is pervasive monitoring relevant to this work and if so, how has it >>>> been considered? >> >> I don't intend to do this for every RFC until a "Pervasive >> montitoring" section is required for submission. Otherwise, we will >> end up derailing *every* RFC with *every* BCP that's *ever* been issued. > > But in considering this draft WE have to consider pervasive monitoring, we don't *have* to... as I said, this doc isn't aimed at increasing or decreasing monitoring per se... > and it is fair game to ask the question whether or not we should up the > requirement for at least a justification as to why they're not > encrypting. I was confused by your question; I thought you were talking about this doc only, but I think you're saying we should ask those questions to the applicant, right? We already basically do ask what they're doing about security indirectly - we should be more direct about that, and that's consistent with the need for all RFCs to have a Security Considerations section. However, I don't think that's independently true for monitoring; if it's a security issue, they can address it there, and if not, we should wait until RFCs are asked to have a separate monitoring section. > But maybe that's a 6335bis? It doesn't have to be; 6553 talks about the information needed for an application already. The specific questions we (the Expert Review team) ask on the application are really just to facilitate our review, and fall under "Description" in 6335. >>> Reviewers can then use their judgment as to the validity of the answers. >>> >>> Going to the next paragraph: >>> >>>> >>>> o Ports are not for indicating different service versions. >>>> Version differentiation should be handled in-band, e.g., >>>> using >>>> a version number at the beginning of a connection or >>>> transaction. This may not be possible with legacy >>>> assignments, >>>> but all new assignments should incorporate support for >>>> version >>>> indication. >>> >>> This point requires expansion. We are currently seeing a number of >>> requests around HTTP in particular in which there is absolutely no >>> difference between protocol being run on port 80 and what is being >>> requested. The reason for the request, however, is that the applicant >>> is offering some sort of server management function. The above guidance >>> says that hosts should multiplex this function on port 80. As a matter >>> of architecture, we need to decide what the real guidance should be in >>> this case. Should it be require that web servers support such >>> multiplexing? We certainly have the means through .well-known, for >>> instance. >> >> In 1999 HTTP 1.1 added the Host header field, and TLS was extended to >> support this in its SNI for this very purpose. >> >> The issue with HTTP is that it both a presentation layer and an >> application layer at the same time. When used as a presentation layer, >> other protocols can be designed on top and that easily warrants a new >> port. When used as an application layer, the "no duplicate" rule applies. >> >> I.e., server management by custom protocols warrants a new port. >> Servers managed by unmodified web clients should use port 80 or 443. >> >> Otherwise, every web server instance would warrant a new port - and >> that would easily overwhelm the number of available ports. This is we >> should not assign multiple ports to the same service (even though this >> was done in the past, e.g., 8080). > > I think the issue here really is that one cannot assume the ability to > multiplex the service on port 80 or 443. They can - by hostname. (Host field in HTTP). > One cannot require the use of > .well-known on port 80 or 443. Agreed - those are for other things beyond multipexing, though. Joe