From nobody Wed Jul 1 09:26:23 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89F31A914C for ; Wed, 1 Jul 2015 09:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 nDewa0R7lmoa for ; Wed, 1 Jul 2015 09:26:19 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F47A1A9149 for ; Wed, 1 Jul 2015 09:26:18 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZAKq1-0000Pq-7q for spud@ietf.org; Wed, 01 Jul 2015 18:26:17 +0200 Received: from 62-193-53-219.as16211.net ([62.193.53.219] helo=[192.168.101.158]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1ZAKq0-0000w7-9b for spud@ietf.org; Wed, 01 Jul 2015 18:26:17 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jul 2015 18:26:16 +0200 References: <612B7EC6-8AF9-4FDB-879F-735213ACAB1A@ifi.uio.no> To: spud@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 3 sum rcpts/h 10 sum msgs/h 7 total rcpts 30643 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5F3DBB5886347145F3FFF25D7214DDAE69121A74 X-UiO-SPAM-Test: remote_host: 62.193.53.219 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 37 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Spud] Fwd: [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 16:26:22 -0000 Hi, See below - this is remotely related to SPUD (really remotely, in that = it addresses a human, but the human in control of a device of concern to = SPUD). We're collecting opinions on this - please let us have them :-) Michael > Begin forwarded message: >=20 > Resent-From: > From: Michael Welzl > Date: 30. juni 2015 kl. 00.35.39 CEST > To: Int-area@ietf.org > Subject: [Int-area] Fwd: New Version Notification for = draft-welzl-icmp-text-middleboxes-00.txt >=20 > Dear all, >=20 > We just posted the draft below. Not knowing which other group would = fit, we're sending it here. We're really transport people and at least I = am newbie to this group... very curious to hear your thoughts: > - completely idiotic? > - exactly what the world has been waiting for? >=20 > ... I guess it can only be one of the two above :-) If the chairs = think that this makes sense to discuss in Prague, we'll be there, and = I'd be happy to do a supershort presentation, but let us first hear what = you think. It's a short and easy read, we promise that! :-) >=20 > Thanks! > Michael & Janjie >=20 >=20 >> Begin forwarded message: >>=20 >> Resent-From: >> From: >> To: Jianjie You , Michael Welzl = , Jianjie You , Michael Welzl = >> Subject: New Version Notification for = draft-welzl-icmp-text-middleboxes-00.txt >> Date: 30. juni 2015 kl. 00.24.23 CEST >>=20 >>=20 >> A new version of I-D, draft-welzl-icmp-text-middleboxes-00.txt >> has been successfully submitted by Michael Welzl and posted to the >> IETF repository. >>=20 >> Name: draft-welzl-icmp-text-middleboxes >> Revision: 00 >> Title: Text messaging to middlebox administrators using = ICMP >> Document date: 2015-06-30 >> Group: Individual Submission >> Pages: 6 >> URL: = https://www.ietf.org/internet-drafts/draft-welzl-icmp-text-middleboxes-00.= txt >> Status: = https://datatracker.ietf.org/doc/draft-welzl-icmp-text-middleboxes/ >> Htmlized: = https://tools.ietf.org/html/draft-welzl-icmp-text-middleboxes-00 >>=20 >>=20 >> Abstract: >> This document describes the use of an ICMP message to send text >> messages to on-path middleboxes from the endpoints. The text = message >> is sent towards a destination but meant to be read by administrators >> of middleboxes along the path to the destination. The goal is to >> improve the user's experience with simple middlebox cooperation. >>=20 >>=20 >>=20 >>=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 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Jul 1 09:55:39 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A221A92A9 for ; Wed, 1 Jul 2015 09:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lu5gwWwuC0d3 for ; Wed, 1 Jul 2015 09:55:35 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 99B0E1A885D for ; Wed, 1 Jul 2015 09:55:35 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 068231B00194; Wed, 1 Jul 2015 17:55:33 +0100 (BST) Received: from 62.193.53.219 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 1 Jul 2015 17:54:25 +0100 Message-ID: In-Reply-To: References: <612B7EC6-8AF9-4FDB-879F-735213ACAB1A@ifi.uio.no> Date: Wed, 1 Jul 2015 17:54:25 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] Fwd: [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 16:55:37 -0000 So, if there is no IP header in the payload, I have two questions: (1) How do you verify the ICMP packet came from something on-path. rather than being generated by a random, potentially malicious sender? Why would any host trust this? (2) No header no encaps info - hence no ports or originating address etc? - In other words not useful. (3) Obviously this will not traverse NATs or tunnels (always a problem for feed-backwards control messages), since these would not be able to determine the next endpoint. Gorry > Hi, > > See below - this is remotely related to SPUD (really remotely, in that it > addresses a human, but the human in control of a device of concern to > SPUD). > > We're collecting opinions on this - please let us have them :-) > > Michael > > > >> Begin forwarded message: >> >> Resent-From: >> From: Michael Welzl >> Date: 30. juni 2015 kl. 00.35.39 CEST >> To: Int-area@ietf.org >> Subject: [Int-area] Fwd: New Version Notification for >> draft-welzl-icmp-text-middleboxes-00.txt >> >> Dear all, >> >> We just posted the draft below. Not knowing which other group would fit, >> we're sending it here. We're really transport people and at least I am >> newbie to this group... very curious to hear your thoughts: >> - completely idiotic? >> - exactly what the world has been waiting for? >> >> ... I guess it can only be one of the two above :-) If the chairs >> think that this makes sense to discuss in Prague, we'll be there, and >> I'd be happy to do a supershort presentation, but let us first hear what >> you think. It's a short and easy read, we promise that! :-) >> >> Thanks! >> Michael & Janjie >> >> >>> Begin forwarded message: >>> >>> Resent-From: >>> From: >>> To: Jianjie You , Michael Welzl >>> , Jianjie You , Michael >>> Welzl >>> Subject: New Version Notification for >>> draft-welzl-icmp-text-middleboxes-00.txt >>> Date: 30. juni 2015 kl. 00.24.23 CEST >>> >>> >>> A new version of I-D, draft-welzl-icmp-text-middleboxes-00.txt >>> has been successfully submitted by Michael Welzl and posted to the >>> IETF repository. >>> >>> Name: draft-welzl-icmp-text-middleboxes >>> Revision: 00 >>> Title: Text messaging to middlebox administrators using ICMP >>> Document date: 2015-06-30 >>> Group: Individual Submission >>> Pages: 6 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-welzl-icmp-text-middleboxes-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-welzl-icmp-text-middleboxes/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-welzl-icmp-text-middleboxes-00 >>> >>> >>> Abstract: >>> This document describes the use of an ICMP message to send text >>> messages to on-path middleboxes from the endpoints. The text message >>> is sent towards a destination but meant to be read by administrators >>> of middleboxes along the path to the destination. The goal is to >>> improve the user's experience with simple middlebox cooperation. >>> >>> >>> >>> >>> >>> 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 >>> >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Wed Jul 1 10:08:19 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7261AC3DB for ; Wed, 1 Jul 2015 10:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 K1j2AHj7QIpa for ; Wed, 1 Jul 2015 10:08:16 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E241AC3F4 for ; Wed, 1 Jul 2015 10:07:53 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZALUF-00037t-IJ; Wed, 01 Jul 2015 19:07:51 +0200 Received: from 62-193-53-219.as16211.net ([62.193.53.219] helo=[192.168.101.158]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZALUE-0003m0-Lu; Wed, 01 Jul 2015 19:07:51 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 1 Jul 2015 19:07:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A563A0C-CCF5-4D97-935E-1509237BB357@ifi.uio.no> References: <612B7EC6-8AF9-4FDB-879F-735213ACAB1A@ifi.uio.no> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 8 sum msgs/h 5 total rcpts 30649 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 86AEEFE7E1E357B292947BB92D6D5E6EB5892F0B X-UiO-SPAM-Test: remote_host: 62.193.53.219 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 41 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 17:08:18 -0000 Answering all three issues in one go: It's intended to reach the first, maybe second hop. There you can either = verify where it came from by considering the physical interface, or = (more likely I think) you can "trust but verify" ;-) (since we're on = the SPUD list) Indeed these text messages are only meant as hints. Consider this use case in the draft: "This is Michael Welzl, sitting in office 4164 at IFI. I want to run videoconferencing software XY that I need for a project I'm in, but it doesn't seem to work. I think you blocked some UDP ports there. Not good, please fix and get back to me." =3D> this is a request to check for port usage of a videoconferencing = software. Depending on whether the box admin believes this software = should be supported or not, (s)he might accept that hint and check. (yes = it opens for interesting denial of service attacks: "port X is blocked!" = "no, actually, port Y!" "please check port Z now!" - haha... in which = case you might want to check against the source, based on your physical = network setup. Unless you see a sequence of contradicting messages, it might be worth a = check. Consider the other use case: "Hello, I like the WiFi that's being provided at this airport! But did you notice that there is almost no reception near the C gates in terminal 3?" No way for an attacker to find out if you got the message or if you care = about it. So, one solution is: read the messages with some delay, maybe = daily. If there is an indication of an attacker sending you back and = forth between A, B and C gates, don't believe it. In other words: it's just an unreliable & advisory text message, and - = as with road signs etc. - attacks can be counteracted by common sense = :-) Michael > On 1. jul. 2015, at 18.54, gorry@erg.abdn.ac.uk wrote: >=20 > So, if there is no IP header in the payload, I have two questions: >=20 > (1) How do you verify the ICMP packet came from something on-path. = rather > than being generated by a random, potentially malicious sender? Why = would > any host trust this? >=20 > (2) No header no encaps info - hence no ports or originating address = etc? > - In other words not useful. >=20 > (3) Obviously this will not traverse NATs or tunnels (always a problem = for > feed-backwards control messages), since these would not be able to > determine the next endpoint. >=20 > Gorry >=20 >> Hi, >>=20 >> See below - this is remotely related to SPUD (really remotely, in = that it >> addresses a human, but the human in control of a device of concern to >> SPUD). >>=20 >> We're collecting opinions on this - please let us have them :-) >>=20 >> Michael >>=20 >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> Resent-From: >>> From: Michael Welzl >>> Date: 30. juni 2015 kl. 00.35.39 CEST >>> To: Int-area@ietf.org >>> Subject: [Int-area] Fwd: New Version Notification for >>> draft-welzl-icmp-text-middleboxes-00.txt >>>=20 >>> Dear all, >>>=20 >>> We just posted the draft below. Not knowing which other group would = fit, >>> we're sending it here. We're really transport people and at least I = am >>> newbie to this group... very curious to hear your thoughts: >>> - completely idiotic? >>> - exactly what the world has been waiting for? >>>=20 >>> ... I guess it can only be one of the two above :-) If the = chairs >>> think that this makes sense to discuss in Prague, we'll be there, = and >>> I'd be happy to do a supershort presentation, but let us first hear = what >>> you think. It's a short and easy read, we promise that! :-) >>>=20 >>> Thanks! >>> Michael & Janjie >>>=20 >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> Resent-From: >>>> From: >>>> To: Jianjie You , Michael Welzl >>>> , Jianjie You , Michael >>>> Welzl >>>> Subject: New Version Notification for >>>> draft-welzl-icmp-text-middleboxes-00.txt >>>> Date: 30. juni 2015 kl. 00.24.23 CEST >>>>=20 >>>>=20 >>>> A new version of I-D, draft-welzl-icmp-text-middleboxes-00.txt >>>> has been successfully submitted by Michael Welzl and posted to the >>>> IETF repository. >>>>=20 >>>> Name: draft-welzl-icmp-text-middleboxes >>>> Revision: 00 >>>> Title: Text messaging to middlebox administrators using = ICMP >>>> Document date: 2015-06-30 >>>> Group: Individual Submission >>>> Pages: 6 >>>> URL: >>>> = https://www.ietf.org/internet-drafts/draft-welzl-icmp-text-middleboxes-00.= txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-welzl-icmp-text-middleboxes/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-welzl-icmp-text-middleboxes-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> This document describes the use of an ICMP message to send text >>>> messages to on-path middleboxes from the endpoints. The text = message >>>> is sent towards a destination but meant to be read by = administrators >>>> of middleboxes along the path to the destination. The goal is to >>>> improve the user's experience with simple middlebox cooperation. >>>>=20 >>>>=20 >>>>=20 >>>>=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 >>>> The IETF Secretariat >>>>=20 >>>=20 >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >>=20 >=20 From nobody Wed Jul 1 11:49:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506AC1B2A4E for ; Wed, 1 Jul 2015 11:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 QQ0JlbL_XS6j for ; Wed, 1 Jul 2015 11:49:23 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047371B2A46 for ; Wed, 1 Jul 2015 11:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7566; q=dns/txt; s=iport; t=1435776564; x=1436986164; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7JVHS0ya5UzSzqYoS9uqdT+21PVxuDb9x9lUWl1KjfY=; b=dbmK6mOte2TdcXMv1gCUbOHE5VuRc18XNOgoSbQP9a+bgsjdB+sPREdF ey9ku2fMa5+ZdbOcr6NfjyON4KGWVXdxBtzzPJp4Y7ifedrJieS3pcR6l sjs/urypxtlcH+CYeqJRJgQ79/QpiRdzWMQkU6RPOI79qhH5VY31xJMtT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DfAwD7NJRV/49dJa1bgxFUX70yCYFkDIJCgzQCgVY4FAEBAQEBAQGBCoQiAQEBAwEBAQE3NAkCDgILDgMDAQIBGQITFhEoCAYTG4gMCA3NDAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEi0aEUzMHBiECgm6BFAWMF2+HCoRdhGKCIoE6FDCDUIJrIowMg10mggcFHBWBXR4xAWUfgUMBAQE X-IronPort-AV: E=Sophos;i="5.15,387,1432598400"; d="scan'208";a="164644011" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 01 Jul 2015 18:49:23 +0000 Received: from [10.136.10.48] ([10.136.10.48]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t61InLqE016379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jul 2015 18:49:21 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <1A563A0C-CCF5-4D97-935E-1509237BB357@ifi.uio.no> Date: Wed, 1 Jul 2015 11:49:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33970202-61F0-4F9D-8B04-85B677AD381E@cisco.com> References: <612B7EC6-8AF9-4FDB-879F-735213ACAB1A@ifi.uio.no> <1A563A0C-CCF5-4D97-935E-1509237BB357@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: gorry@erg.abdn.ac.uk, spud@ietf.org Subject: Re: [Spud] [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 18:49:25 -0000 I don't see high likelyhood of someone typing (or speaking) a message = like that, pointing out a problem that might or might not get heard and = result in action. I could see an application or OS spitting out messages, though -- but = probably not in the format proposed. For example, it could be valuable = for a network administrator to know that their users want to use = SRTP-over-UDP, but UDP is being blocked forcing users to use = SRTP-over-TCP (which has a different -- sometimes worse -- user = experience than UDP). A browser might want to use QUIC-over-UDP, and it = could be useful to tell the network administrator that it was forced to = fallback to TCP. An OS might want to use native SCTP, native IPsec = (protocol 50), or native QUIC or native RTP (QUIC and RTP are not IANA = registered as protocols on top of IP, but by all rights they could / = should be). Another complaint message might be "Gosh, I need IPv6" or = "I need NAT64". If the "complaint" messages were to be = computer-parsable, I see more value in your proposal. I'm not too keen = on ICMP for this communication, though; perhaps HTTP POST to a = well-known FQDN, such as complaint.local, and some sort of structure to = what is posted could be more valuable. -d On 01-Jul-2015 10:07 am, Michael Welzl wrote: >=20 > Answering all three issues in one go: >=20 > It's intended to reach the first, maybe second hop. There you can = either verify where it came from by considering the physical interface, = or (more likely I think) you can "trust but verify" ;-) (since we're = on the SPUD list) >=20 > Indeed these text messages are only meant as hints. >=20 > Consider this use case in the draft: >=20 > "This is Michael Welzl, sitting in office 4164 at IFI. I want to run > videoconferencing software XY that I need for a project I'm in, but > it doesn't seem to work. I think you blocked some UDP ports there. > Not good, please fix and get back to me." >=20 > =3D> this is a request to check for port usage of a videoconferencing = software. Depending on whether the box admin believes this software = should be supported or not, (s)he might accept that hint and check. (yes = it opens for interesting denial of service attacks: "port X is blocked!" = "no, actually, port Y!" "please check port Z now!" - haha... in which = case you might want to check against the source, based on your physical = network setup. >=20 > Unless you see a sequence of contradicting messages, it might be worth = a check. Consider the other use case: > "Hello, I like the WiFi that's being provided at this airport! But > did you notice that there is almost no reception near the C gates in > terminal 3?" >=20 > No way for an attacker to find out if you got the message or if you = care about it. So, one solution is: read the messages with some delay, = maybe daily. If there is an indication of an attacker sending you back = and forth between A, B and C gates, don't believe it. >=20 > In other words: it's just an unreliable & advisory text message, and - = as with road signs etc. - attacks can be counteracted by common sense = :-) >=20 > Michael >=20 >=20 >=20 >> On 1. jul. 2015, at 18.54, gorry@erg.abdn.ac.uk wrote: >>=20 >> So, if there is no IP header in the payload, I have two questions: >>=20 >> (1) How do you verify the ICMP packet came from something on-path. = rather >> than being generated by a random, potentially malicious sender? Why = would >> any host trust this? >>=20 >> (2) No header no encaps info - hence no ports or originating address = etc? >> - In other words not useful. >>=20 >> (3) Obviously this will not traverse NATs or tunnels (always a = problem for >> feed-backwards control messages), since these would not be able to >> determine the next endpoint. >>=20 >> Gorry >>=20 >>> Hi, >>>=20 >>> See below - this is remotely related to SPUD (really remotely, in = that it >>> addresses a human, but the human in control of a device of concern = to >>> SPUD). >>>=20 >>> We're collecting opinions on this - please let us have them :-) >>>=20 >>> Michael >>>=20 >>>=20 >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> Resent-From: >>>> From: Michael Welzl >>>> Date: 30. juni 2015 kl. 00.35.39 CEST >>>> To: Int-area@ietf.org >>>> Subject: [Int-area] Fwd: New Version Notification for >>>> draft-welzl-icmp-text-middleboxes-00.txt >>>>=20 >>>> Dear all, >>>>=20 >>>> We just posted the draft below. Not knowing which other group would = fit, >>>> we're sending it here. We're really transport people and at least I = am >>>> newbie to this group... very curious to hear your thoughts: >>>> - completely idiotic? >>>> - exactly what the world has been waiting for? >>>>=20 >>>> ... I guess it can only be one of the two above :-) If the = chairs >>>> think that this makes sense to discuss in Prague, we'll be there, = and >>>> I'd be happy to do a supershort presentation, but let us first hear = what >>>> you think. It's a short and easy read, we promise that! :-) >>>>=20 >>>> Thanks! >>>> Michael & Janjie >>>>=20 >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> Resent-From: >>>>> From: >>>>> To: Jianjie You , Michael Welzl >>>>> , Jianjie You , Michael >>>>> Welzl >>>>> Subject: New Version Notification for >>>>> draft-welzl-icmp-text-middleboxes-00.txt >>>>> Date: 30. juni 2015 kl. 00.24.23 CEST >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-welzl-icmp-text-middleboxes-00.txt >>>>> has been successfully submitted by Michael Welzl and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-welzl-icmp-text-middleboxes >>>>> Revision: 00 >>>>> Title: Text messaging to middlebox administrators using = ICMP >>>>> Document date: 2015-06-30 >>>>> Group: Individual Submission >>>>> Pages: 6 >>>>> URL: >>>>> = https://www.ietf.org/internet-drafts/draft-welzl-icmp-text-middleboxes-00.= txt >>>>> Status: >>>>> = https://datatracker.ietf.org/doc/draft-welzl-icmp-text-middleboxes/ >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-welzl-icmp-text-middleboxes-00 >>>>>=20 >>>>>=20 >>>>> Abstract: >>>>> This document describes the use of an ICMP message to send text >>>>> messages to on-path middleboxes from the endpoints. The text = message >>>>> is sent towards a destination but meant to be read by = administrators >>>>> of middleboxes along the path to the destination. The goal is to >>>>> improve the user's experience with simple middlebox cooperation. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=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 >>>>> The IETF Secretariat >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Int-area mailing list >>>> Int-area@ietf.org >>>> https://www.ietf.org/mailman/listinfo/int-area >>>=20 >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud >>>=20 >>=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Wed Jul 1 15:18:09 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE62E1A1AB3 for ; Wed, 1 Jul 2015 15:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 T51rwwmIYKnN for ; Wed, 1 Jul 2015 15:18:04 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C73C1B2AAA for ; Wed, 1 Jul 2015 15:18:04 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZAQKM-000805-4a; Thu, 02 Jul 2015 00:17:58 +0200 Received: from 62-193-53-219.as16211.net ([62.193.53.219] helo=[192.168.101.158]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1ZAQKJ-0001pF-TF; Thu, 02 Jul 2015 00:17:58 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <33970202-61F0-4F9D-8B04-85B677AD381E@cisco.com> Date: Thu, 2 Jul 2015 00:17:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <612B7EC6-8AF9-4FDB-879F-735213ACAB1A@ifi.uio.no> <1A563A0C-CCF5-4D97-935E-1509237BB357@ifi.uio.no> <33970202-61F0-4F9D-8B04-85B677AD381E@cisco.com> To: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 9 sum msgs/h 5 total rcpts 30656 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D58EDAB422B60F943EF6453B031D66B04034516B X-UiO-SPAM-Test: remote_host: 62.193.53.219 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 45 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: gorry@erg.abdn.ac.uk, spud@ietf.org Subject: Re: [Spud] [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 22:18:07 -0000 > On 1. jul. 2015, at 20.49, =F0=9F=94=93Dan Wing = wrote: >=20 > I don't see high likelyhood of someone typing (or speaking) a message = like that, pointing out a problem that might or might not get heard and = result in action. Well... I can imagine you're right but how to know before trying? > I could see an application or OS spitting out messages, though -- but = probably not in the format proposed. For example, it could be valuable = for a network administrator to know that their users want to use = SRTP-over-UDP, but UDP is being blocked forcing users to use = SRTP-over-TCP (which has a different -- sometimes worse -- user = experience than UDP). A browser might want to use QUIC-over-UDP, and it = could be useful to tell the network administrator that it was forced to = fallback to TCP. An OS might want to use native SCTP, native IPsec = (protocol 50), or native QUIC or native RTP (QUIC and RTP are not IANA = registered as protocols on top of IP, but by all rights they could / = should be). Another complaint message might be "Gosh, I need IPv6" or = "I need NAT64". If the "complaint" messages were to be = computer-parsable, I see more value in your proposal. I'm not too keen = on ICMP for this communication, though; perhaps HTTP POST to a = well-known FQDN, such as complaint.local, and some sort of structure to = what is posted could be more valuable. Funny that you mention this - I was actually planning to include a "use = case" on such automated messages but just forgot. I agree that's perhaps = the most useful case. But I wonder, why wouldn't ascii be computer-parsable? I can't imagine = trying to agree on a common "complaint format", so I guess ascii is as = good as anything... maybe then applications would begin to send messages = in a certain style? That style could develop... be defined elsewhere? = Anyway we could make a start, differentiate between computer-parsable = and human messages, and require a certain base format to start with... = if others see value in that too? As for ICMP being the carrier, I don't mind & I'm open to ideas. Hard to = know what's best to use to communicate with a box that drops some of = your stuff, really. The HTTP POST idea is interesting. I personally prefer sending a packet = to the actual destination where the problem happened and expecting it to = be read by boxes on the path though - because the person you want to = reach MAY be local, but it MAY also be a few hops away?! Cheers, Michael >=20 > -d >=20 >=20 > On 01-Jul-2015 10:07 am, Michael Welzl wrote: >>=20 >> Answering all three issues in one go: >>=20 >> It's intended to reach the first, maybe second hop. There you can = either verify where it came from by considering the physical interface, = or (more likely I think) you can "trust but verify" ;-) (since we're = on the SPUD list) >>=20 >> Indeed these text messages are only meant as hints. >>=20 >> Consider this use case in the draft: >>=20 >> "This is Michael Welzl, sitting in office 4164 at IFI. I want to run >> videoconferencing software XY that I need for a project I'm in, but >> it doesn't seem to work. I think you blocked some UDP ports there. >> Not good, please fix and get back to me." >>=20 >> =3D> this is a request to check for port usage of a videoconferencing = software. Depending on whether the box admin believes this software = should be supported or not, (s)he might accept that hint and check. (yes = it opens for interesting denial of service attacks: "port X is blocked!" = "no, actually, port Y!" "please check port Z now!" - haha... in which = case you might want to check against the source, based on your physical = network setup. >>=20 >> Unless you see a sequence of contradicting messages, it might be = worth a check. Consider the other use case: >> "Hello, I like the WiFi that's being provided at this airport! But >> did you notice that there is almost no reception near the C gates in >> terminal 3?" >>=20 >> No way for an attacker to find out if you got the message or if you = care about it. So, one solution is: read the messages with some delay, = maybe daily. If there is an indication of an attacker sending you back = and forth between A, B and C gates, don't believe it. >>=20 >> In other words: it's just an unreliable & advisory text message, and = - as with road signs etc. - attacks can be counteracted by common sense = :-) >>=20 >> Michael >>=20 >>=20 >>=20 >>> On 1. jul. 2015, at 18.54, gorry@erg.abdn.ac.uk wrote: >>>=20 >>> So, if there is no IP header in the payload, I have two questions: >>>=20 >>> (1) How do you verify the ICMP packet came from something on-path. = rather >>> than being generated by a random, potentially malicious sender? Why = would >>> any host trust this? >>>=20 >>> (2) No header no encaps info - hence no ports or originating address = etc? >>> - In other words not useful. >>>=20 >>> (3) Obviously this will not traverse NATs or tunnels (always a = problem for >>> feed-backwards control messages), since these would not be able to >>> determine the next endpoint. >>>=20 >>> Gorry >>>=20 >>>> Hi, >>>>=20 >>>> See below - this is remotely related to SPUD (really remotely, in = that it >>>> addresses a human, but the human in control of a device of concern = to >>>> SPUD). >>>>=20 >>>> We're collecting opinions on this - please let us have them :-) >>>>=20 >>>> Michael >>>>=20 >>>>=20 >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> Resent-From: >>>>> From: Michael Welzl >>>>> Date: 30. juni 2015 kl. 00.35.39 CEST >>>>> To: Int-area@ietf.org >>>>> Subject: [Int-area] Fwd: New Version Notification for >>>>> draft-welzl-icmp-text-middleboxes-00.txt >>>>>=20 >>>>> Dear all, >>>>>=20 >>>>> We just posted the draft below. Not knowing which other group = would fit, >>>>> we're sending it here. We're really transport people and at least = I am >>>>> newbie to this group... very curious to hear your thoughts: >>>>> - completely idiotic? >>>>> - exactly what the world has been waiting for? >>>>>=20 >>>>> ... I guess it can only be one of the two above :-) If the = chairs >>>>> think that this makes sense to discuss in Prague, we'll be there, = and >>>>> I'd be happy to do a supershort presentation, but let us first = hear what >>>>> you think. It's a short and easy read, we promise that! :-) >>>>>=20 >>>>> Thanks! >>>>> Michael & Janjie >>>>>=20 >>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>> Resent-From: >>>>>> From: >>>>>> To: Jianjie You , Michael Welzl >>>>>> , Jianjie You , = Michael >>>>>> Welzl >>>>>> Subject: New Version Notification for >>>>>> draft-welzl-icmp-text-middleboxes-00.txt >>>>>> Date: 30. juni 2015 kl. 00.24.23 CEST >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-welzl-icmp-text-middleboxes-00.txt >>>>>> has been successfully submitted by Michael Welzl and posted to = the >>>>>> IETF repository. >>>>>>=20 >>>>>> Name: draft-welzl-icmp-text-middleboxes >>>>>> Revision: 00 >>>>>> Title: Text messaging to middlebox administrators using = ICMP >>>>>> Document date: 2015-06-30 >>>>>> Group: Individual Submission >>>>>> Pages: 6 >>>>>> URL: >>>>>> = https://www.ietf.org/internet-drafts/draft-welzl-icmp-text-middleboxes-00.= txt >>>>>> Status: >>>>>> = https://datatracker.ietf.org/doc/draft-welzl-icmp-text-middleboxes/ >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-welzl-icmp-text-middleboxes-00 >>>>>>=20 >>>>>>=20 >>>>>> Abstract: >>>>>> This document describes the use of an ICMP message to send text >>>>>> messages to on-path middleboxes from the endpoints. The text = message >>>>>> is sent towards a destination but meant to be read by = administrators >>>>>> of middleboxes along the path to the destination. The goal is to >>>>>> improve the user's experience with simple middlebox cooperation. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=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 >>>>>> The IETF Secretariat >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Int-area mailing list >>>>> Int-area@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/int-area >>>>=20 >>>> _______________________________________________ >>>> Spud mailing list >>>> Spud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spud >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >=20 >=20 From nobody Thu Jul 2 06:52:08 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A201A9028 for ; Thu, 2 Jul 2015 06:52:06 -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 Yy8lGjXd8sta for ; Thu, 2 Jul 2015 06:52:05 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26741A9007 for ; Thu, 2 Jul 2015 06:52:04 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so56733034ieb.1 for ; Thu, 02 Jul 2015 06:52:04 -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:content-type; bh=/foAbVnOmsRxGEHgmfR8hQdblEXNVu5QEB6E/FPMZ5k=; b=FvGj97NXSPX5MdWS7m3XUY8dqvDAGNDy3jv7T9iX9Lo7S9pH0MQ5Le7JKPTKTyFsc0 +nXP2kzC09RZAa3Dq1uRFpeto2e86omeJNz0Of+FebROXcGGQkDKhX7xbeKjou5ny7To RbbJZjklML22MwCBXId1JPrNSN7lwDGaCvBSHrBzRE27mDgwv5B/qQeBmmefmg7/NcFH R181PePX+MBnnLTb+uO9CHGKZVz1By+7ur9o/LuEp9gtuUMcmY/CBoccBrVt852eFrOe VOfEGUlsbW5Lrgk2s29BkznIQPV0vx3PltUbpZRyM/6nVkBad4a8Nxq/SoyA+XmJhqaQ w6mQ== MIME-Version: 1.0 X-Received: by 10.43.54.20 with SMTP id vs20mr12076270icb.96.1435845124411; Thu, 02 Jul 2015 06:52:04 -0700 (PDT) Received: by 10.64.59.225 with HTTP; Thu, 2 Jul 2015 06:52:04 -0700 (PDT) Date: Thu, 2 Jul 2015 09:52:04 -0400 Message-ID: From: Aaron Falk To: "spud@ietf.org" Content-Type: multipart/alternative; boundary=bcaec51d226497dbc20519e4be0f Archived-At: Subject: [Spud] meeting in Prague? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 13:52:06 -0000 --bcaec51d226497dbc20519e4be0f Content-Type: text/plain; charset=UTF-8 I see there is no SPUD BoF scheduled in Prague. Will it be on the agenda of another meeting? Will there be informal meetings? If none of the above, is that an indication that there is insufficient interest in moving forward with SPUD? --aaron --bcaec51d226497dbc20519e4be0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see there is no SPUD BoF scheduled in Prague.=C2=A0 Will= it be on the agenda of another meeting?=C2=A0 Will there be informal meeti= ngs?

If none of the above, is that an indication that th= ere is insufficient interest in moving forward with SPUD?

--aaron
--bcaec51d226497dbc20519e4be0f-- From nobody Thu Jul 2 15:04:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B801A9026 for ; Thu, 2 Jul 2015 15:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UucaW2l_9qmf for ; Thu, 2 Jul 2015 15:04:17 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D530D1A9170 for ; Thu, 2 Jul 2015 15:03:00 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t62M2nXG009152 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Jul 2015 18:02:50 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t62M2nXG009152 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1435874570; bh=8NI9BrWIQ8gdiEglAr/NGITIdBo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=gZH/AqrVAJCUl8vpBHXA1CC5YWiUcOXrZrwMD378+U/WTncTavnqJmlvV9rnf99E1 s4BINAeIibiRlHRy7SIX2GOt0+TqkwKRMwpCbt988mdrPqQcpK2a+/jDETaCds6xuP Ex7PsUJEnGATCCe/NYgohU/RT+PpB/KblElwy7Uk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t62M2nXG009152 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd52.lss.emc.com (RSA Interceptor); Thu, 2 Jul 2015 18:02:40 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t62M2T56005568 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Jul 2015 18:02:29 -0400 Received: from MXHUB204.corp.emc.com (10.253.68.30) by mxhub03.corp.emc.com (10.254.141.105) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 2 Jul 2015 18:02:28 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.107]) by MXHUB204.corp.emc.com ([10.253.68.30]) with mapi id 14.03.0224.002; Thu, 2 Jul 2015 18:02:28 -0400 From: "Black, David" To: Michael Welzl Thread-Topic: [Spud] [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt Thread-Index: AQHQtCCM8LnP3CS5WUqoDxLdwKLcf53HOBWAgAA6QACAAUpuMA== Date: Thu, 2 Jul 2015 22:02:27 +0000 Message-ID: References: <612B7EC6-8AF9-4FDB-879F-735213ACAB1A@ifi.uio.no> <1A563A0C-CCF5-4D97-935E-1509237BB357@ifi.uio.no> <33970202-61F0-4F9D-8B04-85B677AD381E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.81] 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: DLM_1, public Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "spud@ietf.org" Subject: Re: [Spud] [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 22:04:24 -0000 PiBCdXQgSSB3b25kZXIsIHdoeSB3b3VsZG4ndCBhc2NpaSBiZSBjb21wdXRlci1wYXJzYWJsZT8g SSBjYW4ndCBpbWFnaW5lIHRyeWluZw0KPiB0byBhZ3JlZSBvbiBhIGNvbW1vbiAiY29tcGxhaW50 IGZvcm1hdCIsIHNvIEkgZ3Vlc3MgYXNjaWkgaXMgYXMgZ29vZCBhcw0KPiBhbnl0aGluZy4uLiBt YXliZSB0aGVuIGFwcGxpY2F0aW9ucyB3b3VsZCBiZWdpbiB0byBzZW5kIG1lc3NhZ2VzIGluIGEg Y2VydGFpbg0KPiBzdHlsZT8gVGhhdCBzdHlsZSBjb3VsZCBkZXZlbG9wLi4uIGJlIGRlZmluZWQg ZWxzZXdoZXJlPyAgQW55d2F5IHdlIGNvdWxkIG1ha2UNCj4gYSBzdGFydCwgZGlmZmVyZW50aWF0 ZSBiZXR3ZWVuIGNvbXB1dGVyLXBhcnNhYmxlIGFuZCBodW1hbiBtZXNzYWdlcywgYW5kDQo+IHJl cXVpcmUgYSBjZXJ0YWluIGJhc2UgZm9ybWF0IHRvIHN0YXJ0IHdpdGguLi4gIGlmIG90aGVycyBz ZWUgdmFsdWUgaW4gdGhhdA0KPiB0b28/DQoNClBpY2sgeW91ciBmYXZvcml0ZSBsb2cgZm9ybWF0 IC0gbW9zdCBsb2cgYW5hbHlzaXMgdG9vbHMgb3V0IHRoZXJlIGhhdmUgbGVhcm5lZA0KdG8gZXh0 cmFjdCBpbmZvcm1hdGlvbiBmcm9tIGFsbCB0aGUgInVzdXNhbCBzdXNwZWN0cyIgYXMgdGhlcmUg YXJlIG5vIHJlYWxseQ0Kd2VsbC1kZWZpbmVkIHN0YW5kYXJkcyB0aGF0IGNhbiBiZSByZWxpZWQg dXBvbi4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFNwdWQgW21haWx0bzpzcHVkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNaWNoYWVsIFdlbHpsDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwMSwgMjAxNSA2OjE4IFBN DQo+IFRvOiDwn5STRGFuIFdpbmcNCj4gQ2M6IGdvcnJ5QGVyZy5hYmRuLmFjLnVrOyBzcHVkQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbU3B1ZF0gW0ludC1hcmVhXSBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXdlbHpsLWljbXAtDQo+IHRleHQtbWlkZGxlYm94ZXMtMDAudHh0 DQo+IA0KPiANCj4gPiBPbiAxLiBqdWwuIDIwMTUsIGF0IDIwLjQ5LCDwn5STRGFuIFdpbmcgPGR3 aW5nQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBJIGRvbid0IHNlZSBoaWdoIGxpa2VseWhv b2Qgb2Ygc29tZW9uZSB0eXBpbmcgKG9yIHNwZWFraW5nKSBhIG1lc3NhZ2UgbGlrZQ0KPiB0aGF0 LCBwb2ludGluZyBvdXQgYSBwcm9ibGVtIHRoYXQgbWlnaHQgb3IgbWlnaHQgbm90IGdldCBoZWFy ZCBhbmQgcmVzdWx0IGluDQo+IGFjdGlvbi4NCj4gDQo+IFdlbGwuLi4gSSBjYW4gaW1hZ2luZSB5 b3UncmUgcmlnaHQgYnV0IGhvdyB0byBrbm93IGJlZm9yZSB0cnlpbmc/DQo+IA0KPiANCj4gPiBJ IGNvdWxkIHNlZSBhbiBhcHBsaWNhdGlvbiBvciBPUyBzcGl0dGluZyBvdXQgbWVzc2FnZXMsIHRo b3VnaCAtLSBidXQNCj4gcHJvYmFibHkgbm90IGluIHRoZSBmb3JtYXQgcHJvcG9zZWQuICBGb3Ig ZXhhbXBsZSwgaXQgY291bGQgYmUgdmFsdWFibGUgZm9yIGENCj4gbmV0d29yayBhZG1pbmlzdHJh dG9yIHRvIGtub3cgdGhhdCB0aGVpciB1c2VycyB3YW50IHRvIHVzZSBTUlRQLW92ZXItVURQLCBi dXQNCj4gVURQIGlzIGJlaW5nIGJsb2NrZWQgZm9yY2luZyB1c2VycyB0byB1c2UgU1JUUC1vdmVy LVRDUCAod2hpY2ggaGFzIGEgZGlmZmVyZW50DQo+IC0tIHNvbWV0aW1lcyB3b3JzZSAtLSB1c2Vy IGV4cGVyaWVuY2UgdGhhbiBVRFApLiAgQSBicm93c2VyIG1pZ2h0IHdhbnQgdG8gdXNlDQo+IFFV SUMtb3Zlci1VRFAsIGFuZCBpdCBjb3VsZCBiZSB1c2VmdWwgdG8gdGVsbCB0aGUgbmV0d29yayBh ZG1pbmlzdHJhdG9yIHRoYXQNCj4gaXQgd2FzIGZvcmNlZCB0byBmYWxsYmFjayB0byBUQ1AuICBB biBPUyBtaWdodCB3YW50IHRvIHVzZSBuYXRpdmUgU0NUUCwgbmF0aXZlDQo+IElQc2VjIChwcm90 b2NvbCA1MCksIG9yIG5hdGl2ZSBRVUlDIG9yIG5hdGl2ZSBSVFAgKFFVSUMgYW5kIFJUUCBhcmUg bm90IElBTkENCj4gcmVnaXN0ZXJlZCBhcyBwcm90b2NvbHMgb24gdG9wIG9mIElQLCBidXQgYnkg YWxsIHJpZ2h0cyB0aGV5IGNvdWxkIC8gc2hvdWxkDQo+IGJlKS4gIEFub3RoZXIgY29tcGxhaW50 IG1lc3NhZ2UgbWlnaHQgYmUgIkdvc2gsIEkgbmVlZCBJUHY2IiBvciAiSSBuZWVkDQo+IE5BVDY0 Ii4gIElmIHRoZSAiY29tcGxhaW50IiBtZXNzYWdlcyB3ZXJlIHRvIGJlIGNvbXB1dGVyLXBhcnNh YmxlLCBJIHNlZSBtb3JlDQo+IHZhbHVlIGluIHlvdXIgcHJvcG9zYWwuICBJJ20gbm90IHRvbyBr ZWVuIG9uIElDTVAgZm9yIHRoaXMgY29tbXVuaWNhdGlvbiwNCj4gdGhvdWdoOyBwZXJoYXBzIEhU VFAgUE9TVCB0byBhIHdlbGwta25vd24gRlFETiwgc3VjaCBhcyBjb21wbGFpbnQubG9jYWwsIGFu ZA0KPiBzb21lIHNvcnQgb2Ygc3RydWN0dXJlIHRvIHdoYXQgaXMgcG9zdGVkIGNvdWxkIGJlIG1v cmUgdmFsdWFibGUuDQo+IA0KPiBGdW5ueSB0aGF0IHlvdSBtZW50aW9uIHRoaXMgLSBJIHdhcyBh Y3R1YWxseSBwbGFubmluZyB0byBpbmNsdWRlIGEgInVzZSBjYXNlIg0KPiBvbiBzdWNoIGF1dG9t YXRlZCBtZXNzYWdlcyBidXQganVzdCBmb3Jnb3QuIEkgYWdyZWUgdGhhdCdzIHBlcmhhcHMgdGhl IG1vc3QNCj4gdXNlZnVsIGNhc2UuDQo+IA0KPiBCdXQgSSB3b25kZXIsIHdoeSB3b3VsZG4ndCBh c2NpaSBiZSBjb21wdXRlci1wYXJzYWJsZT8gSSBjYW4ndCBpbWFnaW5lIHRyeWluZw0KPiB0byBh Z3JlZSBvbiBhIGNvbW1vbiAiY29tcGxhaW50IGZvcm1hdCIsIHNvIEkgZ3Vlc3MgYXNjaWkgaXMg YXMgZ29vZCBhcw0KPiBhbnl0aGluZy4uLiBtYXliZSB0aGVuIGFwcGxpY2F0aW9ucyB3b3VsZCBi ZWdpbiB0byBzZW5kIG1lc3NhZ2VzIGluIGEgY2VydGFpbg0KPiBzdHlsZT8gVGhhdCBzdHlsZSBj b3VsZCBkZXZlbG9wLi4uIGJlIGRlZmluZWQgZWxzZXdoZXJlPyAgQW55d2F5IHdlIGNvdWxkIG1h a2UNCj4gYSBzdGFydCwgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGNvbXB1dGVyLXBhcnNhYmxlIGFu ZCBodW1hbiBtZXNzYWdlcywgYW5kDQo+IHJlcXVpcmUgYSBjZXJ0YWluIGJhc2UgZm9ybWF0IHRv IHN0YXJ0IHdpdGguLi4gIGlmIG90aGVycyBzZWUgdmFsdWUgaW4gdGhhdA0KPiB0b28/DQo+IA0K PiBBcyBmb3IgSUNNUCBiZWluZyB0aGUgY2FycmllciwgSSBkb24ndCBtaW5kICYgSSdtIG9wZW4g dG8gaWRlYXMuIEhhcmQgdG8ga25vdw0KPiB3aGF0J3MgYmVzdCB0byB1c2UgdG8gY29tbXVuaWNh dGUgd2l0aCBhIGJveCB0aGF0IGRyb3BzIHNvbWUgb2YgeW91ciBzdHVmZiwNCj4gcmVhbGx5Lg0K PiBUaGUgSFRUUCBQT1NUIGlkZWEgaXMgaW50ZXJlc3RpbmcuIEkgcGVyc29uYWxseSBwcmVmZXIg c2VuZGluZyBhIHBhY2tldCB0byB0aGUNCj4gYWN0dWFsIGRlc3RpbmF0aW9uIHdoZXJlIHRoZSBw cm9ibGVtIGhhcHBlbmVkIGFuZCBleHBlY3RpbmcgaXQgdG8gYmUgcmVhZCBieQ0KPiBib3hlcyBv biB0aGUgcGF0aCB0aG91Z2ggLSBiZWNhdXNlIHRoZSBwZXJzb24geW91IHdhbnQgdG8gcmVhY2gg TUFZIGJlIGxvY2FsLA0KPiBidXQgaXQgTUFZIGFsc28gYmUgYSBmZXcgaG9wcyBhd2F5PyENCj4g DQo+IENoZWVycywNCj4gTWljaGFlbA0KPiANCj4gDQo+ID4NCj4gPiAtZA0KPiA+DQo+ID4NCj4g PiBPbiAwMS1KdWwtMjAxNSAxMDowNyBhbSwgTWljaGFlbCBXZWx6bCA8bWljaGF3ZUBpZmkudWlv Lm5vPiB3cm90ZToNCj4gPj4NCj4gPj4gQW5zd2VyaW5nIGFsbCB0aHJlZSBpc3N1ZXMgaW4gb25l IGdvOg0KPiA+Pg0KPiA+PiBJdCdzIGludGVuZGVkIHRvIHJlYWNoIHRoZSBmaXJzdCwgbWF5YmUg c2Vjb25kIGhvcC4gVGhlcmUgeW91IGNhbiBlaXRoZXINCj4gdmVyaWZ5IHdoZXJlIGl0IGNhbWUg ZnJvbSBieSBjb25zaWRlcmluZyB0aGUgcGh5c2ljYWwgaW50ZXJmYWNlLCBvciAobW9yZQ0KPiBs aWtlbHkgSSB0aGluaykgeW91IGNhbiAidHJ1c3QgYnV0IHZlcmlmeSIgIDstKSAgIChzaW5jZSB3 ZSdyZSBvbiB0aGUgU1BVRA0KPiBsaXN0KQ0KPiA+Pg0KPiA+PiBJbmRlZWQgdGhlc2UgdGV4dCBt ZXNzYWdlcyBhcmUgb25seSBtZWFudCBhcyBoaW50cy4NCj4gPj4NCj4gPj4gQ29uc2lkZXIgdGhp cyB1c2UgY2FzZSBpbiB0aGUgZHJhZnQ6DQo+ID4+DQo+ID4+ICJUaGlzIGlzIE1pY2hhZWwgV2Vs emwsIHNpdHRpbmcgaW4gb2ZmaWNlIDQxNjQgYXQgSUZJLiAgSSB3YW50IHRvIHJ1bg0KPiA+PiAg dmlkZW9jb25mZXJlbmNpbmcgc29mdHdhcmUgWFkgdGhhdCBJIG5lZWQgZm9yIGEgcHJvamVjdCBJ J20gaW4sIGJ1dA0KPiA+PiAgaXQgZG9lc24ndCBzZWVtIHRvIHdvcmsuICBJIHRoaW5rIHlvdSBi bG9ja2VkIHNvbWUgVURQIHBvcnRzIHRoZXJlLg0KPiA+PiAgTm90IGdvb2QsIHBsZWFzZSBmaXgg YW5kIGdldCBiYWNrIHRvIG1lLiINCj4gPj4NCj4gPj4gPT4gdGhpcyBpcyBhIHJlcXVlc3QgdG8g Y2hlY2sgZm9yIHBvcnQgdXNhZ2Ugb2YgYSB2aWRlb2NvbmZlcmVuY2luZw0KPiBzb2Z0d2FyZS4g RGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhlIGJveCBhZG1pbiBiZWxpZXZlcyB0aGlzIHNvZnR3YXJl IHNob3VsZCBiZQ0KPiBzdXBwb3J0ZWQgb3Igbm90LCAocyloZSBtaWdodCBhY2NlcHQgdGhhdCBo aW50IGFuZCBjaGVjay4gKHllcyBpdCBvcGVucyBmb3INCj4gaW50ZXJlc3RpbmcgZGVuaWFsIG9m IHNlcnZpY2UgYXR0YWNrczogInBvcnQgWCBpcyBibG9ja2VkISIgIm5vLCBhY3R1YWxseSwNCj4g cG9ydCBZISIgInBsZWFzZSBjaGVjayBwb3J0IFogbm93ISIgLSBoYWhhLi4uICAgIGluIHdoaWNo IGNhc2UgeW91IG1pZ2h0IHdhbnQNCj4gdG8gY2hlY2sgYWdhaW5zdCB0aGUgc291cmNlLCBiYXNl ZCBvbiB5b3VyIHBoeXNpY2FsIG5ldHdvcmsgc2V0dXAuDQo+ID4+DQo+ID4+IFVubGVzcyB5b3Ug c2VlIGEgc2VxdWVuY2Ugb2YgY29udHJhZGljdGluZyBtZXNzYWdlcywgaXQgbWlnaHQgYmUgd29y dGggYQ0KPiBjaGVjay4gQ29uc2lkZXIgdGhlIG90aGVyIHVzZSBjYXNlOg0KPiA+PiAiSGVsbG8s IEkgbGlrZSB0aGUgV2lGaSB0aGF0J3MgYmVpbmcgcHJvdmlkZWQgYXQgdGhpcyBhaXJwb3J0ISAg QnV0DQo+ID4+ICBkaWQgeW91IG5vdGljZSB0aGF0IHRoZXJlIGlzIGFsbW9zdCBubyByZWNlcHRp b24gbmVhciB0aGUgQyBnYXRlcyBpbg0KPiA+PiAgdGVybWluYWwgMz8iDQo+ID4+DQo+ID4+IE5v IHdheSBmb3IgYW4gYXR0YWNrZXIgdG8gZmluZCBvdXQgaWYgeW91IGdvdCB0aGUgbWVzc2FnZSBv ciBpZiB5b3UgY2FyZQ0KPiBhYm91dCBpdC4gU28sIG9uZSBzb2x1dGlvbiBpczogcmVhZCB0aGUg bWVzc2FnZXMgd2l0aCBzb21lIGRlbGF5LCBtYXliZSBkYWlseS4NCj4gSWYgdGhlcmUgaXMgYW4g aW5kaWNhdGlvbiBvZiBhbiBhdHRhY2tlciBzZW5kaW5nIHlvdSBiYWNrIGFuZCBmb3J0aCBiZXR3 ZWVuIEEsDQo+IEIgYW5kIEMgZ2F0ZXMsIGRvbid0IGJlbGlldmUgaXQuDQo+ID4+DQo+ID4+IElu IG90aGVyIHdvcmRzOiBpdCdzIGp1c3QgYW4gdW5yZWxpYWJsZSAmIGFkdmlzb3J5IHRleHQgbWVz c2FnZSwgYW5kIC0gYXMNCj4gd2l0aCByb2FkIHNpZ25zIGV0Yy4gLSBhdHRhY2tzIGNhbiBiZSBj b3VudGVyYWN0ZWQgYnkgY29tbW9uIHNlbnNlICA6LSkNCj4gPj4NCj4gPj4gTWljaGFlbA0KPiA+ Pg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gT24gMS4ganVsLiAyMDE1LCBhdCAxOC41NCwgZ29ycnlAZXJn LmFiZG4uYWMudWsgd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gU28sIGlmIHRoZXJlIGlzIG5vIElQIGhl YWRlciBpbiB0aGUgcGF5bG9hZCwgSSBoYXZlIHR3byBxdWVzdGlvbnM6DQo+ID4+Pg0KPiA+Pj4g KDEpIEhvdyBkbyB5b3UgdmVyaWZ5IHRoZSBJQ01QIHBhY2tldCBjYW1lIGZyb20gc29tZXRoaW5n IG9uLXBhdGguIHJhdGhlcg0KPiA+Pj4gdGhhbiBiZWluZyBnZW5lcmF0ZWQgYnkgYSAgcmFuZG9t LCBwb3RlbnRpYWxseSBtYWxpY2lvdXMgc2VuZGVyPyBXaHkgd291bGQNCj4gPj4+IGFueSBob3N0 IHRydXN0IHRoaXM/DQo+ID4+Pg0KPiA+Pj4gKDIpIE5vIGhlYWRlciBubyBlbmNhcHMgaW5mbyAt IGhlbmNlIG5vIHBvcnRzIG9yIG9yaWdpbmF0aW5nIGFkZHJlc3MgZXRjPw0KPiA+Pj4gLSBJbiBv dGhlciB3b3JkcyBub3QgdXNlZnVsLg0KPiA+Pj4NCj4gPj4+ICgzKSBPYnZpb3VzbHkgdGhpcyB3 aWxsIG5vdCB0cmF2ZXJzZSBOQVRzIG9yIHR1bm5lbHMgKGFsd2F5cyBhIHByb2JsZW0gZm9yDQo+ ID4+PiBmZWVkLWJhY2t3YXJkcyBjb250cm9sIG1lc3NhZ2VzKSwgc2luY2UgdGhlc2Ugd291bGQg bm90IGJlIGFibGUgdG8NCj4gPj4+IGRldGVybWluZSB0aGUgbmV4dCBlbmRwb2ludC4NCj4gPj4+ DQo+ID4+PiBHb3JyeQ0KPiA+Pj4NCj4gPj4+PiBIaSwNCj4gPj4+Pg0KPiA+Pj4+IFNlZSBiZWxv dyAtIHRoaXMgaXMgcmVtb3RlbHkgcmVsYXRlZCB0byBTUFVEIChyZWFsbHkgcmVtb3RlbHksIGlu IHRoYXQgaXQNCj4gPj4+PiBhZGRyZXNzZXMgYSBodW1hbiwgYnV0IHRoZSBodW1hbiBpbiBjb250 cm9sIG9mIGEgZGV2aWNlIG9mIGNvbmNlcm4gdG8NCj4gPj4+PiBTUFVEKS4NCj4gPj4+Pg0KPiA+ Pj4+IFdlJ3JlIGNvbGxlY3Rpbmcgb3BpbmlvbnMgb24gdGhpcyAtIHBsZWFzZSBsZXQgdXMgaGF2 ZSB0aGVtICAgOi0pDQo+ID4+Pj4NCj4gPj4+PiBNaWNoYWVsDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4+IEJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KPiA+Pj4+Pg0KPiA+Pj4+PiBS ZXNlbnQtRnJvbTogPG1pY2hhd2VAaWZpLnVpby5ubz4NCj4gPj4+Pj4gRnJvbTogTWljaGFlbCBX ZWx6bCA8bWljaGF3ZUBpZmkudWlvLm5vPg0KPiA+Pj4+PiBEYXRlOiAzMC4ganVuaSAyMDE1IGts LiAwMC4zNS4zOSBDRVNUDQo+ID4+Pj4+IFRvOiBJbnQtYXJlYUBpZXRmLm9yZw0KPiA+Pj4+PiBT dWJqZWN0OiBbSW50LWFyZWFdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+ Pj4+PiBkcmFmdC13ZWx6bC1pY21wLXRleHQtbWlkZGxlYm94ZXMtMDAudHh0DQo+ID4+Pj4+DQo+ ID4+Pj4+IERlYXIgYWxsLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBXZSBqdXN0IHBvc3RlZCB0aGUgZHJh ZnQgYmVsb3cuIE5vdCBrbm93aW5nIHdoaWNoIG90aGVyIGdyb3VwIHdvdWxkIGZpdCwNCj4gPj4+ Pj4gd2UncmUgc2VuZGluZyBpdCBoZXJlLiBXZSdyZSByZWFsbHkgdHJhbnNwb3J0IHBlb3BsZSBh bmQgYXQgbGVhc3QgSSBhbQ0KPiA+Pj4+PiBuZXdiaWUgdG8gdGhpcyBncm91cC4uLiAgdmVyeSBj dXJpb3VzIHRvIGhlYXIgeW91ciB0aG91Z2h0czoNCj4gPj4+Pj4gLSBjb21wbGV0ZWx5IGlkaW90 aWM/DQo+ID4+Pj4+IC0gZXhhY3RseSB3aGF0IHRoZSB3b3JsZCBoYXMgYmVlbiB3YWl0aW5nIGZv cj8NCj4gPj4+Pj4NCj4gPj4+Pj4gLi4uIEkgZ3Vlc3MgaXQgY2FuIG9ubHkgYmUgb25lIG9mIHRo ZSB0d28gYWJvdmUgIDotKSAgICAgSWYgdGhlIGNoYWlycw0KPiA+Pj4+PiB0aGluayB0aGF0IHRo aXMgbWFrZXMgc2Vuc2UgdG8gZGlzY3VzcyBpbiBQcmFndWUsIHdlJ2xsIGJlIHRoZXJlLCBhbmQN Cj4gPj4+Pj4gSSdkIGJlIGhhcHB5IHRvIGRvIGEgc3VwZXJzaG9ydCBwcmVzZW50YXRpb24sIGJ1 dCBsZXQgdXMgZmlyc3QgaGVhciB3aGF0DQo+ID4+Pj4+IHlvdSB0aGluay4gSXQncyBhIHNob3J0 IGFuZCBlYXN5IHJlYWQsIHdlIHByb21pc2UgdGhhdCEgIDotKQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBU aGFua3MhDQo+ID4+Pj4+IE1pY2hhZWwgJiBKYW5qaWUNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+ Pj4+IEJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFJlc2VudC1G cm9tOiA8bWljaGF3ZUBpZmkudWlvLm5vPg0KPiA+Pj4+Pj4gRnJvbTogPGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz4NCj4gPj4+Pj4+IFRvOiBKaWFuamllIFlvdSA8eW91amlhbmppZUBodWF3ZWku Y29tPiwgTWljaGFlbCBXZWx6bA0KPiA+Pj4+Pj4gPG1pY2hhd2VAaWZpLnVpby5ubz4sIEppYW5q aWUgWW91IDx5b3VqaWFuamllQGh1YXdlaS5jb20+LCBNaWNoYWVsDQo+ID4+Pj4+PiBXZWx6bCA8 bWljaGF3ZUBpZmkudWlvLm5vPg0KPiA+Pj4+Pj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvcg0KPiA+Pj4+Pj4gZHJhZnQtd2VsemwtaWNtcC10ZXh0LW1pZGRsZWJveGVzLTAw LnR4dA0KPiA+Pj4+Pj4gRGF0ZTogMzAuIGp1bmkgMjAxNSBrbC4gMDAuMjQuMjMgQ0VTVA0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2Vs emwtaWNtcC10ZXh0LW1pZGRsZWJveGVzLTAwLnR4dA0KPiA+Pj4+Pj4gaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBNaWNoYWVsIFdlbHpsIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4+ Pj4+PiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gTmFtZToJCWRyYWZ0LXdl bHpsLWljbXAtdGV4dC1taWRkbGVib3hlcw0KPiA+Pj4+Pj4gUmV2aXNpb246CTAwDQo+ID4+Pj4+ PiBUaXRsZToJCVRleHQgbWVzc2FnaW5nIHRvIG1pZGRsZWJveCBhZG1pbmlzdHJhdG9ycyB1c2lu ZyBJQ01QDQo+ID4+Pj4+PiBEb2N1bWVudCBkYXRlOgkyMDE1LTA2LTMwDQo+ID4+Pj4+PiBHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+Pj4+Pj4gUGFnZXM6CQk2DQo+ID4+Pj4+PiBV Ukw6DQo+ID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt d2VsemwtaWNtcC10ZXh0LW1pZGRsZWJveGVzLQ0KPiAwMC50eHQNCj4gPj4+Pj4+IFN0YXR1czoN Cj4gPj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdlbHpsLWlj bXAtdGV4dC1taWRkbGVib3hlcy8NCj4gPj4+Pj4+IEh0bWxpemVkOg0KPiA+Pj4+Pj4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdlbHpsLWljbXAtdGV4dC1taWRkbGVib3hlcy0w MA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBBYnN0cmFjdDoNCj4gPj4+Pj4+IFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB1c2Ugb2YgYW4gSUNNUCBtZXNzYWdlIHRvIHNlbmQgdGV4 dA0KPiA+Pj4+Pj4gbWVzc2FnZXMgdG8gb24tcGF0aCBtaWRkbGVib3hlcyBmcm9tIHRoZSBlbmRw b2ludHMuICBUaGUgdGV4dCBtZXNzYWdlDQo+ID4+Pj4+PiBpcyBzZW50IHRvd2FyZHMgYSBkZXN0 aW5hdGlvbiBidXQgbWVhbnQgdG8gYmUgcmVhZCBieSBhZG1pbmlzdHJhdG9ycw0KPiA+Pj4+Pj4g b2YgbWlkZGxlYm94ZXMgYWxvbmcgdGhlIHBhdGggdG8gdGhlIGRlc3RpbmF0aW9uLiAgVGhlIGdv YWwgaXMgdG8NCj4gPj4+Pj4+IGltcHJvdmUgdGhlIHVzZXIncyBleHBlcmllbmNlIHdpdGggc2lt cGxlIG1pZGRsZWJveCBjb29wZXJhdGlvbi4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPj4+Pj4+IHN1Ym1pc3Np b24NCj4gPj4+Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCj4gPj4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+IEludC1hcmVhIG1haWxpbmcgbGlz dA0KPiA+Pj4+PiBJbnQtYXJlYUBpZXRmLm9yZw0KPiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhDQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+IFNwdWQgbWFpbGluZyBs aXN0DQo+ID4+Pj4gU3B1ZEBpZXRmLm9yZw0KPiA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3B1ZA0KPiA+Pj4+DQo+ID4+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBTcHVkIG1haWxpbmcg bGlzdA0KPiA+PiBTcHVkQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3B1ZA0KPiA+DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNwdWQgbWFpbGluZyBsaXN0DQo+IFNwdWRAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkDQo= From nobody Thu Jul 2 15:13:20 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07561A9114; Thu, 2 Jul 2015 15:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 j3-NXsnsE1XK; Thu, 2 Jul 2015 15:13:14 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BA31A90DD; Thu, 2 Jul 2015 15:13:14 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZAmjI-0006pv-I2; Fri, 03 Jul 2015 00:13:12 +0200 Received: from [46.189.28.223] (helo=[10.25.10.70]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZAmjI-0006Qn-0a; Fri, 03 Jul 2015 00:13:12 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Fri, 3 Jul 2015 00:13:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150629222423.11828.57025.idtracker@ietfa.amsl.com> <612B7EC6-8AF9-4FDB-879F-735213ACAB1A@ifi.uio.no> <5591CF7B.5060205@bogus.com> <5591D30C.4070508@isi.edu> <531CB84E-6C1A-45C2-BF2B-25AD7BB1444A@ifi.uio.no> <5592CBC7.5090504@isi.edu> <7EFA2E94-20CC-4304-B4FD-23079F95C3D4@ifi.uio.no> <5592D8B6.9010009@isi.edu> <1A13E924-93B6-4881-B6C4-3DA3C3D42E92@ifi.uio.no> To: "Black, David" X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 30694 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A0F83A97D3A5C53A05342C21385C46FCC793C627 X-UiO-SPAM-Test: remote_host: 46.189.28.223 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 14 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "Int-area@ietf.org" , spud@ietf.org Subject: Re: [Spud] [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 22:13:16 -0000 [ + spud list ] > On 2. jul. 2015, at 22.07, Black, David wrote: >=20 >>>>> cases where the latter doesn't happen. >>>>=20 >>>> Got it now, sorry for the confusion. >>>> So I don't really care much about the middlebox behind a NAT on the = other >> side - it's *my* side I care about. The usage examples in the draft = refer to >> talking people in my institution or at the airport where I'm sitting. = I don't >> expect to be (or care about being) able to talk to a middlebox far, = far >> away... chances are, the message is dropped long before anyway. >>>=20 >>> It's a limitation; it might be useful to explain the limitation and = why >>> the remainder is still useful. >>=20 >> ok >=20 > And specify boundaries at which these text messages SHOULD be dropped = because > they are likely to be irrelevant beyond that point. For the airport = or > university example, this may be where the airport or university = network hands > off to the ISP that provides connectivity to the Internet. ok > I also concur with Joel's and Diego's observation that an operator = with strongly > structured procedures (e.g., ticketing system) is going to have some = difficulty > dealing with this sort of problem report, especially as it's = unauthenticated - > the fact that one can get an ICMP packet into the operator's network = does not > automatically entitle one to draw upon the operator's support = resources. This was also said by Diego Lopez - such operators may just not be a = suitable target for this type of message (rather, smaller ones, then). = But "entitle to draw upon the resources" is a bit exaggerated when we're = talking about sending an ascii message. Nobody's obliged to listen to = it, after all. Anyway, I have to say I'm getting some very good feedback here - in = particular, I like Dan Wing's observation (on the spud list) that = applications could auto-generate this (e.g. "Tried QUIC but failed UDP, = falling back to TCP"); he suggested a machine-parsable format but now I = wonder how to do this? All of a sudden, this seems to become more reasonable and make more = sense than I ever expected :-) Thanks! Michael From nobody Thu Jul 2 15:14:05 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B4B1A9114 for ; Thu, 2 Jul 2015 15:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 wCINBC99n0v6 for ; Thu, 2 Jul 2015 15:14:03 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155A91A90DD for ; Thu, 2 Jul 2015 15:14:03 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZAmk2-0006rt-Sx; Fri, 03 Jul 2015 00:13:58 +0200 Received: from [46.189.28.223] (helo=[10.25.10.70]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZAmk2-0006Qn-J7; Fri, 03 Jul 2015 00:13:58 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Fri, 3 Jul 2015 00:13:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F296D63-AE5D-4B1A-ABA4-FBE7D2CA0479@ifi.uio.no> References: <612B7EC6-8AF9-4FDB-879F-735213ACAB1A@ifi.uio.no> <1A563A0C-CCF5-4D97-935E-1509237BB357@ifi.uio.no> <33970202-61F0-4F9D-8B04-85B677AD381E@cisco.com> To: "Black, David" X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 7 sum msgs/h 3 total rcpts 30697 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C1BD2AA0A9B7A9139C9C8C9D329D65553DBE1F5B X-UiO-SPAM-Test: remote_host: 46.189.28.223 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 15 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "spud@ietf.org" Subject: Re: [Spud] [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 22:14:04 -0000 > On 3. jul. 2015, at 00.02, Black, David wrote: >=20 >> But I wonder, why wouldn't ascii be computer-parsable? I can't = imagine trying >> to agree on a common "complaint format", so I guess ascii is as good = as >> anything... maybe then applications would begin to send messages in a = certain >> style? That style could develop... be defined elsewhere? Anyway we = could make >> a start, differentiate between computer-parsable and human messages, = and >> require a certain base format to start with... if others see value = in that >> too? >=20 > Pick your favorite log format - most log analysis tools out there have = learned > to extract information from all the "ususal suspects" as there are no = really > well-defined standards that can be relied upon. Ah, sorry, I saw this one too late - it answers a question I ask in my = previous answer :( From nobody Fri Jul 3 06:21:55 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B6A1B2F5D for ; Fri, 3 Jul 2015 06:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qqyZiv470bYl for ; Fri, 3 Jul 2015 06:21:51 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3181B2F5F for ; Fri, 3 Jul 2015 06:21:50 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2:b1f3:a723:886d:f5ef] (unknown [IPv6:2001:470:26:9c2:b1f3:a723:886d:f5ef]) by trammell.ch (Postfix) with ESMTPSA id 806401A01F5; Fri, 3 Jul 2015 15:21:49 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8A829901-7286-4289-8650-3DA1F79D27B7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: Date: Fri, 3 Jul 2015 15:21:48 +0200 Message-Id: <01659EBB-E426-44A1-BD85-463312CC3709@trammell.ch> References: To: Aaron Falk X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] meeting in Prague? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 13:21:53 -0000 --Apple-Mail=_8A829901-7286-4289-8650-3DA1F79D27B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Aaron, Apologies for not answering this question in advance on the list. > On 02 Jul 2015, at 15:52, Aaron Falk wrote: >=20 > I see there is no SPUD BoF scheduled in Prague. Will it be on the = agenda of another meeting? Will there be informal meetings? There is not a BoF or formal meeting scheduled. In our (BoF proponents') = opinion, there is not yet enough clarity on what an eventual WG charter = would look like to hold a WG-forming BoF, nor a coherent enough = statement of a research question to try to form an RG. A group of us (mainly BoF proponents and presenters) are working on a = document outlining potential requirements for transport encapsulation = with middlebox cooperation. We plan to submit this Real Soon Now, = definitely before the Monday deadline. This document is very much a work = in progress -- musings on open questions take up more space than things = we think are definite requirements -- but we have tried to capture what = we've heard in the ongoing discussion into a coherent basis for further = discussion. We hope this document to trigger both list and hallway discussions in = Prague. The contributors to this document will also meet in Prague on = the Saturday before the IETF to work on the next revision of it. Cheers, Brian --Apple-Mail=_8A829901-7286-4289-8650-3DA1F79D27B7 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVloxsAAoJENt3nsOmbNJcP3kH/2pZHdb4LxCZTsNkMAOmI5Pe boCEwHgk4L5+Mwwlnyd//OTRZ3mpMa39Ni2gRoVmsp3Cu5/rAB9wM0tWFdVJjkFW lTxL9fFrSuUtD9FQbQQOYsUtSKp+fwrAS9shZThmK/G9dNVbRKKnGy32W9KDdD4p 22o5Bej3FWXWD73HriQwYhsOaSExKbhn8cDLtWFl9Qr+bl6E1rjf1MRpXag/WNno B6tEuAA2mOMNAfjc1pkNc4f4PI+mCyGhn6nyeT/cOcT9fYYQsTteMI6iaGenHDaX Xx7cp63C1UjAKXYOwZzT1sCs9UfS9BtHWKz6v7nB9ONp8FoKK8zgqZMc4WtOEXw= =Jljh -----END PGP SIGNATURE----- --Apple-Mail=_8A829901-7286-4289-8650-3DA1F79D27B7-- From nobody Fri Jul 3 08:25:16 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3534D1ABC0F for ; Fri, 3 Jul 2015 08:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 k_-fuEP3NrOY for ; Fri, 3 Jul 2015 08:25:02 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903AE1ACE4C for ; Fri, 3 Jul 2015 08:25:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AACCFD9303; Fri, 3 Jul 2015 17:25:00 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QJ-OrRNTtmcZ; Fri, 3 Jul 2015 17:25:00 +0200 (MEST) Received: from [192.168.178.33] (x5f7001fc.dyn.telefonica.de [95.112.1.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 33473D9302; Fri, 3 Jul 2015 17:25:00 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Date: Fri, 3 Jul 2015 17:24:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> To: spud@ietf.org X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Brian Trammell Subject: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 15:25:11 -0000 Hi all, we=E2=80=99ve just submitted a new use case document. This document = describes in more detail the use cases as already presented/discussed at = the BoF. Please review and comment. Also partial reviews of e.g. just one use = case are more than welcome. Further if you=E2=80=99d like to contribute = to this document, please let use know as well. For everybody who potentially has additional use cases in mind, I = personally would appreciate to see future use case descriptions with a = similar structure than use in this document. In found it very helpful to = capture the most important points. However, this structure is also open = for discussion. Brian and Mirja > Anfang der weitergeleiteten Nachricht: >=20 > Von: internet-drafts@ietf.org > Betreff: New Version Notification for = draft-kuehlewind-spud-use-cases-00.txt > Datum: 3. Juli 2015 17:19:10 MESZ > An: "Mirja Kuehlewind" , "Mirja = Kuehlewind" , "Brian Trammell" = , "Brian Trammell" >=20 >=20 > A new version of I-D, draft-kuehlewind-spud-use-cases-00.txt > has been successfully submitted by Mirja Kuehlewind and posted to the > IETF repository. >=20 > Name: draft-kuehlewind-spud-use-cases > Revision: 00 > Title: SPUD Use Cases > Document date: 2015-07-03 > Group: Individual Submission > Pages: 15 > URL: = https://www.ietf.org/internet-drafts/draft-kuehlewind-spud-use-cases-00.tx= t > Status: = https://datatracker.ietf.org/doc/draft-kuehlewind-spud-use-cases/ > Htmlized: = https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00 >=20 >=20 > Abstract: > The Substrate Protocol for User Datagrams (SPUD) BoF session at the > IETF 92 meeting in Dallas in March 2015 identified the potential = need > for a UDP-based encapsulation protocol to allow explicit cooperation > with middleboxes while using new, encrypted transport protocols. > This document summarizes the use cases discuss at the BoF and = thereby > proposes a structure for the description of further use cases. >=20 >=20 >=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 > The IETF Secretariat From nobody Mon Jul 6 10:20:23 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3271ACD8E for ; Mon, 6 Jul 2015 10:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 eKL39dd25y8c for ; Mon, 6 Jul 2015 10:20:12 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405AA1ACC91 for ; Mon, 6 Jul 2015 10:20:12 -0700 (PDT) Received: by igcsj18 with SMTP id sj18so240020272igc.1 for ; Mon, 06 Jul 2015 10:20:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7l/YvNNTodQYYh7u7vXNCIM+jWp5n1AiOzKCWL+2BDA=; b=TPCmKvyymI6L8xMabT+au69S0o+yUdX3j+e9/0xtTd9dLMpqORu56izm4G4dvmRbX3 Eoc1k3YkdIXdWaGUv7rn2colYZH4kAef7/txFf7jHI4hZFP/kYSvAS5mFFQFBUSAhLav qj99aBh+mr4SGXRJLI1QQd4i4B5y/HOsEhzXwQAtX/ru2lQrtxkFnEwfpZ0vIHYhWgcZ V/XAcVMtzR4pBX7BgYoZEruKSejFk9gf6lyukYj8H0zBksxoDi9MmGO8H+F6X4xfIufX adWKaQdSaBjsUe5NrHndj6ci0ymfXlsSHNgR3V+v26lWGE6YdxfYUIk1+LAZH09VCa7N 8icg== X-Gm-Message-State: ALoCoQkZMj88OzwlgavLmSec63+AkzsLYXsnRKaR6VmKjk0wLrGLiRI3n74iJhaHk3DIBnQ5C1mJ MIME-Version: 1.0 X-Received: by 10.42.244.4 with SMTP id lo4mr37319214icb.65.1436203211510; Mon, 06 Jul 2015 10:20:11 -0700 (PDT) Received: by 10.107.142.86 with HTTP; Mon, 6 Jul 2015 10:20:11 -0700 (PDT) In-Reply-To: <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> Date: Mon, 6 Jul 2015 10:20:11 -0700 Message-ID: From: Tom Herbert To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Brian Trammell , spud@ietf.org Subject: Re: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 17:20:14 -0000 On Fri, Jul 3, 2015 at 8:24 AM, Mirja K=C3=BChlewind wrote: > Hi all, > > we=E2=80=99ve just submitted a new use case document. This document descr= ibes in more detail the use cases as already presented/discussed at the BoF= . > > Please review and comment. Also partial reviews of e.g. just one use case= are more than welcome. Further if you=E2=80=99d like to contribute to this= document, please let use know as well. > Hi Mirja, thanks for the draft! Here are my comments. General comments: It seems to me there are two motivations for SPUD: 1) A common protocol layer for UDP flow based protocols to pass through stateful firewalls and NAT. 2) A rich inband flow based QoS signaling initiated by end hosts which can be interpreted by network devices in the path. The first motivation seems pretty clear, the inability to pass UDP (really anything besides TCP) through stateful firewalls has impeded deployment of new L4 protocols. The second motivation is less clear. Disregarding previously raised questions around new DoS vectors and whether we can ever trust anything anyone says on the Internet, I would ask if SPUD (UDP) is the right layer for this. The need for this signaling doesn't seem to be specific to UDP transport protocols, but also should applicable to TCP, SCTP, and other protocols. Barring that these protocols transition to running over SPUD (unlikely in the foreseeable future), it seems like such signaling should be implemented in a more common layer, maybe something like IP options. Another general question I have is how much leeway should be taken in relaxing or modifying the end-to-end semantics of UDP. In particular, I think an important question is rather middleboxes should be modifying UDP payloads. We've accepted that NAT devices can modify UDP port numbers, but mucking with the payload seems worse to me. This makes end-to-end authentication or integrity checks much more difficult, and if a packet is ever misclassified as SPUD this could result in data corruption. This issue also comes up in other proposals, such as BIER, but those seem have more narrow application (i.e. for multicast, deployed in closed network not the Internet as SPUD is intended). > For everybody who potentially has additional use cases in mind, I persona= lly would appreciate to see future use case descriptions with a similar str= ucture than use in this document. In found it very helpful to capture the m= ost important points. However, this structure is also open for discussion. > Use of SPUD with NAT should probably be mentioned in the draft. It might be worthwhile to consider some more specific applications of firewalls. For example, if a firewall is deployed between a site and the Internet, we might be more inclined to trust SPUD directives received from the internal network as opposed to the Internet. Another potential use case to investigate would be mobile devices behind a middlebox. Comments on the draft: "This state should be bound to something beyond the five-tuple to link packets together." question here of whether UDP source should be part of identifying tuple. UDP encapsulation protocols are defining source port as an entropy field for ECMP, so it might be good to take out source port in the tuple. "Further, to maintain state, the sender must explicitly indicate the start and end of a tube to the path, while the receiver must confirm connection establishment.". Sender and receiver might be ambiguous terms, I like initiator and target if this is meant to indicate perspective roles in the connection establishment. An alternative mode could be request/response communication where the request creates the state and the response closes it (this is described in draft-herbert-gue-session-id-00 ). I believe the mechanisms described in section 2 and the SPUD prototype protocol could be vulnerable to something like a classic SYN attack. That is an attacker could spoof open commands in an attempt to DOS at the middlebox. Part of the defense against this attack is to do 3-WHS. This might be already implied in the draft at "This, together with the first packet following the confirmation, provides a guarantee of return routability", but this isn't sufficient if the attacker can also spoof that first packet following the confirmation. A solution is to have the receiver (target) set part of the tube ID which an attacker could not predict (this is analogous the requirement that both SYN and ACK numbers must be synchronized before moving to Established state in TCP). Please look at draft-herbert-gue-session-id-00 for more on this. "A SPUD endpoint receiving a SPUD header with timeout information should reflect this information to the sender". This is a good example of the trust problem. Why would we trust an endpoint to do this correctly? Maybe they just always return the smallest possible value instead without any regard to the cost at the sender or its network for sending frequent heart beats. In this case, I think it would be better for the middlebox (local to the sender) to return the timeout information to the sender using an out of band protocol. Also, this might not be needed for every flow, in the common case of a node being behind a single firewall getting the value once would probably suffice. "Therefore it has to send heartbeat fairly rapidly, or might assume a default value of 150ms that is commonly used today." Where does this value come from? Couldn't such a rate kill battery on a mobile device? "An application does not benefit from wronly indicating loss- or latency-sensitivity" Typo :-)... The question here is what are the consequences if traffic is incorrectly marked. If mis-marking packets can adversely affect other non-related flows then this mechanism potentially becomes the basis for a DoS attack. For example, if someone arbitrarily decides to mark all their packets as low latency, increasing the latency of other flows or even worse increasing packet loss for other correctly marked low latency traffic would be a problem. Tom > Brian and Mirja > > > >> Anfang der weitergeleiteten Nachricht: >> >> Von: internet-drafts@ietf.org >> Betreff: New Version Notification for draft-kuehlewind-spud-use-cases-00= .txt >> Datum: 3. Juli 2015 17:19:10 MESZ >> An: "Mirja Kuehlewind" , "Mirja Kuehlew= ind" , "Brian Trammell" = , "Brian Trammell" >> >> >> A new version of I-D, draft-kuehlewind-spud-use-cases-00.txt >> has been successfully submitted by Mirja Kuehlewind and posted to the >> IETF repository. >> >> Name: draft-kuehlewind-spud-use-cases >> Revision: 00 >> Title: SPUD Use Cases >> Document date: 2015-07-03 >> Group: Individual Submission >> Pages: 15 >> URL: https://www.ietf.org/internet-drafts/draft-kuehlewind-sp= ud-use-cases-00.txt >> Status: https://datatracker.ietf.org/doc/draft-kuehlewind-spud-u= se-cases/ >> Htmlized: https://tools.ietf.org/html/draft-kuehlewind-spud-use-ca= ses-00 >> >> >> Abstract: >> The Substrate Protocol for User Datagrams (SPUD) BoF session at the >> IETF 92 meeting in Dallas in March 2015 identified the potential need >> for a UDP-based encapsulation protocol to allow explicit cooperation >> with middleboxes while using new, encrypted transport protocols. >> This document summarizes the use cases discuss at the BoF and thereby >> proposes a structure for the description of further use cases. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon Jul 6 10:37:56 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3E41A0393 for ; Mon, 6 Jul 2015 10:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 GmxfWcIxYJqa for ; Mon, 6 Jul 2015 10:37:54 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A691A0354 for ; Mon, 6 Jul 2015 10:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1615; q=dns/txt; s=iport; t=1436204274; x=1437413874; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uGoXrb41/Ed1kFaaJmCNRIX64l21Bi8X3epGSQz56dw=; b=V6edq2NABQ7VhxCQ8JHVJsM+hrNVezvgAkc9hAkpX0VqWHCtBv7c46ac r7EFAhKKLuldWStzapdeJRKxevJAM1WI15ns93938POoP0/aTQVYqfmZX MJcRE4Wf7QrOOMfepR276cgQ88LjuWLh2silu6KN732EO1hmktIIHXhlS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnAwBZvJpV/4gNJK1cgxJUYAa9VwmBboV3AoE4OBQBAQEBAQEBgQqEJAEBBDo/EAIBCA4KHhAhESUCBAENBYgZAxINxWMNhWgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItLgk2COQeEKwEElBUBigKBZZE5hx0mg3tvgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,415,1432598400"; d="scan'208";a="13035342" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jul 2015 17:37:53 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t66HbrM3006376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jul 2015 17:37:53 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 12:37:52 -0500 From: "Charles Eckel (eckelcu)" To: Brian Trammell , Aaron Falk Thread-Topic: [Spud] meeting in Prague? Thread-Index: AQHQtM5LFfC4K6ONGEKOQYaf2gFiMZ3KEKIAgAS7L4A= Date: Mon, 6 Jul 2015 17:37:52 +0000 Message-ID: References: <01659EBB-E426-44A1-BD85-463312CC3709@trammell.ch> In-Reply-To: <01659EBB-E426-44A1-BD85-463312CC3709@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.82.218.152] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] meeting in Prague? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 17:37:55 -0000 SPUD is also on the list of technologies included for the hackathon: https://www.ietf.org/registration/MeetingWiki/wiki/93hackathon Cheers, Charles On 7/3/15, 9:21 AM, "Spud on behalf of Brian Trammell" wrote: >hi Aaron, > >Apologies for not answering this question in advance on the list. > >> On 02 Jul 2015, at 15:52, Aaron Falk wrote: >>=20 >> I see there is no SPUD BoF scheduled in Prague. Will it be on the >>agenda of another meeting? Will there be informal meetings? > >There is not a BoF or formal meeting scheduled. In our (BoF proponents') >opinion, there is not yet enough clarity on what an eventual WG charter >would look like to hold a WG-forming BoF, nor a coherent enough statement >of a research question to try to form an RG. > >A group of us (mainly BoF proponents and presenters) are working on a >document outlining potential requirements for transport encapsulation >with middlebox cooperation. We plan to submit this Real Soon Now, >definitely before the Monday deadline. This document is very much a work >in progress -- musings on open questions take up more space than things >we think are definite requirements -- but we have tried to capture what >we've heard in the ongoing discussion into a coherent basis for further >discussion. > >We hope this document to trigger both list and hallway discussions in >Prague. The contributors to this document will also meet in Prague on the >Saturday before the IETF to work on the next revision of it. > >Cheers, > >Brian From nobody Tue Jul 7 03:44:43 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7516E1A89FA for ; Tue, 7 Jul 2015 03:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 j7k_Nnm0iLFa for ; Tue, 7 Jul 2015 03:44:39 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6AADD1A89A1 for ; Tue, 7 Jul 2015 03:44:39 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 159DA1A001C for ; Tue, 7 Jul 2015 12:44:38 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_53110BA4-A734-4B9E-A869-512890EFB954"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 7 Jul 2015 12:44:40 +0200 References: <20150706211605.21421.53970.idtracker@ietfa.amsl.com> To: spud@ietf.org Message-Id: <204D1558-3215-4E66-8BBA-B7F8B731DB29@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Spud] Fwd: New Version Notification for draft-trammell-spud-req-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 10:44:41 -0000 --Apple-Mail=_53110BA4-A734-4B9E-A869-512890EFB954 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We have submitted a first pass at a requirements document for a SPUD = protocol, attempting to capture the things we think we have as = functional and nonfunctional requirements (sections 5 and 6 = respectively), as well as a discussion of the tradeoffs involved in the = open questions (section 7). We've tried to capture discussion in Dallas = and subsequently on the list, and intend this document to help = facilitate discussions on an (eventual) set of requirements to do some = engineering around. Cheers, Brian and Mirja (for the contributors to draft-trammell-spud-req). > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-trammell-spud-req-00.txt > Date: 6 Jul 2015 23:16:05 CEST > To: "Mirja Kuehlewind" , "Mirja = Kuehlewind" , "Brian Trammell" = , "Brian Trammell" >=20 >=20 > A new version of I-D, draft-trammell-spud-req-00.txt > has been successfully submitted by Mirja Kuehlewind and posted to the > IETF repository. >=20 > Name: draft-trammell-spud-req > Revision: 00 > Title: Requirements for the design of a Substrate = Protocol for User Datagrams (SPUD) > Document date: 2015-07-06 > Group: Individual Submission > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-trammell-spud-req-00.txt > Status: = https://datatracker.ietf.org/doc/draft-trammell-spud-req/ > Htmlized: https://tools.ietf.org/html/draft-trammell-spud-req-00 >=20 >=20 > Abstract: > The Substrate Protocol for User Datagrams (SPUD) BoF session at the > IETF 92 meeting in Dallas in March 2015 identified the potential = need > for a UDP-based encapsulation protocol to allow explicit cooperation > with middleboxes while using new, encrypted transport protocols. > This document proposes an initial set of requirements for such a > protocol, and discusses tradeoffs to be made in further refining > these requirements. >=20 >=20 >=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 > The IETF Secretariat >=20 --Apple-Mail=_53110BA4-A734-4B9E-A869-512890EFB954 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVm62YAAoJENt3nsOmbNJcB/UH/3NcdiW2M76Uqq/aaIZEIKmX f2XVkv7wPPgNyO3Mjul85AFGiAg2Wzd0uVMoYNeQk5NxcPizH2ZZQGjydprIPLDR XTzi/SqaLRDLCLYmchJRiEKETVjVRLuDH1/QD/ZyVymb10wj69271VY8GJf0j7he RXJKMcYoTlsVrz3s8W12BuphJ2UA82ZQ+S6M5L/QI0NSKbcGpe1Gj2uK3bnE62Eu PyrZYUAYQ3SC4lSiTwYvpMxHI5F7ng5BzI1dGJGs1i5kq6xSPFiI4OiJcggrD2o9 cblGuX6EMPUx9jPXwu3DriPG7tCpzTOopFeV/nqj7DNX1ZXxkjtzc2NzMqXnRgc= =jYkg -----END PGP SIGNATURE----- --Apple-Mail=_53110BA4-A734-4B9E-A869-512890EFB954-- From nobody Tue Jul 7 03:53:42 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D63B1A8A80 for ; Tue, 7 Jul 2015 03:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 zLkfCQnyYPuX for ; Tue, 7 Jul 2015 03:53:39 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C031A8A6E for ; Tue, 7 Jul 2015 03:53:38 -0700 (PDT) Received: from [195.245.230.51] by server-5.bemta-3.messagelabs.com id 26/B3-23832-0BFAB955; Tue, 07 Jul 2015 10:53:36 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-11.tower-33.messagelabs.com!1436266414!16443710!1 X-Originating-IP: [195.232.244.133] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23756 invoked from network); 7 Jul 2015 10:53:34 -0000 Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-11.tower-33.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2015 10:53:34 -0000 Received: from mailint02.vodafone.com (mailint02.vodafone.com [195.232.244.199]) by mailout01.vodafone.com (Postfix) with ESMTP id 3mQgbx3mGvz1yBs; Tue, 7 Jul 2015 12:53:33 +0200 (CEST) Received: from mailint02.vodafone.com (localhost [127.0.0.1]) by mailint02.vodafone.com (Postfix) with ESMTP id 3mQgbx2CNbzQkYq; Tue, 7 Jul 2015 12:53:33 +0200 (CEST) Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint02.vodafone.com (Postfix) with ESMTPS id 3mQgbx1ng1zQkTv; Tue, 7 Jul 2015 12:53:33 +0200 (CEST) Received: from VOEXC10W.internal.vodafone.com (145.230.101.30) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 7 Jul 2015 12:53:32 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.243]) by VOEXC10W.internal.vodafone.com ([145.230.101.30]) with mapi id 14.03.0224.002; Tue, 7 Jul 2015 12:53:31 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: Tom Herbert , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt Thread-Index: AQHQuBANlPwiiTUrOEWZ7lNEHmDa953P0sPw Date: Tue, 7 Jul 2015 10:53:29 +0000 Message-ID: References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 10:53:42 -0000 SGkgVG9tLCBNaXJqYSwNCg0KPiAgSXQgc2VlbXMgdG8gbWUgdGhlcmUgYXJlIHR3byBtb3RpdmF0 aW9ucyBmb3IgU1BVRDoNCg0KPiAxKSBBIGNvbW1vbiBwcm90b2NvbCBsYXllciBmb3IgVURQIGZs b3cgYmFzZWQgcHJvdG9jb2xzIHRvIHBhc3MgdGhyb3VnaCBzdGF0ZWZ1bCBmaXJld2FsbHMgYW5k IE5BVC4NCj4gMikgQSByaWNoIGluYmFuZCBmbG93IGJhc2VkIFFvUyBzaWduYWxpbmcgaW5pdGlh dGVkIGJ5IGVuZCBob3N0cyB3aGljaCBjYW4gYmUgaW50ZXJwcmV0ZWQgYnkgbmV0d29yayBkZXZp Y2VzIGluIHRoZSBwYXRoLg0KDQpJJ2QgYWxzbyBzdWdnZXN0IHRoaXMgbW90aXZhdGlvbg0KICgz KSBJbmJhbmQgc2lnbmFsaW5nIG9mIGhpbnRzIGZyb20gbmV0d29yayBkZXZpY2VzIGluIHRoZSBw YXRoIHRvd2FyZHMgZW5kcG9pbnRzIGFuZC9vciBlYWNoIG90aGVyDQoNClRoaXMgd291bGQgYWxs b3cgKGZvciBleGFtcGxlKSBhIHJhZGlvIG5ldHdvcmsgbm9kZSB0byBwcm92aWRlIGhpbnRzIG9u IGNlbGwgY29uZ2VzdGlvbiB0b3dhcmRzIHRoZSBlbmRwb2ludHMsIHRoYXQgbWF5IGJlIHVzZWQg dG8gcGFjZSB0aGUgY29udGVudCBmbG93IGFjY29yZGluZ2x5LiBUaGVzZSB3b3VsZCByZW1haW4g aGludHMgYW5kIG5vdCBkaXJlY3RpdmVzLCBhbmQgd291bGQgcmVxdWlyZSBhdXRoZW50aWNhdGlv bi4gQXMgVG9tIHNheXMsIGEga2V5IHF1ZXN0aW9uIGlzIHRoZSB3aGV0aGVyIHRvIGNvbnNpZGVy IElQIGxheWVyIGV4dGVuc2lvbnMsIGhvd2V2ZXIgSSBzdXNwZWN0IHRoZXJlIG1heSBiZSBzb21l IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIHdoZXJlYnkgcm91dGVycyBkaXNjYXJkIElQIG9wdGlv bnMsIGFuZCBJQ01QIGlzIHNvdXJjZS1kZXN0aW5hdGlvbiBvbmx5LiBJZiBTUFVEIGNhbiBpbmRl ZWQgcnVuIHVuZGVyIFRDUCB0aGVuIHRoYXQgbWFrZXMgaXQgYSBtb3JlIGF0dHJhY3RpdmUgb3B0 aW9uIElNTy4NCg0KQWxsIGJlc3QNCktldmluDQoNCktldmluIFNtaXRoLCBWb2RhZm9uZSBSJkQN Cg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNwdWQgW21haWx0bzpz cHVkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb20gSGVyYmVydA0KU2VudDogMDYg SnVseSAyMDE1IDE4OjIwDQpUbzogTWlyamEgS8O8aGxld2luZA0KQ2M6IEJyaWFuIFRyYW1tZWxs OyBzcHVkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NwdWRdIEZ3ZDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1rdWVobGV3aW5kLXNwdWQtdXNlLWNhc2VzLTAwLnR4dA0KDQpP biBGcmksIEp1bCAzLCAyMDE1IGF0IDg6MjQgQU0sIE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1 ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+IHdyb3RlOg0KPiBIaSBhbGwsDQo+DQo+IHdl4oCZdmUg anVzdCBzdWJtaXR0ZWQgYSBuZXcgdXNlIGNhc2UgZG9jdW1lbnQuIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGluIG1vcmUgZGV0YWlsIHRoZSB1c2UgY2FzZXMgYXMgYWxyZWFkeSBwcmVzZW50ZWQv ZGlzY3Vzc2VkIGF0IHRoZSBCb0YuDQo+DQo+IFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuIEFs c28gcGFydGlhbCByZXZpZXdzIG9mIGUuZy4ganVzdCBvbmUgdXNlIGNhc2UgYXJlIG1vcmUgdGhh biB3ZWxjb21lLiBGdXJ0aGVyIGlmIHlvdeKAmWQgbGlrZSB0byBjb250cmlidXRlIHRvIHRoaXMg ZG9jdW1lbnQsIHBsZWFzZSBsZXQgdXNlIGtub3cgYXMgd2VsbC4NCj4NCkhpIE1pcmphLCB0aGFu a3MgZm9yIHRoZSBkcmFmdCEgSGVyZSBhcmUgbXkgY29tbWVudHMuDQoNCkdlbmVyYWwgY29tbWVu dHM6DQoNCkl0IHNlZW1zIHRvIG1lIHRoZXJlIGFyZSB0d28gbW90aXZhdGlvbnMgZm9yIFNQVUQ6 DQoNCjEpIEEgY29tbW9uIHByb3RvY29sIGxheWVyIGZvciBVRFAgZmxvdyBiYXNlZCBwcm90b2Nv bHMgdG8gcGFzcyB0aHJvdWdoIHN0YXRlZnVsIGZpcmV3YWxscyBhbmQgTkFULg0KMikgQSByaWNo IGluYmFuZCBmbG93IGJhc2VkIFFvUyBzaWduYWxpbmcgaW5pdGlhdGVkIGJ5IGVuZCBob3N0cyB3 aGljaCBjYW4gYmUgaW50ZXJwcmV0ZWQgYnkgbmV0d29yayBkZXZpY2VzIGluIHRoZSBwYXRoLg0K DQpUaGUgZmlyc3QgbW90aXZhdGlvbiBzZWVtcyBwcmV0dHkgY2xlYXIsIHRoZSBpbmFiaWxpdHkg dG8gcGFzcyBVRFAgKHJlYWxseSBhbnl0aGluZyBiZXNpZGVzIFRDUCkgdGhyb3VnaCBzdGF0ZWZ1 bCBmaXJld2FsbHMgaGFzIGltcGVkZWQgZGVwbG95bWVudCBvZiBuZXcgTDQgcHJvdG9jb2xzLg0K DQpUaGUgc2Vjb25kIG1vdGl2YXRpb24gaXMgbGVzcyBjbGVhci4gRGlzcmVnYXJkaW5nIHByZXZp b3VzbHkgcmFpc2VkIHF1ZXN0aW9ucyBhcm91bmQgbmV3IERvUyB2ZWN0b3JzIGFuZCB3aGV0aGVy IHdlIGNhbiBldmVyIHRydXN0IGFueXRoaW5nIGFueW9uZSBzYXlzIG9uIHRoZSBJbnRlcm5ldCwg SSB3b3VsZCBhc2sgaWYgU1BVRCAoVURQKSBpcyB0aGUgcmlnaHQgbGF5ZXIgZm9yIHRoaXMuIFRo ZSBuZWVkIGZvciB0aGlzIHNpZ25hbGluZyBkb2Vzbid0IHNlZW0gdG8gYmUgc3BlY2lmaWMgdG8g VURQIHRyYW5zcG9ydCBwcm90b2NvbHMsIGJ1dCBhbHNvIHNob3VsZCBhcHBsaWNhYmxlIHRvIFRD UCwgU0NUUCwgYW5kIG90aGVyIHByb3RvY29scy4gQmFycmluZyB0aGF0IHRoZXNlIHByb3RvY29s cyB0cmFuc2l0aW9uIHRvIHJ1bm5pbmcgb3ZlciBTUFVEICh1bmxpa2VseSBpbiB0aGUgZm9yZXNl ZWFibGUgZnV0dXJlKSwgaXQgc2VlbXMgbGlrZSBzdWNoIHNpZ25hbGluZyBzaG91bGQgYmUgaW1w bGVtZW50ZWQgaW4gYSBtb3JlIGNvbW1vbiBsYXllciwgbWF5YmUgc29tZXRoaW5nIGxpa2UgSVAg b3B0aW9ucy4NCg0KQW5vdGhlciBnZW5lcmFsIHF1ZXN0aW9uIEkgaGF2ZSBpcyBob3cgbXVjaCBs ZWV3YXkgc2hvdWxkIGJlIHRha2VuIGluIHJlbGF4aW5nIG9yIG1vZGlmeWluZyB0aGUgZW5kLXRv LWVuZCBzZW1hbnRpY3Mgb2YgVURQLiBJbiBwYXJ0aWN1bGFyLCBJIHRoaW5rIGFuIGltcG9ydGFu dCBxdWVzdGlvbiBpcyByYXRoZXIgbWlkZGxlYm94ZXMgc2hvdWxkIGJlIG1vZGlmeWluZyBVRFAg cGF5bG9hZHMuIFdlJ3ZlIGFjY2VwdGVkIHRoYXQgTkFUIGRldmljZXMgY2FuIG1vZGlmeSBVRFAg cG9ydCBudW1iZXJzLCBidXQgbXVja2luZyB3aXRoIHRoZSBwYXlsb2FkIHNlZW1zIHdvcnNlIHRv IG1lLiBUaGlzIG1ha2VzIGVuZC10by1lbmQgYXV0aGVudGljYXRpb24gb3IgaW50ZWdyaXR5IGNo ZWNrcyBtdWNoIG1vcmUgZGlmZmljdWx0LCBhbmQgaWYgYSBwYWNrZXQgaXMgZXZlciBtaXNjbGFz c2lmaWVkIGFzIFNQVUQgdGhpcyBjb3VsZCByZXN1bHQgaW4gZGF0YSBjb3JydXB0aW9uLiBUaGlz IGlzc3VlIGFsc28gY29tZXMgdXAgaW4gb3RoZXIgcHJvcG9zYWxzLCBzdWNoIGFzIEJJRVIsIGJ1 dCB0aG9zZSBzZWVtIGhhdmUgbW9yZSBuYXJyb3cgYXBwbGljYXRpb24gKGkuZS4gZm9yIG11bHRp Y2FzdCwgZGVwbG95ZWQgaW4gY2xvc2VkIG5ldHdvcmsgbm90IHRoZSBJbnRlcm5ldCBhcyBTUFVE IGlzIGludGVuZGVkKS4NCg0KPiBGb3IgZXZlcnlib2R5IHdobyBwb3RlbnRpYWxseSBoYXMgYWRk aXRpb25hbCB1c2UgY2FzZXMgaW4gbWluZCwgSSBwZXJzb25hbGx5IHdvdWxkIGFwcHJlY2lhdGUg dG8gc2VlIGZ1dHVyZSB1c2UgY2FzZSBkZXNjcmlwdGlvbnMgd2l0aCBhIHNpbWlsYXIgc3RydWN0 dXJlIHRoYW4gdXNlIGluIHRoaXMgZG9jdW1lbnQuIEluIGZvdW5kIGl0IHZlcnkgaGVscGZ1bCB0 byBjYXB0dXJlIHRoZSBtb3N0IGltcG9ydGFudCBwb2ludHMuIEhvd2V2ZXIsIHRoaXMgc3RydWN0 dXJlIGlzIGFsc28gb3BlbiBmb3IgZGlzY3Vzc2lvbi4NCj4NClVzZSBvZiBTUFVEIHdpdGggTkFU IHNob3VsZCBwcm9iYWJseSBiZSBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0Lg0KDQpJdCBtaWdodCBi ZSB3b3J0aHdoaWxlIHRvIGNvbnNpZGVyIHNvbWUgbW9yZSBzcGVjaWZpYyBhcHBsaWNhdGlvbnMg b2YgZmlyZXdhbGxzLiBGb3IgZXhhbXBsZSwgaWYgYSBmaXJld2FsbCBpcyBkZXBsb3llZCBiZXR3 ZWVuIGEgc2l0ZSBhbmQgdGhlIEludGVybmV0LCB3ZSBtaWdodCBiZSBtb3JlIGluY2xpbmVkIHRv IHRydXN0IFNQVUQgZGlyZWN0aXZlcyByZWNlaXZlZCBmcm9tIHRoZSBpbnRlcm5hbCBuZXR3b3Jr IGFzIG9wcG9zZWQgdG8gdGhlIEludGVybmV0Lg0KDQpBbm90aGVyIHBvdGVudGlhbCB1c2UgY2Fz ZSB0byBpbnZlc3RpZ2F0ZSB3b3VsZCBiZSBtb2JpbGUgZGV2aWNlcyBiZWhpbmQgYSBtaWRkbGVi b3guDQoNCkNvbW1lbnRzIG9uIHRoZSBkcmFmdDoNCg0KIlRoaXMgc3RhdGUgc2hvdWxkIGJlIGJv dW5kIHRvIHNvbWV0aGluZyBiZXlvbmQgdGhlIGZpdmUtdHVwbGUgdG8gbGluayBwYWNrZXRzIHRv Z2V0aGVyLiIgcXVlc3Rpb24gaGVyZSBvZiB3aGV0aGVyIFVEUCBzb3VyY2Ugc2hvdWxkIGJlIHBh cnQgb2YgaWRlbnRpZnlpbmcgdHVwbGUuIFVEUCBlbmNhcHN1bGF0aW9uIHByb3RvY29scyBhcmUg ZGVmaW5pbmcgc291cmNlIHBvcnQgYXMgYW4gZW50cm9weSBmaWVsZCBmb3IgRUNNUCwgc28gaXQg bWlnaHQgYmUgZ29vZCB0byB0YWtlIG91dCBzb3VyY2UgcG9ydCBpbiB0aGUgdHVwbGUuDQoNCiJG dXJ0aGVyLCB0byBtYWludGFpbiBzdGF0ZSwgdGhlIHNlbmRlciBtdXN0IGV4cGxpY2l0bHkgaW5k aWNhdGUgdGhlIHN0YXJ0IGFuZCBlbmQgb2YgYSB0dWJlIHRvIHRoZSBwYXRoLCB3aGlsZSB0aGUg cmVjZWl2ZXIgbXVzdCBjb25maXJtIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudC4iLiBTZW5kZXIg YW5kIHJlY2VpdmVyIG1pZ2h0IGJlIGFtYmlndW91cyB0ZXJtcywgSSBsaWtlIGluaXRpYXRvciBh bmQgdGFyZ2V0IGlmIHRoaXMgaXMgbWVhbnQgdG8gaW5kaWNhdGUgcGVyc3BlY3RpdmUgcm9sZXMg aW4gdGhlIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudC4gIEFuIGFsdGVybmF0aXZlIG1vZGUgY291 bGQgYmUgIHJlcXVlc3QvcmVzcG9uc2UgY29tbXVuaWNhdGlvbiB3aGVyZSB0aGUgcmVxdWVzdCBj cmVhdGVzIHRoZSBzdGF0ZSBhbmQgdGhlIHJlc3BvbnNlIGNsb3NlcyBpdCAodGhpcyBpcyBkZXNj cmliZWQgaW4NCmRyYWZ0LWhlcmJlcnQtZ3VlLXNlc3Npb24taWQtMDAgKS4NCg0KSSBiZWxpZXZl IHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIgYW5kIHRoZSBTUFVEIHByb3Rv dHlwZSBwcm90b2NvbCBjb3VsZCBiZSB2dWxuZXJhYmxlIHRvIHNvbWV0aGluZyBsaWtlIGEgY2xh c3NpYyBTWU4gYXR0YWNrLg0KVGhhdCBpcyBhbiBhdHRhY2tlciBjb3VsZCBzcG9vZiBvcGVuIGNv bW1hbmRzIGluIGFuIGF0dGVtcHQgdG8gRE9TIGF0IHRoZSBtaWRkbGVib3guIFBhcnQgb2YgdGhl IGRlZmVuc2UgYWdhaW5zdCB0aGlzIGF0dGFjayBpcyB0byBkbyAzLVdIUy4NClRoaXMgbWlnaHQg YmUgYWxyZWFkeSBpbXBsaWVkIGluIHRoZSBkcmFmdCBhdCAiVGhpcywgdG9nZXRoZXIgd2l0aCB0 aGUgZmlyc3QgcGFja2V0IGZvbGxvd2luZyB0aGUgY29uZmlybWF0aW9uLCBwcm92aWRlcyBhIGd1 YXJhbnRlZSBvZiByZXR1cm4gcm91dGFiaWxpdHkiLCBidXQgdGhpcyBpc24ndCBzdWZmaWNpZW50 IGlmIHRoZSBhdHRhY2tlciBjYW4gYWxzbyBzcG9vZiB0aGF0IGZpcnN0IHBhY2tldCBmb2xsb3dp bmcgdGhlIGNvbmZpcm1hdGlvbi4gQSBzb2x1dGlvbiBpcyB0byBoYXZlIHRoZSByZWNlaXZlciAo dGFyZ2V0KSBzZXQgcGFydCBvZiB0aGUgdHViZSBJRCB3aGljaCBhbiBhdHRhY2tlciBjb3VsZCBu b3QgcHJlZGljdCAodGhpcyBpcyBhbmFsb2dvdXMgdGhlIHJlcXVpcmVtZW50IHRoYXQgYm90aCBT WU4gYW5kIEFDSyBudW1iZXJzIG11c3QgYmUgc3luY2hyb25pemVkIGJlZm9yZSBtb3ZpbmcgdG8g RXN0YWJsaXNoZWQgc3RhdGUgaW4gVENQKS4gUGxlYXNlIGxvb2sgYXQNCmRyYWZ0LWhlcmJlcnQt Z3VlLXNlc3Npb24taWQtMDAgZm9yIG1vcmUgb24gdGhpcy4NCg0KIkEgU1BVRCBlbmRwb2ludCBy ZWNlaXZpbmcgYSBTUFVEIGhlYWRlciB3aXRoIHRpbWVvdXQgaW5mb3JtYXRpb24gc2hvdWxkIHJl ZmxlY3QgdGhpcyBpbmZvcm1hdGlvbiB0byB0aGUgc2VuZGVyIi4gVGhpcyBpcyBhIGdvb2QgZXhh bXBsZSBvZiB0aGUgdHJ1c3QgcHJvYmxlbS4gV2h5IHdvdWxkIHdlIHRydXN0IGFuIGVuZHBvaW50 IHRvIGRvIHRoaXMgY29ycmVjdGx5PyBNYXliZSB0aGV5IGp1c3QgYWx3YXlzIHJldHVybiB0aGUg c21hbGxlc3QgcG9zc2libGUgdmFsdWUgaW5zdGVhZCB3aXRob3V0IGFueSByZWdhcmQgdG8gdGhl IGNvc3QgYXQgdGhlIHNlbmRlciBvciBpdHMgbmV0d29yayBmb3Igc2VuZGluZyBmcmVxdWVudCBo ZWFydCBiZWF0cy4gSW4gdGhpcyBjYXNlLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciBmb3Ig dGhlIG1pZGRsZWJveCAobG9jYWwgdG8gdGhlIHNlbmRlcikgdG8gcmV0dXJuIHRoZSB0aW1lb3V0 IGluZm9ybWF0aW9uIHRvIHRoZSBzZW5kZXIgdXNpbmcgYW4gb3V0IG9mIGJhbmQgcHJvdG9jb2wu IEFsc28sIHRoaXMgbWlnaHQgbm90IGJlIG5lZWRlZCBmb3IgZXZlcnkgZmxvdywgaW4gdGhlIGNv bW1vbiBjYXNlIG9mIGEgbm9kZSBiZWluZyBiZWhpbmQgYSBzaW5nbGUgZmlyZXdhbGwgZ2V0dGlu ZyB0aGUgdmFsdWUgb25jZSB3b3VsZCBwcm9iYWJseSBzdWZmaWNlLg0KDQoiVGhlcmVmb3JlIGl0 IGhhcyB0byBzZW5kIGhlYXJ0YmVhdCBmYWlybHkgcmFwaWRseSwgb3IgbWlnaHQgYXNzdW1lIGEg ZGVmYXVsdCB2YWx1ZSBvZiAxNTBtcyB0aGF0IGlzIGNvbW1vbmx5IHVzZWQgdG9kYXkuIiBXaGVy ZSBkb2VzIHRoaXMgdmFsdWUgY29tZSBmcm9tPyBDb3VsZG4ndCBzdWNoIGEgcmF0ZSBraWxsIGJh dHRlcnkgb24gYSBtb2JpbGUgZGV2aWNlPw0KDQoiQW4gYXBwbGljYXRpb24gZG9lcyBub3QgYmVu ZWZpdCBmcm9tIHdyb25seSBpbmRpY2F0aW5nIGxvc3MtIG9yIGxhdGVuY3ktc2Vuc2l0aXZpdHki IFR5cG8gOi0pLi4uIFRoZSBxdWVzdGlvbiBoZXJlIGlzIHdoYXQgYXJlIHRoZSBjb25zZXF1ZW5j ZXMgaWYgdHJhZmZpYyBpcyBpbmNvcnJlY3RseSBtYXJrZWQuIElmIG1pcy1tYXJraW5nIHBhY2tl dHMgY2FuIGFkdmVyc2VseSBhZmZlY3Qgb3RoZXIgbm9uLXJlbGF0ZWQgZmxvd3MgdGhlbiB0aGlz IG1lY2hhbmlzbSBwb3RlbnRpYWxseSBiZWNvbWVzIHRoZSBiYXNpcyBmb3IgYSBEb1MgYXR0YWNr LiBGb3IgZXhhbXBsZSwgaWYgc29tZW9uZSBhcmJpdHJhcmlseSBkZWNpZGVzIHRvIG1hcmsgYWxs IHRoZWlyIHBhY2tldHMgYXMgbG93IGxhdGVuY3ksIGluY3JlYXNpbmcgdGhlIGxhdGVuY3kgb2Yg b3RoZXIgZmxvd3Mgb3IgZXZlbiB3b3JzZSBpbmNyZWFzaW5nIHBhY2tldCBsb3NzIGZvciBvdGhl ciBjb3JyZWN0bHkgbWFya2VkIGxvdyBsYXRlbmN5IHRyYWZmaWMgd291bGQgYmUgYSBwcm9ibGVt Lg0KDQpUb20NCg0KDQoNCj4gQnJpYW4gYW5kIE1pcmphDQo+DQo+DQo+DQo+PiBBbmZhbmcgZGVy IHdlaXRlcmdlbGVpdGV0ZW4gTmFjaHJpY2h0Og0KPj4NCj4+IFZvbjogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnDQo+PiBCZXRyZWZmOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPj4g ZHJhZnQta3VlaGxld2luZC1zcHVkLXVzZS1jYXNlcy0wMC50eHQNCj4+IERhdHVtOiAzLiBKdWxp IDIwMTUgMTc6MTk6MTAgTUVTWg0KPj4gQW46ICJNaXJqYSBLdWVobGV3aW5kIiA8bWlyamEua3Vl aGxld2luZEB0aWsuZWUuZXRoei5jaD4sICJNaXJqYSANCj4+IEt1ZWhsZXdpbmQiIDxtaXJqYS5r dWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPiwgIkJyaWFuIFRyYW1tZWxsIiANCj4+IDxpZXRmQHRy YW1tZWxsLmNoPiwgIkJyaWFuIFRyYW1tZWxsIiA8aWV0ZkB0cmFtbWVsbC5jaD4NCj4+DQo+Pg0K Pj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWt1ZWhsZXdpbmQtc3B1ZC11c2UtY2FzZXMt MDAudHh0DQo+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1pcmphIEt1ZWhs ZXdpbmQgYW5kIHBvc3RlZCB0byB0aGUgDQo+PiBJRVRGIHJlcG9zaXRvcnkuDQo+Pg0KPj4gTmFt ZTogICAgICAgICBkcmFmdC1rdWVobGV3aW5kLXNwdWQtdXNlLWNhc2VzDQo+PiBSZXZpc2lvbjog ICAgIDAwDQo+PiBUaXRsZTogICAgICAgICAgICAgICAgU1BVRCBVc2UgQ2FzZXMNCj4+IERvY3Vt ZW50IGRhdGU6ICAgICAgICAyMDE1LTA3LTAzDQo+PiBHcm91cDogICAgICAgICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+PiBQYWdlczogICAgICAgICAgICAgICAgMTUNCj4+IFVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta3Vl aGxld2luZC1zcHVkLXVzZS1jYXNlcy0wMC50eHQNCj4+IFN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rdWVobGV3aW5kLXNwdWQtdXNlLWNhc2Vz Lw0KPj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1r dWVobGV3aW5kLXNwdWQtdXNlLWNhc2VzLTAwDQo+Pg0KPj4NCj4+IEFic3RyYWN0Og0KPj4gICBU aGUgU3Vic3RyYXRlIFByb3RvY29sIGZvciBVc2VyIERhdGFncmFtcyAoU1BVRCkgQm9GIHNlc3Np b24gYXQgdGhlDQo+PiAgIElFVEYgOTIgbWVldGluZyBpbiBEYWxsYXMgaW4gTWFyY2ggMjAxNSBp ZGVudGlmaWVkIHRoZSBwb3RlbnRpYWwgbmVlZA0KPj4gICBmb3IgYSBVRFAtYmFzZWQgZW5jYXBz dWxhdGlvbiBwcm90b2NvbCB0byBhbGxvdyBleHBsaWNpdCBjb29wZXJhdGlvbg0KPj4gICB3aXRo IG1pZGRsZWJveGVzIHdoaWxlIHVzaW5nIG5ldywgZW5jcnlwdGVkIHRyYW5zcG9ydCBwcm90b2Nv bHMuDQo+PiAgIFRoaXMgZG9jdW1lbnQgc3VtbWFyaXplcyB0aGUgdXNlIGNhc2VzIGRpc2N1c3Mg YXQgdGhlIEJvRiBhbmQgdGhlcmVieQ0KPj4gICBwcm9wb3NlcyBhIHN0cnVjdHVyZSBmb3IgdGhl IGRlc2NyaXB0aW9uIG9mIGZ1cnRoZXIgdXNlIGNhc2VzLg0KPj4NCj4+DQo+Pg0KPj4NCj4+IFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIA0KPj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4NCj4+IFRoZSBJRVRGIFNlY3Jl dGFyaWF0DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IFNwdWQgbWFpbGluZyBsaXN0DQo+IFNwdWRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpTcHVkIG1haWxpbmcgbGlzdA0KU3B1ZEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkDQo= From nobody Tue Jul 7 04:49:10 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723351ABD3C for ; Tue, 7 Jul 2015 04:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 GNQ4-2mOdCqb for ; Tue, 7 Jul 2015 04:49:05 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29571AC399 for ; Tue, 7 Jul 2015 04:49:04 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-e7-559bbcae2b0f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 70.7B.12828.EACBB955; Tue, 7 Jul 2015 13:49:03 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Tue, 7 Jul 2015 13:49:01 +0200 From: Szilveszter Nadas To: "Smith, Kevin, (R&D) Vodafone Group" , "Tom Herbert" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt Thread-Index: AQHQtaR4Bap8Sh/Wt06Aa/eTfpJZcZ3OkzaAgAEmSoCAAC8PMA== Date: Tue, 7 Jul 2015 11:49:01 +0000 Message-ID: References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGfG3Rnf9ntmhBh+rLTa2vGOzeHxzEZPF htVTWCwWXXjKaHH50iNmB1aP3rnTWD2WLPnJ5HHsw1c2jyf7Z7J49M1YzxjAGsVlk5Kak1mW WqRvl8CV8eHbX+aCe7kVx/7eY2pg/JLVxcjJISFgIrGnaykThC0mceHeerYuRi4OIYGjjBLL nneyQziLGCU+Tu1iBKliE7CQaFi5GaxKRGALo0TXs7msIAlmATeJlt+HmLsYOTiEBeIkVk2N AAmLCMRL3OhfzQ5hO0kc79zPDGKzCKhIvHm2igmknFfAV+LOEVOIXV1MEle/bga7iFMgTGLP xNlg9YxA130/tYYJYpW4xK0n86GuFpBYsuc8M4QtKvHy8T9WkJkSAkoS07amgZjMApoS63fp Q3QqSkzpfgh2Da+AoMTJmU9YJjCKzUIydBZCxywkHbOQdCxgZFnFKFqcWlycm25krJdalJlc XJyfp5eXWrKJERh1B7f81t3BuPq14yFGAQ5GJR7eBUazQ4VYE8uKK3MPMUpzsCiJ887YnBcq JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTHznMo+BplpwtO9pHT2vPn04pfkRZeXhTqqXKYX Yr6YOc348P5J9/y08+rL77LKLvj5voi7oik1/caR/4XfCqcUbu9q06yICbl49H5Ghm3V2ddG 1dOXrlea9ObAac2F2o4R30L0w6dZyfBaBld534rjEjdlKDum+n6rkZ0tU/v+lX1ezjUuz5VY ijMSDbWYi4oTAdzyeVibAgAA Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: Re: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 11:49:08 -0000 SGksDQoNCkkgYWdyZWUgd2l0aCAiSSBzdXNwZWN0IHRoZXJlIG1heSBiZSBzb21lIGludGVyb3Bl cmFiaWxpdHkgaXNzdWVzIHdoZXJlYnkgcm91dGVycyBkaXNjYXJkIElQIG9wdGlvbnMiLiBJdCBp cyBhbHNvIGhhcmQgZm9yIG1lIHRvIGltYWdpbmUgKDIpIHdpdGhvdXQgYXV0aGVudGljYXRpb24g aW4gbWFueSBjYXNlcy4gV2UgYWxzbyBoYXZlIG1vcmUgdXNlIGNhc2VzIGluIG1pbmQgZm9yICgy KSBhbmQgKDMpLCBidXQgSSBhbSBub3QgMTAwJSBzdXJlLCB3aGV0aGVyIHRoYXQgc3RpbGwgZml0 cyB0aGUgU1BVRCBzY29wZS4gSSB3aWxsIHNlbmQgdGhlIGRyYWZ0IGFib3V0IHRoYXQgc2hvcnRs eS4NCg0KQ2hlZXJzLA0KU3oNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNw dWQgW21haWx0bzpzcHVkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTbWl0aCwgS2V2 aW4sIChSJkQpIFZvZGFmb25lIEdyb3VwDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA3LCAyMDE1IDEy OjUzDQpUbzogVG9tIEhlcmJlcnQ7IE1pcmphIEvDvGhsZXdpbmQNCkNjOiBCcmlhbiBUcmFtbWVs bDsgc3B1ZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTcHVkXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQta3VlaGxld2luZC1zcHVkLXVzZS1jYXNlcy0wMC50eHQNCg0K SGkgVG9tLCBNaXJqYSwNCg0KPiAgSXQgc2VlbXMgdG8gbWUgdGhlcmUgYXJlIHR3byBtb3RpdmF0 aW9ucyBmb3IgU1BVRDoNCg0KPiAxKSBBIGNvbW1vbiBwcm90b2NvbCBsYXllciBmb3IgVURQIGZs b3cgYmFzZWQgcHJvdG9jb2xzIHRvIHBhc3MgdGhyb3VnaCBzdGF0ZWZ1bCBmaXJld2FsbHMgYW5k IE5BVC4NCj4gMikgQSByaWNoIGluYmFuZCBmbG93IGJhc2VkIFFvUyBzaWduYWxpbmcgaW5pdGlh dGVkIGJ5IGVuZCBob3N0cyB3aGljaCBjYW4gYmUgaW50ZXJwcmV0ZWQgYnkgbmV0d29yayBkZXZp Y2VzIGluIHRoZSBwYXRoLg0KDQpJJ2QgYWxzbyBzdWdnZXN0IHRoaXMgbW90aXZhdGlvbg0KICgz KSBJbmJhbmQgc2lnbmFsaW5nIG9mIGhpbnRzIGZyb20gbmV0d29yayBkZXZpY2VzIGluIHRoZSBw YXRoIHRvd2FyZHMgZW5kcG9pbnRzIGFuZC9vciBlYWNoIG90aGVyDQoNClRoaXMgd291bGQgYWxs b3cgKGZvciBleGFtcGxlKSBhIHJhZGlvIG5ldHdvcmsgbm9kZSB0byBwcm92aWRlIGhpbnRzIG9u IGNlbGwgY29uZ2VzdGlvbiB0b3dhcmRzIHRoZSBlbmRwb2ludHMsIHRoYXQgbWF5IGJlIHVzZWQg dG8gcGFjZSB0aGUgY29udGVudCBmbG93IGFjY29yZGluZ2x5LiBUaGVzZSB3b3VsZCByZW1haW4g aGludHMgYW5kIG5vdCBkaXJlY3RpdmVzLCBhbmQgd291bGQgcmVxdWlyZSBhdXRoZW50aWNhdGlv bi4gQXMgVG9tIHNheXMsIGEga2V5IHF1ZXN0aW9uIGlzIHRoZSB3aGV0aGVyIHRvIGNvbnNpZGVy IElQIGxheWVyIGV4dGVuc2lvbnMsIGhvd2V2ZXIgSSBzdXNwZWN0IHRoZXJlIG1heSBiZSBzb21l IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIHdoZXJlYnkgcm91dGVycyBkaXNjYXJkIElQIG9wdGlv bnMsIGFuZCBJQ01QIGlzIHNvdXJjZS1kZXN0aW5hdGlvbiBvbmx5LiBJZiBTUFVEIGNhbiBpbmRl ZWQgcnVuIHVuZGVyIFRDUCB0aGVuIHRoYXQgbWFrZXMgaXQgYSBtb3JlIGF0dHJhY3RpdmUgb3B0 aW9uIElNTy4NCg0KQWxsIGJlc3QNCktldmluDQoNCktldmluIFNtaXRoLCBWb2RhZm9uZSBSJkQN Cg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNwdWQgW21haWx0bzpz cHVkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb20gSGVyYmVydA0KU2VudDogMDYg SnVseSAyMDE1IDE4OjIwDQpUbzogTWlyamEgS8O8aGxld2luZA0KQ2M6IEJyaWFuIFRyYW1tZWxs OyBzcHVkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NwdWRdIEZ3ZDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1rdWVobGV3aW5kLXNwdWQtdXNlLWNhc2VzLTAwLnR4dA0KDQpP biBGcmksIEp1bCAzLCAyMDE1IGF0IDg6MjQgQU0sIE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1 ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+IHdyb3RlOg0KPiBIaSBhbGwsDQo+DQo+IHdl4oCZdmUg anVzdCBzdWJtaXR0ZWQgYSBuZXcgdXNlIGNhc2UgZG9jdW1lbnQuIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGluIG1vcmUgZGV0YWlsIHRoZSB1c2UgY2FzZXMgYXMgYWxyZWFkeSBwcmVzZW50ZWQv ZGlzY3Vzc2VkIGF0IHRoZSBCb0YuDQo+DQo+IFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuIEFs c28gcGFydGlhbCByZXZpZXdzIG9mIGUuZy4ganVzdCBvbmUgdXNlIGNhc2UgYXJlIG1vcmUgdGhh biB3ZWxjb21lLiBGdXJ0aGVyIGlmIHlvdeKAmWQgbGlrZSB0byBjb250cmlidXRlIHRvIHRoaXMg ZG9jdW1lbnQsIHBsZWFzZSBsZXQgdXNlIGtub3cgYXMgd2VsbC4NCj4NCkhpIE1pcmphLCB0aGFu a3MgZm9yIHRoZSBkcmFmdCEgSGVyZSBhcmUgbXkgY29tbWVudHMuDQoNCkdlbmVyYWwgY29tbWVu dHM6DQoNCkl0IHNlZW1zIHRvIG1lIHRoZXJlIGFyZSB0d28gbW90aXZhdGlvbnMgZm9yIFNQVUQ6 DQoNCjEpIEEgY29tbW9uIHByb3RvY29sIGxheWVyIGZvciBVRFAgZmxvdyBiYXNlZCBwcm90b2Nv bHMgdG8gcGFzcyB0aHJvdWdoIHN0YXRlZnVsIGZpcmV3YWxscyBhbmQgTkFULg0KMikgQSByaWNo IGluYmFuZCBmbG93IGJhc2VkIFFvUyBzaWduYWxpbmcgaW5pdGlhdGVkIGJ5IGVuZCBob3N0cyB3 aGljaCBjYW4gYmUgaW50ZXJwcmV0ZWQgYnkgbmV0d29yayBkZXZpY2VzIGluIHRoZSBwYXRoLg0K DQpUaGUgZmlyc3QgbW90aXZhdGlvbiBzZWVtcyBwcmV0dHkgY2xlYXIsIHRoZSBpbmFiaWxpdHkg dG8gcGFzcyBVRFAgKHJlYWxseSBhbnl0aGluZyBiZXNpZGVzIFRDUCkgdGhyb3VnaCBzdGF0ZWZ1 bCBmaXJld2FsbHMgaGFzIGltcGVkZWQgZGVwbG95bWVudCBvZiBuZXcgTDQgcHJvdG9jb2xzLg0K DQpUaGUgc2Vjb25kIG1vdGl2YXRpb24gaXMgbGVzcyBjbGVhci4gRGlzcmVnYXJkaW5nIHByZXZp b3VzbHkgcmFpc2VkIHF1ZXN0aW9ucyBhcm91bmQgbmV3IERvUyB2ZWN0b3JzIGFuZCB3aGV0aGVy IHdlIGNhbiBldmVyIHRydXN0IGFueXRoaW5nIGFueW9uZSBzYXlzIG9uIHRoZSBJbnRlcm5ldCwg SSB3b3VsZCBhc2sgaWYgU1BVRCAoVURQKSBpcyB0aGUgcmlnaHQgbGF5ZXIgZm9yIHRoaXMuIFRo ZSBuZWVkIGZvciB0aGlzIHNpZ25hbGluZyBkb2Vzbid0IHNlZW0gdG8gYmUgc3BlY2lmaWMgdG8g VURQIHRyYW5zcG9ydCBwcm90b2NvbHMsIGJ1dCBhbHNvIHNob3VsZCBhcHBsaWNhYmxlIHRvIFRD UCwgU0NUUCwgYW5kIG90aGVyIHByb3RvY29scy4gQmFycmluZyB0aGF0IHRoZXNlIHByb3RvY29s cyB0cmFuc2l0aW9uIHRvIHJ1bm5pbmcgb3ZlciBTUFVEICh1bmxpa2VseSBpbiB0aGUgZm9yZXNl ZWFibGUgZnV0dXJlKSwgaXQgc2VlbXMgbGlrZSBzdWNoIHNpZ25hbGluZyBzaG91bGQgYmUgaW1w bGVtZW50ZWQgaW4gYSBtb3JlIGNvbW1vbiBsYXllciwgbWF5YmUgc29tZXRoaW5nIGxpa2UgSVAg b3B0aW9ucy4NCg0KQW5vdGhlciBnZW5lcmFsIHF1ZXN0aW9uIEkgaGF2ZSBpcyBob3cgbXVjaCBs ZWV3YXkgc2hvdWxkIGJlIHRha2VuIGluIHJlbGF4aW5nIG9yIG1vZGlmeWluZyB0aGUgZW5kLXRv LWVuZCBzZW1hbnRpY3Mgb2YgVURQLiBJbiBwYXJ0aWN1bGFyLCBJIHRoaW5rIGFuIGltcG9ydGFu dCBxdWVzdGlvbiBpcyByYXRoZXIgbWlkZGxlYm94ZXMgc2hvdWxkIGJlIG1vZGlmeWluZyBVRFAg cGF5bG9hZHMuIFdlJ3ZlIGFjY2VwdGVkIHRoYXQgTkFUIGRldmljZXMgY2FuIG1vZGlmeSBVRFAg cG9ydCBudW1iZXJzLCBidXQgbXVja2luZyB3aXRoIHRoZSBwYXlsb2FkIHNlZW1zIHdvcnNlIHRv IG1lLiBUaGlzIG1ha2VzIGVuZC10by1lbmQgYXV0aGVudGljYXRpb24gb3IgaW50ZWdyaXR5IGNo ZWNrcyBtdWNoIG1vcmUgZGlmZmljdWx0LCBhbmQgaWYgYSBwYWNrZXQgaXMgZXZlciBtaXNjbGFz c2lmaWVkIGFzIFNQVUQgdGhpcyBjb3VsZCByZXN1bHQgaW4gZGF0YSBjb3JydXB0aW9uLiBUaGlz IGlzc3VlIGFsc28gY29tZXMgdXAgaW4gb3RoZXIgcHJvcG9zYWxzLCBzdWNoIGFzIEJJRVIsIGJ1 dCB0aG9zZSBzZWVtIGhhdmUgbW9yZSBuYXJyb3cgYXBwbGljYXRpb24gKGkuZS4gZm9yIG11bHRp Y2FzdCwgZGVwbG95ZWQgaW4gY2xvc2VkIG5ldHdvcmsgbm90IHRoZSBJbnRlcm5ldCBhcyBTUFVE IGlzIGludGVuZGVkKS4NCg0KPiBGb3IgZXZlcnlib2R5IHdobyBwb3RlbnRpYWxseSBoYXMgYWRk aXRpb25hbCB1c2UgY2FzZXMgaW4gbWluZCwgSSBwZXJzb25hbGx5IHdvdWxkIGFwcHJlY2lhdGUg dG8gc2VlIGZ1dHVyZSB1c2UgY2FzZSBkZXNjcmlwdGlvbnMgd2l0aCBhIHNpbWlsYXIgc3RydWN0 dXJlIHRoYW4gdXNlIGluIHRoaXMgZG9jdW1lbnQuIEluIGZvdW5kIGl0IHZlcnkgaGVscGZ1bCB0 byBjYXB0dXJlIHRoZSBtb3N0IGltcG9ydGFudCBwb2ludHMuIEhvd2V2ZXIsIHRoaXMgc3RydWN0 dXJlIGlzIGFsc28gb3BlbiBmb3IgZGlzY3Vzc2lvbi4NCj4NClVzZSBvZiBTUFVEIHdpdGggTkFU IHNob3VsZCBwcm9iYWJseSBiZSBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0Lg0KDQpJdCBtaWdodCBi ZSB3b3J0aHdoaWxlIHRvIGNvbnNpZGVyIHNvbWUgbW9yZSBzcGVjaWZpYyBhcHBsaWNhdGlvbnMg b2YgZmlyZXdhbGxzLiBGb3IgZXhhbXBsZSwgaWYgYSBmaXJld2FsbCBpcyBkZXBsb3llZCBiZXR3 ZWVuIGEgc2l0ZSBhbmQgdGhlIEludGVybmV0LCB3ZSBtaWdodCBiZSBtb3JlIGluY2xpbmVkIHRv IHRydXN0IFNQVUQgZGlyZWN0aXZlcyByZWNlaXZlZCBmcm9tIHRoZSBpbnRlcm5hbCBuZXR3b3Jr IGFzIG9wcG9zZWQgdG8gdGhlIEludGVybmV0Lg0KDQpBbm90aGVyIHBvdGVudGlhbCB1c2UgY2Fz ZSB0byBpbnZlc3RpZ2F0ZSB3b3VsZCBiZSBtb2JpbGUgZGV2aWNlcyBiZWhpbmQgYSBtaWRkbGVi b3guDQoNCkNvbW1lbnRzIG9uIHRoZSBkcmFmdDoNCg0KIlRoaXMgc3RhdGUgc2hvdWxkIGJlIGJv dW5kIHRvIHNvbWV0aGluZyBiZXlvbmQgdGhlIGZpdmUtdHVwbGUgdG8gbGluayBwYWNrZXRzIHRv Z2V0aGVyLiIgcXVlc3Rpb24gaGVyZSBvZiB3aGV0aGVyIFVEUCBzb3VyY2Ugc2hvdWxkIGJlIHBh cnQgb2YgaWRlbnRpZnlpbmcgdHVwbGUuIFVEUCBlbmNhcHN1bGF0aW9uIHByb3RvY29scyBhcmUg ZGVmaW5pbmcgc291cmNlIHBvcnQgYXMgYW4gZW50cm9weSBmaWVsZCBmb3IgRUNNUCwgc28gaXQg bWlnaHQgYmUgZ29vZCB0byB0YWtlIG91dCBzb3VyY2UgcG9ydCBpbiB0aGUgdHVwbGUuDQoNCiJG dXJ0aGVyLCB0byBtYWludGFpbiBzdGF0ZSwgdGhlIHNlbmRlciBtdXN0IGV4cGxpY2l0bHkgaW5k aWNhdGUgdGhlIHN0YXJ0IGFuZCBlbmQgb2YgYSB0dWJlIHRvIHRoZSBwYXRoLCB3aGlsZSB0aGUg cmVjZWl2ZXIgbXVzdCBjb25maXJtIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudC4iLiBTZW5kZXIg YW5kIHJlY2VpdmVyIG1pZ2h0IGJlIGFtYmlndW91cyB0ZXJtcywgSSBsaWtlIGluaXRpYXRvciBh bmQgdGFyZ2V0IGlmIHRoaXMgaXMgbWVhbnQgdG8gaW5kaWNhdGUgcGVyc3BlY3RpdmUgcm9sZXMg aW4gdGhlIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudC4gIEFuIGFsdGVybmF0aXZlIG1vZGUgY291 bGQgYmUgIHJlcXVlc3QvcmVzcG9uc2UgY29tbXVuaWNhdGlvbiB3aGVyZSB0aGUgcmVxdWVzdCBj cmVhdGVzIHRoZSBzdGF0ZSBhbmQgdGhlIHJlc3BvbnNlIGNsb3NlcyBpdCAodGhpcyBpcyBkZXNj cmliZWQgaW4NCmRyYWZ0LWhlcmJlcnQtZ3VlLXNlc3Npb24taWQtMDAgKS4NCg0KSSBiZWxpZXZl IHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIgYW5kIHRoZSBTUFVEIHByb3Rv dHlwZSBwcm90b2NvbCBjb3VsZCBiZSB2dWxuZXJhYmxlIHRvIHNvbWV0aGluZyBsaWtlIGEgY2xh c3NpYyBTWU4gYXR0YWNrLg0KVGhhdCBpcyBhbiBhdHRhY2tlciBjb3VsZCBzcG9vZiBvcGVuIGNv bW1hbmRzIGluIGFuIGF0dGVtcHQgdG8gRE9TIGF0IHRoZSBtaWRkbGVib3guIFBhcnQgb2YgdGhl IGRlZmVuc2UgYWdhaW5zdCB0aGlzIGF0dGFjayBpcyB0byBkbyAzLVdIUy4NClRoaXMgbWlnaHQg YmUgYWxyZWFkeSBpbXBsaWVkIGluIHRoZSBkcmFmdCBhdCAiVGhpcywgdG9nZXRoZXIgd2l0aCB0 aGUgZmlyc3QgcGFja2V0IGZvbGxvd2luZyB0aGUgY29uZmlybWF0aW9uLCBwcm92aWRlcyBhIGd1 YXJhbnRlZSBvZiByZXR1cm4gcm91dGFiaWxpdHkiLCBidXQgdGhpcyBpc24ndCBzdWZmaWNpZW50 IGlmIHRoZSBhdHRhY2tlciBjYW4gYWxzbyBzcG9vZiB0aGF0IGZpcnN0IHBhY2tldCBmb2xsb3dp bmcgdGhlIGNvbmZpcm1hdGlvbi4gQSBzb2x1dGlvbiBpcyB0byBoYXZlIHRoZSByZWNlaXZlciAo dGFyZ2V0KSBzZXQgcGFydCBvZiB0aGUgdHViZSBJRCB3aGljaCBhbiBhdHRhY2tlciBjb3VsZCBu b3QgcHJlZGljdCAodGhpcyBpcyBhbmFsb2dvdXMgdGhlIHJlcXVpcmVtZW50IHRoYXQgYm90aCBT WU4gYW5kIEFDSyBudW1iZXJzIG11c3QgYmUgc3luY2hyb25pemVkIGJlZm9yZSBtb3ZpbmcgdG8g RXN0YWJsaXNoZWQgc3RhdGUgaW4gVENQKS4gUGxlYXNlIGxvb2sgYXQNCmRyYWZ0LWhlcmJlcnQt Z3VlLXNlc3Npb24taWQtMDAgZm9yIG1vcmUgb24gdGhpcy4NCg0KIkEgU1BVRCBlbmRwb2ludCBy ZWNlaXZpbmcgYSBTUFVEIGhlYWRlciB3aXRoIHRpbWVvdXQgaW5mb3JtYXRpb24gc2hvdWxkIHJl ZmxlY3QgdGhpcyBpbmZvcm1hdGlvbiB0byB0aGUgc2VuZGVyIi4gVGhpcyBpcyBhIGdvb2QgZXhh bXBsZSBvZiB0aGUgdHJ1c3QgcHJvYmxlbS4gV2h5IHdvdWxkIHdlIHRydXN0IGFuIGVuZHBvaW50 IHRvIGRvIHRoaXMgY29ycmVjdGx5PyBNYXliZSB0aGV5IGp1c3QgYWx3YXlzIHJldHVybiB0aGUg c21hbGxlc3QgcG9zc2libGUgdmFsdWUgaW5zdGVhZCB3aXRob3V0IGFueSByZWdhcmQgdG8gdGhl IGNvc3QgYXQgdGhlIHNlbmRlciBvciBpdHMgbmV0d29yayBmb3Igc2VuZGluZyBmcmVxdWVudCBo ZWFydCBiZWF0cy4gSW4gdGhpcyBjYXNlLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciBmb3Ig dGhlIG1pZGRsZWJveCAobG9jYWwgdG8gdGhlIHNlbmRlcikgdG8gcmV0dXJuIHRoZSB0aW1lb3V0 IGluZm9ybWF0aW9uIHRvIHRoZSBzZW5kZXIgdXNpbmcgYW4gb3V0IG9mIGJhbmQgcHJvdG9jb2wu IEFsc28sIHRoaXMgbWlnaHQgbm90IGJlIG5lZWRlZCBmb3IgZXZlcnkgZmxvdywgaW4gdGhlIGNv bW1vbiBjYXNlIG9mIGEgbm9kZSBiZWluZyBiZWhpbmQgYSBzaW5nbGUgZmlyZXdhbGwgZ2V0dGlu ZyB0aGUgdmFsdWUgb25jZSB3b3VsZCBwcm9iYWJseSBzdWZmaWNlLg0KDQoiVGhlcmVmb3JlIGl0 IGhhcyB0byBzZW5kIGhlYXJ0YmVhdCBmYWlybHkgcmFwaWRseSwgb3IgbWlnaHQgYXNzdW1lIGEg ZGVmYXVsdCB2YWx1ZSBvZiAxNTBtcyB0aGF0IGlzIGNvbW1vbmx5IHVzZWQgdG9kYXkuIiBXaGVy ZSBkb2VzIHRoaXMgdmFsdWUgY29tZSBmcm9tPyBDb3VsZG4ndCBzdWNoIGEgcmF0ZSBraWxsIGJh dHRlcnkgb24gYSBtb2JpbGUgZGV2aWNlPw0KDQoiQW4gYXBwbGljYXRpb24gZG9lcyBub3QgYmVu ZWZpdCBmcm9tIHdyb25seSBpbmRpY2F0aW5nIGxvc3MtIG9yIGxhdGVuY3ktc2Vuc2l0aXZpdHki IFR5cG8gOi0pLi4uIFRoZSBxdWVzdGlvbiBoZXJlIGlzIHdoYXQgYXJlIHRoZSBjb25zZXF1ZW5j ZXMgaWYgdHJhZmZpYyBpcyBpbmNvcnJlY3RseSBtYXJrZWQuIElmIG1pcy1tYXJraW5nIHBhY2tl dHMgY2FuIGFkdmVyc2VseSBhZmZlY3Qgb3RoZXIgbm9uLXJlbGF0ZWQgZmxvd3MgdGhlbiB0aGlz IG1lY2hhbmlzbSBwb3RlbnRpYWxseSBiZWNvbWVzIHRoZSBiYXNpcyBmb3IgYSBEb1MgYXR0YWNr LiBGb3IgZXhhbXBsZSwgaWYgc29tZW9uZSBhcmJpdHJhcmlseSBkZWNpZGVzIHRvIG1hcmsgYWxs IHRoZWlyIHBhY2tldHMgYXMgbG93IGxhdGVuY3ksIGluY3JlYXNpbmcgdGhlIGxhdGVuY3kgb2Yg b3RoZXIgZmxvd3Mgb3IgZXZlbiB3b3JzZSBpbmNyZWFzaW5nIHBhY2tldCBsb3NzIGZvciBvdGhl ciBjb3JyZWN0bHkgbWFya2VkIGxvdyBsYXRlbmN5IHRyYWZmaWMgd291bGQgYmUgYSBwcm9ibGVt Lg0KDQpUb20NCg0KDQoNCj4gQnJpYW4gYW5kIE1pcmphDQo+DQo+DQo+DQo+PiBBbmZhbmcgZGVy IHdlaXRlcmdlbGVpdGV0ZW4gTmFjaHJpY2h0Og0KPj4NCj4+IFZvbjogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnDQo+PiBCZXRyZWZmOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPj4g ZHJhZnQta3VlaGxld2luZC1zcHVkLXVzZS1jYXNlcy0wMC50eHQNCj4+IERhdHVtOiAzLiBKdWxp IDIwMTUgMTc6MTk6MTAgTUVTWg0KPj4gQW46ICJNaXJqYSBLdWVobGV3aW5kIiA8bWlyamEua3Vl aGxld2luZEB0aWsuZWUuZXRoei5jaD4sICJNaXJqYSANCj4+IEt1ZWhsZXdpbmQiIDxtaXJqYS5r dWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPiwgIkJyaWFuIFRyYW1tZWxsIg0KPj4gPGlldGZAdHJh bW1lbGwuY2g+LCAiQnJpYW4gVHJhbW1lbGwiIDxpZXRmQHRyYW1tZWxsLmNoPg0KPj4NCj4+DQo+ PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta3VlaGxld2luZC1zcHVkLXVzZS1jYXNlcy0w MC50eHQNCj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWlyamEgS3VlaGxl d2luZCBhbmQgcG9zdGVkIHRvIHRoZSANCj4+IElFVEYgcmVwb3NpdG9yeS4NCj4+DQo+PiBOYW1l OiAgICAgICAgIGRyYWZ0LWt1ZWhsZXdpbmQtc3B1ZC11c2UtY2FzZXMNCj4+IFJldmlzaW9uOiAg ICAgMDANCj4+IFRpdGxlOiAgICAgICAgICAgICAgICBTUFVEIFVzZSBDYXNlcw0KPj4gRG9jdW1l bnQgZGF0ZTogICAgICAgIDIwMTUtMDctMDMNCj4+IEdyb3VwOiAgICAgICAgICAgICAgICBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCj4+IFBhZ2VzOiAgICAgICAgICAgICAgICAxNQ0KPj4gVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rdWVo bGV3aW5kLXNwdWQtdXNlLWNhc2VzLTAwLnR4dA0KPj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt1ZWhsZXdpbmQtc3B1ZC11c2UtY2FzZXMv DQo+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt1 ZWhsZXdpbmQtc3B1ZC11c2UtY2FzZXMtMDANCj4+DQo+Pg0KPj4gQWJzdHJhY3Q6DQo+PiAgIFRo ZSBTdWJzdHJhdGUgUHJvdG9jb2wgZm9yIFVzZXIgRGF0YWdyYW1zIChTUFVEKSBCb0Ygc2Vzc2lv biBhdCB0aGUNCj4+ICAgSUVURiA5MiBtZWV0aW5nIGluIERhbGxhcyBpbiBNYXJjaCAyMDE1IGlk ZW50aWZpZWQgdGhlIHBvdGVudGlhbCBuZWVkDQo+PiAgIGZvciBhIFVEUC1iYXNlZCBlbmNhcHN1 bGF0aW9uIHByb3RvY29sIHRvIGFsbG93IGV4cGxpY2l0IGNvb3BlcmF0aW9uDQo+PiAgIHdpdGgg bWlkZGxlYm94ZXMgd2hpbGUgdXNpbmcgbmV3LCBlbmNyeXB0ZWQgdHJhbnNwb3J0IHByb3RvY29s cy4NCj4+ICAgVGhpcyBkb2N1bWVudCBzdW1tYXJpemVzIHRoZSB1c2UgY2FzZXMgZGlzY3VzcyBh dCB0aGUgQm9GIGFuZCB0aGVyZWJ5DQo+PiAgIHByb3Bvc2VzIGEgc3RydWN0dXJlIGZvciB0aGUg ZGVzY3JpcHRpb24gb2YgZnVydGhlciB1c2UgY2FzZXMuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2YgDQo+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pg0KPj4gVGhlIElFVEYgU2VjcmV0 YXJpYXQNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gU3B1ZCBtYWlsaW5nIGxpc3QNCj4gU3B1ZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwdWQNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClNwdWQgbWFpbGluZyBsaXN0DQpTcHVkQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwdWQNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTcHVkIG1haWxpbmcgbGlzdA0K U3B1ZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVk DQo= From nobody Tue Jul 7 06:43:55 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF261A902A for ; Tue, 7 Jul 2015 06:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 r-NX0GBm7BWz for ; Tue, 7 Jul 2015 06:43:50 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0344F1A8AD9 for ; Tue, 7 Jul 2015 06:43:49 -0700 (PDT) Received: from nb-10604.ethz.ch (nb-10604.ethz.ch [82.130.102.91]) by trammell.ch (Postfix) with ESMTPSA id A1E241A0398; Tue, 7 Jul 2015 15:43:47 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8363F35E-64D1-430D-B5C8-5D48F6ED0E77"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: Date: Tue, 7 Jul 2015 15:43:46 +0200 Message-Id: <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> To: Tom Herbert X-Mailer: Apple Mail (2.2098) Archived-At: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud@ietf.org Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 13:43:54 -0000 --Apple-Mail=_8363F35E-64D1-430D-B5C8-5D48F6ED0E77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Tom, > On 06 Jul 2015, at 19:20, Tom Herbert wrote: >=20 > On Fri, Jul 3, 2015 at 8:24 AM, Mirja K=C3=BChlewind > wrote: >> Hi all, >>=20 >> we=E2=80=99ve just submitted a new use case document. This document = describes in more detail the use cases as already presented/discussed at = the BoF. >>=20 >> Please review and comment. Also partial reviews of e.g. just one use = case are more than welcome. Further if you=E2=80=99d like to contribute = to this document, please let use know as well. >>=20 > Hi Mirja, thanks for the draft! Here are my comments. >=20 > General comments: >=20 > It seems to me there are two motivations for SPUD: >=20 > 1) A common protocol layer for UDP flow based protocols to pass > through stateful firewalls and NAT. > 2) A rich inband flow based QoS signaling initiated by end hosts which > can be interpreted by network devices in the path. Kind of, though it's not *strictly* QoS focused. There's also (1.5): enable network management functionality which today = uses DPI but will no longer function with increasing payload encryption. = But the current draft doesn't go into much depth on this point. > The first motivation seems pretty clear, the inability to pass UDP > (really anything besides TCP) through stateful firewalls has impeded > deployment of new L4 protocols. >=20 > The second motivation is less clear. Disregarding previously raised > questions around new DoS vectors and whether we can ever trust > anything anyone says on the Internet, I would ask if SPUD (UDP) is the > right layer for this. The need for this signaling doesn't seem to be > specific to UDP transport protocols, but also should applicable to > TCP, SCTP, and other protocols. Barring that these protocols > transition to running over SPUD (unlikely in the foreseeable future), > it seems like such signaling should be implemented in a more common > layer, maybe something like IP options. I tend to think that the signaling vocabulary and encoding(s) should be = defined *separately* from the mechanism to bind that encoding into the = protocol stack. Taking draft-hildebrand-spud-prototype as an example, = one could define a set of CBOR keys that one must understand for a given = SPUD application (say, the low latency use case), and then bind those = CBOR keys into userspace transports using SPUD, into IPv6 traffic using = hop-by-hop and/or destination options (in a world in which those work), = etc. In any case, I think at *minimum* any layer supporting this has to be = able to run over UDP, by process of elimination -> you can't always add = things to the kernel or get privilege to open a raw socket (i.e. = requirement 6.3 in draft-trammell-spud-req). > Another general question I have is how much leeway should be taken in > relaxing or modifying the end-to-end semantics of UDP. In particular, > I think an important question is rather middleboxes should be > modifying UDP payloads. We've accepted that NAT devices can modify UDP > port numbers, but mucking with the payload seems worse to me. First off I've come to accept that the de facto boundary between the = network and transport layer in the Internet architecture is four bytes = after the end of the IPv4 header-plus-options or the IPv6 headers. The = ports are used often enough in forwarding decisions, and protocols that = don't have port numbers in those positions are consequently not as able = to get through the network as protocols that do. Given the installed = base, it's conceptually cleaner to treat these thirty-two bits as = belonging to the network layer now. The eventual idea is to put stuff that middleboxes can look at (and = potentially mess with) outside the crypto curtain, while encrypting = everything else. The fact that middleboxes can mess with the data makes = it inherently less trustworthy, yes, but that's the case with = unencrypted traffic in today's Internet anyway. There's a discussion on the tradeoffs of this sort of "piggyback" = signaling in draft-trammell-spud-req (section 7.5). > This > makes end-to-end authentication or integrity checks much more > difficult End-to-end authentication and integrity checks would happen in the = payload layered on top of SPUD -- signaling between the endpoints that = that path doesn't need to see should be encrypted anyway. There are = possibly types of information that the endpoints need to expose that = also require protection... > and if a packet is ever misclassified as SPUD this could > result in data corruption. This is the rationale behind requirement 6.2 in draft-trammell-spud-req: = it has to be easy to recognize a SPUD packet (indeed, we should also = state that this recognition requires a bounded error probability). > This issue also comes up in other > proposals, such as BIER, but those seem have more narrow application > (i.e. for multicast, deployed in closed network not the Internet as > SPUD is intended). >=20 >> For everybody who potentially has additional use cases in mind, I = personally would appreciate to see future use case descriptions with a = similar structure than use in this document. In found it very helpful to = capture the most important points. However, this structure is also open = for discussion. >>=20 > Use of SPUD with NAT should probably be mentioned in the draft. >=20 > It might be worthwhile to consider some more specific applications of > firewalls. For example, if a firewall is deployed between a site and > the Internet, we might be more inclined to trust SPUD directives > received from the internal network as opposed to the Internet. >=20 > Another potential use case to investigate would be mobile devices > behind a middlebox. >=20 > Comments on the draft: >=20 > "This state should be bound to something beyond the five-tuple to link > packets together." question here of whether UDP source should be part > of identifying tuple. UDP encapsulation protocols are defining source > port as an entropy field for ECMP, so it might be good to take out > source port in the tuple. I don't see that the protocols running over SPUD and the protocols = running over an encapsulation with this ECMP entropy hack (in the nicest = sense of the word?) are trying to solve the same problem... The UDP = source port is crucial for return routability to the far endpoint when = its stack is implemented in userspace... > "Further, to maintain state, the sender must explicitly indicate the > start and end of a tube to the path, while the receiver must confirm > connection establishment.". Sender and receiver might be ambiguous > terms, I like initiator and target if this is meant to indicate > perspective roles in the connection establishment. An alternative > mode could be request/response communication where the request > creates the state and the response closes it (this is described in > draft-herbert-gue-session-id-00 ). >=20 > I believe the mechanisms described in section 2 and the SPUD prototype > protocol could be vulnerable to something like a classic SYN attack. > That is an attacker could spoof open commands in an attempt to DOS at > the middlebox. Part of the defense against this attack is to do 3-WHS. > This might be already implied in the draft at "This, together with the > first packet following the confirmation, provides a guarantee of > return routability", but this isn't sufficient if the attacker can > also spoof that first packet following the confirmation. A solution is > to have the receiver (target) set part of the tube ID which an > attacker could not predict (this is analogous the requirement that > both SYN and ACK numbers must be synchronized before moving to > Established state in TCP). Please look at > draft-herbert-gue-session-id-00 for more on this. Thanks for the pointer; yes, we do need something like this mechanism. = There are also probably cryptographic approaches here that would be = worth looking into, if there *is* indeed already established trust = between the endpoints and the overlying transport can share that with = SPUD. > "A SPUD endpoint receiving a SPUD header with timeout information > should reflect this information to the sender". This is a good example > of the trust problem. Why would we trust an endpoint to do this > correctly? Maybe they just always return the smallest possible value > instead without any regard to the cost at the sender or its network > for sending frequent heart beats. In this case, I think it would be > better for the middlebox (local to the sender) to return the timeout > information to the sender using an out of band protocol. Also, this > might not be needed for every flow, in the common case of a node being > behind a single firewall getting the value once would probably > suffice. >=20 > "Therefore it has to send heartbeat fairly rapidly, or might assume a > default value of 150ms that is commonly used today." Where does this > value come from? Couldn't such a rate kill battery on a mobile device? Yes, which is one of the reasons an explicit signaling protocol here = would be a nice thing to have. Agreed that we need to get to vocabulary = and incentives to cooperate right. > "An application does not benefit from wronly indicating loss- or > latency-sensitivity" Typo :-)... The question here is what are the > consequences if traffic is incorrectly marked. If mis-marking packets > can adversely affect other non-related flows then this mechanism > potentially becomes the basis for a DoS attack. For example, if > someone arbitrarily decides to mark all their packets as low latency, > increasing the latency of other flows or even worse increasing packet > loss for other correctly marked low latency traffic would be a > problem. Presuming a well-implemented dual-service system, masses of traffic = piling into the low-latency queue would indeed increase loss rate. Of = course, the low-latency service is only intended for transport protocols = which can already tolerate more loss than TCP, and I'd need to run some = experiments with such a thing before I were convinced that an attacker = that has the power to overrun the low-latency queue doesn't also already = have the ability to cause the same or worse disruption in service in a = single-queue system. Cheers, Brian >>=20 >>> Anfang der weitergeleiteten Nachricht: >>>=20 >>> Von: internet-drafts@ietf.org >>> Betreff: New Version Notification for = draft-kuehlewind-spud-use-cases-00.txt >>> Datum: 3. Juli 2015 17:19:10 MESZ >>> An: "Mirja Kuehlewind" , "Mirja = Kuehlewind" , "Brian Trammell" = , "Brian Trammell" >>>=20 >>>=20 >>> A new version of I-D, draft-kuehlewind-spud-use-cases-00.txt >>> has been successfully submitted by Mirja Kuehlewind and posted to = the >>> IETF repository. >>>=20 >>> Name: draft-kuehlewind-spud-use-cases >>> Revision: 00 >>> Title: SPUD Use Cases >>> Document date: 2015-07-03 >>> Group: Individual Submission >>> Pages: 15 >>> URL: = https://www.ietf.org/internet-drafts/draft-kuehlewind-spud-use-cases-00.tx= t >>> Status: = https://datatracker.ietf.org/doc/draft-kuehlewind-spud-use-cases/ >>> Htmlized: = https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00 >>>=20 >>>=20 >>> Abstract: >>> The Substrate Protocol for User Datagrams (SPUD) BoF session at the >>> IETF 92 meeting in Dallas in March 2015 identified the potential = need >>> for a UDP-based encapsulation protocol to allow explicit = cooperation >>> with middleboxes while using new, encrypted transport protocols. >>> This document summarizes the use cases discuss at the BoF and = thereby >>> proposes a structure for the description of further use cases. >>>=20 >>>=20 >>>=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 >>> The IETF Secretariat >>=20 >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_8363F35E-64D1-430D-B5C8-5D48F6ED0E77 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVm9eTAAoJENt3nsOmbNJcif4IAIuxYt9pnekoXMoDrNSMnCyd 6/fH3wuqgm6GRGBtQIGXir/Eyq/E2+6Fh3FC2hFP/383gBVVPnvIc3oyPXfxNvgC g2Sv6Saa9kgfyvTi3GgRxr5TwU+WCHi5N6GY7EZ0LFi8CfG6ezF3uIlsZvWBR3Ml VBfXVsYkX4Ym5U1bZ5nDr5jwIvPnnZ4/yfCgryhmMzVpmsPRHtkO1W5mOp9jxgS3 9YKli3LfAOJLdlAmbg1LwryHgaXpPEMg/qI6SeUCVmz1Ppep9A9B1m1BaKzYQAJA E/T246WFVxevO5FAJw553+cPuRBffgQDjR0XHmeE3UmGGbPbpnjOA2UUqgfTwW0= =Ukol -----END PGP SIGNATURE----- --Apple-Mail=_8363F35E-64D1-430D-B5C8-5D48F6ED0E77-- From nobody Tue Jul 7 07:03:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E542A1AC3EA for ; Tue, 7 Jul 2015 07:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 T2vgwjCfHYOv for ; Tue, 7 Jul 2015 07:03:19 -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 C500B1AC3E2 for ; Tue, 7 Jul 2015 07:03:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUU73350; Tue, 07 Jul 2015 14:03:17 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Jul 2015 15:03:16 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.184]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 7 Jul 2015 22:03:10 +0800 From: Youjianjie To: "Smith, Kevin, (R&D) Vodafone Group" , "Tom Herbert" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [Spud] Fwd: New Version Notification for draft-kuehlewind-spud-use-cases-00.txt Thread-Index: AQHQtaR8jagfQKtUlUSpw5v1KSwuUp3OLqGAgAEmSoCAALmeEA== Date: Tue, 7 Jul 2015 14:03:09 +0000 Message-ID: References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.77.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Brian Trammell , "spud@ietf.org" Subject: [Spud] =?utf-8?b?562U5aSNOiAgRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?utf-8?q?on_for_draft-kuehlewind-spud-use-cases-00=2Etxt?= X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 14:03:24 -0000 SGkgS2V2aW4sDQoNClRoZSBmb2xsb3dpbmcgZHJhZnQgZGVzY3JpYmVzIHRoZSB1c2UgY2FzZSBm b3IgaXRlbSAoMyksIGVzcGVjaWFsbHkgZm9yIFRDUC4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC15dy1zcHVkLXVzZS1jYXNlcy0wMC50eHQNCg0KUmVnYXJkcywN CkppYW5qaWUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogU3B1ZCBb bWFpbHRvOnNwdWQtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFNtaXRoLCBLZXZpbiwgKFImRCkN Cj4gVm9kYWZvbmUgR3JvdXANCj4g5Y+R6YCB5pe26Ze0OiAyMDE15bm0N+aciDfml6UgMTg6NTMN Cj4g5pS25Lu25Lq6OiBUb20gSGVyYmVydDsgTWlyamEgS8O8aGxld2luZA0KPiDmioTpgIE6IEJy aWFuIFRyYW1tZWxsOyBzcHVkQGlldGYub3JnDQo+IOS4u+mimDogUmU6IFtTcHVkXSBGd2Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQta3VlaGxld2luZC1zcHVkLXVzZS1j YXNlcy0wMC50eHQNCj4gDQo+IEhpIFRvbSwgTWlyamEsDQo+IA0KPiA+ICBJdCBzZWVtcyB0byBt ZSB0aGVyZSBhcmUgdHdvIG1vdGl2YXRpb25zIGZvciBTUFVEOg0KPiANCj4gPiAxKSBBIGNvbW1v biBwcm90b2NvbCBsYXllciBmb3IgVURQIGZsb3cgYmFzZWQgcHJvdG9jb2xzIHRvIHBhc3MgdGhy b3VnaA0KPiBzdGF0ZWZ1bCBmaXJld2FsbHMgYW5kIE5BVC4NCj4gPiAyKSBBIHJpY2ggaW5iYW5k IGZsb3cgYmFzZWQgUW9TIHNpZ25hbGluZyBpbml0aWF0ZWQgYnkgZW5kIGhvc3RzIHdoaWNoIGNh biBiZQ0KPiBpbnRlcnByZXRlZCBieSBuZXR3b3JrIGRldmljZXMgaW4gdGhlIHBhdGguDQo+IA0K PiBJJ2QgYWxzbyBzdWdnZXN0IHRoaXMgbW90aXZhdGlvbg0KPiAgKDMpIEluYmFuZCBzaWduYWxp bmcgb2YgaGludHMgZnJvbSBuZXR3b3JrIGRldmljZXMgaW4gdGhlIHBhdGggdG93YXJkcw0KPiBl bmRwb2ludHMgYW5kL29yIGVhY2ggb3RoZXINCj4gDQo+IFRoaXMgd291bGQgYWxsb3cgKGZvciBl eGFtcGxlKSBhIHJhZGlvIG5ldHdvcmsgbm9kZSB0byBwcm92aWRlIGhpbnRzIG9uIGNlbGwNCj4g Y29uZ2VzdGlvbiB0b3dhcmRzIHRoZSBlbmRwb2ludHMsIHRoYXQgbWF5IGJlIHVzZWQgdG8gcGFj ZSB0aGUgY29udGVudCBmbG93DQo+IGFjY29yZGluZ2x5LiBUaGVzZSB3b3VsZCByZW1haW4gaGlu dHMgYW5kIG5vdCBkaXJlY3RpdmVzLCBhbmQgd291bGQgcmVxdWlyZQ0KPiBhdXRoZW50aWNhdGlv bi4gQXMgVG9tIHNheXMsIGEga2V5IHF1ZXN0aW9uIGlzIHRoZSB3aGV0aGVyIHRvIGNvbnNpZGVy IElQIGxheWVyDQo+IGV4dGVuc2lvbnMsIGhvd2V2ZXIgSSBzdXNwZWN0IHRoZXJlIG1heSBiZSBz b21lIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzDQo+IHdoZXJlYnkgcm91dGVycyBkaXNjYXJkIElQ IG9wdGlvbnMsIGFuZCBJQ01QIGlzIHNvdXJjZS1kZXN0aW5hdGlvbiBvbmx5LiBJZg0KPiBTUFVE IGNhbiBpbmRlZWQgcnVuIHVuZGVyIFRDUCB0aGVuIHRoYXQgbWFrZXMgaXQgYSBtb3JlIGF0dHJh Y3RpdmUgb3B0aW9uDQo+IElNTy4NCj4gDQo+IEFsbCBiZXN0DQo+IEtldmluDQo+IA0KPiBLZXZp biBTbWl0aCwgVm9kYWZvbmUgUiZEDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBTcHVkIFttYWlsdG86c3B1ZC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgVG9tIEhlcmJlcnQNCj4gU2VudDogMDYgSnVseSAyMDE1IDE4OjIwDQo+IFRv OiBNaXJqYSBLw7xobGV3aW5kDQo+IENjOiBCcmlhbiBUcmFtbWVsbDsgc3B1ZEBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW1NwdWRdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0K PiBkcmFmdC1rdWVobGV3aW5kLXNwdWQtdXNlLWNhc2VzLTAwLnR4dA0KPiANCj4gT24gRnJpLCBK dWwgMywgMjAxNSBhdCA4OjI0IEFNLCBNaXJqYSBLw7xobGV3aW5kDQo+IDxtaXJqYS5rdWVobGV3 aW5kQHRpay5lZS5ldGh6LmNoPiB3cm90ZToNCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiB3ZeKAmXZl IGp1c3Qgc3VibWl0dGVkIGEgbmV3IHVzZSBjYXNlIGRvY3VtZW50LiBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBpbg0KPiBtb3JlIGRldGFpbCB0aGUgdXNlIGNhc2VzIGFzIGFscmVhZHkgcHJlc2Vu dGVkL2Rpc2N1c3NlZCBhdCB0aGUgQm9GLg0KPiA+DQo+ID4gUGxlYXNlIHJldmlldyBhbmQgY29t bWVudC4gQWxzbyBwYXJ0aWFsIHJldmlld3Mgb2YgZS5nLiBqdXN0IG9uZSB1c2UgY2FzZSBhcmUN Cj4gbW9yZSB0aGFuIHdlbGNvbWUuIEZ1cnRoZXIgaWYgeW914oCZZCBsaWtlIHRvIGNvbnRyaWJ1 dGUgdG8gdGhpcyBkb2N1bWVudCwNCj4gcGxlYXNlIGxldCB1c2Uga25vdyBhcyB3ZWxsLg0KPiA+ DQo+IEhpIE1pcmphLCB0aGFua3MgZm9yIHRoZSBkcmFmdCEgSGVyZSBhcmUgbXkgY29tbWVudHMu DQo+IA0KPiBHZW5lcmFsIGNvbW1lbnRzOg0KPiANCj4gSXQgc2VlbXMgdG8gbWUgdGhlcmUgYXJl IHR3byBtb3RpdmF0aW9ucyBmb3IgU1BVRDoNCj4gDQo+IDEpIEEgY29tbW9uIHByb3RvY29sIGxh eWVyIGZvciBVRFAgZmxvdyBiYXNlZCBwcm90b2NvbHMgdG8gcGFzcyB0aHJvdWdoDQo+IHN0YXRl ZnVsIGZpcmV3YWxscyBhbmQgTkFULg0KPiAyKSBBIHJpY2ggaW5iYW5kIGZsb3cgYmFzZWQgUW9T IHNpZ25hbGluZyBpbml0aWF0ZWQgYnkgZW5kIGhvc3RzIHdoaWNoIGNhbiBiZQ0KPiBpbnRlcnBy ZXRlZCBieSBuZXR3b3JrIGRldmljZXMgaW4gdGhlIHBhdGguDQo+IA0KPiBUaGUgZmlyc3QgbW90 aXZhdGlvbiBzZWVtcyBwcmV0dHkgY2xlYXIsIHRoZSBpbmFiaWxpdHkgdG8gcGFzcyBVRFAgKHJl YWxseQ0KPiBhbnl0aGluZyBiZXNpZGVzIFRDUCkgdGhyb3VnaCBzdGF0ZWZ1bCBmaXJld2FsbHMg aGFzIGltcGVkZWQgZGVwbG95bWVudCBvZg0KPiBuZXcgTDQgcHJvdG9jb2xzLg0KPiANCj4gVGhl IHNlY29uZCBtb3RpdmF0aW9uIGlzIGxlc3MgY2xlYXIuIERpc3JlZ2FyZGluZyBwcmV2aW91c2x5 IHJhaXNlZCBxdWVzdGlvbnMNCj4gYXJvdW5kIG5ldyBEb1MgdmVjdG9ycyBhbmQgd2hldGhlciB3 ZSBjYW4gZXZlciB0cnVzdCBhbnl0aGluZyBhbnlvbmUgc2F5cw0KPiBvbiB0aGUgSW50ZXJuZXQs IEkgd291bGQgYXNrIGlmIFNQVUQgKFVEUCkgaXMgdGhlIHJpZ2h0IGxheWVyIGZvciB0aGlzLiBU aGUgbmVlZA0KPiBmb3IgdGhpcyBzaWduYWxpbmcgZG9lc24ndCBzZWVtIHRvIGJlIHNwZWNpZmlj IHRvIFVEUCB0cmFuc3BvcnQgcHJvdG9jb2xzLCBidXQNCj4gYWxzbyBzaG91bGQgYXBwbGljYWJs ZSB0byBUQ1AsIFNDVFAsIGFuZCBvdGhlciBwcm90b2NvbHMuIEJhcnJpbmcgdGhhdCB0aGVzZQ0K PiBwcm90b2NvbHMgdHJhbnNpdGlvbiB0byBydW5uaW5nIG92ZXIgU1BVRCAodW5saWtlbHkgaW4g dGhlIGZvcmVzZWVhYmxlIGZ1dHVyZSksIGl0DQo+IHNlZW1zIGxpa2Ugc3VjaCBzaWduYWxpbmcg c2hvdWxkIGJlIGltcGxlbWVudGVkIGluIGEgbW9yZSBjb21tb24gbGF5ZXIsDQo+IG1heWJlIHNv bWV0aGluZyBsaWtlIElQIG9wdGlvbnMuDQo+IA0KPiBBbm90aGVyIGdlbmVyYWwgcXVlc3Rpb24g SSBoYXZlIGlzIGhvdyBtdWNoIGxlZXdheSBzaG91bGQgYmUgdGFrZW4gaW4NCj4gcmVsYXhpbmcg b3IgbW9kaWZ5aW5nIHRoZSBlbmQtdG8tZW5kIHNlbWFudGljcyBvZiBVRFAuIEluIHBhcnRpY3Vs YXIsIEkgdGhpbmsgYW4NCj4gaW1wb3J0YW50IHF1ZXN0aW9uIGlzIHJhdGhlciBtaWRkbGVib3hl cyBzaG91bGQgYmUgbW9kaWZ5aW5nIFVEUCBwYXlsb2Fkcy4NCj4gV2UndmUgYWNjZXB0ZWQgdGhh dCBOQVQgZGV2aWNlcyBjYW4gbW9kaWZ5IFVEUCBwb3J0IG51bWJlcnMsIGJ1dCBtdWNraW5nDQo+ IHdpdGggdGhlIHBheWxvYWQgc2VlbXMgd29yc2UgdG8gbWUuIFRoaXMgbWFrZXMgZW5kLXRvLWVu ZCBhdXRoZW50aWNhdGlvbiBvcg0KPiBpbnRlZ3JpdHkgY2hlY2tzIG11Y2ggbW9yZSBkaWZmaWN1 bHQsIGFuZCBpZiBhIHBhY2tldCBpcyBldmVyIG1pc2NsYXNzaWZpZWQgYXMNCj4gU1BVRCB0aGlz IGNvdWxkIHJlc3VsdCBpbiBkYXRhIGNvcnJ1cHRpb24uIFRoaXMgaXNzdWUgYWxzbyBjb21lcyB1 cCBpbiBvdGhlcg0KPiBwcm9wb3NhbHMsIHN1Y2ggYXMgQklFUiwgYnV0IHRob3NlIHNlZW0gaGF2 ZSBtb3JlIG5hcnJvdyBhcHBsaWNhdGlvbiAoaS5lLiBmb3INCj4gbXVsdGljYXN0LCBkZXBsb3ll ZCBpbiBjbG9zZWQgbmV0d29yayBub3QgdGhlIEludGVybmV0IGFzIFNQVUQgaXMgaW50ZW5kZWQp Lg0KPiANCj4gPiBGb3IgZXZlcnlib2R5IHdobyBwb3RlbnRpYWxseSBoYXMgYWRkaXRpb25hbCB1 c2UgY2FzZXMgaW4gbWluZCwgSSBwZXJzb25hbGx5DQo+IHdvdWxkIGFwcHJlY2lhdGUgdG8gc2Vl IGZ1dHVyZSB1c2UgY2FzZSBkZXNjcmlwdGlvbnMgd2l0aCBhIHNpbWlsYXIgc3RydWN0dXJlDQo+ IHRoYW4gdXNlIGluIHRoaXMgZG9jdW1lbnQuIEluIGZvdW5kIGl0IHZlcnkgaGVscGZ1bCB0byBj YXB0dXJlIHRoZSBtb3N0DQo+IGltcG9ydGFudCBwb2ludHMuIEhvd2V2ZXIsIHRoaXMgc3RydWN0 dXJlIGlzIGFsc28gb3BlbiBmb3IgZGlzY3Vzc2lvbi4NCj4gPg0KPiBVc2Ugb2YgU1BVRCB3aXRo IE5BVCBzaG91bGQgcHJvYmFibHkgYmUgbWVudGlvbmVkIGluIHRoZSBkcmFmdC4NCj4gDQo+IEl0 IG1pZ2h0IGJlIHdvcnRod2hpbGUgdG8gY29uc2lkZXIgc29tZSBtb3JlIHNwZWNpZmljIGFwcGxp Y2F0aW9ucyBvZiBmaXJld2FsbHMuDQo+IEZvciBleGFtcGxlLCBpZiBhIGZpcmV3YWxsIGlzIGRl cGxveWVkIGJldHdlZW4gYSBzaXRlIGFuZCB0aGUgSW50ZXJuZXQsIHdlIG1pZ2h0DQo+IGJlIG1v cmUgaW5jbGluZWQgdG8gdHJ1c3QgU1BVRCBkaXJlY3RpdmVzIHJlY2VpdmVkIGZyb20gdGhlIGlu dGVybmFsIG5ldHdvcmsgYXMNCj4gb3Bwb3NlZCB0byB0aGUgSW50ZXJuZXQuDQo+IA0KPiBBbm90 aGVyIHBvdGVudGlhbCB1c2UgY2FzZSB0byBpbnZlc3RpZ2F0ZSB3b3VsZCBiZSBtb2JpbGUgZGV2 aWNlcyBiZWhpbmQgYQ0KPiBtaWRkbGVib3guDQo+IA0KPiBDb21tZW50cyBvbiB0aGUgZHJhZnQ6 DQo+IA0KPiAiVGhpcyBzdGF0ZSBzaG91bGQgYmUgYm91bmQgdG8gc29tZXRoaW5nIGJleW9uZCB0 aGUgZml2ZS10dXBsZSB0byBsaW5rIHBhY2tldHMNCj4gdG9nZXRoZXIuIiBxdWVzdGlvbiBoZXJl IG9mIHdoZXRoZXIgVURQIHNvdXJjZSBzaG91bGQgYmUgcGFydCBvZiBpZGVudGlmeWluZw0KPiB0 dXBsZS4gVURQIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2xzIGFyZSBkZWZpbmluZyBzb3VyY2UgcG9y dCBhcyBhbiBlbnRyb3B5IGZpZWxkDQo+IGZvciBFQ01QLCBzbyBpdCBtaWdodCBiZSBnb29kIHRv IHRha2Ugb3V0IHNvdXJjZSBwb3J0IGluIHRoZSB0dXBsZS4NCj4gDQo+ICJGdXJ0aGVyLCB0byBt YWludGFpbiBzdGF0ZSwgdGhlIHNlbmRlciBtdXN0IGV4cGxpY2l0bHkgaW5kaWNhdGUgdGhlIHN0 YXJ0IGFuZA0KPiBlbmQgb2YgYSB0dWJlIHRvIHRoZSBwYXRoLCB3aGlsZSB0aGUgcmVjZWl2ZXIg bXVzdCBjb25maXJtIGNvbm5lY3Rpb24NCj4gZXN0YWJsaXNobWVudC4iLiBTZW5kZXIgYW5kIHJl Y2VpdmVyIG1pZ2h0IGJlIGFtYmlndW91cyB0ZXJtcywgSSBsaWtlIGluaXRpYXRvcg0KPiBhbmQg dGFyZ2V0IGlmIHRoaXMgaXMgbWVhbnQgdG8gaW5kaWNhdGUgcGVyc3BlY3RpdmUgcm9sZXMgaW4g dGhlIGNvbm5lY3Rpb24NCj4gZXN0YWJsaXNobWVudC4gIEFuIGFsdGVybmF0aXZlIG1vZGUgY291 bGQgYmUgIHJlcXVlc3QvcmVzcG9uc2UNCj4gY29tbXVuaWNhdGlvbiB3aGVyZSB0aGUgcmVxdWVz dCBjcmVhdGVzIHRoZSBzdGF0ZSBhbmQgdGhlIHJlc3BvbnNlIGNsb3NlcyBpdA0KPiAodGhpcyBp cyBkZXNjcmliZWQgaW4NCj4gZHJhZnQtaGVyYmVydC1ndWUtc2Vzc2lvbi1pZC0wMCApLg0KPiAN Cj4gSSBiZWxpZXZlIHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIgYW5kIHRo ZSBTUFVEIHByb3RvdHlwZQ0KPiBwcm90b2NvbCBjb3VsZCBiZSB2dWxuZXJhYmxlIHRvIHNvbWV0 aGluZyBsaWtlIGEgY2xhc3NpYyBTWU4gYXR0YWNrLg0KPiBUaGF0IGlzIGFuIGF0dGFja2VyIGNv dWxkIHNwb29mIG9wZW4gY29tbWFuZHMgaW4gYW4gYXR0ZW1wdCB0byBET1MgYXQgdGhlDQo+IG1p ZGRsZWJveC4gUGFydCBvZiB0aGUgZGVmZW5zZSBhZ2FpbnN0IHRoaXMgYXR0YWNrIGlzIHRvIGRv IDMtV0hTLg0KPiBUaGlzIG1pZ2h0IGJlIGFscmVhZHkgaW1wbGllZCBpbiB0aGUgZHJhZnQgYXQg IlRoaXMsIHRvZ2V0aGVyIHdpdGggdGhlIGZpcnN0DQo+IHBhY2tldCBmb2xsb3dpbmcgdGhlIGNv bmZpcm1hdGlvbiwgcHJvdmlkZXMgYSBndWFyYW50ZWUgb2YgcmV0dXJuIHJvdXRhYmlsaXR5IiwN Cj4gYnV0IHRoaXMgaXNuJ3Qgc3VmZmljaWVudCBpZiB0aGUgYXR0YWNrZXIgY2FuIGFsc28gc3Bv b2YgdGhhdCBmaXJzdCBwYWNrZXQgZm9sbG93aW5nDQo+IHRoZSBjb25maXJtYXRpb24uIEEgc29s dXRpb24gaXMgdG8gaGF2ZSB0aGUgcmVjZWl2ZXIgKHRhcmdldCkgc2V0IHBhcnQgb2YgdGhlIHR1 YmUNCj4gSUQgd2hpY2ggYW4gYXR0YWNrZXIgY291bGQgbm90IHByZWRpY3QgKHRoaXMgaXMgYW5h bG9nb3VzIHRoZSByZXF1aXJlbWVudCB0aGF0DQo+IGJvdGggU1lOIGFuZCBBQ0sgbnVtYmVycyBt dXN0IGJlIHN5bmNocm9uaXplZCBiZWZvcmUgbW92aW5nIHRvIEVzdGFibGlzaGVkDQo+IHN0YXRl IGluIFRDUCkuIFBsZWFzZSBsb29rIGF0DQo+IGRyYWZ0LWhlcmJlcnQtZ3VlLXNlc3Npb24taWQt MDAgZm9yIG1vcmUgb24gdGhpcy4NCj4gDQo+ICJBIFNQVUQgZW5kcG9pbnQgcmVjZWl2aW5nIGEg U1BVRCBoZWFkZXIgd2l0aCB0aW1lb3V0IGluZm9ybWF0aW9uIHNob3VsZA0KPiByZWZsZWN0IHRo aXMgaW5mb3JtYXRpb24gdG8gdGhlIHNlbmRlciIuIFRoaXMgaXMgYSBnb29kIGV4YW1wbGUgb2Yg dGhlIHRydXN0DQo+IHByb2JsZW0uIFdoeSB3b3VsZCB3ZSB0cnVzdCBhbiBlbmRwb2ludCB0byBk byB0aGlzIGNvcnJlY3RseT8gTWF5YmUgdGhleSBqdXN0DQo+IGFsd2F5cyByZXR1cm4gdGhlIHNt YWxsZXN0IHBvc3NpYmxlIHZhbHVlIGluc3RlYWQgd2l0aG91dCBhbnkgcmVnYXJkIHRvIHRoZQ0K PiBjb3N0IGF0IHRoZSBzZW5kZXIgb3IgaXRzIG5ldHdvcmsgZm9yIHNlbmRpbmcgZnJlcXVlbnQg aGVhcnQgYmVhdHMuIEluIHRoaXMgY2FzZSwNCj4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIg Zm9yIHRoZSBtaWRkbGVib3ggKGxvY2FsIHRvIHRoZSBzZW5kZXIpIHRvIHJldHVybiB0aGUNCj4g dGltZW91dCBpbmZvcm1hdGlvbiB0byB0aGUgc2VuZGVyIHVzaW5nIGFuIG91dCBvZiBiYW5kIHBy b3RvY29sLiBBbHNvLCB0aGlzDQo+IG1pZ2h0IG5vdCBiZSBuZWVkZWQgZm9yIGV2ZXJ5IGZsb3cs IGluIHRoZSBjb21tb24gY2FzZSBvZiBhIG5vZGUgYmVpbmcgYmVoaW5kDQo+IGEgc2luZ2xlIGZp cmV3YWxsIGdldHRpbmcgdGhlIHZhbHVlIG9uY2Ugd291bGQgcHJvYmFibHkgc3VmZmljZS4NCj4g DQo+ICJUaGVyZWZvcmUgaXQgaGFzIHRvIHNlbmQgaGVhcnRiZWF0IGZhaXJseSByYXBpZGx5LCBv ciBtaWdodCBhc3N1bWUgYSBkZWZhdWx0DQo+IHZhbHVlIG9mIDE1MG1zIHRoYXQgaXMgY29tbW9u bHkgdXNlZCB0b2RheS4iIFdoZXJlIGRvZXMgdGhpcyB2YWx1ZSBjb21lDQo+IGZyb20/IENvdWxk bid0IHN1Y2ggYSByYXRlIGtpbGwgYmF0dGVyeSBvbiBhIG1vYmlsZSBkZXZpY2U/DQo+IA0KPiAi QW4gYXBwbGljYXRpb24gZG9lcyBub3QgYmVuZWZpdCBmcm9tIHdyb25seSBpbmRpY2F0aW5nIGxv c3MtIG9yDQo+IGxhdGVuY3ktc2Vuc2l0aXZpdHkiIFR5cG8gOi0pLi4uIFRoZSBxdWVzdGlvbiBo ZXJlIGlzIHdoYXQgYXJlIHRoZSBjb25zZXF1ZW5jZXMNCj4gaWYgdHJhZmZpYyBpcyBpbmNvcnJl Y3RseSBtYXJrZWQuIElmIG1pcy1tYXJraW5nIHBhY2tldHMgY2FuIGFkdmVyc2VseSBhZmZlY3QN Cj4gb3RoZXIgbm9uLXJlbGF0ZWQgZmxvd3MgdGhlbiB0aGlzIG1lY2hhbmlzbSBwb3RlbnRpYWxs eSBiZWNvbWVzIHRoZSBiYXNpcyBmb3INCj4gYSBEb1MgYXR0YWNrLiBGb3IgZXhhbXBsZSwgaWYg c29tZW9uZSBhcmJpdHJhcmlseSBkZWNpZGVzIHRvIG1hcmsgYWxsIHRoZWlyDQo+IHBhY2tldHMg YXMgbG93IGxhdGVuY3ksIGluY3JlYXNpbmcgdGhlIGxhdGVuY3kgb2Ygb3RoZXIgZmxvd3Mgb3Ig ZXZlbiB3b3JzZQ0KPiBpbmNyZWFzaW5nIHBhY2tldCBsb3NzIGZvciBvdGhlciBjb3JyZWN0bHkg bWFya2VkIGxvdyBsYXRlbmN5IHRyYWZmaWMgd291bGQgYmUgYQ0KPiBwcm9ibGVtLg0KPiANCj4g VG9tDQo+IA0KPiANCj4gDQo+ID4gQnJpYW4gYW5kIE1pcmphDQo+ID4NCj4gPg0KPiA+DQo+ID4+ IEFuZmFuZyBkZXIgd2VpdGVyZ2VsZWl0ZXRlbiBOYWNocmljaHQ6DQo+ID4+DQo+ID4+IFZvbjog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4+IEJldHJlZmY6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3INCj4gPj4gZHJhZnQta3VlaGxld2luZC1zcHVkLXVzZS1jYXNlcy0wMC50eHQN Cj4gPj4gRGF0dW06IDMuIEp1bGkgMjAxNSAxNzoxOToxMCBNRVNaDQo+ID4+IEFuOiAiTWlyamEg S3VlaGxld2luZCIgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+LCAiTWlyamENCj4g Pj4gS3VlaGxld2luZCIgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+LCAiQnJpYW4g VHJhbW1lbGwiDQo+ID4+IDxpZXRmQHRyYW1tZWxsLmNoPiwgIkJyaWFuIFRyYW1tZWxsIiA8aWV0 ZkB0cmFtbWVsbC5jaD4NCj4gPj4NCj4gPj4NCj4gPj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWt1ZWhsZXdpbmQtc3B1ZC11c2UtY2FzZXMtMDAudHh0DQo+ID4+IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgTWlyamEgS3VlaGxld2luZCBhbmQgcG9zdGVkIHRvIHRoZQ0K PiA+PiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4+DQo+ID4+IE5hbWU6ICAgICAgICAgZHJhZnQta3Vl aGxld2luZC1zcHVkLXVzZS1jYXNlcw0KPiA+PiBSZXZpc2lvbjogICAgIDAwDQo+ID4+IFRpdGxl OiAgICAgICAgICAgICAgICBTUFVEIFVzZSBDYXNlcw0KPiA+PiBEb2N1bWVudCBkYXRlOiAgICAg ICAgMjAxNS0wNy0wMw0KPiA+PiBHcm91cDogICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQo+ID4+IFBhZ2VzOiAgICAgICAgICAgICAgICAxNQ0KPiA+PiBVUkw6DQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rdWVobGV3aW5kLXNwdWQtdXNl LWNhc2VzLTAwLnR4dA0KPiA+PiBTdGF0dXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWt1ZWhsZXdpbmQtc3B1ZC11c2UtY2FzZXMvDQo+ID4+IEh0bWxpemVkOg0K PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta3VlaGxld2luZC1zcHVkLXVzZS1j YXNlcy0wMA0KPiA+Pg0KPiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4gPj4gICBUaGUgU3Vic3RyYXRl IFByb3RvY29sIGZvciBVc2VyIERhdGFncmFtcyAoU1BVRCkgQm9GIHNlc3Npb24gYXQgdGhlDQo+ ID4+ICAgSUVURiA5MiBtZWV0aW5nIGluIERhbGxhcyBpbiBNYXJjaCAyMDE1IGlkZW50aWZpZWQg dGhlIHBvdGVudGlhbCBuZWVkDQo+ID4+ICAgZm9yIGEgVURQLWJhc2VkIGVuY2Fwc3VsYXRpb24g cHJvdG9jb2wgdG8gYWxsb3cgZXhwbGljaXQgY29vcGVyYXRpb24NCj4gPj4gICB3aXRoIG1pZGRs ZWJveGVzIHdoaWxlIHVzaW5nIG5ldywgZW5jcnlwdGVkIHRyYW5zcG9ydCBwcm90b2NvbHMuDQo+ ID4+ICAgVGhpcyBkb2N1bWVudCBzdW1tYXJpemVzIHRoZSB1c2UgY2FzZXMgZGlzY3VzcyBhdCB0 aGUgQm9GIGFuZCB0aGVyZWJ5DQo+ID4+ICAgcHJvcG9zZXMgYSBzdHJ1Y3R1cmUgZm9yIHRoZSBk ZXNjcmlwdGlvbiBvZiBmdXJ0aGVyIHVzZSBjYXNlcy4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4N Cj4gPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YNCj4gPj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+Pg0KPiA+PiBU aGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiBTcHVkIG1haWxpbmcgbGlzdA0KPiA+IFNwdWRAaWV0 Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwdWQNCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNw dWQgbWFpbGluZyBsaXN0DQo+IFNwdWRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zcHVkDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IFNwdWQgbWFpbGluZyBsaXN0DQo+IFNwdWRAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkDQo= From nobody Tue Jul 7 07:22:34 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EF51AC3FC for ; Tue, 7 Jul 2015 07:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 J40khVeOut21 for ; Tue, 7 Jul 2015 07:22:31 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592501AC405 for ; Tue, 7 Jul 2015 07:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2566; q=dns/txt; s=iport; t=1436278951; x=1437488551; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ZL7FezNS7UMajh3aew27Y+p4vB7vakDwkM7Z+sNAMTo=; b=MA2Trtg2zFz3bMz6s2Zir+KoSEWc2+w8fSd4QWIgZvblWS/sWBngwqfF wUJC5n06o4OgPbs5O5XvIQ2HAWpildYSE6IOKa6oxEplGLZJtQg8dv+H0 I47hav77pqf6t85ADkqacmPXIFinUNtFJowEmhGlZUoVsYHJ0sucO/NZ9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BsAwDj35tV/5BdJa1cgxKBNL1sCYdmAoFSOBQBAQEBAQEBgQqEIwEBAQMBJxM9AgULCxgJJQ8FSROIJgjMCwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLS4UGB4QrAQSNC4cNi2gBgTqTQ4NdJoQbHjGCSwEBAQ X-IronPort-AV: E=Sophos;i="5.15,423,1432598400"; d="scan'208";a="13317976" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 07 Jul 2015 14:22:31 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t67EMUOE028132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2015 14:22:30 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t67EMTSq024154; Tue, 7 Jul 2015 07:22:29 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t67EMS0I024152; Tue, 7 Jul 2015 07:22:28 -0700 Date: Tue, 7 Jul 2015 07:22:28 -0700 From: Toerless Eckert To: Tom Herbert Message-ID: <20150707142228.GG27147@cisco.com> References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Brian Trammell , mirja.kuehlewind@tik.ee.ethz.ch, spud@ietf.org Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 14:22:33 -0000 > On 06 Jul 2015, at 19:20, Tom Herbert wrote: > It seems to me there are two motivations for SPUD: > > 1) A common protocol layer for UDP flow based protocols to pass > through stateful firewalls and NAT. > 2) A rich inband flow based QoS signaling initiated by end hosts which > can be interpreted by network devices in the path. Point 2 already expanded by Mirja - not only QoS, but any form of policy. > > The second motivation is less clear. Disregarding previously raised > questions around new DoS vectors and whether we can ever trust > anything anyone says on the Internet, I would ask if SPUD (UDP) is the > right layer for this. The need for this signaling doesn't seem to be > specific to UDP transport protocols, but also should applicable to > TCP, SCTP, and other protocols. Barring that these protocols > transition to running over SPUD (unlikely in the foreseeable future), > it seems like such signaling should be implemented in a more common > layer, maybe something like IP options. You just mentioned two key goals. I think there are four: 1) Common connection layer for transport protocols (your 1) for signaling application<->network middleboxes 2) Common policy signaling layer for transport flows (your 2) for signaling application<->network middleboxes 3) 1) and 2) shareable by existing AND novel transport protocols [Existing protocols may duplicate some of 1) and 2) but without the ability to signal application<->network well0 4) Ability to build 1)..3) at the application layer Aka: Outside the classical OS to app boundary Aka: After OS demultiplexing Aka: faster developed, deployed, security-fixed, enhanced,... than our existing IETF protocol stack model. Aka: must be on top of UDP. I contend your statement that we will not be able to have reliable transport protocols run over SPUD. Of course, there is a lot of work to create successfull proliferation: Browsers, RTCweb, IoT protocol stacks, Cross-OS Open Source stacks are IMHO four key targets which are necessary and sufficient to make the SPUD strategy work. Your mentioning of IP options is quite correct in the face of the historic OS protocol stack. And we need to change this: OS: routing/forwarding (IPv6) OS app-demultiplex (UDP) Base SDK, bound to OS-app: connection signaling policy/QoS signaling (un)reliable/realtime flow managemenet ("transport") Higher layer SDK: Eg: Browser Higher layer app Cheers Toerless From nobody Tue Jul 7 08:13:56 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760C31ACDAA for ; Tue, 7 Jul 2015 08:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 M7vouvbq-eyt for ; Tue, 7 Jul 2015 08:13:53 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EF21ACDA7 for ; Tue, 7 Jul 2015 08:13:53 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-00-559becaf27b8 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7B.5C.29223.FACEB955; Tue, 7 Jul 2015 17:13:51 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0210.002; Tue, 7 Jul 2015 17:13:50 +0200 From: Szilveszter Nadas To: "spud@ietf.org" Thread-Topic: draft-mihaly-spud-mb-communication (Was: SPUD Scope?) Thread-Index: AdC4xALWvXDbKpYzRSChSQfDiJi8bA== Date: Tue, 7 Jul 2015 15:13:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvje76N7NDDd4fF7dYc6KPxaK1+zOT xaILTxktVn27xOLA4tH6bC+rx9nudlaPJUt+MnncfnicJYAlissmJTUnsyy1SN8ugStj66O0 gh0KFX/nrWVpYFwp1cXIySEhYCJxYuN8ZghbTOLCvfVsILaQwFFGiZ59ll2MXED2IkaJ1dOm gSXYBCwkGlZuBrNFBJQl1t5ZxA5SxCxwh1Hi3Nn9YJOEBewkHn3pY4UocpboXL8HyOYAsvUk XpwOAQmzCKhINO26zQJi8wr4Shz9PQ2snBHoiO+n1jCB2MwC4hK3nsxngjhOQGLJnvNQh4pK vHz8D2ykhICSxLStaRDlehI3pk5hg7C1JZYtfM0MMV5Q4uTMJywTGEVmIZk6C0nLLCQts5C0 LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGDMHt/w22MH48rnjIUYBDkYlHt4FRrND hVgTy4orcw8xSnOwKInzzticFyokkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMdFY/cZegeC/ n9e9uph8SLNm51z58rCFzWquvRt3KGkdKa5aEfPCecfdXcdqlZeGlbxeUOD6Nf3DPtFO7Ys/ m3zEqvqsnuWu25GYaJWuG/xo3RGzDcvnPnp85tD0c3V3dfJ2fj4TW+tnaqdw5NHFPOafimfj wydM2e4z/ZvAlU+v/0uYTUjYt1mJpTgj0VCLuag4EQBCIsH6egIAAA== Archived-At: Cc: Ken Calvert , =?iso-8859-1?Q?Attila_Mih=E1ly?= , "FOSSATI, Thomas \(Thomas\)" , Daniel Kahn Gillmor Subject: [Spud] draft-mihaly-spud-mb-communication (Was: SPUD Scope?) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 15:13:55 -0000 Hi, We wrote a draft about our ideas on how to support uneven resource sharing = among users in the SPUD way. We intend to show a way forward in addressing = the following concerns: -The endpoints have an incentive to lie, how can we create the right incent= ive for them to ask for higher resource share only when they need it. -The choice of QoS shall be given to user, to be fair. At the same time thi= s would require bothersome user interaction, which would itself ruin the ex= perience of the user. We tried to design a framework that builds on the existing QoS architecture= s and the existing subscription models, and where the users may control whi= ch applications and when to use a specific service delivery option. Last bu= t not least, it is fair to the users. We exploit the Advantage of SPUD (-li= ke) protocol: simple in-band signaling where with incremental usefulness wh= ere no mandatory minimum vocabulary needed, ensures data confidentiality. Comments are welcome! Cheers, Sz. Name: draft-mihaly-spud-mb-communication Revision: 00 Title: Middlebox Communication Enabling for Enhanced User Experience Document date: 2015-07-06 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-mihaly-spud-mb-c= ommunication-00.txt Status: https://datatracker.ietf.org/doc/draft-mihaly-spud-mb-commu= nication/ Htmlized: https://tools.ietf.org/html/draft-mihaly-spud-mb-communicat= ion-00 Abstract: In this draft we address some of the key discussion points related to the scope of Substrate Protocol for User Datagrams (SPUD). Specifically, we show how we can define the middlebox communication framework such that it allows uneven resource sharing on the path among the endpoints enhancing in this way the user experience. Issues related to trust and incentives as well as how to support user decisions in this eco-system are clarified. -----Original Message----- From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Szilveszter Nadas Sent: Monday, June 08, 2015 16:20 To: FOSSATI, Thomas (Thomas); Ken Calvert; Daniel Kahn Gillmor Cc: spud@ietf.org Subject: Re: [Spud] SPUD Scope? Hi, >>Yes, the path is fraught with challenges; I don't disagree with most=20 >>of your points. On the other hand, call me an optimist, but I believe=20 >>such a mechanism could not only help break the "ossification" logjam,=20 >>but perhaps eventually shift the balance of power back toward the end=20 >>users by giving them more choices w.r.t. network services. I share the same belief. I think that middleboxes must demonstrate their value for one of the ends i= n order to receive metadata. This is what I mean on them being explicit. Ho= wever if they do demonstrate then I believe in giving them the information = they want.=20 I personally prefer that even without metadata a reasonable default service= is available. How to achieve this is a good question. I guess regulators h= ave bigger rule here than engineers. Though I believe that engineers are re= sponsible to educate regulators to find the right path. Without the right r= egulation blocking when not getting metadata can always happen even if we m= ake it harder with protocol design. >I totally agree with you, as long as the underlying principles are: >- explicit vs implicit service; >- ability of endpoints to choose based on clear information about the=20 >service value vs leaked meta-data; >- preservation of e2e security properties. > >I think the biggest (though not insurmountable) challenges are: >- UX (as already noted by Daniel); >- scale mechanism to n middle boxes. > >We probably need a good deal of research to solve scale and UX, and I hope= stackevo has enough breath to account for this. I agree. I am thinking about writing a draft along these lines and also inc= lude some example use cases with "good" cooperation examples. Cheers, Sz. _______________________________________________ Spud mailing list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud From nobody Wed Jul 8 08:54:10 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6422C1A00FA for ; Wed, 8 Jul 2015 08:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 IPBwD_u3LKzG for ; Wed, 8 Jul 2015 08:54:06 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979981A00F7 for ; Wed, 8 Jul 2015 08:54:06 -0700 (PDT) Received: by iecuq6 with SMTP id uq6so158453803iec.2 for ; Wed, 08 Jul 2015 08:54:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M4BRKetzsaqlaByZ10NcJK8iOnBF3uCszkcSBeSMAa8=; b=Lajzw4WO/sVZuzipWEO3LiN6ua/NJ8hBcv5rNQ0QhUMSAghQTlTSN28evxiKDoSznM +lmBdnUggH8ca+XqSN0hC3eh7D+NaRv+NGlrExBkQQ2epKl0if1YSPMxBKmCsV2hDcUs vUvYo6WR3QeMGOSAkz711LfK81jVGvP/iT3UUWqH/0D5drUJY2n6Rw6veWK8fxFad/TF rY9hsmbOEwQ/wetxSYn5Bpqwa/4AaaksLpWG1EF4F2MCBtBy7AXLa22+qLaAo2boh+bq a0cK0+mdN7vNycDWUicJCBJbXy5iqsggVUE/652uCO0DG5mm2P2eEgaSoaHEAWsSsr2f LQMg== X-Gm-Message-State: ALoCoQk3Skagtkz6aI+bA2z0qp43h2HN4T93ZrrnMVVbi2dSGv1Se5NqHyO5HTjjticU7iTWD/rZ MIME-Version: 1.0 X-Received: by 10.107.41.146 with SMTP id p140mr17402105iop.58.1436370845886; Wed, 08 Jul 2015 08:54:05 -0700 (PDT) Received: by 10.107.142.86 with HTTP; Wed, 8 Jul 2015 08:54:05 -0700 (PDT) In-Reply-To: <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> Date: Wed, 8 Jul 2015 08:54:05 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud@ietf.org Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 15:54:08 -0000 On Tue, Jul 7, 2015 at 6:43 AM, Brian Trammell wrote: > Hi, Tom, > >> On 06 Jul 2015, at 19:20, Tom Herbert wrote: >> >> On Fri, Jul 3, 2015 at 8:24 AM, Mirja K=C3=BChlewind >> wrote: >>> Hi all, >>> >>> we=E2=80=99ve just submitted a new use case document. This document des= cribes in more detail the use cases as already presented/discussed at the B= oF. >>> >>> Please review and comment. Also partial reviews of e.g. just one use ca= se are more than welcome. Further if you=E2=80=99d like to contribute to th= is document, please let use know as well. >>> >> Hi Mirja, thanks for the draft! Here are my comments. >> >> General comments: >> >> It seems to me there are two motivations for SPUD: >> >> 1) A common protocol layer for UDP flow based protocols to pass >> through stateful firewalls and NAT. >> 2) A rich inband flow based QoS signaling initiated by end hosts which >> can be interpreted by network devices in the path. > > Kind of, though it's not *strictly* QoS focused. > > There's also (1.5): enable network management functionality which today u= ses DPI but will no longer function with increasing payload encryption. But= the current draft doesn't go into much depth on this point. > >> The first motivation seems pretty clear, the inability to pass UDP >> (really anything besides TCP) through stateful firewalls has impeded >> deployment of new L4 protocols. >> >> The second motivation is less clear. Disregarding previously raised >> questions around new DoS vectors and whether we can ever trust >> anything anyone says on the Internet, I would ask if SPUD (UDP) is the >> right layer for this. The need for this signaling doesn't seem to be >> specific to UDP transport protocols, but also should applicable to >> TCP, SCTP, and other protocols. Barring that these protocols >> transition to running over SPUD (unlikely in the foreseeable future), >> it seems like such signaling should be implemented in a more common >> layer, maybe something like IP options. > > I tend to think that the signaling vocabulary and encoding(s) should be d= efined *separately* from the mechanism to bind that encoding into the proto= col stack. Taking draft-hildebrand-spud-prototype as an example, one could = define a set of CBOR keys that one must understand for a given SPUD applica= tion (say, the low latency use case), and then bind those CBOR keys into us= erspace transports using SPUD, into IPv6 traffic using hop-by-hop and/or de= stination options (in a world in which those work), etc. > > In any case, I think at *minimum* any layer supporting this has to be abl= e to run over UDP, by process of elimination -> you can't always add things= to the kernel or get privilege to open a raw socket (i.e. requirement 6.3 = in draft-trammell-spud-req). > IP is the least common denominator and so use of IP options would be applicable to all IP protocols, not just a new application based protocol that currently has zero deployment. This is the appropriate place for the policy/QoS information information described in the use cases, and there are already facilities for both hop-by-hop options and allowing middle boxes to modify options inflight. The ability for applications and receive and arbitrary list of IP options has long been supported in kernels (IP_OPTIONS and IP_RECVOPTS socket options), so I really don't see any argument that kernel can't provide necessary support. Tom From nobody Wed Jul 8 09:25:31 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0E1A03A3 for ; Wed, 8 Jul 2015 09:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Bd3ijgTWL4jb for ; Wed, 8 Jul 2015 09:25:28 -0700 (PDT) Received: from mail3.netlab.uky.edu (wonder.netlab.uky.edu [128.163.140.37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0941A01FA for ; Wed, 8 Jul 2015 09:25:27 -0700 (PDT) Received: from culp.local (cpe-96-29-182-38.kya.res.rr.com [96.29.182.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail3.netlab.uky.edu (Postfix) with ESMTPSA id 6ECFDC078; Wed, 8 Jul 2015 12:25:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ken Calvert In-Reply-To: Date: Wed, 8 Jul 2015 12:25:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> To: Tom Herbert X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 16:25:30 -0000 >>> The first motivation seems pretty clear, the inability to pass UDP >>> (really anything besides TCP) through stateful firewalls has impeded >>> deployment of new L4 protocols. >>>=20 >>> The second motivation is less clear. Disregarding previously raised >>> questions around new DoS vectors and whether we can ever trust >>> anything anyone says on the Internet, I would ask if SPUD (UDP) is = the >>> right layer for this. The need for this signaling doesn't seem to be >>> specific to UDP transport protocols, but also should applicable to >>> TCP, SCTP, and other protocols. Barring that these protocols >>> transition to running over SPUD (unlikely in the foreseeable = future), >>> it seems like such signaling should be implemented in a more common >>> layer, maybe something like IP options. >>=20 >> I tend to think that the signaling vocabulary and encoding(s) should = be defined *separately* from the mechanism to bind that encoding into = the protocol stack. Taking draft-hildebrand-spud-prototype as an = example, one could define a set of CBOR keys that one must understand = for a given SPUD application (say, the low latency use case), and then = bind those CBOR keys into userspace transports using SPUD, into IPv6 = traffic using hop-by-hop and/or destination options (in a world in which = those work), etc. >>=20 >> In any case, I think at *minimum* any layer supporting this has to be = able to run over UDP, by process of elimination -> you can't always add = things to the kernel or get privilege to open a raw socket (i.e. = requirement 6.3 in draft-trammell-spud-req). >>=20 > IP is the least common denominator and so use of IP options would be > applicable to all IP protocols, not just a new application based > protocol that currently has zero deployment. This is the appropriate > place for the policy/QoS information information described in the use > cases, and there are already facilities for both hop-by-hop options > and allowing middle boxes to modify options inflight. The ability for > applications and receive and arbitrary list of IP options has long > been supported in kernels (IP_OPTIONS and IP_RECVOPTS socket options), > so I really don't see any argument that kernel can't provide necessary > support. Seems like the 40-byte limit in v4 would make it difficult to do some = things you might want to do, especially as hash sizes keep growing. I like the viewpoint someone (Brian, I think) suggested earlier: the = network layer header effectively includes the UDP header. So SPUD = could be viewed as a way of carrying network layer options (in addition = to transport info). Ken Calvert= From nobody Wed Jul 8 09:27:47 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2E1A09C9 for ; Wed, 8 Jul 2015 09:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 igPi5IgoInCo for ; Wed, 8 Jul 2015 09:27:33 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id A48971A03A1 for ; Wed, 8 Jul 2015 09:27:32 -0700 (PDT) Received: from nb-10604.ethz.ch (nb-10604.ethz.ch [82.130.102.91]) by trammell.ch (Postfix) with ESMTPSA id 18A5F1A0398; Wed, 8 Jul 2015 18:27:31 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8F84606F-5EE7-41C6-B417-2676407E2602"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: Date: Wed, 8 Jul 2015 18:27:31 +0200 Message-Id: <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> To: Tom Herbert X-Mailer: Apple Mail (2.2102) Archived-At: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud@ietf.org Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 16:27:42 -0000 --Apple-Mail=_8F84606F-5EE7-41C6-B417-2676407E2602 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 08 Jul 2015, at 17:54, Tom Herbert wrote: >=20 > On Tue, Jul 7, 2015 at 6:43 AM, Brian Trammell = wrote: >> Hi, Tom, >>=20 >>> On 06 Jul 2015, at 19:20, Tom Herbert wrote: >>>=20 >>> On Fri, Jul 3, 2015 at 8:24 AM, Mirja K=C3=BChlewind >>> wrote: >>>> Hi all, >>>>=20 >>>> we=E2=80=99ve just submitted a new use case document. This document = describes in more detail the use cases as already presented/discussed at = the BoF. >>>>=20 >>>> Please review and comment. Also partial reviews of e.g. just one = use case are more than welcome. Further if you=E2=80=99d like to = contribute to this document, please let use know as well. >>>>=20 >>> Hi Mirja, thanks for the draft! Here are my comments. >>>=20 >>> General comments: >>>=20 >>> It seems to me there are two motivations for SPUD: >>>=20 >>> 1) A common protocol layer for UDP flow based protocols to pass >>> through stateful firewalls and NAT. >>> 2) A rich inband flow based QoS signaling initiated by end hosts = which >>> can be interpreted by network devices in the path. >>=20 >> Kind of, though it's not *strictly* QoS focused. >>=20 >> There's also (1.5): enable network management functionality which = today uses DPI but will no longer function with increasing payload = encryption. But the current draft doesn't go into much depth on this = point. >>=20 >>> The first motivation seems pretty clear, the inability to pass UDP >>> (really anything besides TCP) through stateful firewalls has impeded >>> deployment of new L4 protocols. >>>=20 >>> The second motivation is less clear. Disregarding previously raised >>> questions around new DoS vectors and whether we can ever trust >>> anything anyone says on the Internet, I would ask if SPUD (UDP) is = the >>> right layer for this. The need for this signaling doesn't seem to be >>> specific to UDP transport protocols, but also should applicable to >>> TCP, SCTP, and other protocols. Barring that these protocols >>> transition to running over SPUD (unlikely in the foreseeable = future), >>> it seems like such signaling should be implemented in a more common >>> layer, maybe something like IP options. >>=20 >> I tend to think that the signaling vocabulary and encoding(s) should = be defined *separately* from the mechanism to bind that encoding into = the protocol stack. Taking draft-hildebrand-spud-prototype as an = example, one could define a set of CBOR keys that one must understand = for a given SPUD application (say, the low latency use case), and then = bind those CBOR keys into userspace transports using SPUD, into IPv6 = traffic using hop-by-hop and/or destination options (in a world in which = those work), etc. >>=20 >> In any case, I think at *minimum* any layer supporting this has to be = able to run over UDP, by process of elimination -> you can't always add = things to the kernel or get privilege to open a raw socket (i.e. = requirement 6.3 in draft-trammell-spud-req). >>=20 > IP is the least common denominator and so use of IP options would be > applicable to all IP protocols, As to appropriateness, yes, I agree completely. > not just a new application based > protocol that currently has zero deployment. ...which I will note is precisely as much deployment as any IP options = based approach would have on day zero; the question of how to get the = data into the packet is IMO separate from the adoption of the data model = of the exposed data itself. > This is the appropriate > place for the policy/QoS information information described in the use > cases, and there are already facilities for both hop-by-hop options > and allowing middle boxes to modify options inflight. Indeed. This presumes that new IP options are more realistically widely = deployable in the Internet than a new protocol over UDP. I would need to = see some data to back that up (indeed, this would fit nicely in a = measurement study we're running right now so we may well end up = generating that data. :) ) > The ability for > applications and receive and arbitrary list of IP options has long > been supported in kernels (IP_OPTIONS and IP_RECVOPTS socket options), > so I really don't see any argument that kernel can't provide necessary > support. ...which at least makes these accessible from platforms which let the = apps muck about with socket options. Thanks, cheers, Brian >=20 > Tom >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_8F84606F-5EE7-41C6-B417-2676407E2602 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVnU9zAAoJENt3nsOmbNJcv2YIAKk51jsky/+2aWPoRw+RwltB M76KnmGR4QO9HnvJW9KABnmckiLKHTX2xdPbdHCa5l7nxiJuY19KNKHje4zcucf+ TKOoFb6d5dUKm7UjVfauENgJybpvKIAXIuoVHLe3lf0prNS6qojhhmg5tSIAQD1L V9cP73MByVNWeQUocS1hqb9/Qi1Wy0t6ryN+tMYivdJ35dE/9PSJp18Iqg1qI2lD x9yT//l8A5RCryu2LzA6CfEkPD4LaZSmEAAdhJnCO1pLn+doarFk5lFSn7hDCuZ0 c8RzrCg817kCiUZe+oRUwFdnV7XuhYjYAOk9USSu4be7nRYNtp2qd8xvjiNrKIg= =4u89 -----END PGP SIGNATURE----- --Apple-Mail=_8F84606F-5EE7-41C6-B417-2676407E2602-- From chappellind@gmail.com Wed Jul 8 10:32:26 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE16B1A1B96 for ; Wed, 8 Jul 2015 10:32:26 -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 PYrJnbEScfJ4 for ; Wed, 8 Jul 2015 10:32:25 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA581A1B95 for ; Wed, 8 Jul 2015 10:32:25 -0700 (PDT) Received: by igau2 with SMTP id u2so69009617iga.0 for ; Wed, 08 Jul 2015 10:32:24 -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:content-type; bh=VK/M86gE1m9f7lvJwF50Ci+863z/8OsXGtjOF9jhkVg=; b=bWE1Je8gfRx8xVDofnLJ7ewp+MzphdhGRulEEYjmJDFV1EDwxjKtgbG3WiTrGi9LFO w+xCwjTLJWxbDa7u5Zmy0EdbD1T2v00qqHvdm+sS/foQCp+cVnXBrX0w9I7yrMCA/3ry ZEw/Rdbyq9Ck5S3/iVfq1FS8XOio4uDRSH+2AreqaIF2dDHIrIBe6dUBog6TAXH08hhb 16he0cY9GwhR4ruxpQfdzX7I+sL9suGgLHkXqztqdTcUTp0NgjnRDPDgiyVQeia6Pnsk Ij3jrvvj9JQ75J8MRDMuKq2imN839f8E3OPAjA+cS9gh0kH8hhz8Gy93T3fnwt/2eMGz /v2w== MIME-Version: 1.0 X-Received: by 10.50.79.169 with SMTP id k9mr88461685igx.44.1436376744647; Wed, 08 Jul 2015 10:32:24 -0700 (PDT) Received: by 10.36.86.66 with HTTP; Wed, 8 Jul 2015 10:32:24 -0700 (PDT) Date: Wed, 8 Jul 2015 13:32:24 -0400 Message-ID: From: Jacob Chappell To: spud@ietf.org Content-Type: multipart/alternative; boundary=089e013a01c8a0e6ec051a608579 Archived-At: Subject: [Spud] Connect and ACK Bits: Why? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 17:33:14 -0000 --089e013a01c8a0e6ec051a608579 Content-Type: text/plain; charset=UTF-8 Good afternoon, everyone. There's been something bothering me since I started working with SPUD. Now that I realize there's a mailing list, I figure why not ask here? My question is, why is connect/ack part of the SPUD protocol? The purpose of these commands does not seem clear from the draft. For one, SPUD runs over UDP, so there's no guarantee the connect or ack will even make it to the other side. Second, a previous message on this mailing list from the archives indicates that you don't even have to wait for an ack to send a data packet. This makes sense, because the ack may be lost in transit (or maybe the original connect was lost in transit). But if this is the case, what's the point in even having connect/ack as part of the protocol? It seems like a possible alternative would be to just send data packets spontaneously. The client can just be sure to generate a new tube ID when sending to a new destination/port pair, and maintain that state. Ultimately, you're going to have to use timers to expire state in case of packet loss, so why not just use timers exclusively? Jacob Chappell --089e013a01c8a0e6ec051a608579 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good afternoon, everyone.

There'= s been something bothering me since I started working with SPUD. Now that I realize there's a mailing list, I figure why not ask here?

My question is, why is connect/ack part of the SPUD protocol? The purpose=20 of these commands does not seem clear from the draft. For one, SPUD runs over UDP, so there's no guarantee the connect or ack will even make it= =20 to the other side. Second, a previous message on this mailing list from=20 the archives indicates that you don't even have to wait for an ack to= =20 send a data packet. This makes sense, because the ack may be lost in=20 transit (or maybe the original connect was lost in transit). But if this is the case, what's the point in even having connect/ack as part of th= e protocol?

It seems like a possible alternative would be to just send data packets=20 spontaneously. The client can just be sure to generate a new tube ID=20 when sending to a new destination/port pair, and maintain that state.=20 Ultimately, you're going to have to use timers to expire state in case= =20 of packet loss, so why not just use timers exclusively?

Jac= ob Chappell
--089e013a01c8a0e6ec051a608579-- From nobody Wed Jul 8 10:35:27 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE971A1B96 for ; Wed, 8 Jul 2015 10:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 SNFQIqYYCmIx for ; Wed, 8 Jul 2015 10:35:25 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C39B1A1BA7 for ; Wed, 8 Jul 2015 10:35:24 -0700 (PDT) Received: by wifm2 with SMTP id m2so96445160wif.1 for ; Wed, 08 Jul 2015 10:35:23 -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:content-type; bh=gF4L8W6vjuJn5b6TJMFMa12urzsGd17mmHUcX97TuHE=; b=VN1Xm3zVY8lm/d0HjjuvSGFPdULkzVMZMaJ6GsMrrA58ToAjVzIbxEPZ58GeUE3nhs 0NKa6KtymqLcVtoBfKFcP7S3q3LzG34UEjX6FiUzA1h221AAzBbNmFs2IffOCwn8Acuu yndTPptQCy3Kpa+6yK/OrThISpNpmDDK/lPiy4x8Ht5K43OpsBTc6CP7ZWroRaNsE8ql Qp4Ds9Kt1N46MrvlXvmb4XmzeNV5ANB2Z9w3C8b5YuYYqU/dqJm1IPVwQOoLwPTqlT/g kjjvvz1hr7U2nKYxrVW9kSttM8vzC36jGZXAfTQ8coo+Fw5P3Y2tTFH8icpIKWTRCsPw cAwQ== MIME-Version: 1.0 X-Received: by 10.181.11.229 with SMTP id el5mr76019109wid.40.1436376923276; Wed, 08 Jul 2015 10:35:23 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Wed, 8 Jul 2015 10:35:23 -0700 (PDT) Date: Wed, 8 Jul 2015 10:35:23 -0700 Message-ID: From: Ted Hardie To: "spud@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c8004468a03051a6090f7 Archived-At: Subject: [Spud] The draft's questions X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 17:35:27 -0000 --f46d043c8004468a03051a6090f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, the draft asks the following questions, which I am going to answer based on a simple prejudice: do the simplest thing that can possibly work. I'd be interested to hear other answers and the design rationale behind them. * Can one packet belong to multiple tubes? Nope. If an overlying protocol needs the same payload in multiple tubes, it needs new packets for each. Rationale: the number of times this is going to come up seems small for the overhead it would take to support carrying the different tube-ids within the same packet. * Do all packets in a five-tuple flow have to belong to one tube? Nope. As the WebRTC bundle use cases shows, you may have a single five-tuple with multiple tubes wanting different treatment by the network. For the related question of "Must all packets in a five-tuple flow have tube-ids if some do?", my answer is still "Nope". If you're not calling out a grouping of packets for separate treatment by the network, it's up to you whether you assign a tube-id and say "nothing special needed" or assign no tube-id at all. I'd do the latter, because of the "simplest possible thing" principle. * Can/Must the backward flow have the same tube ID or a different one? I don't think it MUST. I'm of the opinion that it likely isn't a great idea in general, but you probably need to be able to handle the case where they are, just for the accidental collision case. (Depending on the mechanism for generating them, not handling that would make for some deeply random and very occasional failures). Ken Calvert has pointed out that if you actually want different treatment in the forward and reverse direction that having a different tube-id makes this easier, and that's probably a good enough reason for a SHOULD NOT. * Especially at connection start-up, depending on the semantics of the overlying transport protocol, there likely might be only one packet to start multiple streams/tubes. Can this start message signal multiple tube IDs at once or do we need an own start message for each tube? If the "Nope" above, holds this, doesn't arise. If you want to talk about a tube, send a message about that tube, independently of messages for other tubes. For the multiplexed-on-a-five-tuple case, you are then getting a message per tube, rather than per five-tuple, but that's the cost of independent treatment by the network. If you don't want independent treatment, put them in the same tube. * Or is it in this case not possible to have multiple tubes within one five-tuple? =E2=80=8BSee above. Any other prejudices/answers folks want to share? regards, Ted --f46d043c8004468a03051a6090f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, the draft asks the following questions, which I am going to answer=20 based on a simple prejudice:=C2=A0 do the simplest thing that can possibly= =20 work.=C2=A0 I'd be interested to hear other answers and the design rati= onale=20 behind them.

* Can one packet belong to multiple tubes?

Nope.=C2=A0 If an overlying protocol needs the same payload in multiple tubes, it=20 needs new packets for each.=C2=A0 Rationale:=C2=A0 the number of times this= is=20 going to come up seems small for the overhead it would take to support=20 carrying the different tube-ids within the same packet.
=
* Do all packets in a five-tuple flow have to belong to one tube?

Nope.=C2=A0 As the WebRTC bundle use cases shows, you may have a single five-tuple=20 with multiple tubes wanting different treatment by the network.=C2=A0
<= br>For the related question of "Must all packets in a five-tuple flow = have tube-ids if some do?", my answer is still "Nope".=C2=A0= If you're not calling out a grouping of packets for separate treatment= by the network, it's up to you whether you assign a tube-id and say &q= uot;nothing special needed" or assign no tube-id at all.=C2=A0 I'd= do the latter, because of the "simplest possible thing" principl= e.

* Can/Must the backward flow have the same tube I= D or a different one?

I don't think it MUST.=C2=A0 I'm of the opinion that it likely isn&#= 39;t a great=20 idea in general, but you probably need to be able to handle the case=20 where they are, just for the accidental collision case. (Depending on=20 the mechanism for generating them, not handling that would make for some deeply random and very occasional failures).=C2=A0 Ken Calvert has pointed= out that if you actually want different treatment in the forward and rever= se direction that having a different tube-id makes this easier, and that= 9;s probably a good enough reason for a SHOULD NOT.

=
*=C2=A0 Especially at connection start-up, depending on the semantics of the overlying transport protocol, there likely might be only one packet to start multiple streams/tubes. Can this start message signal multiple tube IDs at once or do we need an own start message for each tube?

If the "Nope" above, holds this, doesn't arise.=C2=A0 If you wa= nt to talk about a tube, send a message about that tube, independently of messages for=20 other tubes.=C2=A0 For the multiplexed-on-a-five-tuple case, you are then= =20 getting a message per tube, rather than per five-tuple, but that's the= =20 cost of independent treatment by the network.=C2=A0 If you don't want= =20 independent treatment, put them in the same tube.=C2=A0

* Or is it in this case not possible to have multiple tubes within one five-tuple?

=E2=80=8BSe= e above.

Any other prejudices/answers folks want to share?


<= /div>
regards,

Ted
--f46d043c8004468a03051a6090f7-- From nobody Wed Jul 8 13:07:51 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3861A877E for ; Wed, 8 Jul 2015 13:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 1eh6L9y1xkKz for ; Wed, 8 Jul 2015 13:07:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377BA1A877C for ; Wed, 8 Jul 2015 13:07:48 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t68K7TO9020182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Jul 2015 13:07:30 -0700 (PDT) Message-ID: <559D8301.2020604@isi.edu> Date: Wed, 08 Jul 2015 13:07:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian Trammell , Tom Herbert References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> In-Reply-To: <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud@ietf.org, =?windows-1252?Q?Mirja_K=FChlewind?= , touch@isi.edu Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 20:07:49 -0000 On 7/8/2015 9:27 AM, Brian Trammell wrote: >> This is the appropriate >> > place for the policy/QoS information information described in the use >> > cases, and there are already facilities for both hop-by-hop options >> > and allowing middle boxes to modify options inflight. > > Indeed. This presumes that new IP options are more realistically > widely deployable in the Internet than a new protocol over UDP. I would > need to see some data to back that up (indeed, this would fit nicely in > a measurement study we're running right now so we may well end up > generating that data. :) ) Check the discussions over in v6ops. There has been a lot of work there trying to deprecate all IPv6 options, which has at least been successful in limiting the length of the option chain. One challenge is that IPv6 options are processed differently than IPv4 - there's no way to "jump" straight into the transport header to find ports (for port-based load balancing, e.g.). I suspect you'll find that IP options are basically a non-starter except for research purposes. Joe From nobody Wed Jul 8 13:08:47 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0533D1A8761 for ; Wed, 8 Jul 2015 13:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 tryalKRkQGmd for ; Wed, 8 Jul 2015 13:08:45 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084531A8716 for ; Wed, 8 Jul 2015 13:08:45 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t68K8Ri1020346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Jul 2015 13:08:28 -0700 (PDT) Message-ID: <559D833B.4090506@isi.edu> Date: Wed, 08 Jul 2015 13:08:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ken Calvert , Tom Herbert References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud@ietf.org, touch@isi.edu Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 20:08:46 -0000 On 7/8/2015 9:25 AM, Ken Calvert wrote: > I like the viewpoint someone (Brian, I think) suggested earlier: the > network layer header effectively includes the UDP header. See my other post on this thread; getting at the UDP header from IP can be cumbersome in IPv6. > So SPUD > could be viewed as a way of carrying network layer options (in > addition to transport info). Not options you expect core routers to examine, IMO. Joe From nobody Wed Jul 8 22:23:06 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253A11A906C for ; Wed, 8 Jul 2015 22:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zo15uvUPGHlm for ; Wed, 8 Jul 2015 22:23:02 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFE21A9067 for ; Wed, 8 Jul 2015 22:23:02 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2:61f9:1bc6:c857:2ec5] (unknown [IPv6:2001:470:26:9c2:61f9:1bc6:c857:2ec5]) by trammell.ch (Postfix) with ESMTPSA id 7BE8D1A02E6; Thu, 9 Jul 2015 07:23:01 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0FC16AC7-0AE8-4023-A26D-7E2EA2193AA7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: <559D8301.2020604@isi.edu> Date: Thu, 9 Jul 2015 07:23:01 +0200 Message-Id: <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Tom Herbert , =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud@ietf.org Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 05:23:04 -0000 --Apple-Mail=_0FC16AC7-0AE8-4023-A26D-7E2EA2193AA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Joe, all, > On 08 Jul 2015, at 22:07, Joe Touch wrote: >=20 >=20 >=20 > On 7/8/2015 9:27 AM, Brian Trammell wrote: >>> This is the appropriate >>>> place for the policy/QoS information information described in the = use >>>> cases, and there are already facilities for both hop-by-hop options >>>> and allowing middle boxes to modify options inflight. >>=20 >> Indeed. This presumes that new IP options are more realistically >> widely deployable in the Internet than a new protocol over UDP. I = would >> need to see some data to back that up (indeed, this would fit nicely = in >> a measurement study we're running right now so we may well end up >> generating that data. :) ) >=20 > Check the discussions over in v6ops. >=20 > There has been a lot of work there trying to deprecate all IPv6 = options, > which has at least been successful in limiting the length of the = option > chain. >=20 > One challenge is that IPv6 options are processed differently than IPv4 = - > there's no way to "jump" straight into the transport header to find > ports (for port-based load balancing, e.g.). Yep. If the option chain had a small and easily-hardware-determinable = set of possible lengths -- which is the case for v4 options -- this = would be easier (but still harder to handle on the fast path than the = arrangements we're proposing here). > I suspect you'll find that IP options are basically a non-starter = except > for research purposes. For the story on the v4 side, do you know of anything newer than Fonseca = et al "IP Options are Not and Option" (tech report version at = http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's = ten years old -- but given where the engineering effort has gone during = that decade, I doubt strongly much has changed here. Cheers, Brian > Joe >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_0FC16AC7-0AE8-4023-A26D-7E2EA2193AA7 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVngU1AAoJENt3nsOmbNJcrUgIAKHhXX1kUm8Kg7wZks/hPem5 upn80TwdB6Y8q0ywyUrWW938uxetAyaX/1Tv18XgRgCXMf16NB0vrUDWnp+HYSRA G8bBLhPkJMmAy0xS1u8xtcI3M9xCRiOhg0LLt5gDk97jPZfGBDBJyPLcZp/ssE8J O8+h7anHrZsVzepTR9eSl8OPBW1dl/TkfQ6jO1z1Gbo0dqO0uOofrNj4kGzboRLR vHGzcQvHKnNh+8bwOjHPTNjPdI0nObNYuUUGFx5Ny+qNzciClRmUlES15jm9OwWy 6n//kLKLqafmgEORruNjCHQuQoSFn1ii+VjjSmRBN0lUS12A/eg8EmAWH9nrMZQ= =o/7t -----END PGP SIGNATURE----- --Apple-Mail=_0FC16AC7-0AE8-4023-A26D-7E2EA2193AA7-- From nobody Thu Jul 9 00:43:05 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502FB1AC44D for ; Thu, 9 Jul 2015 00:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 mE8-2zipu6R9 for ; Thu, 9 Jul 2015 00:43:02 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CF41A8836 for ; Thu, 9 Jul 2015 00:43:01 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-7f-559e260394aa Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F7.F0.29223.3062E955; Thu, 9 Jul 2015 09:42:59 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.228]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Thu, 9 Jul 2015 09:42:59 +0200 From: Salvatore Loreto To: Ted Hardie Thread-Topic: [Spud] The draft's questions Thread-Index: AQHQuaR8BoqianiW20aZwXJ/YcOq1J3SoO6A Date: Thu, 9 Jul 2015 07:42:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_EAE3E239BDEF49CC87DDC552810398E5ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGfG3RpdZbV6owc9+S4tFF54yWjTOtXNg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4Mt42/WYtWJ9dcfVjbAPjtowuRk4OCQETib7J x1ghbDGJC/fWs3UxcnEICRxllHh4YDGUs5hR4s+z5+wgVWwCZhLPH25hBrFFBJQl9l7ZwQZi MwPZMxbuYuxi5OAQFtCU+HcrAaJES+L6pLusELaRxIeFM5hBSlgEVCR2/EkDMXkF7CW2X+UE qRASCJDon74XbDinQKDEue9/wWxGoNO+n1rDBLFIXOLWk/lMECcLSCzZc54ZwhaVePn4H9Qr ShKNS56wQtQnS1yfeZARxOYVEJQ4OfMJywRG0VlIRs1CUjYLSdksoOuYgX5Zv0sfokRRYkr3 Q3YIW0Oidc5cdogSa4mPX3KRlSxg5FjFKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERh7B7f8 NtjB+PK54yFGAQ5GJR7eBVfnhgqxJpYVV+YeYpTmYFES552xOS9USCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA6N9c+6kOP4Nvc8fixy9+Pbds6u7P4g/Uyxv1ctNvmDPr1SadN5j/vntMlnN NVfWGuxQkAjvL5fcseVxVvg85cqnvPHZKpvjfhwUM/+Xsafyx/p3xSkLn/DpFgnEttWcPTff PSrtrKwBg4r6/Z8eTALRn3+9MZ+421/4fEJ+p9PMd73iETpTXimxFGckGmoxFxUnAgCIxm2t ngIAAA== Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] The draft's questions X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 07:43:04 -0000 --_000_EAE3E239BDEF49CC87DDC552810398E5ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVkDQoNCnRoYW5rcyBmb3IgbGlzdGVuaW5nIHRoZSBxdWVzdGlvbnMgYmVsb3cuDQpJIGhh dmUgb25lIGNvbW1lbnQgLCBzZWUgaW4gbGluZQ0KDQpPbiAwOCBKdWwgMjAxNSwgYXQgMTk6MzUs IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86dGVkLmlldGZAZ21haWwuY29t Pj4gd3JvdGU6DQoNClNvLCB0aGUgZHJhZnQgYXNrcyB0aGUgZm9sbG93aW5nIHF1ZXN0aW9ucywg d2hpY2ggSSBhbSBnb2luZyB0byBhbnN3ZXIgYmFzZWQgb24gYSBzaW1wbGUgcHJlanVkaWNlOiAg ZG8gdGhlIHNpbXBsZXN0IHRoaW5nIHRoYXQgY2FuIHBvc3NpYmx5IHdvcmsuICBJJ2QgYmUgaW50 ZXJlc3RlZCB0byBoZWFyIG90aGVyIGFuc3dlcnMgYW5kIHRoZSBkZXNpZ24gcmF0aW9uYWxlIGJl aGluZCB0aGVtLg0KDQoqIENhbiBvbmUgcGFja2V0IGJlbG9uZyB0byBtdWx0aXBsZSB0dWJlcz8N Cg0KTm9wZS4gIElmIGFuIG92ZXJseWluZyBwcm90b2NvbCBuZWVkcyB0aGUgc2FtZSBwYXlsb2Fk IGluIG11bHRpcGxlIHR1YmVzLCBpdCBuZWVkcyBuZXcgcGFja2V0cyBmb3IgZWFjaC4gIFJhdGlv bmFsZTogIHRoZSBudW1iZXIgb2YgdGltZXMgdGhpcyBpcyBnb2luZyB0byBjb21lIHVwIHNlZW1z IHNtYWxsIGZvciB0aGUgb3ZlcmhlYWQgaXQgd291bGQgdGFrZSB0byBzdXBwb3J0IGNhcnJ5aW5n IHRoZSBkaWZmZXJlbnQgdHViZS1pZHMgd2l0aGluIHRoZSBzYW1lIHBhY2tldC4NCg0KKiBEbyBh bGwgcGFja2V0cyBpbiBhIGZpdmUtdHVwbGUgZmxvdyBoYXZlIHRvIGJlbG9uZyB0byBvbmUgdHVi ZT8NCg0KTm9wZS4gIEFzIHRoZSBXZWJSVEMgYnVuZGxlIHVzZSBjYXNlcyBzaG93cywgeW91IG1h eSBoYXZlIGEgc2luZ2xlIGZpdmUtdHVwbGUgd2l0aCBtdWx0aXBsZSB0dWJlcyB3YW50aW5nIGRp ZmZlcmVudCB0cmVhdG1lbnQgYnkgdGhlIG5ldHdvcmsuDQoNCkZvciB0aGUgcmVsYXRlZCBxdWVz dGlvbiBvZiAiTXVzdCBhbGwgcGFja2V0cyBpbiBhIGZpdmUtdHVwbGUgZmxvdyBoYXZlIHR1YmUt aWRzIGlmIHNvbWUgZG8/IiwgbXkgYW5zd2VyIGlzIHN0aWxsICJOb3BlIi4gIElmIHlvdSdyZSBu b3QgY2FsbGluZyBvdXQgYSBncm91cGluZyBvZiBwYWNrZXRzIGZvciBzZXBhcmF0ZSB0cmVhdG1l bnQgYnkgdGhlIG5ldHdvcmssIGl0J3MgdXAgdG8geW91IHdoZXRoZXIgeW91IGFzc2lnbiBhIHR1 YmUtaWQgYW5kIHNheSAibm90aGluZyBzcGVjaWFsIG5lZWRlZCIgb3IgYXNzaWduIG5vIHR1YmUt aWQgYXQgYWxsLiAgSSdkIGRvIHRoZSBsYXR0ZXIsIGJlY2F1c2Ugb2YgdGhlICJzaW1wbGVzdCBw b3NzaWJsZSB0aGluZyIgcHJpbmNpcGxlLg0KDQphYm91dCB0aGUg4oCcTXVzdCBhbGwgcGFja2V0 cyBpbiBhIGZpdmUtdHVwbGUgZmxvdyBoYXZlIHR1YmUtaWRzIGlmIHNvbWUgZG/igJ0NCldoaWxl IEkgYWdyZWUgdGhhdCBpdCBzaG91bGQgbm90IGJlIGEgTVVTVCBiZWNhdXNlIHdlIGNhbiBub3Qg bWFuZGF0ZSB0aGF0IGFsbCB0aGUgZGlmZmVyZW50IGFwcGxpY2F0aW9ucyB3aWxsIGJlIHVwZGF0 ZWQgYXQgdGhlIHNhbWUgdGltZQ0KSG93ZXZlciBmcm9tIHRoZSBuZXR3b3JrIHByb3NwZWN0aXZl IHRoZSDigJxzaW1wbGVzdCBwb3NzaWJsZSB0aGluZ+KAnSB3b3VsZCBiZSBJTU8gdGhhdCBhbGwg dGhlIHBhY2tldHMgaW4gYSBmaXZlLXR1cGxlIGZsb3csIGVzcGVjaWFsbHkNCnRoZSBvbmVzIGdl bmVyYXRlZCBieSB0aGUgc2FtZSBhcHBsaWNhdGlvbiwgbG9va3Mgc2ltaWxhcuKApiBJIG1lYW4g YWxsIG9mIHRoZW0gcnVuIG92ZXIgdGhlIFNQVUQgbGF5ZXINCg0KYmVzdCByZWdhcmRzDQpTYWx2 YXRvcmUNCg0KDQoqIENhbi9NdXN0IHRoZSBiYWNrd2FyZCBmbG93IGhhdmUgdGhlIHNhbWUgdHVi ZSBJRCBvciBhIGRpZmZlcmVudCBvbmU/DQoNCkkgZG9uJ3QgdGhpbmsgaXQgTVVTVC4gIEknbSBv ZiB0aGUgb3BpbmlvbiB0aGF0IGl0IGxpa2VseSBpc24ndCBhIGdyZWF0IGlkZWEgaW4gZ2VuZXJh bCwgYnV0IHlvdSBwcm9iYWJseSBuZWVkIHRvIGJlIGFibGUgdG8gaGFuZGxlIHRoZSBjYXNlIHdo ZXJlIHRoZXkgYXJlLCBqdXN0IGZvciB0aGUgYWNjaWRlbnRhbCBjb2xsaXNpb24gY2FzZS4gKERl cGVuZGluZyBvbiB0aGUgbWVjaGFuaXNtIGZvciBnZW5lcmF0aW5nIHRoZW0sIG5vdCBoYW5kbGlu ZyB0aGF0IHdvdWxkIG1ha2UgZm9yIHNvbWUgZGVlcGx5IHJhbmRvbSBhbmQgdmVyeSBvY2Nhc2lv bmFsIGZhaWx1cmVzKS4gIEtlbiBDYWx2ZXJ0IGhhcyBwb2ludGVkIG91dCB0aGF0IGlmIHlvdSBh Y3R1YWxseSB3YW50IGRpZmZlcmVudCB0cmVhdG1lbnQgaW4gdGhlIGZvcndhcmQgYW5kIHJldmVy c2UgZGlyZWN0aW9uIHRoYXQgaGF2aW5nIGEgZGlmZmVyZW50IHR1YmUtaWQgbWFrZXMgdGhpcyBl YXNpZXIsIGFuZCB0aGF0J3MgcHJvYmFibHkgYSBnb29kIGVub3VnaCByZWFzb24gZm9yIGEgU0hP VUxEIE5PVC4NCg0KDQoqICBFc3BlY2lhbGx5IGF0IGNvbm5lY3Rpb24gc3RhcnQtdXAsIGRlcGVu ZGluZyBvbiB0aGUgc2VtYW50aWNzIG9mIHRoZSBvdmVybHlpbmcgdHJhbnNwb3J0IHByb3RvY29s LCB0aGVyZSBsaWtlbHkgbWlnaHQgYmUgb25seSBvbmUgcGFja2V0IHRvIHN0YXJ0IG11bHRpcGxl IHN0cmVhbXMvdHViZXMuIENhbiB0aGlzIHN0YXJ0IG1lc3NhZ2Ugc2lnbmFsIG11bHRpcGxlIHR1 YmUgSURzIGF0IG9uY2Ugb3IgZG8gd2UgbmVlZCBhbiBvd24gc3RhcnQgbWVzc2FnZSBmb3IgZWFj aCB0dWJlPw0KDQpJZiB0aGUgIk5vcGUiIGFib3ZlLCBob2xkcyB0aGlzLCBkb2Vzbid0IGFyaXNl LiAgSWYgeW91IHdhbnQgdG8gdGFsayBhYm91dCBhIHR1YmUsIHNlbmQgYSBtZXNzYWdlIGFib3V0 IHRoYXQgdHViZSwgaW5kZXBlbmRlbnRseSBvZiBtZXNzYWdlcyBmb3Igb3RoZXIgdHViZXMuICBG b3IgdGhlIG11bHRpcGxleGVkLW9uLWEtZml2ZS10dXBsZSBjYXNlLCB5b3UgYXJlIHRoZW4gZ2V0 dGluZyBhIG1lc3NhZ2UgcGVyIHR1YmUsIHJhdGhlciB0aGFuIHBlciBmaXZlLXR1cGxlLCBidXQg dGhhdCdzIHRoZSBjb3N0IG9mIGluZGVwZW5kZW50IHRyZWF0bWVudCBieSB0aGUgbmV0d29yay4g IElmIHlvdSBkb24ndCB3YW50IGluZGVwZW5kZW50IHRyZWF0bWVudCwgcHV0IHRoZW0gaW4gdGhl IHNhbWUgdHViZS4NCg0KKiBPciBpcyBpdCBpbiB0aGlzIGNhc2Ugbm90IHBvc3NpYmxlIHRvIGhh dmUgbXVsdGlwbGUgdHViZXMgd2l0aGluIG9uZSBmaXZlLXR1cGxlPw0KDQrigItTZWUgYWJvdmUu DQoNCkFueSBvdGhlciBwcmVqdWRpY2VzL2Fuc3dlcnMgZm9sa3Mgd2FudCB0byBzaGFyZT8NClto dHRwczovL3NzbC5nc3RhdGljLmNvbS91aS92MS9pY29ucy9tYWlsL2ltYWdlcy9jbGVhcmRvdC5n aWZdDQoNCnJlZ2FyZHMsDQoNClRlZA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClNwdWQgbWFpbGluZyBsaXN0DQpTcHVkQGlldGYub3JnPG1haWx0bzpT cHVkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVk DQoNCg== --_000_EAE3E239BDEF49CC87DDC552810398E5ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgVGVkDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj50aGFua3MgZm9yIGxpc3Rlbmlu ZyB0aGUgcXVlc3Rpb25zIGJlbG93LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGhhdmUgb25lIGNv bW1lbnQgLCBzZWUgaW4gbGluZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IDA4IEp1bCAyMDE1LCBhdCAxOTozNSwgVGVkIEhhcmRpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRl ZC5pZXRmQGdtYWlsLmNvbSIgY2xhc3M9IiI+dGVkLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVm YXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OnRhaG9tYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFs bCI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6dGFob21h LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClNvLCB0aGUgZHJhZnQgYXNrcyB0aGUgZm9s bG93aW5nIHF1ZXN0aW9ucywgd2hpY2ggSSBhbSBnb2luZyB0byBhbnN3ZXIgYmFzZWQgb24gYSBz aW1wbGUgcHJlanVkaWNlOiZuYnNwOyBkbyB0aGUgc2ltcGxlc3QgdGhpbmcgdGhhdCBjYW4gcG9z c2libHkgd29yay4mbmJzcDsgSSdkIGJlIGludGVyZXN0ZWQgdG8gaGVhciBvdGhlciBhbnN3ZXJz IGFuZCB0aGUgZGVzaWduIHJhdGlvbmFsZSBiZWhpbmQgdGhlbS48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQoqIENhbiBvbmUgcGFja2V0IGJlbG9uZyB0byBtdWx0aXBsZSB0dWJlcz8gPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZh dWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6dGFob21hLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs Ij4NCk5vcGUuJm5ic3A7IElmIGFuIG92ZXJseWluZyBwcm90b2NvbCBuZWVkcyB0aGUgc2FtZSBw YXlsb2FkIGluIG11bHRpcGxlIHR1YmVzLCBpdCBuZWVkcyBuZXcgcGFja2V0cyBmb3IgZWFjaC4m bmJzcDsgUmF0aW9uYWxlOiZuYnNwOyB0aGUgbnVtYmVyIG9mIHRpbWVzIHRoaXMgaXMgZ29pbmcg dG8gY29tZSB1cCBzZWVtcyBzbWFsbCBmb3IgdGhlIG92ZXJoZWFkIGl0IHdvdWxkIHRha2UgdG8g c3VwcG9ydCBjYXJyeWluZyB0aGUgZGlmZmVyZW50IHR1YmUtaWRzIHdpdGhpbiB0aGUNCiBzYW1l IHBhY2tldC48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTp0YWhvbWEsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K PGJyIGNsYXNzPSIiPg0KKiBEbyBhbGwgcGFja2V0cyBpbiBhIGZpdmUtdHVwbGUgZmxvdyBoYXZl IHRvIGJlbG9uZyB0byBvbmUgdHViZT8gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6dGFob21h LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCk5vcGUuJm5ic3A7IEFzIHRoZSBXZWJSVEMg YnVuZGxlIHVzZSBjYXNlcyBzaG93cywgeW91IG1heSBoYXZlIGEgc2luZ2xlIGZpdmUtdHVwbGUg d2l0aCBtdWx0aXBsZSB0dWJlcyB3YW50aW5nIGRpZmZlcmVudCB0cmVhdG1lbnQgYnkgdGhlIG5l dHdvcmsuJm5ic3A7DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpGb3IgdGhlIHJlbGF0 ZWQgcXVlc3Rpb24gb2YgJnF1b3Q7TXVzdCBhbGwgcGFja2V0cyBpbiBhIGZpdmUtdHVwbGUgZmxv dyBoYXZlIHR1YmUtaWRzIGlmIHNvbWUgZG8/JnF1b3Q7LCBteSBhbnN3ZXIgaXMgc3RpbGwgJnF1 b3Q7Tm9wZSZxdW90Oy4mbmJzcDsgSWYgeW91J3JlIG5vdCBjYWxsaW5nIG91dCBhIGdyb3VwaW5n IG9mIHBhY2tldHMgZm9yIHNlcGFyYXRlIHRyZWF0bWVudCBieSB0aGUgbmV0d29yaywgaXQncyB1 cCB0byB5b3Ugd2hldGhlciB5b3UgYXNzaWduIGEgdHViZS1pZCBhbmQNCiBzYXkgJnF1b3Q7bm90 aGluZyBzcGVjaWFsIG5lZWRlZCZxdW90OyBvciBhc3NpZ24gbm8gdHViZS1pZCBhdCBhbGwuJm5i c3A7IEknZCBkbyB0aGUgbGF0dGVyLCBiZWNhdXNlIG9mIHRoZSAmcXVvdDtzaW1wbGVzdCBwb3Nz aWJsZSB0aGluZyZxdW90OyBwcmluY2lwbGUuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdj5hYm91dCB0aGUg4oCcTXVzdCBhbGwgcGFja2V0cyBpbiBhIGZpdmUtdHVwbGUgZmxv dyBoYXZlIHR1YmUtaWRzIGlmIHNvbWUgZG/igJ08L2Rpdj4NCjxkaXY+V2hpbGUgSSBhZ3JlZSB0 aGF0IGl0IHNob3VsZCBub3QgYmUgYSBNVVNUIGJlY2F1c2Ugd2UgY2FuIG5vdCBtYW5kYXRlIHRo YXQgYWxsIHRoZSBkaWZmZXJlbnQgYXBwbGljYXRpb25zIHdpbGwgYmUgdXBkYXRlZCBhdCB0aGUg c2FtZSB0aW1lPC9kaXY+DQo8ZGl2Pkhvd2V2ZXIgZnJvbSB0aGUgbmV0d29yayBwcm9zcGVjdGl2 ZSB0aGUg4oCcc2ltcGxlc3QgcG9zc2libGUgdGhpbmfigJ0gd291bGQgYmUgSU1PIHRoYXQgYWxs IHRoZSBwYWNrZXRzIGluIGEgZml2ZS10dXBsZSBmbG93LCBlc3BlY2lhbGx5PC9kaXY+DQo8ZGl2 PnRoZSBvbmVzIGdlbmVyYXRlZCBieSB0aGUgc2FtZSBhcHBsaWNhdGlvbiwgbG9va3Mgc2ltaWxh cuKApiBJIG1lYW4gYWxsIG9mIHRoZW0gcnVuIG92ZXIgdGhlIFNQVUQgbGF5ZXI8L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PmJlc3QgcmVnYXJkczwvZGl2Pg0KPGRpdj5T YWx2YXRvcmU8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OnRhaG9tYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6dGFob21hLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxiciBjbGFzcz0i Ij4NCiogQ2FuL011c3QgdGhlIGJhY2t3YXJkIGZsb3cgaGF2ZSB0aGUgc2FtZSB0dWJlIElEIG9y IGEgZGlmZmVyZW50IG9uZT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTp0YWhvbWEsc2Fucy1z ZXJpZjtmb250LXNpemU6c21hbGwiPg0KSSBkb24ndCB0aGluayBpdCBNVVNULiZuYnNwOyBJJ20g b2YgdGhlIG9waW5pb24gdGhhdCBpdCBsaWtlbHkgaXNuJ3QgYSBncmVhdCBpZGVhIGluIGdlbmVy YWwsIGJ1dCB5b3UgcHJvYmFibHkgbmVlZCB0byBiZSBhYmxlIHRvIGhhbmRsZSB0aGUgY2FzZSB3 aGVyZSB0aGV5IGFyZSwganVzdCBmb3IgdGhlIGFjY2lkZW50YWwgY29sbGlzaW9uIGNhc2UuIChE ZXBlbmRpbmcgb24gdGhlIG1lY2hhbmlzbSBmb3IgZ2VuZXJhdGluZyB0aGVtLCBub3QgaGFuZGxp bmcNCiB0aGF0IHdvdWxkIG1ha2UgZm9yIHNvbWUgZGVlcGx5IHJhbmRvbSBhbmQgdmVyeSBvY2Nh c2lvbmFsIGZhaWx1cmVzKS4mbmJzcDsgS2VuIENhbHZlcnQgaGFzIHBvaW50ZWQgb3V0IHRoYXQg aWYgeW91IGFjdHVhbGx5IHdhbnQgZGlmZmVyZW50IHRyZWF0bWVudCBpbiB0aGUgZm9yd2FyZCBh bmQgcmV2ZXJzZSBkaXJlY3Rpb24gdGhhdCBoYXZpbmcgYSBkaWZmZXJlbnQgdHViZS1pZCBtYWtl cyB0aGlzIGVhc2llciwgYW5kIHRoYXQncyBwcm9iYWJseSBhIGdvb2QNCiBlbm91Z2ggcmVhc29u IGZvciBhIFNIT1VMRCBOT1QuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6dGFob21hLHNhbnMtc2VyaWY7Zm9udC1zaXpl OnNtYWxsIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiombmJzcDsgRXNwZWNpYWxs eSBhdCBjb25uZWN0aW9uIHN0YXJ0LXVwLCBkZXBlbmRpbmcgb24gdGhlIHNlbWFudGljcyBvZiB0 aGUgb3Zlcmx5aW5nIHRyYW5zcG9ydCBwcm90b2NvbCwgdGhlcmUgbGlrZWx5IG1pZ2h0IGJlIG9u bHkgb25lIHBhY2tldCB0byBzdGFydCBtdWx0aXBsZSBzdHJlYW1zL3R1YmVzLiBDYW4gdGhpcyBz dGFydCBtZXNzYWdlIHNpZ25hbCBtdWx0aXBsZSB0dWJlIElEcyBhdCBvbmNlIG9yIGRvIHdlIG5l ZWQgYW4gb3duIHN0YXJ0IG1lc3NhZ2UNCiBmb3IgZWFjaCB0dWJlPyA8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJm b250LWZhbWlseTp0YWhvbWEsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KSWYgdGhlICZx dW90O05vcGUmcXVvdDsgYWJvdmUsIGhvbGRzIHRoaXMsIGRvZXNuJ3QgYXJpc2UuJm5ic3A7IElm IHlvdSB3YW50IHRvIHRhbGsgYWJvdXQgYSB0dWJlLCBzZW5kIGEgbWVzc2FnZSBhYm91dCB0aGF0 IHR1YmUsIGluZGVwZW5kZW50bHkgb2YgbWVzc2FnZXMgZm9yIG90aGVyIHR1YmVzLiZuYnNwOyBG b3IgdGhlIG11bHRpcGxleGVkLW9uLWEtZml2ZS10dXBsZSBjYXNlLCB5b3UgYXJlIHRoZW4gZ2V0 dGluZyBhIG1lc3NhZ2UgcGVyIHR1YmUsIHJhdGhlciB0aGFuIHBlcg0KIGZpdmUtdHVwbGUsIGJ1 dCB0aGF0J3MgdGhlIGNvc3Qgb2YgaW5kZXBlbmRlbnQgdHJlYXRtZW50IGJ5IHRoZSBuZXR3b3Jr LiZuYnNwOyBJZiB5b3UgZG9uJ3Qgd2FudCBpbmRlcGVuZGVudCB0cmVhdG1lbnQsIHB1dCB0aGVt IGluIHRoZSBzYW1lIHR1YmUuJm5ic3A7DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTp0YWhvbWEsc2Fucy1zZXJpZjtm b250LXNpemU6c21hbGwiPg0KPGJyIGNsYXNzPSIiPg0KKiBPciBpcyBpdCBpbiB0aGlzIGNhc2Ug bm90IHBvc3NpYmxlIHRvIGhhdmUgbXVsdGlwbGUgdHViZXMgd2l0aGluIG9uZSBmaXZlLXR1cGxl PzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxf ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OnRhaG9tYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpz bWFsbCI+DQrigItTZWUgYWJvdmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQpBbnkgb3RoZXIgcHJlanVkaWNlcy9hbnN3ZXJzIGZvbGtzIHdhbnQgdG8gc2hhcmU/DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBpZD0iOjdsdSIgY2xhc3M9IiIgdGFiaW5kZXg9IjAiPjxpbWcgY2xh c3M9IiIgc3JjPSJodHRwczovL3NzbC5nc3RhdGljLmNvbS91aS92MS9pY29ucy9tYWlsL2ltYWdl cy9jbGVhcmRvdC5naWYiPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBpZD0iOjdsdSIgY2xhc3M9IiIgdGFiaW5kZXg9IjAiPnJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGlkPSI6N2x1IiBjbGFzcz0iIiB0YWJpbmRleD0i MCI+VGVkPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N ClNwdWQgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlNwdWRAaWV0 Zi5vcmciIGNsYXNzPSIiPlNwdWRAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHVkPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_EAE3E239BDEF49CC87DDC552810398E5ericssoncom_-- From nobody Thu Jul 9 10:37:42 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174741A1A0B for ; Thu, 9 Jul 2015 10:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 s_itZ6VVUR1B for ; Thu, 9 Jul 2015 10:37:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F011A1A04 for ; Thu, 9 Jul 2015 10:37:39 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t69HaqPE014100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Jul 2015 10:36:52 -0700 (PDT) Message-ID: <559EB134.2090905@isi.edu> Date: Thu, 09 Jul 2015 10:36:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian Trammell References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> In-Reply-To: <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Tom Herbert , spud@ietf.org, =?windows-1252?Q?Mirja_K=FChlewind?= , touch@isi.edu Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 17:37:41 -0000 On 7/8/2015 10:23 PM, Brian Trammell wrote: > hi Joe, all, ... >> One challenge is that IPv6 options are processed differently than IPv4 - >> there's no way to "jump" straight into the transport header to find >> ports (for port-based load balancing, e.g.). > > Yep. If the option chain had a small and > easily-hardware-determinable > set of possible lengths -- which is the case for v4 options -- this > would be easier (but still harder to handle on the fast path than the > arrangements we're proposing here). IPv4 options can be jumped over in one step using the IHL field. There's no such field for IPv6 - routers have to walk the chain of headers one by one. >> I suspect you'll find that IP options are basically a non-starter except >> for research purposes. > > For the story on the v4 side, do you know of anything newer than > Fonseca et al "IP Options are Not and Option" (tech report version at > http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's > ten years old -- but given where the engineering effort has gone during > that decade, I doubt strongly much has changed here. Not much. Those old studies have been used in other WGs to drive documents (IMO, unfortunately). Joe From nobody Thu Jul 9 14:04:49 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5611A0203 for ; Thu, 9 Jul 2015 14:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 WzlLK_L1O0Oz for ; Thu, 9 Jul 2015 14:04:46 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE25A1A0218 for ; Thu, 9 Jul 2015 14:04:46 -0700 (PDT) Received: by iecvh10 with SMTP id vh10so185001198iec.3 for ; Thu, 09 Jul 2015 14:04:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=giwND9kxGUo7xmEo2EYYz1gN0q6qkmlDx02nAzzIwLs=; b=IzACrGx4XmGYB1EtSYqnysjVLjCupQ3wCWv2TBKRudRXNUBYnRagkY9dxQpoXAxsmx qSEm0n7Yem8g8QSdeqIc/+em0kYV935MmeKbpPC2p/XV1NUcwuHIZgq/zIeouN7dtP7v GOztGhJdg1X3sJOpBwlJWx85fQ4Mqip5oRpZAYHwrsQRccOg74PUDfH9gtBGDsgupK1Z u73X2l3DT20TkB8UHopQrvWVzHqKOWAG31hLgNX/fGL6LELJYYXYV1EA+ZEfhyTxJZNv /0Ocao/fT54Bh0BN9w1ReQMpndVUD++L4hcJjKTHMHdpIcdQBgffMPyGxAr9ZQKhDAvZ ZEuA== X-Gm-Message-State: ALoCoQkm0pXMmuG/RLlXY0hkDCcRYphDkxSi9LfLzElM6cmcDeHj8SdVJroIH+iW7iwMGr7BC7ho MIME-Version: 1.0 X-Received: by 10.107.165.142 with SMTP id o136mr1854977ioe.120.1436475886130; Thu, 09 Jul 2015 14:04:46 -0700 (PDT) Received: by 10.107.142.86 with HTTP; Thu, 9 Jul 2015 14:04:46 -0700 (PDT) In-Reply-To: <559D8301.2020604@isi.edu> References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> Date: Thu, 9 Jul 2015 14:04:46 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud@ietf.org Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 21:04:48 -0000 On Wed, Jul 8, 2015 at 1:07 PM, Joe Touch wrote: > > > On 7/8/2015 9:27 AM, Brian Trammell wrote: >>> This is the appropriate >>> > place for the policy/QoS information information described in the use >>> > cases, and there are already facilities for both hop-by-hop options >>> > and allowing middle boxes to modify options inflight. >> >> Indeed. This presumes that new IP options are more realistically >> widely deployable in the Internet than a new protocol over UDP. I would >> need to see some data to back that up (indeed, this would fit nicely in >> a measurement study we're running right now so we may well end up >> generating that data. :) ) > > Check the discussions over in v6ops. > > There has been a lot of work there trying to deprecate all IPv6 options, > which has at least been successful in limiting the length of the option > chain. > Looking at the 6man documents, it seems like there is still an active interest in IPv6 options. I know there is currently work being done on implementing the segment routing option. > One challenge is that IPv6 options are processed differently than IPv4 - > there's no way to "jump" straight into the transport header to find > ports (for port-based load balancing, e.g.). > The IPv6 label flow can be used to provide the entropy needed for ECMP (like in RFC6438). With flow labels, devices would not need to do DPI for purposes of ECMP. This solves the issue not only for devices that don't want to parse over extension headers, but also allows flow-based ECMP with protocols other than just UDP and TCP. Several vendors are already providing support for flow labels and ECMP, and we intend to start setting flow labels by default in end hosts (Linux at least). Tom > I suspect you'll find that IP options are basically a non-starter except > for research purposes. > > Joe From nobody Thu Jul 9 14:11:11 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3471A0217 for ; Thu, 9 Jul 2015 14:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 DQcrSxNDgOi2 for ; Thu, 9 Jul 2015 14:11:08 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00CF71A0235 for ; Thu, 9 Jul 2015 14:11:06 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t69LAVp4016524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Jul 2015 14:10:31 -0700 (PDT) Message-ID: <559EE346.7080200@isi.edu> Date: Thu, 09 Jul 2015 14:10:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tom Herbert References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , spud@ietf.org, =?UTF-8?B?TWlyamEgSw==?= =?UTF-8?B?w7xobGV3aW5k?= , touch@isi.edu Subject: Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 21:11:10 -0000 On 7/9/2015 2:04 PM, Tom Herbert wrote: > On Wed, Jul 8, 2015 at 1:07 PM, Joe Touch wrote: >> >> >> On 7/8/2015 9:27 AM, Brian Trammell wrote: >>>> This is the appropriate >>>>> place for the policy/QoS information information described in the use >>>>> cases, and there are already facilities for both hop-by-hop options >>>>> and allowing middle boxes to modify options inflight. >>> >>> Indeed. This presumes that new IP options are more realistically >>> widely deployable in the Internet than a new protocol over UDP. I would >>> need to see some data to back that up (indeed, this would fit nicely in >>> a measurement study we're running right now so we may well end up >>> generating that data. :) ) >> >> Check the discussions over in v6ops. >> >> There has been a lot of work there trying to deprecate all IPv6 options, >> which has at least been successful in limiting the length of the option >> chain. >> > Looking at the 6man documents, it seems like there is still an active > interest in IPv6 options. I know there is currently work being done on > implementing the segment routing option. Yes - that's one of my concerns with the rush to deprecate them ;-) >> One challenge is that IPv6 options are processed differently than IPv4 - >> there's no way to "jump" straight into the transport header to find >> ports (for port-based load balancing, e.g.). > > The IPv6 label flow can be used to provide the entropy needed for ECMP > (like in RFC6438). With flow labels, devices would not need to do DPI > for purposes of ECMP. While I agree with your logic, the other issue is that the flow labels aren't set properly AND existing ops is based on port-directed forwarding. I'm not suggesting I agree with this; IMO, anything that digs into a packet deep enough to find the transport header is acting like an endpoint and ought to expect to do the work needed to find that header. Joe From nobody Fri Jul 10 03:44:44 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576491A8FD6 for ; Fri, 10 Jul 2015 03:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qJRGXAPFj5JP for ; Fri, 10 Jul 2015 03:44:41 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6D1A8FD5 for ; Fri, 10 Jul 2015 03:44:40 -0700 (PDT) Received: from [10.0.27.104] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 8BDC01A0365; Fri, 10 Jul 2015 12:44:39 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_38C878DC-E987-4D24-BAFF-0629170389C4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: <559EB134.2090905@isi.edu> Date: Fri, 10 Jul 2015 12:44:38 +0200 Message-Id: References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Tom Herbert , =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud@ietf.org Subject: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 10:44:43 -0000 --Apple-Mail=_38C878DC-E987-4D24-BAFF-0629170389C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 09 Jul 2015, at 19:36, Joe Touch wrote: >=20 >=20 >=20 > On 7/8/2015 10:23 PM, Brian Trammell wrote: >> hi Joe, all, > ... >>> One challenge is that IPv6 options are processed differently than = IPv4 - >>> there's no way to "jump" straight into the transport header to find >>> ports (for port-based load balancing, e.g.). >>=20 >> Yep. If the option chain had a small and >> easily-hardware-determinable >> set of possible lengths -- which is the case for v4 options -- this >> would be easier (but still harder to handle on the fast path than the >> arrangements we're proposing here). >=20 > IPv4 options can be jumped over in one step using the IHL field. yes, |set| =3D 1. > There's > no such field for IPv6 - routers have to walk the chain of headers one > by one. Right. It seems to me the way out of this (which is not just a problem = for boxes that want to muck about in transport protocols, but ones that = want to properly process hop by hop options) would be to define a new = (small) set of IPv6 options headers that themselves would (1) not be = combinable and (2) have a fixed length, allowing the next-header field = to be _treated_ in constant time / with relatively few gates as the IHL = field. I haven't followed 6man, though I presume this approach or approaches = like it have been discussed there ad nauseam. The fixed-lengthness of these new v6 options headers would make them = problematic for freely extensible options, though one could use these to = stick common fast path options in the "fixed" point of the header, and = otherwise point to space elsewhere in the packet for things that can = happen slowly. You eat the cost of following pointers and doing the more = expensive deframing only if you need to in this case. >>> I suspect you'll find that IP options are basically a non-starter = except >>> for research purposes. >>=20 >> For the story on the v4 side, do you know of anything newer than >> Fonseca et al "IP Options are Not and Option" (tech report version at >> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? = It's >> ten years old -- but given where the engineering effort has gone = during >> that decade, I doubt strongly much has changed here. >=20 > Not much. Those old studies have been used in other WGs to drive > documents (IMO, unfortunately). I've been thinking about whether it would be worth the effort to do an = updated IP options transparency study. We revisited the safety of ECN in part because there were plausible = processes for the situation to have changed -- the biggest problems that = caused the Internet to be ECN-unsafe involved what were basically = single-packet exploits against routers, and needed to be fixed for = reasons *other* than making the feature work. (ECN *support* is another = question, the answer to which is less cheerful.) I can't think of a comparable process making new/experimental options = support less linked to connectivity risk in edge networks -- if nobody = uses them (because they don't work) then if you try to use them and they = don't work, it's your fault. That would unfortunately seem to be a = rather stable state. Coming back to the layering question: It does seem to me that what we're (the we that wrote the two documents = starting this thread) trying to do is explicitly reinforce the boundary = between the network layer and the transport layer, where this is defined = as "things the path needs to see versus things only endpoints need to = see". Asking nicely (i.e., publishing RFCs) did not work in this case: = the transport ports are de facto part of the network layer now, and = short of blowing the Internet up and starting over I can't see a way to = get them back. So now we are left with enforcing the boundary = cryptographically, leaving some space in the "new network layer" (in = this case, IP + UDP (for ports) + SPUD) for those things now commonly = done within the network. If we can do this in the _current_ network layer (IPv6 (with options) = with some alternate way to handle NAT + DTLS, or we find a portal to an = alternate universe where end-to-end IPsec is widely deployable and = manageable), then great, let's do that. I'm pessimistic enough to = believe that that hasn't been a realistic prospect at any time during = this century, though. Cheers, Brian > Joe >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_38C878DC-E987-4D24-BAFF-0629170389C4 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVn6IWAAoJENt3nsOmbNJctO0H/iLxJN0+kyYdd4IJYwcB9xcV WvApGPDVRZSWXtfdwia9WK5N9WeXY6LVWiMt7GwgovQK+NZo5WKsvQi8P0hHsGGn NXiXLJLb/Ne1KMprba11L4KaJKKAhNKMt6cHzxkBI644hFqaJGQK4x8woi98X4v4 c2cvrMcdz8ejtok69ef2eNYBDLFiVlIP6/nLbIDcu0RiXvLumD8YABuTA4sYpcNB lUOFbrZCcI25r4W6MKraq5I7x/PRgUbXPWQI0WCP31hgcmLhgeDkGgbVAIEbI5sI vLydvzZXBEv9Pv0OazWDVDgYqDq7DPUo20cLIGXHcHJq9QBoEcRS1PxpRNdeMcM= =Sevi -----END PGP SIGNATURE----- --Apple-Mail=_38C878DC-E987-4D24-BAFF-0629170389C4-- From nobody Fri Jul 10 09:19:24 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E46C1B2CEC for ; Fri, 10 Jul 2015 09:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 AoOTYD9mcWbS for ; Fri, 10 Jul 2015 09:19:21 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911581B2CF1 for ; Fri, 10 Jul 2015 09:19:19 -0700 (PDT) Received: by igoe12 with SMTP id e12so38615218igo.1 for ; Fri, 10 Jul 2015 09:19:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VfT3bYE9ZfvNh9lCseAxcNoL+MjLIyGzby6WjP8Oqu0=; b=entlbPiWIjWFZ0FZ6BiSeLlYip3uhIXuTGSEiOZg3/ta5Kz3KCzHHrD6NuOkC5QlQo I6dzR16rt2ahZ9R45EZct/uwK+wRgnlNRVuE5/WbaC7LrXy9lV1Da+1/rDt5HByaqM5V EENW8UYvpHd3YtCHMectd7ZVgSUVXsRCL6v4JAQar3COsQzAmpB9353Fkyrg2X6jQJic EGmuV9pYY9GQnU8OGQBHg9XnqkBTXqTgeVFjE2ZyZFzsppe5pmEMeWMxLzx91D6XjK87 I/HYRBg7k03V66syQGRNHVLLhC4RHCor8+o2UARc/wk00jLQ6eYF42VgXZdhUeMRhjDj 6UhQ== X-Gm-Message-State: ALoCoQlCJ/s/wbFirWanFEUwho3EzVw7jpwoKHSPC9D8x95ivWsqVfuOBuAM761m9ejoa1JyfunA MIME-Version: 1.0 X-Received: by 10.107.9.142 with SMTP id 14mr6820721ioj.142.1436545159095; Fri, 10 Jul 2015 09:19:19 -0700 (PDT) Received: by 10.107.142.86 with HTTP; Fri, 10 Jul 2015 09:19:19 -0700 (PDT) In-Reply-To: References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> Date: Fri, 10 Jul 2015 09:19:19 -0700 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: spud@ietf.org, =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:19:23 -0000 > Coming back to the layering question: > > It does seem to me that what we're (the we that wrote the two documents s= tarting this thread) trying to do is explicitly reinforce the boundary betw= een the network layer and the transport layer, where this is defined as "th= ings the path needs to see versus things only endpoints need to see". Askin= g nicely (i.e., publishing RFCs) did not work in this case: the transport p= orts are de facto part of the network layer now, and short of blowing the I= nternet up and starting over I can't see a way to get them back. So now we = are left with enforcing the boundary cryptographically, leaving some space = in the "new network layer" (in this case, IP + UDP (for ports) + SPUD) for = those things now commonly done within the network. > This "new network layer" breaks down at fragmentation. Only the first fragment carries port numbers and the embedded network layer information in the payload. Other fragments will carry neither, but still can carry IP options, DSCP, TTL, ECN marking, flow labels in IPv6. An alternate possibility would be to embed IP options within UDP. So a packet might look like IP-UDP-IP options-payload. This allows us to use native options (say in our data center where we can control things), but maybe to use embedded IP options in UDP on paths in the Internet where we see options are being dropped. SFC-in-UDP (https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transport-00) proposes a similar model, although I don't believe they allow middleboxes to modify or to be regularly looking the headers. > If we can do this in the _current_ network layer (IPv6 (with options) wit= h some alternate way to handle NAT + DTLS, or we find a portal to an altern= ate universe where end-to-end IPsec is widely deployable and manageable), t= hen great, let's do that. I'm pessimistic enough to believe that that hasn'= t been a realistic prospect at any time during this century, though. > I don't understand what the issue is with crypto here. SSL/TLS are widely deployed with use of NAT, and we are certainly using encrypted tunnels over the Internet. Tom > Cheers, > > Brian > >> Joe >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Fri Jul 10 09:25:14 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9177B1A0127 for ; Fri, 10 Jul 2015 09:25:12 -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 mYn-2BcTe5Qr for ; Fri, 10 Jul 2015 09:25:11 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D331A00BE for ; Fri, 10 Jul 2015 09:25:10 -0700 (PDT) Received: by wicmz13 with SMTP id mz13so17842561wic.0 for ; Fri, 10 Jul 2015 09:25:09 -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=yn4HaAPtbJmc8FbTnXwFuJI/oDFRa1mTCXT/hcnQvco=; b=IxbhjSCAGpmvRvbYUUUDloIpnc2sSoZrdWOZHQQMiZRfTNN53LRR3QvysRxitf+7cq iDmHeN4O83z6+H1FPerB1mSFrj+sJJtf2yf/UA3PIMynQOkpnFyMnJAc72MGQdUZM9PQ muAC1LlPaGuStp/bhJ2EIsDeVcbeVrV+pyjGNA2ytmvA351b0iR6E8RW5cwi9vcyQ5RU hRrDv5CdP1sqO+SgCrvEx1FZ+wSis6wiiOy6n+7YeV+efNlpLhAbM4fNd9G2KvbOfC9n 7/C0rbRDfr5VzTeWVqfTN0zaLkn9NmurjzuirucJvBpgurVkDoEQU0UnExqNEy0psV3f D/aQ== MIME-Version: 1.0 X-Received: by 10.194.85.116 with SMTP id g20mr41509411wjz.154.1436545509699; Fri, 10 Jul 2015 09:25:09 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Fri, 10 Jul 2015 09:25:09 -0700 (PDT) In-Reply-To: References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> Date: Fri, 10 Jul 2015 09:25:09 -0700 Message-ID: From: Ted Hardie To: Brian Trammell Content-Type: multipart/alternative; boundary=047d7bfcfd50cf36bf051a87d03e Archived-At: Cc: Tom Herbert , "spud@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:25:12 -0000 --047d7bfcfd50cf36bf051a87d03e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 10, 2015 at 3:44 AM, Brian Trammell wrote: > > I've been thinking about whether it would be worth the effort to do an > updated IP options transparency study. > > We revisited the safety of ECN in part because there were plausible > processes for the situation to have changed -- the biggest problems that > caused the Internet to be ECN-unsafe involved what were basically > single-packet exploits against routers, and needed to be fixed for reason= s > *other* than making the feature work. (ECN *support* is another question, > the answer to which is less cheerful.) > > I can't think of a comparable process making new/experimental options > support less linked to connectivity risk in edge networks -- if nobody us= es > them (because they don't work) then if you try to use them and they don't > work, it's your fault. That would unfortunately seem to be a rather stabl= e > state. > > =E2=80=8BFrom a research design point of view, I think you could construct = such a study so that your test nodes tried both IP options=E2=80=8B and SPUD, so I= think it is worth thinking about quite seriously. While it is not the main point of them, you might be able to talk the RIPE and MLAB folks into adding code to their test devices to enable these checks. More data is always good, Ted --047d7bfcfd50cf36bf051a87d03e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 10, 2015 at 3:44 AM= , Brian Trammell <ietf@trammell.ch> wrote:

I've been thinking about whether it would be worth the effort to do an = updated IP options transparency study.

We revisited the safety of ECN in part because there were plausible process= es for the situation to have changed -- the biggest problems that caused th= e Internet to be ECN-unsafe involved what were basically single-packet expl= oits against routers, and needed to be fixed for reasons *other* than makin= g the feature work. (ECN *support* is another question, the answer to which= is less cheerful.)

I can't think of a comparable process making new/experimental options s= upport less linked to connectivity risk in edge networks -- if nobody uses = them (because they don't work) then if you try to use them and they don= 't work, it's your fault. That would unfortunately seem to be a rat= her stable state.



=E2=80=8BFrom a research design poi= nt of view, I think you could construct such a study so that your test node= s tried both IP options=E2=80=8B and SPUD, so I think it is worth thinking = about quite seriously.=C2=A0 While it is not the main point of them, you mi= ght be able to talk the RIPE and MLAB folks into adding code to their test = devices to enable these checks.

More data is always = good,

Ted

--047d7bfcfd50cf36bf051a87d03e-- From nobody Fri Jul 10 10:15:36 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB031B2A5C for ; Fri, 10 Jul 2015 10:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 zWD6Bl4-ACXU for ; Fri, 10 Jul 2015 10:15:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900CE1B2A4B for ; Fri, 10 Jul 2015 10:15:32 -0700 (PDT) Received: from [128.9.184.209] ([128.9.184.209]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6AHF1uD000615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jul 2015 10:15:03 -0700 (PDT) To: Brian Trammell References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <559FFD93.8010307@isi.edu> Date: Fri, 10 Jul 2015 10:14:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Tom Herbert , spud@ietf.org, =?UTF-8?Q?Mirja_K=c3=bchlewind?= , touch@isi.edu Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 17:15:35 -0000 Hi, Brian, On 7/10/2015 3:44 AM, Brian Trammell wrote: > >> On 09 Jul 2015, at 19:36, Joe Touch wrote: ... >> IPv4 options can be jumped over in one step using the IHL field. > > yes, |set| = 1. Well, it's actually also because the offset is in the default header and nowhere else. The number of options varies, as does the length of many options. >> There's >> no such field for IPv6 - routers have to walk the chain of headers one >> by one. > > Right. It seems to me the way out of this (which is not just a > problem for boxes that want to muck about in transport protocols, but > ones thatwant to properly process hop by hop options) would be to > define a new(small) set of IPv6 options headers that themselves would > (1) not be combinable and (2) have a fixed length, allowing the > next-header field to be _treated_ in constant time / with relatively > few gates as the IHL field. There are several hurdles, not the least of which is that the length of HBH options can change in transit. You don't really need a fixed length to solve this, or even a fixed set. The options can even be mutable. What you really need is a "jump to transport" header that comes before all the others, and that is maintained by any device that adds, deletes, or changes the length of an option. The real problem there isn't doing that; its knowing whether you've traversed a router that obeys those rules without dropping packets at routers that don't. That would kill IPv6. > I haven't followed 6man, though I presume this approach or > approaches like it have been discussed there ad nauseam. See above. > The fixed-lengthness of these new v6 options headers would make them > problematic for freely extensible options, though one could use these > to stick common fast path options in the "fixed" point of the header, > and otherwise point to space elsewhere in the packet for things that > can happen slowly. You eat the cost of following pointers and doing > the more expensive deframing only if you need to in this case. The real issue, AFIACT, is detecting the behavior of legacy devices that wouldn't know to follow these rules - without having them drop the packet because it is an unknown option (i.e., you can set "drop if unknown", but that would be bad; if you don't set that bit, then you can''t detect when changes occur easily). >>>> I suspect you'll find that IP options are basically a non-starter except >>>> for research purposes. >>> >>> For the story on the v4 side, do you know of anything newer than >>> Fonseca et al "IP Options are Not and Option" (tech report version at >>> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's >>> ten years old -- but given where the engineering effort has gone during >>> that decade, I doubt strongly much has changed here. >> >> Not much. Those old studies have been used in other WGs to drive >> documents (IMO, unfortunately). > > I've been thinking about whether it would be worth the effort to do > an updated IP options transparency study. The IETF has a persistent problem with extensibility. Vendors don't make money supporting capabilities not in current use, but that ossifies the protocols badly. Joe From nobody Fri Jul 10 10:31:40 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3061A037C for ; Fri, 10 Jul 2015 10:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 BzwrJIHzLZ7k for ; Fri, 10 Jul 2015 10:31:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004101A0275 for ; Fri, 10 Jul 2015 10:31:30 -0700 (PDT) Received: from [128.9.184.209] ([128.9.184.209]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6AHVEGY002223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jul 2015 10:31:15 -0700 (PDT) To: Tom Herbert , Brian Trammell References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55A0015F.2090502@isi.edu> Date: Fri, 10 Jul 2015 10:31:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud@ietf.org, =?UTF-8?Q?Mirja_K=c3=bchlewind?= , touch@isi.edu Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 17:31:33 -0000 Hi, Tom, On 7/10/2015 9:19 AM, Tom Herbert wrote: > This "new network layer" breaks down at fragmentation. Only the first > fragment carries port numbers and the embedded network layer > information in the payload. Other fragments will carry neither, but > still can carry IP options, DSCP, TTL, ECN marking, flow labels in > IPv6. Right. Which goes to the point that port numbers are NOT part of the network layer. Those who want to filter on port numbers are operating network devices that act on behalf of endpoints - which is fine, but also means they really ought to be reassembling the network-layer fragments. I.e., the benefit of port filtering needs to come with the work of reassembly. Or, "with great (filtering) power, comes great (don't break the Internet) responsibility". > An alternate possibility would be to embed IP options within UDP. That would be a tunnel, and you might look at GUE. However, you'd have the problem of the relationship of the inner and outer options and how to maintain them as consistent if they're related. Joe From nobody Fri Jul 10 13:45:22 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDAF1A0091 for ; Fri, 10 Jul 2015 13:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 B90NsrgUSlA7 for ; Fri, 10 Jul 2015 13:45:19 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5731A007A for ; Fri, 10 Jul 2015 13:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5442; q=dns/txt; s=iport; t=1436561119; x=1437770719; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=7+umUlnepzqFaCY6uKOE/VqnBrrXDhwK6Rd7gGTu2kg=; b=EKCWsZ5AtZszIEh0oKGRaXBUYFlbiSJsAl4npf7njvezccwe2PdwtEIO DPJw+SabAzBX+kMCklQzKhopzFnlDH8jRL3p3COu7YHbVog3en7A5ROFP cFpXX0zPglCtJcVgfbq4aJ2XI1QnaAK2BmakChAzXI4ZevUzUwZeaeYC+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A1BQBfLqBV/5xdJa1bDoMEVGC9IwqFdwKBSjwQAQEBAQEBAYEKhCQBAQICAQEBNzQLEAsSBgklDwUTIhQTG4gTDc99AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tLhQYHgxeBFAWNHIQsgmmMAwGBP4QYkxQmggwcgRVeHjEBAYEEJYEgAQEB X-IronPort-AV: E=Sophos;i="5.15,449,1432598400"; d="scan'208";a="167467602" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 10 Jul 2015 20:45:17 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6AKjGSA012378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2015 20:45:16 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6AKjFxE024623; Fri, 10 Jul 2015 13:45:15 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6AKjEI1024621; Fri, 10 Jul 2015 13:45:14 -0700 Date: Fri, 10 Jul 2015 13:45:14 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20150710204514.GA23837@cisco.com> References: <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> <559FFD93.8010307@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559FFD93.8010307@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Brian Trammell , spud@ietf.org, Mirja =?iso-8859-1?Q?K=FChlewind?= , Tom Herbert Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:45:21 -0000 IMHO, IP options do not get us anywhere. I want a solution that works against the lowest common denominator of APIs for applications that i have across not only platfornms, but also application development environments. I have UDP APIs on a lot more SDKs that UDP + IP options. I bet if i looked, i wouldn't find IP optoins in a lot of interpreted language SDKs. Even if supported by language SDK, its an OS issue whether IP optoins are supported. I remember that some investigation for a project we did 2? years back now resulted in us finding that at C level system APIs, android for example was not supporting IP router alert for a UDP socket for IPv6, even though it supported it for IPv4 (i hope i remember these details correctly). And its just one example. If all of this stuff is fine, i am totally not persuaded that IP options are going to be accepted by network operators. There is no way to guarantee to a network operator that packets with IP options are NOT punted and cause performance impacts. We went through this exercise with ECN, and still haven't moved ahead. After 10 years or so. Where is the stealth data-collection facility in eg: firefox that tries randomn ECN flows not only to see whether they pass through, but also checking latency & jitter to validate that these ECN packets where not punted in routers when they did pass through ? I am not saying we shouldn't have a glorified plan for STUN that ALSO includes the architecture for doing it correctly for the 1980's Internet architecture, but please lets not make this plan A. The Internet architecture has evolved on so many fronts. Can we not learn in the network/transport layer structure too how to get the best solutions for reality ? Just saying. Toerless On Fri, Jul 10, 2015 at 10:14:59AM -0700, Joe Touch wrote: > Hi, Brian, > > On 7/10/2015 3:44 AM, Brian Trammell wrote: > > > >> On 09 Jul 2015, at 19:36, Joe Touch wrote: > ... > >> IPv4 options can be jumped over in one step using the IHL field. > > > > yes, |set| = 1. > > Well, it's actually also because the offset is in the default header and > nowhere else. The number of options varies, as does the length of many > options. > > >> There's > >> no such field for IPv6 - routers have to walk the chain of headers one > >> by one. > > > > Right. It seems to me the way out of this (which is not just a > > problem for boxes that want to muck about in transport protocols, but > > ones thatwant to properly process hop by hop options) would be to > > define a new(small) set of IPv6 options headers that themselves would > > (1) not be combinable and (2) have a fixed length, allowing the > > next-header field to be _treated_ in constant time / with relatively > > few gates as the IHL field. > > There are several hurdles, not the least of which is that the length of > HBH options can change in transit. > > You don't really need a fixed length to solve this, or even a fixed set. > The options can even be mutable. > > What you really need is a "jump to transport" header that comes before > all the others, and that is maintained by any device that adds, deletes, > or changes the length of an option. > > The real problem there isn't doing that; its knowing whether you've > traversed a router that obeys those rules without dropping packets at > routers that don't. That would kill IPv6. > > > I haven't followed 6man, though I presume this approach or > > approaches like it have been discussed there ad nauseam. > > See above. > > > The fixed-lengthness of these new v6 options headers would make them > > problematic for freely extensible options, though one could use these > > to stick common fast path options in the "fixed" point of the header, > > and otherwise point to space elsewhere in the packet for things that > > can happen slowly. You eat the cost of following pointers and doing > > the more expensive deframing only if you need to in this case. > > The real issue, AFIACT, is detecting the behavior of legacy devices that > wouldn't know to follow these rules - without having them drop the > packet because it is an unknown option (i.e., you can set "drop if > unknown", but that would be bad; if you don't set that bit, then you > can''t detect when changes occur easily). > > >>>> I suspect you'll find that IP options are basically a non-starter except > >>>> for research purposes. > >>> > >>> For the story on the v4 side, do you know of anything newer than > >>> Fonseca et al "IP Options are Not and Option" (tech report version at > >>> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's > >>> ten years old -- but given where the engineering effort has gone during > >>> that decade, I doubt strongly much has changed here. > >> > >> Not much. Those old studies have been used in other WGs to drive > >> documents (IMO, unfortunately). > > > > I've been thinking about whether it would be worth the effort to do > > an updated IP options transparency study. > > The IETF has a persistent problem with extensibility. Vendors don't make > money supporting capabilities not in current use, but that ossifies the > protocols badly. > > Joe > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Fri Jul 10 14:45:33 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1FD1B2CE0 for ; Fri, 10 Jul 2015 14:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 69z6s3ez3xNe for ; Fri, 10 Jul 2015 14:45:28 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFBF1B2CFE for ; Fri, 10 Jul 2015 14:45:27 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6ALiig7012306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jul 2015 14:44:45 -0700 (PDT) Message-ID: <55A03CCC.1060904@isi.edu> Date: Fri, 10 Jul 2015 14:44:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Toerless Eckert References: <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> <559FFD93.8010307@isi.edu> <20150710204514.GA23837@cisco.com> In-Reply-To: <20150710204514.GA23837@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t6ALiig7012306 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , spud@ietf.org, =?windows-1252?Q?Mirja_K=FChlewind?= , Tom Herbert , touch@isi.edu Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 21:45:31 -0000 +1, for somewhat different reasons, notably the problem deploying new IP options and layer separation. This really hints that UDP isn't quite sufficient without its own options. There seems only one place to do this - using the UDP length field. E.g., let's say you have a 1500B IP packet with a 20B IP header, leaving 1480 for UDP. But instead of saying that UDP's Length is 1280, we say it's 1400; in that case, the last 80 bytes could be used as a 'trailer option area'. This is somewhat like UDP-lite, except that instead of declaring the length to indicate "checksum coverage", it would just indicate the UDP payload vs. extended header, and it would use the existing UDP protocol number (17) rather than that of UDPlite (136). --- The reason why this mechanism can use the current UDP protocol number is that we're not changing the semantics of UDP or the length of the data delivered to the application vs. the existing UDP length field. Because we're still assuming that the UDP checksum covers only the length indicated in the UDP header, there should be no inconsistency with "mismatching pseudoheaders" - I think. I'll check with the UDPlite crowd (unless any are already on this list - Gorry?) --- I'm still not convinced it's safe, though. It would not be covered by the UDP checksum. I have no idea whether existing stacks would handle it correctly (i.e., ignoring the extra bytes) vs. shortening the IP packet to make the lengths match. NOTE: this appears valid per RFC1122 and RFC768, but I haven't tried it to see whether it makes various OSes blow up yet... Hmmm. Joe On 7/10/2015 1:45 PM, Toerless Eckert wrote: > IMHO, IP options do not get us anywhere. > > I want a solution that works against the lowest common denominator > of APIs for applications that i have across not only platfornms, > but also application development environments. I have UDP APIs on > a lot more SDKs that UDP + IP options. I bet if i looked, i wouldn't > find IP optoins in a lot of interpreted language SDKs. > > Even if supported by language SDK, its an OS issue whether IP optoins > are supported. I remember that some investigation for a project we did > 2? years back now resulted in us finding that at C level system APIs, > android for example was not supporting IP router alert for a UDP socket > for IPv6, even though it supported it for IPv4 (i hope i remember these > details correctly). And its just one example. > > If all of this stuff is fine, i am totally not persuaded that IP > options are going to be accepted by network operators. There is no > way to guarantee to a network operator that packets with IP options are > NOT punted and cause performance impacts. > > We went through this exercise with ECN, and still haven't moved ahead. > After 10 years or so. Where is the stealth data-collection facility in > eg: firefox that tries randomn ECN flows not only to see whether they > pass through, but also checking latency & jitter to validate that > these ECN packets where not punted in routers when they did pass through ? > > I am not saying we shouldn't have a glorified plan for STUN that ALSO > includes the architecture for doing it correctly for the > 1980's Internet architecture, but please lets not make this plan A. > > The Internet architecture has evolved on so many fronts. Can we not > learn in the network/transport layer structure too how to get the > best solutions for reality ? > > Just saying. > > Toerless > > On Fri, Jul 10, 2015 at 10:14:59AM -0700, Joe Touch wrote: >> Hi, Brian, >> >> On 7/10/2015 3:44 AM, Brian Trammell wrote: >>> >>>> On 09 Jul 2015, at 19:36, Joe Touch wrote: >> ... >>>> IPv4 options can be jumped over in one step using the IHL field. >>> >>> yes, |set| = 1. >> >> Well, it's actually also because the offset is in the default header and >> nowhere else. The number of options varies, as does the length of many >> options. >> >>>> There's >>>> no such field for IPv6 - routers have to walk the chain of headers one >>>> by one. >>> >>> Right. It seems to me the way out of this (which is not just a >>> problem for boxes that want to muck about in transport protocols, but >>> ones thatwant to properly process hop by hop options) would be to >>> define a new(small) set of IPv6 options headers that themselves would >>> (1) not be combinable and (2) have a fixed length, allowing the >>> next-header field to be _treated_ in constant time / with relatively >>> few gates as the IHL field. >> >> There are several hurdles, not the least of which is that the length of >> HBH options can change in transit. >> >> You don't really need a fixed length to solve this, or even a fixed set. >> The options can even be mutable. >> >> What you really need is a "jump to transport" header that comes before >> all the others, and that is maintained by any device that adds, deletes, >> or changes the length of an option. >> >> The real problem there isn't doing that; its knowing whether you've >> traversed a router that obeys those rules without dropping packets at >> routers that don't. That would kill IPv6. >> >>> I haven't followed 6man, though I presume this approach or >>> approaches like it have been discussed there ad nauseam. >> >> See above. >> >>> The fixed-lengthness of these new v6 options headers would make them >>> problematic for freely extensible options, though one could use these >>> to stick common fast path options in the "fixed" point of the header, >>> and otherwise point to space elsewhere in the packet for things that >>> can happen slowly. You eat the cost of following pointers and doing >>> the more expensive deframing only if you need to in this case. >> >> The real issue, AFIACT, is detecting the behavior of legacy devices that >> wouldn't know to follow these rules - without having them drop the >> packet because it is an unknown option (i.e., you can set "drop if >> unknown", but that would be bad; if you don't set that bit, then you >> can''t detect when changes occur easily). >> >>>>>> I suspect you'll find that IP options are basically a non-starter except >>>>>> for research purposes. >>>>> >>>>> For the story on the v4 side, do you know of anything newer than >>>>> Fonseca et al "IP Options are Not and Option" (tech report version at >>>>> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's >>>>> ten years old -- but given where the engineering effort has gone during >>>>> that decade, I doubt strongly much has changed here. >>>> >>>> Not much. Those old studies have been used in other WGs to drive >>>> documents (IMO, unfortunately). >>> >>> I've been thinking about whether it would be worth the effort to do >>> an updated IP options transparency study. >> >> The IETF has a persistent problem with extensibility. Vendors don't make >> money supporting capabilities not in current use, but that ossifies the >> protocols badly. >> >> Joe >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud From nobody Fri Jul 10 15:22:33 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742061A0019 for ; Fri, 10 Jul 2015 15:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 UJi83cGPaUPV for ; Fri, 10 Jul 2015 15:22:29 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC5E1A00C0 for ; Fri, 10 Jul 2015 15:19:54 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so204324610ieb.1 for ; Fri, 10 Jul 2015 15:19:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4WoZZ1ohgGJFxtTePkAN9+Ku7T2lfA4ilUaWkIO9OcQ=; b=hmdrJH73VT4ZONiJrK0XYCbnQUoUePnGZ7caXKxqsXE7525w3ADwYdQ5Rf2Uy3QLMg 5OPFEyuT93IVmCWzd8NIS2Cwp0sANr3VSkBd1y6j0XvZiwHT0/hM9SE6Cy6zNyk7Ntg8 4SITY02GpPRbOaT7ExUGhE+yZo9mycEcvBCwGfrQpG4Ln6D0rI2ODr8i8207bRovVK5o uIaqdF9ESgpJEw8zZkNRoUPL/3TDIDadnQkUgMRw4z/0pS16Fgx554IeQBJC9RXrz1JR Zz8eg+vis6HK3U0PixGTv6FuOJ8V5zK3sAWco+woQKjogGdZoweEbvXyeojEu/CKcgPY HIQA== X-Gm-Message-State: ALoCoQkNJX+eTnPBE0lfAQ2QpHzU2ewbufZg6fjv3VuNMB5dzrgl5lZGuac3LUoaj82pMnvB0IZf MIME-Version: 1.0 X-Received: by 10.107.9.142 with SMTP id 14mr8411485ioj.142.1436566793659; Fri, 10 Jul 2015 15:19:53 -0700 (PDT) Received: by 10.107.142.86 with HTTP; Fri, 10 Jul 2015 15:19:53 -0700 (PDT) In-Reply-To: <55A03CCC.1060904@isi.edu> References: <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> <559FFD93.8010307@isi.edu> <20150710204514.GA23837@cisco.com> <55A03CCC.1060904@isi.edu> Date: Fri, 10 Jul 2015 15:19:53 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Trammell , Toerless Eckert , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud@ietf.org Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 22:22:31 -0000 On Fri, Jul 10, 2015 at 2:44 PM, Joe Touch wrote: > +1, for somewhat different reasons, notably the problem deploying new IP > options and layer separation. > > This really hints that UDP isn't quite sufficient without its own > options. There seems only one place to do this - using the UDP length > field. > > E.g., let's say you have a 1500B IP packet with a 20B IP header, leaving > 1480 for UDP. But instead of saying that UDP's Length is 1280, we say > it's 1400; in that case, the last 80 bytes could be used as a 'trailer > option area'. > You get UDP data on a UDP socket, so 1400 bytes is returned. Returning the extra bytes would be a simple kernel and API change (at least in Linux). Besides that, I imagine that HW vendors probably want the options to be in the headers due to the HW limitations of packet processing. > This is somewhat like UDP-lite, except that instead of declaring the > length to indicate "checksum coverage", it would just indicate the UDP > payload vs. extended header, and it would use the existing UDP protocol > number (17) rather than that of UDPlite (136). > > --- > The reason why this mechanism can use the current UDP protocol number is > that we're not changing the semantics of UDP or the length of the data > delivered to the application vs. the existing UDP length field. > > Because we're still assuming that the UDP checksum covers only the > length indicated in the UDP header, there should be no inconsistency > with "mismatching pseudoheaders" - I think. I'll check with the UDPlite > crowd (unless any are already on this list - Gorry?) > --- IIRC there was a proposal to contort the UDP checksum to become something closer to a UDP-lite checksum. The idea was to indicate this mode by setting a UDP length less than 8, and inferring the actual length of the UDP payload from the IP total length. Conceptually, this same hack could be used to add options to UDP. > > I'm still not convinced it's safe, though. It would not be covered by > the UDP checksum. I have no idea whether existing stacks would handle it > correctly (i.e., ignoring the extra bytes) vs. shortening the IP packet > to make the lengths match. > > NOTE: this appears valid per RFC1122 and RFC768, but I haven't tried it > to see whether it makes various OSes blow up yet... > > Hmmm. > > Joe > > On 7/10/2015 1:45 PM, Toerless Eckert wrote: >> IMHO, IP options do not get us anywhere. >> >> I want a solution that works against the lowest common denominator >> of APIs for applications that i have across not only platfornms, >> but also application development environments. I have UDP APIs on >> a lot more SDKs that UDP + IP options. I bet if i looked, i wouldn't >> find IP optoins in a lot of interpreted language SDKs. >> >> Even if supported by language SDK, its an OS issue whether IP optoins >> are supported. I remember that some investigation for a project we did >> 2? years back now resulted in us finding that at C level system APIs, >> android for example was not supporting IP router alert for a UDP socket >> for IPv6, even though it supported it for IPv4 (i hope i remember these >> details correctly). And its just one example. >> >> If all of this stuff is fine, i am totally not persuaded that IP >> options are going to be accepted by network operators. There is no >> way to guarantee to a network operator that packets with IP options are >> NOT punted and cause performance impacts. >> >> We went through this exercise with ECN, and still haven't moved ahead. >> After 10 years or so. Where is the stealth data-collection facility in >> eg: firefox that tries randomn ECN flows not only to see whether they >> pass through, but also checking latency & jitter to validate that >> these ECN packets where not punted in routers when they did pass through ? >> >> I am not saying we shouldn't have a glorified plan for STUN that ALSO >> includes the architecture for doing it correctly for the >> 1980's Internet architecture, but please lets not make this plan A. >> >> The Internet architecture has evolved on so many fronts. Can we not >> learn in the network/transport layer structure too how to get the >> best solutions for reality ? >> >> Just saying. >> >> Toerless >> >> On Fri, Jul 10, 2015 at 10:14:59AM -0700, Joe Touch wrote: >>> Hi, Brian, >>> >>> On 7/10/2015 3:44 AM, Brian Trammell wrote: >>>> >>>>> On 09 Jul 2015, at 19:36, Joe Touch wrote: >>> ... >>>>> IPv4 options can be jumped over in one step using the IHL field. >>>> >>>> yes, |set| = 1. >>> >>> Well, it's actually also because the offset is in the default header and >>> nowhere else. The number of options varies, as does the length of many >>> options. >>> >>>>> There's >>>>> no such field for IPv6 - routers have to walk the chain of headers one >>>>> by one. >>>> >>>> Right. It seems to me the way out of this (which is not just a >>>> problem for boxes that want to muck about in transport protocols, but >>>> ones thatwant to properly process hop by hop options) would be to >>>> define a new(small) set of IPv6 options headers that themselves would >>>> (1) not be combinable and (2) have a fixed length, allowing the >>>> next-header field to be _treated_ in constant time / with relatively >>>> few gates as the IHL field. >>> >>> There are several hurdles, not the least of which is that the length of >>> HBH options can change in transit. >>> >>> You don't really need a fixed length to solve this, or even a fixed set. >>> The options can even be mutable. >>> >>> What you really need is a "jump to transport" header that comes before >>> all the others, and that is maintained by any device that adds, deletes, >>> or changes the length of an option. >>> >>> The real problem there isn't doing that; its knowing whether you've >>> traversed a router that obeys those rules without dropping packets at >>> routers that don't. That would kill IPv6. >>> >>>> I haven't followed 6man, though I presume this approach or >>>> approaches like it have been discussed there ad nauseam. >>> >>> See above. >>> >>>> The fixed-lengthness of these new v6 options headers would make them >>>> problematic for freely extensible options, though one could use these >>>> to stick common fast path options in the "fixed" point of the header, >>>> and otherwise point to space elsewhere in the packet for things that >>>> can happen slowly. You eat the cost of following pointers and doing >>>> the more expensive deframing only if you need to in this case. >>> >>> The real issue, AFIACT, is detecting the behavior of legacy devices that >>> wouldn't know to follow these rules - without having them drop the >>> packet because it is an unknown option (i.e., you can set "drop if >>> unknown", but that would be bad; if you don't set that bit, then you >>> can''t detect when changes occur easily). >>> >>>>>>> I suspect you'll find that IP options are basically a non-starter except >>>>>>> for research purposes. >>>>>> >>>>>> For the story on the v4 side, do you know of anything newer than >>>>>> Fonseca et al "IP Options are Not and Option" (tech report version at >>>>>> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's >>>>>> ten years old -- but given where the engineering effort has gone during >>>>>> that decade, I doubt strongly much has changed here. >>>>> >>>>> Not much. Those old studies have been used in other WGs to drive >>>>> documents (IMO, unfortunately). >>>> >>>> I've been thinking about whether it would be worth the effort to do >>>> an updated IP options transparency study. >>> >>> The IETF has a persistent problem with extensibility. Vendors don't make >>> money supporting capabilities not in current use, but that ossifies the >>> protocols badly. >>> >>> Joe >>> >>> _______________________________________________ >>> Spud mailing list >>> Spud@ietf.org >>> https://www.ietf.org/mailman/listinfo/spud From nobody Fri Jul 10 15:29:54 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD04E1A0022 for ; Fri, 10 Jul 2015 15:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 s1qc8j747nPH for ; Fri, 10 Jul 2015 15:29:50 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3074A1A0011 for ; Fri, 10 Jul 2015 15:29:50 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6AMT5mU017399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jul 2015 15:29:05 -0700 (PDT) Message-ID: <55A04731.90209@isi.edu> Date: Fri, 10 Jul 2015 15:29:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tom Herbert References: <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> <559FFD93.8010307@isi.edu> <20150710204514.GA23837@cisco.com> <55A03CCC.1060904@isi.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t6AMT5mU017399 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , Toerless Eckert , spud@ietf.org, =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , touch@isi.edu Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 22:29:52 -0000 On 7/10/2015 3:19 PM, Tom Herbert wrote: > On Fri, Jul 10, 2015 at 2:44 PM, Joe Touch wrote: >> +1, for somewhat different reasons, notably the problem deploying new IP >> options and layer separation. >> >> This really hints that UDP isn't quite sufficient without its own >> options. There seems only one place to do this - using the UDP length >> field. >> >> E.g., let's say you have a 1500B IP packet with a 20B IP header, leaving >> 1480 for UDP. But instead of saying that UDP's Length is 1280, we say >> it's 1400; in that case, the last 80 bytes could be used as a 'trailer >> option area'. >> > You get UDP data on a UDP socket, so 1400 bytes is returned. Sure - to the user. > Returning > the extra bytes would be a simple kernel and API change (at least in > Linux). You'd keep that within "UDP". If you want to get at that portion, it'd be like accessing a raw IP socket. > Besides that, I imagine that HW vendors probably want the > options to be in the headers due to the HW limitations of packet > processing. They just want a quick way to find them. ;-) > >> This is somewhat like UDP-lite, except that instead of declaring the >> length to indicate "checksum coverage", it would just indicate the UDP >> payload vs. extended header, and it would use the existing UDP protocol >> number (17) rather than that of UDPlite (136). >> >> --- >> The reason why this mechanism can use the current UDP protocol number is >> that we're not changing the semantics of UDP or the length of the data >> delivered to the application vs. the existing UDP length field. >> >> Because we're still assuming that the UDP checksum covers only the >> length indicated in the UDP header, there should be no inconsistency >> with "mismatching pseudoheaders" - I think. I'll check with the UDPlite >> crowd (unless any are already on this list - Gorry?) >> --- > > IIRC there was a proposal to contort the UDP checksum to become > something closer to a UDP-lite checksum. The idea was to indicate this > mode by setting a UDP length less than 8, and inferring the actual > length of the UDP payload from the IP total length. Conceptually, this > same hack could be used to add options to UDP. Yes, that's what I am proposing. The difference with UDP-lite is that I would not be returning the extra UDP header option space to the user; UDP-lite treats that space as "not covered by the checksum" but also returned to the user. Joe >> I'm still not convinced it's safe, though. It would not be covered by >> the UDP checksum. I have no idea whether existing stacks would handle it >> correctly (i.e., ignoring the extra bytes) vs. shortening the IP packet >> to make the lengths match. >> >> NOTE: this appears valid per RFC1122 and RFC768, but I haven't tried it >> to see whether it makes various OSes blow up yet... >> >> Hmmm. >> >> Joe >> >> On 7/10/2015 1:45 PM, Toerless Eckert wrote: >>> IMHO, IP options do not get us anywhere. >>> >>> I want a solution that works against the lowest common denominator >>> of APIs for applications that i have across not only platfornms, >>> but also application development environments. I have UDP APIs on >>> a lot more SDKs that UDP + IP options. I bet if i looked, i wouldn't >>> find IP optoins in a lot of interpreted language SDKs. >>> >>> Even if supported by language SDK, its an OS issue whether IP optoins >>> are supported. I remember that some investigation for a project we did >>> 2? years back now resulted in us finding that at C level system APIs, >>> android for example was not supporting IP router alert for a UDP socket >>> for IPv6, even though it supported it for IPv4 (i hope i remember these >>> details correctly). And its just one example. >>> >>> If all of this stuff is fine, i am totally not persuaded that IP >>> options are going to be accepted by network operators. There is no >>> way to guarantee to a network operator that packets with IP options are >>> NOT punted and cause performance impacts. >>> >>> We went through this exercise with ECN, and still haven't moved ahead. >>> After 10 years or so. Where is the stealth data-collection facility in >>> eg: firefox that tries randomn ECN flows not only to see whether they >>> pass through, but also checking latency & jitter to validate that >>> these ECN packets where not punted in routers when they did pass through ? >>> >>> I am not saying we shouldn't have a glorified plan for STUN that ALSO >>> includes the architecture for doing it correctly for the >>> 1980's Internet architecture, but please lets not make this plan A. >>> >>> The Internet architecture has evolved on so many fronts. Can we not >>> learn in the network/transport layer structure too how to get the >>> best solutions for reality ? >>> >>> Just saying. >>> >>> Toerless >>> >>> On Fri, Jul 10, 2015 at 10:14:59AM -0700, Joe Touch wrote: >>>> Hi, Brian, >>>> >>>> On 7/10/2015 3:44 AM, Brian Trammell wrote: >>>>> >>>>>> On 09 Jul 2015, at 19:36, Joe Touch wrote: >>>> ... >>>>>> IPv4 options can be jumped over in one step using the IHL field. >>>>> >>>>> yes, |set| = 1. >>>> >>>> Well, it's actually also because the offset is in the default header and >>>> nowhere else. The number of options varies, as does the length of many >>>> options. >>>> >>>>>> There's >>>>>> no such field for IPv6 - routers have to walk the chain of headers one >>>>>> by one. >>>>> >>>>> Right. It seems to me the way out of this (which is not just a >>>>> problem for boxes that want to muck about in transport protocols, but >>>>> ones thatwant to properly process hop by hop options) would be to >>>>> define a new(small) set of IPv6 options headers that themselves would >>>>> (1) not be combinable and (2) have a fixed length, allowing the >>>>> next-header field to be _treated_ in constant time / with relatively >>>>> few gates as the IHL field. >>>> >>>> There are several hurdles, not the least of which is that the length of >>>> HBH options can change in transit. >>>> >>>> You don't really need a fixed length to solve this, or even a fixed set. >>>> The options can even be mutable. >>>> >>>> What you really need is a "jump to transport" header that comes before >>>> all the others, and that is maintained by any device that adds, deletes, >>>> or changes the length of an option. >>>> >>>> The real problem there isn't doing that; its knowing whether you've >>>> traversed a router that obeys those rules without dropping packets at >>>> routers that don't. That would kill IPv6. >>>> >>>>> I haven't followed 6man, though I presume this approach or >>>>> approaches like it have been discussed there ad nauseam. >>>> >>>> See above. >>>> >>>>> The fixed-lengthness of these new v6 options headers would make them >>>>> problematic for freely extensible options, though one could use these >>>>> to stick common fast path options in the "fixed" point of the header, >>>>> and otherwise point to space elsewhere in the packet for things that >>>>> can happen slowly. You eat the cost of following pointers and doing >>>>> the more expensive deframing only if you need to in this case. >>>> >>>> The real issue, AFIACT, is detecting the behavior of legacy devices that >>>> wouldn't know to follow these rules - without having them drop the >>>> packet because it is an unknown option (i.e., you can set "drop if >>>> unknown", but that would be bad; if you don't set that bit, then you >>>> can''t detect when changes occur easily). >>>> >>>>>>>> I suspect you'll find that IP options are basically a non-starter except >>>>>>>> for research purposes. >>>>>>> >>>>>>> For the story on the v4 side, do you know of anything newer than >>>>>>> Fonseca et al "IP Options are Not and Option" (tech report version at >>>>>>> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's >>>>>>> ten years old -- but given where the engineering effort has gone during >>>>>>> that decade, I doubt strongly much has changed here. >>>>>> >>>>>> Not much. Those old studies have been used in other WGs to drive >>>>>> documents (IMO, unfortunately). >>>>> >>>>> I've been thinking about whether it would be worth the effort to do >>>>> an updated IP options transparency study. >>>> >>>> The IETF has a persistent problem with extensibility. Vendors don't make >>>> money supporting capabilities not in current use, but that ossifies the >>>> protocols badly. >>>> >>>> Joe >>>> >>>> _______________________________________________ >>>> Spud mailing list >>>> Spud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spud From nobody Mon Jul 13 04:43:09 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41ED1A9078 for ; Mon, 13 Jul 2015 04:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 eup0eMzwXin2 for ; Mon, 13 Jul 2015 04:43:04 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961841A9069 for ; Mon, 13 Jul 2015 04:43:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 998BAD9305; Mon, 13 Jul 2015 13:43:01 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TWHXsBHQhksX; Mon, 13 Jul 2015 13:43:01 +0200 (MEST) Received: from [192.168.178.33] (x4d02d263.dyn.telefonica.de [77.2.210.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BB1CED9302; Mon, 13 Jul 2015 13:43:00 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <55A04731.90209@isi.edu> Date: Mon, 13 Jul 2015 13:42:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B016995-0037-42B2-B504-35D5D2726732@tik.ee.ethz.ch> References: <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> <559FFD93.8010307@isi.edu> <20150710204514.GA23837@cisco.com> <55A03CCC.1060904@isi.edu> <55A04731.90209@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Tom Herbert , Toerless Eckert , spud@ietf.org, Brian Trammell Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 11:43:08 -0000 +1 Now this extra space is for me the place where you put a SPUD header (no = matter how this header looks like). I personally was seen SPUD over UDP = also as a way to make UDP extensible. So you could also add end-to-end = information to SPUD e.g. timestamp information, if these information are = useful for different overlaying protocols=E2=80=A6 The little 'hack' you describe below is great to address the discover = problem: How do I know the other end is SPUD enable=E2=80=A6? - I = don=E2=80=99t care=E2=80=A6 Mirja =20 > Am 11.07.2015 um 00:29 schrieb Joe Touch : >=20 >=20 >=20 > On 7/10/2015 3:19 PM, Tom Herbert wrote: >> On Fri, Jul 10, 2015 at 2:44 PM, Joe Touch wrote: >>> +1, for somewhat different reasons, notably the problem deploying = new IP >>> options and layer separation. >>>=20 >>> This really hints that UDP isn't quite sufficient without its own >>> options. There seems only one place to do this - using the UDP = length >>> field. >>>=20 >>> E.g., let's say you have a 1500B IP packet with a 20B IP header, = leaving >>> 1480 for UDP. But instead of saying that UDP's Length is 1280, we = say >>> it's 1400; in that case, the last 80 bytes could be used as a = 'trailer >>> option area'. >>>=20 >> You get UDP data on a UDP socket, so 1400 bytes is returned. >=20 > Sure - to the user. >=20 >> Returning >> the extra bytes would be a simple kernel and API change (at least in >> Linux). >=20 > You'd keep that within "UDP". If you want to get at that portion, it'd > be like accessing a raw IP socket. >=20 >> Besides that, I imagine that HW vendors probably want the >> options to be in the headers due to the HW limitations of packet >> processing. >=20 > They just want a quick way to find them. ;-) >=20 >>=20 >>> This is somewhat like UDP-lite, except that instead of declaring the >>> length to indicate "checksum coverage", it would just indicate the = UDP >>> payload vs. extended header, and it would use the existing UDP = protocol >>> number (17) rather than that of UDPlite (136). >>>=20 >>> --- >>> The reason why this mechanism can use the current UDP protocol = number is >>> that we're not changing the semantics of UDP or the length of the = data >>> delivered to the application vs. the existing UDP length field. >>>=20 >>> Because we're still assuming that the UDP checksum covers only the >>> length indicated in the UDP header, there should be no inconsistency >>> with "mismatching pseudoheaders" - I think. I'll check with the = UDPlite >>> crowd (unless any are already on this list - Gorry?) >>> --- >>=20 >> IIRC there was a proposal to contort the UDP checksum to become >> something closer to a UDP-lite checksum. The idea was to indicate = this >> mode by setting a UDP length less than 8, and inferring the actual >> length of the UDP payload from the IP total length. Conceptually, = this >> same hack could be used to add options to UDP. >=20 > Yes, that's what I am proposing. The difference with UDP-lite is that = I > would not be returning the extra UDP header option space to the user; > UDP-lite treats that space as "not covered by the checksum" but also > returned to the user. >=20 > Joe >=20 >>> I'm still not convinced it's safe, though. It would not be covered = by >>> the UDP checksum. I have no idea whether existing stacks would = handle it >>> correctly (i.e., ignoring the extra bytes) vs. shortening the IP = packet >>> to make the lengths match. >>>=20 >>> NOTE: this appears valid per RFC1122 and RFC768, but I haven't tried = it >>> to see whether it makes various OSes blow up yet... >>>=20 >>> Hmmm. >>>=20 >>> Joe >>>=20 >>> On 7/10/2015 1:45 PM, Toerless Eckert wrote: >>>> IMHO, IP options do not get us anywhere. >>>>=20 >>>> I want a solution that works against the lowest common denominator >>>> of APIs for applications that i have across not only platfornms, >>>> but also application development environments. I have UDP APIs on >>>> a lot more SDKs that UDP + IP options. I bet if i looked, i = wouldn't >>>> find IP optoins in a lot of interpreted language SDKs. >>>>=20 >>>> Even if supported by language SDK, its an OS issue whether IP = optoins >>>> are supported. I remember that some investigation for a project we = did >>>> 2? years back now resulted in us finding that at C level system = APIs, >>>> android for example was not supporting IP router alert for a UDP = socket >>>> for IPv6, even though it supported it for IPv4 (i hope i remember = these >>>> details correctly). And its just one example. >>>>=20 >>>> If all of this stuff is fine, i am totally not persuaded that IP >>>> options are going to be accepted by network operators. There is no >>>> way to guarantee to a network operator that packets with IP options = are >>>> NOT punted and cause performance impacts. >>>>=20 >>>> We went through this exercise with ECN, and still haven't moved = ahead. >>>> After 10 years or so. Where is the stealth data-collection facility = in >>>> eg: firefox that tries randomn ECN flows not only to see whether = they >>>> pass through, but also checking latency & jitter to validate that >>>> these ECN packets where not punted in routers when they did pass = through ? >>>>=20 >>>> I am not saying we shouldn't have a glorified plan for STUN that = ALSO >>>> includes the architecture for doing it correctly for the >>>> 1980's Internet architecture, but please lets not make this plan A. >>>>=20 >>>> The Internet architecture has evolved on so many fronts. Can we not >>>> learn in the network/transport layer structure too how to get the >>>> best solutions for reality ? >>>>=20 >>>> Just saying. >>>>=20 >>>> Toerless >>>>=20 >>>> On Fri, Jul 10, 2015 at 10:14:59AM -0700, Joe Touch wrote: >>>>> Hi, Brian, >>>>>=20 >>>>> On 7/10/2015 3:44 AM, Brian Trammell wrote: >>>>>>=20 >>>>>>> On 09 Jul 2015, at 19:36, Joe Touch wrote: >>>>> ... >>>>>>> IPv4 options can be jumped over in one step using the IHL field. >>>>>>=20 >>>>>> yes, |set| =3D 1. >>>>>=20 >>>>> Well, it's actually also because the offset is in the default = header and >>>>> nowhere else. The number of options varies, as does the length of = many >>>>> options. >>>>>=20 >>>>>>> There's >>>>>>> no such field for IPv6 - routers have to walk the chain of = headers one >>>>>>> by one. >>>>>>=20 >>>>>> Right. It seems to me the way out of this (which is not just a >>>>>> problem for boxes that want to muck about in transport protocols, = but >>>>>> ones thatwant to properly process hop by hop options) would be to >>>>>> define a new(small) set of IPv6 options headers that themselves = would >>>>>> (1) not be combinable and (2) have a fixed length, allowing the >>>>>> next-header field to be _treated_ in constant time / with = relatively >>>>>> few gates as the IHL field. >>>>>=20 >>>>> There are several hurdles, not the least of which is that the = length of >>>>> HBH options can change in transit. >>>>>=20 >>>>> You don't really need a fixed length to solve this, or even a = fixed set. >>>>> The options can even be mutable. >>>>>=20 >>>>> What you really need is a "jump to transport" header that comes = before >>>>> all the others, and that is maintained by any device that adds, = deletes, >>>>> or changes the length of an option. >>>>>=20 >>>>> The real problem there isn't doing that; its knowing whether = you've >>>>> traversed a router that obeys those rules without dropping packets = at >>>>> routers that don't. That would kill IPv6. >>>>>=20 >>>>>> I haven't followed 6man, though I presume this approach or >>>>>> approaches like it have been discussed there ad nauseam. >>>>>=20 >>>>> See above. >>>>>=20 >>>>>> The fixed-lengthness of these new v6 options headers would make = them >>>>>> problematic for freely extensible options, though one could use = these >>>>>> to stick common fast path options in the "fixed" point of the = header, >>>>>> and otherwise point to space elsewhere in the packet for things = that >>>>>> can happen slowly. You eat the cost of following pointers and = doing >>>>>> the more expensive deframing only if you need to in this case. >>>>>=20 >>>>> The real issue, AFIACT, is detecting the behavior of legacy = devices that >>>>> wouldn't know to follow these rules - without having them drop the >>>>> packet because it is an unknown option (i.e., you can set "drop if >>>>> unknown", but that would be bad; if you don't set that bit, then = you >>>>> can''t detect when changes occur easily). >>>>>=20 >>>>>>>>> I suspect you'll find that IP options are basically a = non-starter except >>>>>>>>> for research purposes. >>>>>>>>=20 >>>>>>>> For the story on the v4 side, do you know of anything newer = than >>>>>>>> Fonseca et al "IP Options are Not and Option" (tech report = version at >>>>>>>> = http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's >>>>>>>> ten years old -- but given where the engineering effort has = gone during >>>>>>>> that decade, I doubt strongly much has changed here. >>>>>>>=20 >>>>>>> Not much. Those old studies have been used in other WGs to drive >>>>>>> documents (IMO, unfortunately). >>>>>>=20 >>>>>> I've been thinking about whether it would be worth the effort to = do >>>>>> an updated IP options transparency study. >>>>>=20 >>>>> The IETF has a persistent problem with extensibility. Vendors = don't make >>>>> money supporting capabilities not in current use, but that = ossifies the >>>>> protocols badly. >>>>>=20 >>>>> Joe >>>>>=20 >>>>> _______________________________________________ >>>>> Spud mailing list >>>>> Spud@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spud From nobody Mon Jul 13 05:09:51 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54431ACDCA for ; Mon, 13 Jul 2015 05:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 PpfG1nGj1UMI for ; Mon, 13 Jul 2015 05:09:48 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2059B1ACD6A for ; Mon, 13 Jul 2015 05:09:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5A06AD9303; Mon, 13 Jul 2015 14:09:46 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MsAOyOQK0btt; Mon, 13 Jul 2015 14:09:46 +0200 (MEST) Received: from [192.168.178.33] (x4d02d263.dyn.telefonica.de [77.2.210.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BDE92D9302; Mon, 13 Jul 2015 14:09:45 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 13 Jul 2015 14:09:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jacob Chappell X-Mailer: Apple Mail (2.2102) Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] Connect and ACK Bits: Why? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 12:09:51 -0000 Hi Jacob, I believe nobody answered this mail so far, so I=E2=80=99ll have a try. = We=E2=80=99ve been discussing this a lot and also have not decided if we = will need these flags or not. See further below. > Am 08.07.2015 um 19:32 schrieb Jacob Chappell : >=20 > Good afternoon, everyone. >=20 > There's been something bothering me since I started working with SPUD. = Now that I realize there's a mailing list, I figure why not ask here? >=20 > My question is, why is connect/ack part of the SPUD protocol? The = purpose of these commands does not seem clear from the draft. May I ask which draft you are referring here? The prototype draft really = only is a prototype which mean one example protocol that might or might = not address the needs. In the mean time there is also a requirement = draft as well as a use case draft that are basically independent of the = finally protocol design. The both also suggest to have a start flag as = well as an ACK and maybe give slightly more discussion on this (but = might also need more discussion). While it is less clear if we actually = need a start bit, we definitely would like to require SPUD to basically = send an ACK=E2=80=A6 see below. > For one, SPUD runs over UDP, so there's no guarantee the connect or = ack will even make it to the other side. Second, a previous message on = this mailing list from the archives indicates that you don't even have = to wait for an ack to send a data packet. This makes sense, because the = ack may be lost in transit (or maybe the original connect was lost in = transit). But if this is the case, what's the point in even having = connect/ack as part of the protocol? The idea is to assist network devices to set up state. E.g. a firewall = might forward the connect/start packet to the receiver behind the = firewall but is only willing to forward additional packets if the = receiver send at least one packet to confirm that this is a wanted = connection. That=E2=80=99s why we think an ACK is useful. The connect/start is rather to distinguish if there actually is a newly = starting flow or a middlebox only sees the middle of a flow because the = flow was e.g. rerouted. In this case the middlebox might not be willing = to sst up state but maybe sends an error message to the sender instead. = As I said this is all still under discussion. The question if you are going to resent a connect/start packet in SPUD = because it or the corresponding ACK packet was lost depends on the = higher layer protocol you are using over SPUD. SPUD (over UDP) is not = indented to be used as a stand-alone transport protocol but is rather a = shim layer between network and transport. So you could have e.g. TCP = over SPUD over UDP or UDP over SPUD over UDP. In case of TCP you = probably retransmit the SYN and therefore also the SPUD connect. In case = of UDP you might not retransmit and simply try to send data without = knowing if they will be received or not as your application might do it = over UDP today as well. >=20 > It seems like a possible alternative would be to just send data = packets spontaneously. The client can just be sure to generate a new = tube ID when sending to a new destination/port pair, and maintain that = state. Ultimately, you're going to have to use timers to expire state in = case of packet loss, so why not just use timers exclusively? As described above it=E2=80=99s more about network state then client = state. However, you probably will always need timers because you can = never be sure that certain information will be delivered. However, if = you can get more explicitly signals (and that=E2=80=99s why we also = would like to have a SPUD finish/stop packet) you can assist network = nodes as well as end host to e.g remove state quicker and maybe also = use SPUD to set timer values correctly (see the use case draft). Mirja >=20 > Jacob Chappell > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Mon Jul 13 08:11:07 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC20C1B2B57 for ; Mon, 13 Jul 2015 08:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 qO4rEZxuEuLT for ; Mon, 13 Jul 2015 08:11:03 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060E61B2B8B for ; Mon, 13 Jul 2015 08:11:02 -0700 (PDT) Received: by iggp10 with SMTP id p10so77813593igg.0 for ; Mon, 13 Jul 2015 08:11:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IESy5wEU5Lo4RiJAxIYjqFQi7dCH0adoxwecO+aAlM0=; b=JI75fStEDjYhXvyE8oQy3N0csRe2Mag1tUuOAULXJVICmxubu4TkSm2DZXbeKLnXg3 BQHRZT9wu3GYdMFDcPapOR9tz+C5NH7ZwU5Az3Tez5Og16Wqw89x6diL2uUfAi3yBxZI ouf1M0SVlUXznFksplDmzrvpp/w4rk/UqHeQQjdPJ6k+23Phx7SvAG0xFBWDxDlVE2ax Ws9leLbsTujSzyE/LEKYlL7bDk2Gqo5LwXqHmcUoGfOqSYkQ2U8dY8DoYV/pNsHKphm/ 2n9eLA0ANHLUke0oGIeJfXUuI0bDqwR9Nh0vcvRMCCvCso0yw3Sws212/daBz/+tV1jC WlPg== X-Gm-Message-State: ALoCoQmRpU+QKvlB4q/M4p8G9uAGQ05IF812xFGyWntheQ79k6Rm15+j8qiDMcOPmv3wXTvq9AZa MIME-Version: 1.0 X-Received: by 10.107.165.142 with SMTP id o136mr21138705ioe.120.1436800262468; Mon, 13 Jul 2015 08:11:02 -0700 (PDT) Received: by 10.107.142.86 with HTTP; Mon, 13 Jul 2015 08:11:02 -0700 (PDT) In-Reply-To: <559FFD93.8010307@isi.edu> References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> <559FFD93.8010307@isi.edu> Date: Mon, 13 Jul 2015 08:11:02 -0700 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , spud@ietf.org Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 15:11:06 -0000 On Fri, Jul 10, 2015 at 10:14 AM, Joe Touch wrote: > Hi, Brian, > > On 7/10/2015 3:44 AM, Brian Trammell wrote: >> >>> On 09 Jul 2015, at 19:36, Joe Touch wrote: > ... >>> IPv4 options can be jumped over in one step using the IHL field. >> >> yes, |set| = 1. > > Well, it's actually also because the offset is in the default header and > nowhere else. The number of options varies, as does the length of many > options. > >>> There's >>> no such field for IPv6 - routers have to walk the chain of headers one >>> by one. >> >> Right. It seems to me the way out of this (which is not just a >> problem for boxes that want to muck about in transport protocols, but >> ones thatwant to properly process hop by hop options) would be to >> define a new(small) set of IPv6 options headers that themselves would >> (1) not be combinable and (2) have a fixed length, allowing the >> next-header field to be _treated_ in constant time / with relatively >> few gates as the IHL field. > > There are several hurdles, not the least of which is that the length of > HBH options can change in transit. > > You don't really need a fixed length to solve this, or even a fixed set. > The options can even be mutable. > > What you really need is a "jump to transport" header that comes before > all the others, and that is maintained by any device that adds, deletes, > or changes the length of an option. > > The real problem there isn't doing that; its knowing whether you've > traversed a router that obeys those rules without dropping packets at > routers that don't. That would kill IPv6. > >> I haven't followed 6man, though I presume this approach or >> approaches like it have been discussed there ad nauseam. > > See above. > >> The fixed-lengthness of these new v6 options headers would make them >> problematic for freely extensible options, though one could use these >> to stick common fast path options in the "fixed" point of the header, >> and otherwise point to space elsewhere in the packet for things that >> can happen slowly. You eat the cost of following pointers and doing >> the more expensive deframing only if you need to in this case. > > The real issue, AFIACT, is detecting the behavior of legacy devices that > wouldn't know to follow these rules - without having them drop the > packet because it is an unknown option (i.e., you can set "drop if > unknown", but that would be bad; if you don't set that bit, then you > can''t detect when changes occur easily). > Hi Joe, Trying to bring up new protocols or features with legacy devices is a problem that appears in several different contexts. For example we see this when bringing up IPv6, using UDP on the Internet, running SCTP or other protocols. In the absence of negotiation with all the relevant devices or explicit knowledge that all the devices in the path support the new feature, the typical solution is to try using the feature and see what the effects are. If we see that packets are being dropped (lack of acknowledgments) or error messages are seen, then we know backoff to some "simpler" mode that is known to work. For instance, use TCP instead of UDP when we see UDP is not making forward progress for an application (Christian mentioned this in reference to Skype and gaming protocols). This works as long as devices are dropping packets because of things they don't understand. Presumably this method could be employed for hosts to send IP options on the Internet, that is try sending options and if there are problems stop sending them to that destination (by definition, options should never required!). Tom >>>>> I suspect you'll find that IP options are basically a non-starter except >>>>> for research purposes. >>>> >>>> For the story on the v4 side, do you know of anything newer than >>>> Fonseca et al "IP Options are Not and Option" (tech report version at >>>> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's >>>> ten years old -- but given where the engineering effort has gone during >>>> that decade, I doubt strongly much has changed here. >>> >>> Not much. Those old studies have been used in other WGs to drive >>> documents (IMO, unfortunately). >> >> I've been thinking about whether it would be worth the effort to do >> an updated IP options transparency study. > > The IETF has a persistent problem with extensibility. Vendors don't make > money supporting capabilities not in current use, but that ossifies the > protocols badly. > > Joe From nobody Mon Jul 13 10:20:16 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493A71B2C93 for ; Mon, 13 Jul 2015 10:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 1l8isrMjqQ65 for ; Mon, 13 Jul 2015 10:20:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A06C1B2C83 for ; Mon, 13 Jul 2015 10:19:56 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 13 Jul 2015 17:19:54 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0207.004; Mon, 13 Jul 2015 17:19:54 +0000 From: Christian Huitema To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Jacob Chappell Thread-Topic: [Spud] Connect and ACK Bits: Why? Thread-Index: AQHQuaQvpPywcQMRoEekZY+qlPvDhJ3ZVlMAgABUytA= Date: Mon, 13 Jul 2015 17:19:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tik.ee.ethz.ch; dkim=none (message not signed) header.d=none; x-originating-ip: [131.107.160.254] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 5:AtMYuPEn64VWf/oI8Ogu6WR83dLmjaf17tLVUlz1hsxNIHr9aFIK2xB3YT8oO3VbpD046N8iBHECro9lrvp5REQTIA7NMih/mRxC3oOV0rk/t+IZDSAwKPbICH+1Y2XV1E9pO9i26pemwQ08JxO5DQ==; 24:u5J4iAsJq5CQqr5KurLnN+Piri6pIiYCqyLfbahQsCyzRbF4gqik6dezh8K/w3q5bH3epysO7/WI4IRdrQJm29Ad/69NPfUrqgtPnFr0X1I=; 20:WuRJdrJuz4b4Up+h1w9OfIE+OHEVIHbHVQ6mqx4VGwYuBtPkQsIZnLvuHYR0ysRimP2cqW+Bd+WW6YTMQ09F7g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 0636271852 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(13464003)(106116001)(86362001)(77096005)(50986999)(87936001)(54356999)(5003600100002)(2656002)(76176999)(122556002)(19580405001)(99286002)(40100003)(19580395003)(77156002)(62966003)(74316001)(76576001)(92566002)(5001960100002)(2950100001)(2900100001)(66066001)(46102003)(33656002)(86612001)(102836002)(5002640100001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2015 17:19:54.4659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Connect and ACK Bits: Why? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 17:20:15 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3B1ZCBbbWFpbHRvOnNw dWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPiBPbiBNb25kYXksIEp1bHkgMTMs IDIwMTUgNToxMCBBTSwgTWlyamEgS8O8aGxld2luZCB3cm90ZToNCj4gLi4uDQo+IEFzIGRlc2Ny aWJlZCBhYm92ZSBpdOKAmXMgbW9yZSBhYm91dCBuZXR3b3JrIHN0YXRlIHRoZW4gY2xpZW50IHN0 YXRlLiBIb3dldmVyLA0KPiB5b3UgcHJvYmFibHkgd2lsbCBhbHdheXMgbmVlZCB0aW1lcnMgYmVj YXVzZSB5b3UgY2FuIG5ldmVyIGJlIHN1cmUgdGhhdCBjZXJ0YWluDQo+IGluZm9ybWF0aW9uIHdp bGwgYmUgZGVsaXZlcmVkLiBIb3dldmVyLCBpZiB5b3UgY2FuIGdldCBtb3JlIGV4cGxpY2l0bHkg c2lnbmFscw0KPiAoYW5kIHRoYXTigJlzIHdoeSB3ZSBhbHNvIHdvdWxkIGxpa2UgdG8gaGF2ZSBh IFNQVUQgZmluaXNoL3N0b3AgcGFja2V0KSB5b3UgY2FuDQo+IGFzc2lzdCBuZXR3b3JrIG5vZGVz IGFzIHdlbGwgYXMgZW5kIGhvc3QgdG8gZS5nIHJlbW92ZSBzdGF0ZSBxdWlja2VyICBhbmQgbWF5 YmUNCj4gYWxzbyB1c2UgU1BVRCB0byBzZXQgdGltZXIgdmFsdWVzIGNvcnJlY3RseSAoc2VlIHRo ZSB1c2UgY2FzZSBkcmFmdCkuDQoNCldlIGhhdmUgdG8gYWNjb3VudCBmb3IgcG9zc2libGUgcm91 dGUgY2hhbmdlcywgd2l0aG91dCB0aGUgZW5kcG9pbnQgYmVpbmcgYXdhcmUuIFRoYXQgbWVhbnMg dGhhdCB0aGUgZmlyc3QgcGFja2V0IHZpc2libGUgb24gdGhlIG5ldyBwYXRoIHdpbGwgbm90IGJl IHRoZSBmaXJzdCBwYWNrZXQgZW5kLXRvLWVuZC4gVGhpcyBpcyBhIHN0cm9uZyBhcmd1bWVudCBm b3IgTk9UIHJlbHlpbmcgb24gYW4gZXhwbGljaXQgIlN0YXJ0IiBmbGFnLiANCg0KVGhlbiB0aGVy ZSBpcyB0aGUgZmxpcCBzaWRlIHRoYXQgYW55IGV4cGxpY2l0IHNpZ25hbCBTVE9QIGNhbiBiZSBz cG9vZmVkLCB3aGljaCBlbmFibGVzIERPUyBhdHRhY2tzLiBPbiB0aGUgb3RoZXIgaGFuZCwgImFi c2VuY2Ugb2YgdHJhZmZpYyIgY2Fubm90IGJlIGVhc2lseSBzcG9vZmVkLg0KDQotLSBDaHJpc3Rp YW4gSHVpdGVtYQ0KDQoNCg== From nobody Mon Jul 13 10:25:43 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A670B1B2C9E for ; Mon, 13 Jul 2015 10:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 fWSTbX-Odp27 for ; Mon, 13 Jul 2015 10:25:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1AF1B2C9D for ; Mon, 13 Jul 2015 10:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1722; q=dns/txt; s=iport; t=1436808340; x=1438017940; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=a2qLEITmJGp3x188A27MYXsLTpRrnj7+NBIGhqGtVh0=; b=X6KGHVyrru8JC0wIOvMyoBcenRr7upUS3YOL+Kjl3ReQVM0tb66jkoPQ xZAam+uxu1KaJjjd5hO/SKMdt/QNcrB+12xlo1cxOevaJyUfln7QeaD1u h0eraFH3BcnbrGxdRKzv2q5+7KaWJ0oxwNLDxqHT2jbqMCTqgZfzAAXkF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BfAwBP86NV/5JdJa1bgxNUabtDCYFqCoV3AoE8OBQBAQEBAQEBgQqEIwEBAQQBAQEvATsLDAQLFQMJDBIHDwUTHxcTiC4NywkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItMhQYHCoMNgRQFjRyHFYwDAZhrJmODOB4xgksBAQE X-IronPort-AV: E=Sophos;i="5.15,464,1432598400"; d="scan'208";a="15004261" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 13 Jul 2015 17:25:40 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6DHPc3U018241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jul 2015 17:25:39 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6DHPcm8013146; Mon, 13 Jul 2015 10:25:38 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6DHPbLA013145; Mon, 13 Jul 2015 10:25:37 -0700 Date: Mon, 13 Jul 2015 10:25:37 -0700 From: Toerless Eckert To: Christian Huitema Message-ID: <20150713172537.GF23837@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Jacob Chappell , Mirja =?iso-8859-1?Q?K=FChlewind?= , "spud@ietf.org" Subject: Re: [Spud] Connect and ACK Bits: Why? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 17:25:41 -0000 Route changes: the middleboxes of interest are setup so that route-changes don't matter, eg: eithre single point of failure or chassis redundancy or the like. Teardown: Explicit teardown in TCP doesn't seem to be bad enough of a problem that TCP was changed, right ? And it is sen as valuable by middlebox vendors. On Mon, Jul 13, 2015 at 05:19:54PM +0000, Christian Huitema wrote: > > > > -----Original Message----- > > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of > > On Monday, July 13, 2015 5:10 AM, Mirja Kühlewind wrote: > > ... > > As described above it???s more about network state then client state. However, > > you probably will always need timers because you can never be sure that certain > > information will be delivered. However, if you can get more explicitly signals > > (and that???s why we also would like to have a SPUD finish/stop packet) you can > > assist network nodes as well as end host to e.g remove state quicker and maybe > > also use SPUD to set timer values correctly (see the use case draft). > > We have to account for possible route changes, without the endpoint being aware. That means that the first packet visible on the new path will not be the first packet end-to-end. This is a strong argument for NOT relying on an explicit "Start" flag. > > Then there is the flip side that any explicit signal STOP can be spoofed, which enables DOS attacks. On the other hand, "absence of traffic" cannot be easily spoofed. > > -- Christian Huitema > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Jul 13 10:45:43 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238951B2CB5 for ; Mon, 13 Jul 2015 10:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 et-ljMnQK6kY for ; Mon, 13 Jul 2015 10:45:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3980C1B2C8B for ; Mon, 13 Jul 2015 10:45:40 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6DHjKoH022741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Jul 2015 10:45:21 -0700 (PDT) Message-ID: <55A3F930.3040105@isi.edu> Date: Mon, 13 Jul 2015 10:45:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Christian Huitema , =?UTF-8?B?TWlyamEgS8O8aGxl?= =?UTF-8?B?d2luZA==?= , Jacob Chappell References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "spud@ietf.org" , touch@isi.edu Subject: Re: [Spud] Connect and ACK Bits: Why? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 17:45:41 -0000 On 7/13/2015 10:19 AM, Christian Huitema wrote: ... > We have to account for possible route changes, without the endpoint > being aware. That means that the first packet visible on the new path > will not be the first packet end-to-end. This is a strong argument for > NOT relying on an explicit "Start" flag. It doesn't matter whether that state change is signaled by an explicit START flag or not. If you have state that persists between messages, then you have to know when that state is established and which messages it affects, and the result is the same. Joe From nobody Mon Jul 13 10:50:04 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555A31B2CD0 for ; Mon, 13 Jul 2015 10:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 kIN5AZw__sZ0 for ; Mon, 13 Jul 2015 10:50:00 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7501A1B2CC3 for ; Mon, 13 Jul 2015 10:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1812; q=dns/txt; s=iport; t=1436809800; x=1438019400; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ppQQa5A2ce3eJdGqHPrZxHqddfaMIWJi3fDLV6Zz4n0=; b=B6grLV9dKMjrNqareuG7u+quvVsgLGMziUlANQI3nnnwXHmNnFXW3BDH 6253NBpOsetYyivXrzzJlrQjtM9qFtqq+XMsRn9/LGoGj2zPlB9zeTOjR CfToe0W7psD9AN1C7SnBB/26SmawGPTnicfV3C0TzolrLzc+rVe+hDhQ+ k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOBACj+aNV/xbLJq1bhFCDI7gph2sCgXYSAQEBAQEBAYEKhCMBAQEEI1UBDAQLFQMJDAoIAwICCQMCAQIBNBEGAQwBBQIBAYgqtSOWDgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLTIUGBwqCXoFDAQSUMYItgVSIA4hEkCcmY4MaPDGCSwEBAQ X-IronPort-AV: E=Sophos;i="5.15,464,1432598400"; d="asc'?scan'208";a="564797890" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 13 Jul 2015 17:49:58 +0000 Received: from [10.61.88.14] (ams3-vpn-dhcp6159.cisco.com [10.61.88.14]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6DHnwHn004595; Mon, 13 Jul 2015 17:49:58 GMT Message-ID: <55A3FA44.9010402@cisco.com> Date: Mon, 13 Jul 2015 19:49:56 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Christian Huitema , =?UTF-8?B?TWlyamEgS8O8aGxl?= =?UTF-8?B?d2luZA==?= , Jacob Chappell References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kgNttGWeCh3iD3k3tMEMfSuc9eKSUJus0" Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Connect and ACK Bits: Why? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 17:50:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kgNttGWeCh3iD3k3tMEMfSuc9eKSUJus0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/13/15 7:19 PM, Christian Huitema wrote: > >> -----Original Message----- >> From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of=20 >> On Monday, July 13, 2015 5:10 AM, Mirja K=C3=BChlewind wrote: >> ... >> As described above it=E2=80=99s more about network state then client s= tate. However, >> you probably will always need timers because you can never be sure tha= t certain >> information will be delivered. However, if you can get more explicitly= signals >> (and that=E2=80=99s why we also would like to have a SPUD finish/stop = packet) you can >> assist network nodes as well as end host to e.g remove state quicker = and maybe >> also use SPUD to set timer values correctly (see the use case draft). > We have to account for possible route changes, without the endpoint bei= ng aware.=20 Unless p2a informs the a of the change. Eliot --kgNttGWeCh3iD3k3tMEMfSuc9eKSUJus0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVo/pFAAoJEIe2a0bZ0noz3KgIAKnSUB1p0CXjgfcpBuopW2U7 j9m8p1E3VgPPWe2XEFea0JTiph/F7is3E1qnqVSMj7L0PNSiBL3KEA4IicM8HRv/ RHXG0E6IpZNdAQLOAPd5Zr/caT0mzvzD6SeTgzLD5pdzciqPKomamSXnsLaVTfk5 aoKllKB7r9+klB9KEUO2A1P7aghWGQ9TmiMnmPG5BDYLIt7cMAk/kZzk52UzG58n JGS66UElCZ9Ys1JzfSPEhK9bOWtNrS+pUsBfZKQyEAXc0o0LuCn2CZlN3RXZ7Nfe 1FUKsdjcWbcYeCI5rSoaMGkniIewGWiFrFPgp4TWumvWeslpW3mAgvhUpKF7Ktk= =52MA -----END PGP SIGNATURE----- --kgNttGWeCh3iD3k3tMEMfSuc9eKSUJus0-- From nobody Mon Jul 13 10:52:13 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A4F1B2CD9 for ; Mon, 13 Jul 2015 10:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 AQZrrIpQ-vDU for ; Mon, 13 Jul 2015 10:52:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5832B1B2CD2 for ; Mon, 13 Jul 2015 10:52:11 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6DHpXhU024133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Jul 2015 10:51:33 -0700 (PDT) Message-ID: <55A3FAA4.7090208@isi.edu> Date: Mon, 13 Jul 2015 10:51:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Toerless Eckert , Christian Huitema References: <20150713172537.GF23837@cisco.com> In-Reply-To: <20150713172537.GF23837@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Jacob Chappell , "spud@ietf.org" , =?windows-1252?Q?Mirja_K=FChlewind?= , touch@isi.edu Subject: Re: [Spud] Connect and ACK Bits: Why? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 17:52:12 -0000 On 7/13/2015 10:25 AM, Toerless Eckert wrote: ... > Teardown: > > Explicit teardown in TCP doesn't seem to be bad enough of a > problem that TCP was changed, right ? See RFCs 4953 and 5961. This is also one reason why BGP sessions use either graceful restart (4724 - to reduce the impact of the lost connection) or are directly protected against spoofing by TCP MD5 (2385) or TCP-AO (5925). I.e., TCP and TCP uses were changed to address this issue. Joe From nobody Mon Jul 13 11:07:21 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB7C1B2CF5 for ; Mon, 13 Jul 2015 11:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 216IJMZOMsPV for ; Mon, 13 Jul 2015 11:07:18 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274D51B2CF6 for ; Mon, 13 Jul 2015 11:07:17 -0700 (PDT) Received: by qkdl129 with SMTP id l129so17291185qkd.0 for ; Mon, 13 Jul 2015 11:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xi/9vOieuVMRYRhW589YQjr7YTt9wf5mrgtJlAQ9FLs=; b=NQtNobv/MXFBK5LIr0up1vJu4gxNspCeobJPW8pz+TM3s2zssQBmtA2OU+/r1OsB3g eCfT58t4MbFLpkASYI0MTQDQ2eItRloYh4oWoYqZLFdxmjhB0zAyG6Dz4GWxbAK/DVln ZLJ/dLv8xu/zaD+aE5+jm1UKOpjjicq+OzdGbxXq+7tyPjn4GKT+FJvIR05QTaVuowuP 9/Jgnpg/sSryXEJARTRDzNWDh1nrPAinry8KqykFyVxBrzU50G7n1P/bkdV4ie2HXt45 0Jz1R8lpqITtSAhTXaiU2kNLcvJXRMHWAI/kZbJIWu9fzehXMyDjfEyXbcw/NUxjDGFt RUMw== MIME-Version: 1.0 X-Received: by 10.140.109.199 with SMTP id l65mr54522965qgf.91.1436810836420; Mon, 13 Jul 2015 11:07:16 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.140.18.232 with HTTP; Mon, 13 Jul 2015 11:07:16 -0700 (PDT) In-Reply-To: <20150713172537.GF23837@cisco.com> References: <20150713172537.GF23837@cisco.com> Date: Mon, 13 Jul 2015 14:07:16 -0400 X-Google-Sender-Auth: I6mj2qDOagxXy0xF81gyW2nqMF0 Message-ID: From: Phillip Hallam-Baker To: Toerless Eckert Content-Type: multipart/alternative; boundary=001a113a37f483ac57051ac59721 Archived-At: Cc: Jacob Chappell , Christian Huitema , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "spud@ietf.org" Subject: Re: [Spud] Connect and ACK Bits: Why? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 18:07:20 -0000 --001a113a37f483ac57051ac59721 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 13, 2015 at 1:25 PM, Toerless Eckert wrote: > Route changes: > > the middleboxes of interest are setup so that route-changes don't > matter, eg: eithre single point of failure or chassis redundancy or > the like. > > Teardown: > > Explicit teardown in TCP doesn't seem to be bad enough of a > problem that TCP was changed, right ? And it is sen as valuable by > middlebox vendors. > TCP was designed in an era when malice was rarely considered as part of network design and when it was considered it was (correctly) regarded as secondary to getting the system working at all. So the lack of authenticated teardown is certainly a concern, but not that difficult to address using some lightweight symmetric crypto: Sender, on session startup: Generate nonce n1, send 128 bits of H(n1) with connect message. Sender on session shutdown: Send nonce n1 with teardown message. Middleboxen: * On receipt of packet without connect, optionally buffer till connect is visible * On receipt of teardown, keep connection open for MAX_TIME seconds. Once a sender has sent a teardown message it is contracting that it is not going to source any further packets without re-establishing the connection. So while a middleboxen may see packets out of order, if it sees packets after the max network time to live has expired, it is an error and they can be discarded. --001a113a37f483ac57051ac59721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 13, 2015 at 1:25 PM, Toerless Eckert <= eckert@cisco.com&= gt; wrote:
Route changes:

the middleboxes of interest are setup so that route-changes don't
matter, eg: eithre single point of failure or chassis redundancy or
the like.

Teardown:

Explicit teardown in TCP doesn't seem to be bad enough of a
problem that TCP was changed, right ? And it is sen as valuable by
middlebox vendors.

TCP was designed in = an era when malice was rarely considered as part of network design and when= it was considered it was (correctly) regarded as secondary to getting the = system working at all.

So the lack of authenticate= d teardown is certainly a concern, but not that difficult to address using = some lightweight symmetric crypto:


= Sender, on session startup:
=C2=A0 =C2=A0Generate nonce n1, send = 128 bits of H(n1) with connect message.

Sender= on session shutdown:
=C2=A0 =C2=A0Send nonce n1 with teardown me= ssage.


Middleboxen:

<= /div>
* On receipt of packet without connect, optionally buffer till co= nnect is visible

* On receipt of teardown, keep co= nnection open for MAX_TIME seconds.


Once a sender has sent a teardown message it is contracting that it is not= going to source any further packets without re-establishing the connection= . So while a middleboxen may see packets out of order, if it sees packets a= fter the max network time to live has expired, it is an error and they can = be discarded.


--001a113a37f483ac57051ac59721-- From nobody Mon Jul 13 11:12:04 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9060B1B2CFE for ; Mon, 13 Jul 2015 11:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 MAkTc57LtAzU for ; Mon, 13 Jul 2015 11:12:00 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2401B2CF8 for ; Mon, 13 Jul 2015 11:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=809; q=dns/txt; s=iport; t=1436811120; x=1438020720; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=QvlWqaDh9b8h9gWyofQ9heHyF7wAHX0YJLQohMQWEtA=; b=aqaSCfwBdIJi0gpbkHxgrLkDrOj15zmNF5e7ByurwQsJBRlbF/AEkRtd ZYyCN4WqRcIVAiFRZIFpATai2hb5804u+IYZJwwQOj325i9/+RWV63q6m sXth34xLBmyRKPwTxLzU6CBiDAZyyi50dzq9gHQFI7o8jKdDa9rK2PJTT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaAwCE/qNV/51dJa1bDoMFvQAJhReCVAKBPDgUAQEBAQEBAYEKhCQBAQQ6PxALGAklDwVJiEHLOwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLTIUGB4QrAQSNHIcVjAMBmGsmY4EqG4EVXh6CfAEBAQ X-IronPort-AV: E=Sophos;i="5.15,464,1432598400"; d="scan'208";a="168226386" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 13 Jul 2015 18:12:00 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6DIBx9j001246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jul 2015 18:11:59 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6DIBmgg016198; Mon, 13 Jul 2015 11:11:48 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6DIBmw1016196; Mon, 13 Jul 2015 11:11:48 -0700 Date: Mon, 13 Jul 2015 11:11:48 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20150713181148.GH23837@cisco.com> References: <20150713172537.GF23837@cisco.com> <55A3FAA4.7090208@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A3FAA4.7090208@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Jacob Chappell , Christian Huitema , Mirja =?iso-8859-1?Q?K=FChlewind?= , "spud@ietf.org" Subject: Re: [Spud] Connect and ACK Bits: Why? X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 18:12:01 -0000 On Mon, Jul 13, 2015 at 10:51:32AM -0700, Joe Touch wrote: > > > On 7/13/2015 10:25 AM, Toerless Eckert wrote: > ... > > Teardown: > > > > Explicit teardown in TCP doesn't seem to be bad enough of a > > problem that TCP was changed, right ? > > See RFCs 4953 and 5961. This is also one reason why BGP sessions use > either graceful restart (4724 - to reduce the impact of the lost > connection) or are directly protected against spoofing by TCP MD5 (2385) > or TCP-AO (5925). > > I.e., TCP and TCP uses were changed to address this issue. Right, my choice of words wasn't ideal. I meant to say that we should ismply consider applying fundamentally the same mechanisms used with TCP, just simplified wherever possible. MD5/A0 do seem to make a lot of sense. Cheers Toerless From nobody Mon Jul 20 04:31:09 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12E41A1F70 for ; Mon, 20 Jul 2015 04:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tCDGKQYSRr7P for ; Mon, 20 Jul 2015 04:31:05 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC811A1A90 for ; Mon, 20 Jul 2015 04:31:04 -0700 (PDT) Received: from dhcp-9b59.meeting.ietf.org (dhcp-9b59.meeting.ietf.org [31.133.155.89]) by trammell.ch (Postfix) with ESMTPSA id D7EA21A0023; Mon, 20 Jul 2015 13:30:33 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B943CDC4-8D62-46B4-AFE7-0D66BBAD8B46"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: Date: Mon, 20 Jul 2015 13:30:32 +0200 Message-Id: References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> To: Tom Herbert X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Joe Touch , =?utf-8?Q?Mirja_K=C3=BChlewind?= , spud@ietf.org Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:31:07 -0000 --Apple-Mail=_B943CDC4-8D62-46B4-AFE7-0D66BBAD8B46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 10 Jul 2015, at 18:19, Tom Herbert wrote: >=20 >> Coming back to the layering question: >>=20 >> It does seem to me that what we're (the we that wrote the two = documents starting this thread) trying to do is explicitly reinforce the = boundary between the network layer and the transport layer, where this = is defined as "things the path needs to see versus things only endpoints = need to see". Asking nicely (i.e., publishing RFCs) did not work in this = case: the transport ports are de facto part of the network layer now, = and short of blowing the Internet up and starting over I can't see a way = to get them back. So now we are left with enforcing the boundary = cryptographically, leaving some space in the "new network layer" (in = this case, IP + UDP (for ports) + SPUD) for those things now commonly = done within the network. >>=20 > This "new network layer" breaks down at fragmentation. One can argue (indeed, I do) that in-network fragmentation is = essentially a deprecated feature of the network layer. The current = version of IP doesn't support it, and AFAICT avoiding fragmentation is = current practice in modern transport protocol design. > Only the first > fragment carries port numbers and the embedded network layer > information in the payload. Other fragments will carry neither, but > still can carry IP options, DSCP, TTL, ECN marking, flow labels in > IPv6. >=20 > An alternate possibility would be to embed IP options within UDP. So a > packet might look like IP-UDP-IP options-payload. This is an intriguing possibility, if there is an advantage to reusing = IP options handling code. > This allows us to > use native options (say in our data center where we can control > things), but maybe to use embedded IP options in UDP on paths in the > Internet where we see options are being dropped. SFC-in-UDP > (https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transport-00) > proposes a similar model, It looks a lot like innerspace = (http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01), too. > although I don't believe they allow > middleboxes to modify or to be regularly looking the headers. What does "allow" mean in this context? >> If we can do this in the _current_ network layer (IPv6 (with options) = with some alternate way to handle NAT + DTLS, or we find a portal to an = alternate universe where end-to-end IPsec is widely deployable and = manageable), then great, let's do that. I'm pessimistic enough to = believe that that hasn't been a realistic prospect at any time during = this century, though. >>=20 > I don't understand what the issue is with crypto here. We want the transport protocol headers to be encrypted, in order to = enforce the network/transport layer boundary. (That's what I would mean = by "allow". :) ) > SSL/TLS are widely deployed with use of NAT, ...which allows mucking about in the transport layer, and using *all* = transport layer metadata to track/fingerprint/etc. > and we are certainly using encrypted > tunnels over the Internet. My understanding of most deployed encrypted tunnels which (also) use = tunnel-mode IPsec is that it has a fallback to a UDP encap to handle = NAT, but I could be mistaken there. Cheers, Brian --Apple-Mail=_B943CDC4-8D62-46B4-AFE7-0D66BBAD8B46 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVrNvYAAoJENt3nsOmbNJcmIsH/0zDZfrKGfk1Hl9xH/AF/kve x7hlhx/JTzqsHNyxf854sjYue9koBc8dbDSMCNABQVoEzBy4jKWHM87aye3/0jYu zW3QBMCdF7mTlj8DZtToOd05igRGeUUeyXnrwDeFeyCd3d9zwZwyLfZ5Vz134AqO +ZUbPdPUx8wKMn6+CPv6rpHxgfzReWruJLG5rN7om11ECwGsIYowfvixLTI2/BOu OyVIEQ54wQhywe6qWE8JdWcn20mDoUiIBqUkMAP1CsMuIvSszyBUc7ISY0PN4TlW PXEiWWB8fghx8ofGfhUrKcfmahG1KT6jFASx1kvYxje+8Rj8rTW5KfrPQMb8tA4= =O4Sk -----END PGP SIGNATURE----- --Apple-Mail=_B943CDC4-8D62-46B4-AFE7-0D66BBAD8B46-- From nobody Mon Jul 20 09:23:13 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A541A90AC for ; Mon, 20 Jul 2015 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ScG5xGSXciHl for ; Mon, 20 Jul 2015 09:23:10 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B71C1ACD7E for ; Mon, 20 Jul 2015 09:23:10 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t6KGMdS7021111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 09:22:39 -0700 (PDT) Message-ID: <55AD204E.5080908@isi.edu> Date: Mon, 20 Jul 2015 09:22:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian Trammell , Tom Herbert References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud@ietf.org, =?windows-1252?Q?Mirja_K=FChlewind?= , touch@isi.edu Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 16:23:12 -0000 On 7/20/2015 4:30 AM, Brian Trammell wrote: > >> On 10 Jul 2015, at 18:19, Tom Herbert wrote: >> >>> Coming back to the layering question: >>> >>> It does seem to me that what we're (the we that wrote the two >>> documents starting this thread) trying to do is explicitly >>> reinforce the boundary between the network layer and the >>> transport layer, where this is defined as "things the path needs >>> to see versus things only endpoints need to see". Asking nicely >>> (i.e., publishing RFCs) did not work in this case: the transport >>> ports are de facto part of the network layer now, and short of >>> blowing the Internet up and starting over I can't see a way to >>> get them back. So now we are left with enforcing the boundary >>> cryptographically, leaving some space in the "new network layer" >>> (in this case, IP + UDP (for ports) + SPUD) for those things now >>> commonly done within the network. >>> >> This "new network layer" breaks down at fragmentation. > > One can argue (indeed, I do) that in-network fragmentation is > essentially a deprecated feature of the network layer. If you think that network devices need to see transport ports, then it doesn't matter where the fragmentation occurs. Source fragmentation - which is still very much a part of the network layer, and needs to be* - causes just as much of a problem. > The current > version of IP doesn't support it, and AFAICT avoiding fragmentation is > current practice in modern transport protocol design. In-network, yes. Source, no. >> Only the first >> fragment carries port numbers and the embedded network layer >> information in the payload. Other fragments will carry neither, but >> still can carry IP options, DSCP, TTL, ECN marking, flow labels in >> IPv6. >> >> An alternate possibility would be to embed IP options within UDP. So a >> packet might look like IP-UDP-IP options-payload. > > This is an intriguing possibility, if there is an advantage to reusing IP options handling code. > >> This allows us to >> use native options (say in our data center where we can control >> things), but maybe to use embedded IP options in UDP on paths in the >> Internet where we see options are being dropped. SFC-in-UDP >> (https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transport-00) >> proposes a similar model, > > It looks a lot like innerspace (http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01), too. Yes and no. UDP has a length field, which means it's actually possible to use space in an IP payload that isn't part of the UDP frame without compliant UDP implementations breaking. That's the real issue with innerspace; it's inside the TCP payload. Joe From nobody Mon Jul 20 09:46:30 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52D41ACE0E for ; Mon, 20 Jul 2015 09:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9y0nCu91NTin for ; Mon, 20 Jul 2015 09:46:27 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66CF1ACE0D for ; Mon, 20 Jul 2015 09:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=704; q=dns/txt; s=iport; t=1437410788; x=1438620388; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=wSG8Zcfv0/xgEgGSs/oG1pyzU6AXk3YPFo1a4VUphcQ=; b=N0PwSCaGZb9mWd48a8bHtIi4PJOoFUcsiMSd7m88zOdoHJ0lfYfO4m0y vypK/rCEAA3pAxVnw9Cjv5aFjJjOeyoKFD4HnaZmJqpD86wf6bgme1ssH /73SzguymyL2Az6H0eUPG6PpUQyZHUX2dq9wd63KiJ++CXQrBK6iz4pJB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaAwBjJa1V/4MNJK1cDoMFvSoJh2wCgS04FAEBAQEBAQGBCoQkAQEEOj8QCxgJJQ8FSYhByBoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0yFBgeEKwEEjSmHKYwgAZkHJoM+Xh6CfAEBAQ X-IronPort-AV: E=Sophos;i="5.15,508,1432598400"; d="scan'208";a="170429612" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 20 Jul 2015 16:46:27 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6KGkQ95030552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2015 16:46:26 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6KGkKHG028737; Mon, 20 Jul 2015 09:46:25 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6KGk9Zt028732; Mon, 20 Jul 2015 09:46:09 -0700 Date: Mon, 20 Jul 2015 09:46:09 -0700 From: Toerless Eckert To: Joe Touch Message-ID: <20150720164609.GP1667@cisco.com> References: <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> <55AD204E.5080908@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AD204E.5080908@isi.edu> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Brian Trammell , spud@ietf.org, Mirja =?iso-8859-1?Q?K=FChlewind?= , Tom Herbert Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 16:46:29 -0000 On Mon, Jul 20, 2015 at 09:22:38AM -0700, Joe Touch wrote: > Yes and no. UDP has a length field, which means it's actually possible > to use space in an IP payload that isn't part of the UDP frame without > compliant UDP implementations breaking. It's a nice possible trick, but it would break the ability to build an app purely on top of unmodified UDP APIs. Those APIs do not provide you with the ability to create a UDP packet with UDP payload + "metadata" payload after the UDP length. So you'd need to get support for this API extensions again in all OSs and programming language SDKs. 8 years minimum. Worse yet, there are likely a good set of firewalls that would drop these packets. From nobody Mon Jul 20 09:53:31 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F34D1ACEAF for ; Mon, 20 Jul 2015 09:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 Vc2OrZUa69XK for ; Mon, 20 Jul 2015 09:53:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C428A1ACECF for ; Mon, 20 Jul 2015 09:53:27 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6KGr7cU007957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 09:53:07 -0700 (PDT) Message-ID: <55AD2772.7040809@isi.edu> Date: Mon, 20 Jul 2015 09:53:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Toerless Eckert References: <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> <55AD204E.5080908@isi.edu> <20150720164609.GP1667@cisco.com> In-Reply-To: <20150720164609.GP1667@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , spud@ietf.org, =?windows-1252?Q?Mirja_K=FChlewind?= , Tom Herbert , touch@isi.edu Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 16:53:29 -0000 On 7/20/2015 9:46 AM, Toerless Eckert wrote: > On Mon, Jul 20, 2015 at 09:22:38AM -0700, Joe Touch wrote: >> Yes and no. UDP has a length field, which means it's actually possible >> to use space in an IP payload that isn't part of the UDP frame without >> compliant UDP implementations breaking. > > It's a nice possible trick, but it would break the ability to build an > app purely on top of unmodified UDP APIs. An unmodified UDP API, by definition, would not be able to do anything except use vanilla UDP. > Those APIs do not provide you > with the ability to create a UDP packet with UDP payload + "metadata" > payload after the UDP length. So you'd need to get support for this API extensions > again in all OSs and programming language SDKs. 8 years minimum. It didn't take that long for MPTCP. > Worse yet, > there are likely a good set of firewalls that would drop these packets. Firewalls typically either look at UDP ports or part of the UDP content. It might complicate firewalls that try to parse the entire IP payload as if it were UDP, i.e., a device that didn't process the UDP length field correctly. But that's a bug - we really can't build protocols to operate over devices that do such things. Joe From nobody Mon Jul 20 16:20:09 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C4A1AC432 for ; Mon, 20 Jul 2015 16:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 I3WJnhSxX9R7 for ; Mon, 20 Jul 2015 16:20:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A36B1AC42A for ; Mon, 20 Jul 2015 16:20:06 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t6KNJPEr025786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 16:19:27 -0700 (PDT) Message-ID: <55AD81FC.3060405@isi.edu> Date: Mon, 20 Jul 2015 16:19:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Toerless Eckert References: <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> <559FFD93.8010307@isi.edu> <20150710204514.GA23837@cisco.com> <55A03CCC.1060904@isi.edu> In-Reply-To: <55A03CCC.1060904@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , spud@ietf.org, =?windows-1252?Q?Mirja_K=FChlewind?= , Tom Herbert , touch@isi.edu Subject: [Spud] a UDP option area X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 23:20:08 -0000 Hi, all, I just posted a draft on "Transport Options for UDP" It's tagged as TSVWG for obvious reasons. I encourage those of you interested in this to discuss it on the TSVWG mailing list. (although I appreciate it may be useful to SPUD, it's not SPUD-specific). Joe ----------------------------------------- A new version of I-D, draft-touch-tsvwg-udp-options-00.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 00 Title: Transport Options for UDP Document date: 2015-07-20 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-00.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-00 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP to provide a location, syntax, and semantics for transport layer options. 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 Tue Jul 21 06:02:04 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E721A9048 for ; Tue, 21 Jul 2015 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 pV00tFddd723 for ; Tue, 21 Jul 2015 06:01:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEC71A1A80 for ; Tue, 21 Jul 2015 06:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=239; q=dns/txt; s=iport; t=1437483716; x=1438693316; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=yooU15unmD80GxO5wNqPDMJc0QTAZp9bmq/jzBgnEm4=; b=bRI8Kk4Ilx0ac/dpH62plX9C3nsqoMU6gfbflwBiIM+X1lYH/4p5T8k2 4zuY6b4aA5ntCfIp/oJAFo0lcfzuPqqrDTh9fRonrgBUG24NR9u3cN2hG Ao5C3vWj1VYbBo+hBGiT49BClhJ9HmmTGiwaqu8bk1czm7JUZfLJkdlN2 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BJAwDfQa5V/5pdJa1cgxNUarwNCYF5hX0CgTs4FAEBAQEBAQGBCoQkAQEEOj8QCxgJJQ8FiQoNyjoBAQEBAQEBAQEBAQEBAQEBAQEBGYtMhQYHFoMBgRQFjSmHKowpAYFDhByTLyZjgVuBXh6CfAEBAQ X-IronPort-AV: E=Sophos;i="5.15,516,1432598400"; d="scan'208";a="13589274" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 21 Jul 2015 13:01:26 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6LD1QxP003780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2015 13:01:26 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6LD1Psg007327; Tue, 21 Jul 2015 06:01:25 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6LD1Pqv007326; Tue, 21 Jul 2015 06:01:25 -0700 Date: Tue, 21 Jul 2015 06:01:25 -0700 From: Toerless Eckert To: spud@ietf.org Message-ID: <20150721130125.GA6559@cisco.com> References: <55AE3F57.7070702@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AE3F57.7070702@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Brian E Carpenter Subject: Re: [Spud] Snowden to the IETF: Please make an internet for users, not the spies ??? The Register X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 13:02:02 -0000 We've got our instructions from Moscow now... On Wed, Jul 22, 2015 at 12:47:19AM +1200, Brian E Carpenter wrote: > http://www.theregister.co.uk/2015/07/20/edward_snowden_to_the_ietf_please_design_an_internet_for_the_user_not_the_spy/ From nobody Tue Jul 21 09:39:49 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865201B3003 for ; Tue, 21 Jul 2015 09:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 7JF7POJPLhyI for ; Tue, 21 Jul 2015 09:39:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0051B2FF4 for ; Tue, 21 Jul 2015 09:39:45 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6LGd2Lw008981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Jul 2015 09:39:03 -0700 (PDT) Message-ID: <55AE75A6.9020303@isi.edu> Date: Tue, 21 Jul 2015 09:39:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Toerless Eckert , spud@ietf.org References: <55AE3F57.7070702@gmail.com> <20150721130125.GA6559@cisco.com> In-Reply-To: <20150721130125.GA6559@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian E Carpenter , touch@isi.edu Subject: Re: [Spud] Snowden to the IETF: Please make an internet for users, not the spies ??? The Register X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:39:47 -0000 Like JACK-FM, I don't take requests ;-) http://www.jack.fm/ The last time I checked, everyone is welcome to participate in the IETF as individuals. Joe On 7/21/2015 6:01 AM, Toerless Eckert wrote: > We've got our instructions from Moscow now... > > On Wed, Jul 22, 2015 at 12:47:19AM +1200, Brian E Carpenter wrote: >> http://www.theregister.co.uk/2015/07/20/edward_snowden_to_the_ietf_please_design_an_internet_for_the_user_not_the_spy/ > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > From nobody Tue Jul 21 15:12:40 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA931B2B20; Tue, 21 Jul 2015 15:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 QFYiHDiuc2sO; Tue, 21 Jul 2015 15:12:37 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AB51B29C9; Tue, 21 Jul 2015 15:12:36 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6LMC7Ri022904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Jul 2015 15:12:09 -0700 (PDT) References: <20150721220446.17166.92955.idtracker@ietfa.amsl.com> To: "tsvwg@ietf.org" From: Joe Touch X-Forwarded-Message-Id: <20150721220446.17166.92955.idtracker@ietfa.amsl.com> Message-ID: <55AEC3B6.3080601@isi.edu> Date: Tue, 21 Jul 2015 15:12:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150721220446.17166.92955.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t6LMC7Ri022904 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "spud@ietf.org" , touch@isi.edu Subject: [Spud] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 22:12:39 -0000 FYI. Minor changes for clarification. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tsvwg-udp-options-01.txt Date: Tue, 21 Jul 2015 15:04:46 -0700 From: internet-drafts@ietf.org To: Dr. Joseph D. Touch , Joe Touch A new version of I-D, draft-touch-tsvwg-udp-options-01.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 01 Title: Transport Options for UDP Document date: 2015-07-21 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-01.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-01 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP to provide a location, syntax, and semantics for transport layer options. 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 Tue Jul 21 21:23:39 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781C91A00FD; Tue, 21 Jul 2015 21:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jONwhHELwYXF; Tue, 21 Jul 2015 21:23:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC481A00F5; Tue, 21 Jul 2015 21:23:36 -0700 (PDT) Received: from DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 04:23:18 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 04:23:17 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0219.018; Wed, 22 Jul 2015 04:23:17 +0000 From: Christian Huitema To: Joe Touch , "tsvwg@ietf.org" Thread-Topic: [Spud] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-01.txt Thread-Index: AQHQxAJds9NWRWAYWk6X7OLFm6y06Z3m5DVw Date: Wed, 22 Jul 2015 04:23:17 +0000 Message-ID: References: <20150721220446.17166.92955.idtracker@ietfa.amsl.com> <55AEC3B6.3080601@isi.edu> In-Reply-To: <55AEC3B6.3080601@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: isi.edu; dkim=none (message not signed) header.d=none; x-originating-ip: [130.129.7.156] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:zX2ZhHJrxWwtATPafq+yyrHpIwE1HXIs9Ql2qcMG943NHHGkh22CX5FBhjkBnISR/j+c5zeSgU6K99TqZDjL1HC12gUoaHNAsx/CTwcE7pKHRtEc4gYQC9siAD/RyEgXbhnxGAwTHULwz1Wjm60Z9A==; 24:9qXAQbqPMoPkyy/T8Bp/diwBY0vbgcAh30ms5co5Su99n1QHBA3Evgz+dk/VkLEbRdf6g37Tt1N67OEb2e3D7jaSvlxlSuJMZXD7n/oiSVo=; 20:F7qesThvb0xD9Gv1yvhXHbVBqObXD+yu2Zy/UrJLpCakdPsKJd3nYRi8KRdkU1BTRvMzWGIRP+WXnbUkiThyIw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; dm2pr0301mb0653: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0645BEB7AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2473001)(13464003)(377424004)(69234005)(377454003)(77096005)(86612001)(19580395003)(74316001)(2656002)(86362001)(50986999)(2171001)(87936001)(19580405001)(66066001)(54356999)(102836002)(33656002)(76176999)(99286002)(2950100001)(76576001)(46102003)(5003600100002)(2501003)(5001960100002)(15975445007)(62966003)(5001770100001)(2900100001)(106116001)(230783001)(92566002)(122556002)(40100003)(189998001)(10090500001)(77156002)(5001920100001)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2015 04:23:17.5522 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0655; 2:/UGKuIjUknk4ED9f19k3iT7uxz2wf3OrblTSqYzMWn4dsl/zP80gXWWiPNWkAzh6; 3:hm+zBS3R+VXU8gXz8jLMiZGFwIMXbEKILWKEvtfRG4g4xcnrxjUR5Pp8M98DS0M567oIyrIyIs5Bzp4CIfipJf6jN9SJaWFwXfPSOShv9nAofZmTgEYknMSE9IkQWVIF0bNQ733RPLkSVo+9wzzR8w==; 25:zgEJUiz/66kKTk6otj9tXgmm3kt9GB6XK2R7LKkPoajlR1GxShz9EVh/dyrWlM96qcmARivr3VmnE2nZbhAWFUOwqPcAZzV1iOc7nWavYRPcvTKJCW9RPgJoMVmaYlNYZGB5w8F/aPBzfNycvdDTYEbvWKu8yzr5TlQeinKJyN4lrtzSTS0dVpckHIsKPx7Fk8mBgQfr9XQT3R1Y7uf5WMNdXEQRsN9jFVFU4O46t2TxR+QkLktSVHbGCneLgGKs X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0655; 20:H7yNKN3mQm7IQGooHkP9Fj8jn3DYzY0miVJ0rRCXRJv+TmjOwf90fIpBFljnal1NTtxJqggMVLWZGKN57H3Kx0w7iVPm/z1ac/OdVoTai2tytvaGnEUlPa5uh/JW5Z+x9vjcIxbvTdBowVW/xYXzCoxFUPzcrGP9CvAr9yAY8qKaugkbilvfux+qDWonW4hXhbOGeK1suVOKPavk4o4gEypNe3TGUgRzkFD2I76Bj1nLbrWP2R6t7UXHeM2qa9wZqo+ux6AA5nk2zC/UQq1jA0RPtiwyeJf+oyHHIaFPaWfCPcyLgwWjYZpWgOWm7Pxu+6W9GhYfRy7ak2qBHYiNQUI8qK+UOqz3Zy2CxwTZgtehOk6xfJ530hhSUlSOkX78p/6nsOhV4dhCNBOqLb0BpTfZuuckXm7y9d3QVHAJ3aDW564yTNareyVPq09fnxJr68mPjBoNjGrB3Myd2r6mOSocARuYZcJmZjklV21OrsOFgv7TjkzWXSxIFNfgVFq5; 23:WNXgL5Vd9MyRkGf924rg5Ic8otjm4ZSwrXhiLuxbOJF8NspE/fD8+Nh01gQ9km4sVVKd5t8dBAg4mKZyXjAXRFPoNC9l6rGe6Tvzcigdbwi0Rizp6aqwbDYidSVBmOqHKPk5TTHZD4jAJkKCBaACiadRFJeyrux5TJ7lBoZ4Nit+91CseznlbEq3dlUOTV6K9d7vOsQTOFS5ioKtnPfjhjHgugFmFDNqbYq/jgDhSCI2NH/q6CYiA+/PbvJdv8C5 DM2PR0301MB0655: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: microsoft.com Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 04:23:38 -0000 Looks good to me. -----Original Message----- From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Joe Touch Sent: Wednesday, July 22, 2015 12:12 AM To: tsvwg@ietf.org Cc: spud@ietf.org; touch@isi.edu Subject: [Spud] Fwd: New Version Notification for draft-touch-tsvwg-udp-opt= ions-01.txt FYI. Minor changes for clarification. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tsvwg-udp-options-01.txt Date: Tue, 21 Jul 2015 15:04:46 -0700 From: internet-drafts@ietf.org To: Dr. Joseph D. Touch , Joe Touch A new version of I-D, draft-touch-tsvwg-udp-options-01.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 01 Title: Transport Options for UDP Document date: 2015-07-21 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-01.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-0= 1 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tsvwg-udp-options-01 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP to provide a location, syntax, and semantics for transport layer options. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Spud mailing list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud From nobody Tue Jul 21 21:24:52 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A901A00F5; Tue, 21 Jul 2015 21:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0mCBjK-jHBlg; Tue, 21 Jul 2015 21:24:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC9B1A00FD; Tue, 21 Jul 2015 21:24:49 -0700 (PDT) Received: from DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 04:24:32 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 04:24:31 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0219.018; Wed, 22 Jul 2015 04:24:31 +0000 From: Christian Huitema To: Christian Huitema , Joe Touch , "tsvwg@ietf.org" Thread-Topic: [Spud] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-01.txt Thread-Index: AQHQxDZOjhBIIIiGlk2bcXscr0/KmQ== Date: Wed, 22 Jul 2015 04:24:31 +0000 Message-ID: References: <20150721220446.17166.92955.idtracker@ietfa.amsl.com> <55AEC3B6.3080601@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: microsoft.com; dkim=none (message not signed) header.d=none; x-originating-ip: [130.129.7.156] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:BnRdFSF/fD6jJPnyDz7rPXuq7bSh3jReVVIc99NQnwyKnegrhphMHFNPA9ZR2CdxIKwoAOOTZHMT5l7fWDorxywFIpX1cSc3qSw749QoGNPIyqtZV8aA63thzX7Mfu/pnhU1KVxUQXGHwgGBZQxc8w==; 24:fDgxufSLpFvFM752DNIctLm6X5XbuLJ7da0hBPSpRJ/iBrHJXlCZ/1cTF/l+Zud2/xNKW29AGbbmjGE5MaraHQ4Z0LqplUhUCZTsT69ntJY=; 20:fnHNM3rKGtdmv6QqB411C/gglkaf98yNfhl5U3vD0RtKSDkZOTg9IavOGPG+XM4q6gGbchonamFYySsdFi1n9A== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; dm2pr0301mb0653: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0645BEB7AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(2473001)(13464003)(377424004)(69234005)(377454003)(77096005)(86612001)(19580395003)(1511001)(74316001)(2656002)(86362001)(50986999)(2171001)(87936001)(19580405001)(66066001)(54356999)(102836002)(33656002)(76176999)(99286002)(2950100001)(76576001)(46102003)(5003600100002)(2561002)(2501003)(5001960100002)(15975445007)(62966003)(5001770100001)(2900100001)(106116001)(230783001)(92566002)(122556002)(40100003)(189998001)(10090500001)(77156002)(5001920100001)(5002640100001)(2421001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2015 04:24:31.2516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0655; 2:JUzi/mzjVDQYDCajaTmY4+1MZv/7wos8xInhHAHIA5RjJve44McAj1isb2rXpM2Y; 3:8di9SgaEhYuqeA1T+MzOLtn0r1sN7+uVGMV1rAs+6XI45jYUbY298Ecr8P9fMV2L63Wrqo+q9m0MR5mi7rDHLwFaCBgXkSzOJjEwIC4gicCLdDs4+blNZ7ntu3bYvKcy+XbMq/3EX3RisCdOkx+o4A==; 25:6rn/W2TfPeKRJq3dqF+SSTecVPXrIJBd/57GW2IGs/HbPL4tVCNrGVp1vP1uqhSWyI/1BRM3+UX+uqOMBpGsOlbOiK16Y+uj8cjg6cjL+GyQTu9woXrIstzqs2p8V72t2ZjZRydtK+VYjjpX2o4mXXXVON5h2H3IBZTsT3ROOLv7DXRw/hUQt5J0S0yoRKBqifvfmIJBBrGg1DYgJvKuPwZ5Cve2NpGJBhAd5mRICC3Q74xdX9jAQKa4FvQ2Hzjx X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0655; 20:hwVsCODWgRvIL4ZRro4NOh0f1NPYWkPZqXFzmB1xIEmHJOV7NFkxQo6RCm+/+cRfHKBfI47d3m9PmbwTKb6YnpXW/qhEjH5ngPdsytvO8O6N0rxa76U/BK+FAvIYdzvwDMts+YVQLN1txOiaVJmFtnSwIbxQV3beD+3VI6GrAXxGpPfwz+qEfZceotf6wovO2ZnYxyU0+xc60oyRSAYGosxz7la8lt92zqFiZrbwl1qnS4TBVdMZTx3vLn9VIwRNgflc9tjmkQJc5xoX3IrF9l/fmxt1uTi68PvuV/9VNRfAQwig/jik2nrvSDvtVo63DJL+uzR+6LZbcPUJOQcn8JdEw3zNXNlQ98JZPFJsGKRJWFYekCNS0r62wii9NR8e4+iWR1XwCun45SuQM/W1UamMvI86K3FVE0vpQF+sf02ze5S9uzCD2/yPiPfavQhmJssaI677R4smxTLMGC57sA1UNntvHs6CIehE2cSJNc/SBvQOlC4rX8m0guqupPvQ; 23:dYtrLUNJw9CEdpM7yvyBLZTeS9KqhUbxmBWCcO99IczvkU1qJw9ZYLshV8hDSuZY1dHUsoGtkiY39UfaF87wUE7aRPfdHGps7IgDk1oJzrYAVVJqz1U/MkIDmLuMojyMGj1QaZY84NKw/vbB/ohpUDSkGzvxJFDsL9WrKa/n34SZsbqAMcrRQGLFCGaCbJOzZUKARHFNYHsxIY652XIxArZiS0DdQOIs/fNKKfeGL1AybZxpEV+tR6GYgaSTQPPm DM2PR0301MB0655: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: microsoft.com Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 04:24:51 -0000 Oops. Sorry about that, I was replying to a different message. I have yet t= o review Joe's draft. -----Original Message----- From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Christian Huitema Sent: Wednesday, July 22, 2015 6:23 AM To: Joe Touch; tsvwg@ietf.org Cc: spud@ietf.org Subject: Re: [Spud] Fwd: New Version Notification for draft-touch-tsvwg-udp= -options-01.txt Looks good to me. -----Original Message----- From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Joe Touch Sent: Wednesday, July 22, 2015 12:12 AM To: tsvwg@ietf.org Cc: spud@ietf.org; touch@isi.edu Subject: [Spud] Fwd: New Version Notification for draft-touch-tsvwg-udp-opt= ions-01.txt FYI. Minor changes for clarification. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tsvwg-udp-options-01.txt Date: Tue, 21 Jul 2015 15:04:46 -0700 From: internet-drafts@ietf.org To: Dr. Joseph D. Touch , Joe Touch A new version of I-D, draft-touch-tsvwg-udp-options-01.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 01 Title: Transport Options for UDP Document date: 2015-07-21 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-01.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-0= 1 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tsvwg-udp-options-01 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP to provide a location, syntax, and semantics for transport layer options. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Spud mailing list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud _______________________________________________ Spud mailing list Spud@ietf.org https://www.ietf.org/mailman/listinfo/spud From nobody Tue Jul 21 23:22:14 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704B81A88E6; Tue, 21 Jul 2015 23:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Rv63Lels1npx; Tue, 21 Jul 2015 23:22:09 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 485561ACD7B; Tue, 21 Jul 2015 23:22:08 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:b09a:8cc7:81dd:4783] (unknown [IPv6:2001:67c:370:176:b09a:8cc7:81dd:4783]) by trammell.ch (Postfix) with ESMTPSA id 0232D1A06C8; Wed, 22 Jul 2015 08:22:06 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_11640972-104C-4950-B495-7521B2A68E3A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: <55AEC3B6.3080601@isi.edu> Date: Wed, 22 Jul 2015 08:22:08 +0200 Message-Id: References: <20150721220446.17166.92955.idtracker@ietfa.amsl.com> <55AEC3B6.3080601@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [Spud] [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 06:22:11 -0000 --Apple-Mail=_11640972-104C-4950-B495-7521B2A68E3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Joe, Thanks for this draft; I appreciate the elegant redundancy-reducing = length hack. :) Data in this case is, I know, hard to come by, but would you have any = feel for how much stuff out there will just break when they see an = inconsistency between IP and UDP length information? Thanks, cheers, Brian > On 22 Jul 2015, at 00:12, Joe Touch wrote: >=20 > FYI. Minor changes for clarification. >=20 > Joe >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for = draft-touch-tsvwg-udp-options-01.txt > Date: Tue, 21 Jul 2015 15:04:46 -0700 > From: internet-drafts@ietf.org > To: Dr. Joseph D. Touch , Joe Touch >=20 >=20 > A new version of I-D, draft-touch-tsvwg-udp-options-01.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. >=20 > Name: draft-touch-tsvwg-udp-options > Revision: 01 > Title: Transport Options for UDP > Document date: 2015-07-21 > Group: Individual Submission > Pages: 8 > URL: > = https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-01.txt > Status: > https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ > Htmlized: = https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tsvwg-udp-options-01 >=20 > Abstract: > Transport protocols are extended through the use of transport header > options. This document experimentally extends UDP to provide a > location, syntax, and semantics for transport layer options. >=20 >=20 >=20 >=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 > The IETF Secretariat >=20 >=20 --Apple-Mail=_11640972-104C-4950-B495-7521B2A68E3A 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVrzaQAAoJENt3nsOmbNJcLn0IAJri9JNDGDiyvPpLJMtCh3zX Gsg72/FbORWCLQWKaQSv5Mwm6TXlvvVOfk8ySY4mnTnutnXCOqgdolZlZQkumrA9 SPe+l77KUDDBUO3ay828Stx/mFfttBMCSpA4JmNO1cXj/wOJtpLtNbaq708JWeOk QwFwX6pcl34qwt9aKk3D+ekCqmSsoaY5TLWIGDABjnd0R8ALbiCmAuJn/zqaloFI uwrhARv2FnI/PDS4Q/7FlL67khqFfx7sxNPQTHmYhZJih+iYVD6KQsLPDgX1zGai 2P7Ypnq0oDjwet0hTK8J/Q8hOqlhq5OTB7htm95WKrlxt7/mqx9eJod9dNPk3xs= =ISS7 -----END PGP SIGNATURE----- --Apple-Mail=_11640972-104C-4950-B495-7521B2A68E3A-- From nobody Wed Jul 22 05:31:14 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360911A026E; Wed, 22 Jul 2015 05:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 xb2K-Gxra9NM; Wed, 22 Jul 2015 05:31:09 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id E1C331A01D5; Wed, 22 Jul 2015 05:31:08 -0700 (PDT) Received: from dhcp-9b03.meeting.ietf.org (dhcp-9b03.meeting.ietf.org [31.133.155.3]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id B39B61B00205; Wed, 22 Jul 2015 13:30:53 +0100 (BST) Message-ID: <55AF8D01.4040700@erg.abdn.ac.uk> Date: Wed, 22 Jul 2015 14:30:57 +0200 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell References: <20150721220446.17166.92955.idtracker@ietfa.amsl.com> <55AEC3B6.3080601@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "spud@ietf.org" , "tsvwg@ietf.org" , Joe Touch Subject: Re: [Spud] [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 12:31:11 -0000 I don't have data, but I am interested in such measurements. I previously proposed UDPTT, which if agreed would allow UDP-Lite-based behaviour for a tunnel: https://tools.ietf.org/html/draft-fairhurst-6man-tsvwg-udptt-03 Maybe we should be bolder to allow UDP-Lite behaviour on the UDP protocol number? This would allow the options usage also - all/any of these would require some network observations to determine what actually is passable across a path and what are the actual sideffects. RFC 6936 discussed potential failures, but presents no data. Gorry On 22/07/2015 08:22, Brian Trammell wrote: > hi Joe, > > Thanks for this draft; I appreciate the elegant redundancy-reducing length hack. :) > > Data in this case is, I know, hard to come by, but would you have any feel for how much stuff out there will just break when they see an inconsistency between IP and UDP length information? > > Thanks, cheers, > > Brian > >> On 22 Jul 2015, at 00:12, Joe Touch wrote: >> >> FYI. Minor changes for clarification. >> >> Joe >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-touch-tsvwg-udp-options-01.txt >> Date: Tue, 21 Jul 2015 15:04:46 -0700 >> From: internet-drafts@ietf.org >> To: Dr. Joseph D. Touch, Joe Touch >> >> >> A new version of I-D, draft-touch-tsvwg-udp-options-01.txt >> has been successfully submitted by Joe Touch and posted to the >> IETF repository. >> >> Name: draft-touch-tsvwg-udp-options >> Revision: 01 >> Title: Transport Options for UDP >> Document date: 2015-07-21 >> Group: Individual Submission >> Pages: 8 >> URL: >> https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ >> Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-01 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-01 >> >> Abstract: >> Transport protocols are extended through the use of transport header >> options. This document experimentally extends UDP to provide a >> location, syntax, and semantics for transport layer options. >> >> >> >> >> >> 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 Wed Jul 22 09:52:55 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19551A8AF5; Wed, 22 Jul 2015 09:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 0nCIHrY2V9E5; Wed, 22 Jul 2015 09:52:51 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABE51A8A9A; Wed, 22 Jul 2015 09:52:51 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6MGqC42006540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 09:52:13 -0700 (PDT) To: Brian Trammell References: <20150721220446.17166.92955.idtracker@ietfa.amsl.com> <55AEC3B6.3080601@isi.edu> From: Joe Touch Message-ID: <55AFCA3C.3060307@isi.edu> Date: Wed, 22 Jul 2015 09:52:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t6MGqC42006540 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "spud@ietf.org" , "tsvwg@ietf.org" , touch@isi.edu Subject: Re: [Spud] [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:52:52 -0000 On 7/21/2015 11:22 PM, Brian Trammell wrote: > hi Joe, > > Thanks for this draft; I appreciate the elegant redundancy-reducing > length hack. :) > > Data in this case is, I know, hard to come by, but would you have > any feel for how much stuff out there will just break when they see an > inconsistency between IP and UDP length information? I have students starting this fall who will look into this and do some tests. We have no information yet. Joe > Thanks, cheers, > > Brian > >> On 22 Jul 2015, at 00:12, Joe Touch wrote: >> >> FYI. Minor changes for clarification. >> >> Joe >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-touch-tsvwg-udp-options-01.txt >> Date: Tue, 21 Jul 2015 15:04:46 -0700 >> From: internet-drafts@ietf.org >> To: Dr. Joseph D. Touch , Joe Touch >> >> >> A new version of I-D, draft-touch-tsvwg-udp-options-01.txt >> has been successfully submitted by Joe Touch and posted to the >> IETF repository. >> >> Name: draft-touch-tsvwg-udp-options >> Revision: 01 >> Title: Transport Options for UDP >> Document date: 2015-07-21 >> Group: Individual Submission >> Pages: 8 >> URL: >> https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ >> Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-01 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-01 >> >> Abstract: >> Transport protocols are extended through the use of transport header >> options. This document experimentally extends UDP to provide a >> location, syntax, and semantics for transport layer options. >> >> >> >> >> >> 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 Wed Jul 22 09:55:11 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214811A8AF0; Wed, 22 Jul 2015 09:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 aJccro3OCUUq; Wed, 22 Jul 2015 09:55:07 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89651A89C4; Wed, 22 Jul 2015 09:54:56 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6MGsOja006876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 09:54:25 -0700 (PDT) To: gorry@erg.abdn.ac.uk, Brian Trammell References: <20150721220446.17166.92955.idtracker@ietfa.amsl.com> <55AEC3B6.3080601@isi.edu> <55AF8D01.4040700@erg.abdn.ac.uk> From: Joe Touch Message-ID: <55AFCAC0.7070701@isi.edu> Date: Wed, 22 Jul 2015 09:54:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55AF8D01.4040700@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t6MGsOja006876 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "spud@ietf.org" , "tsvwg@ietf.org" , touch@isi.edu Subject: Re: [Spud] [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-01.txt X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:55:09 -0000 On 7/22/2015 5:30 AM, Gorry Fairhurst wrote: > I don't have data, but I am interested in such measurements. I > previously proposed UDPTT, which if agreed would allow UDP-Lite-based > behaviour for a tunnel: > https://tools.ietf.org/html/draft-fairhurst-6man-tsvwg-udptt-03 > > Maybe we should be bolder to allow UDP-Lite behaviour on the UDP > protocol number? I can't yet see how to do this. A key difference between udp-options and UDP-Lite is that udp-options doesn't change the semantics of the existing UDP checksum field - which is critical to transiting NATs (who recompute that checksum). We also need to add an option-area checksum for udp-options (I'm working on that). It might be possible to use some area after the option area as a trailing, un-protected data area too - which might do what UDP-Lite does but in a slightly different way. Is that what you're looking for? I'll post that change later. Joe > This would allow the options usage also - all/any of these would require > some network observations to determine what actually is passable across > a path and what are the actual sideffects. RFC 6936 discussed potential > failures, but presents no data. > > Gorry > > On 22/07/2015 08:22, Brian Trammell wrote: >> hi Joe, >> >> Thanks for this draft; I appreciate the elegant redundancy-reducing >> length hack. :) >> >> Data in this case is, I know, hard to come by, but would you have any >> feel for how much stuff out there will just break when they see an >> inconsistency between IP and UDP length information? >> >> Thanks, cheers, >> >> Brian >> >>> On 22 Jul 2015, at 00:12, Joe Touch wrote: >>> >>> FYI. Minor changes for clarification. >>> >>> Joe >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for >>> draft-touch-tsvwg-udp-options-01.txt >>> Date: Tue, 21 Jul 2015 15:04:46 -0700 >>> From: internet-drafts@ietf.org >>> To: Dr. Joseph D. Touch, Joe Touch >>> >>> >>> A new version of I-D, draft-touch-tsvwg-udp-options-01.txt >>> has been successfully submitted by Joe Touch and posted to the >>> IETF repository. >>> >>> Name: draft-touch-tsvwg-udp-options >>> Revision: 01 >>> Title: Transport Options for UDP >>> Document date: 2015-07-21 >>> Group: Individual Submission >>> Pages: 8 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-01.txt >>> >>> Status: >>> https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-01 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-01 >>> >>> Abstract: >>> Transport protocols are extended through the use of transport header >>> options. This document experimentally extends UDP to provide a >>> location, syntax, and semantics for transport layer options. >>> >>> >>> >>> >>> >>> 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 Thu Jul 23 09:32:58 2015 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65F41A1A79; Thu, 23 Jul 2015 09:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KDj13FwQyl7F; Thu, 23 Jul 2015 09:32:54 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6721A2130; Thu, 23 Jul 2015 09:32:45 -0700 (PDT) Received: from dhcp-b12e.meeting.ietf.org (dhcp-b12e.meeting.ietf.org [31.133.177.46]) by trammell.ch (Postfix) with ESMTPSA id C7FDE1A035E; Thu, 23 Jul 2015 18:32:14 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_006389B6-E19D-4E46-BE76-2CB7E73F72D8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 23 Jul 2015 18:32:13 +0200 Message-Id: To: IAB SEMI Workshop , spud@ietf.org, taps WG , hops@ietf.org, tsv-area@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Stackevo , IAB IAB Subject: [Spud] New open IAB list to discuss stack evolution issues X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 16:32:56 -0000 --Apple-Mail=_006389B6-E19D-4E46-BE76-2CB7E73F72D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've heard a bit of confusion about the plethora of mailing lists on = which to discuss efforts to evolve the stack in and around the transport = layer, and we've decided to fix the confusion by creating another list. = :) The stackevo-discuss@iab.org list has been created for discussion any = and all aspects of evolution of the IP protocol stack. List membership = is open; please join at = https://www.iab.org/mailman/listinfo/stackevo-discuss Thanks, cheers, Brian Trammell (IAB IP Stack Evolution Program Lead) --Apple-Mail=_006389B6-E19D-4E46-BE76-2CB7E73F72D8 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVsRcNAAoJENt3nsOmbNJcTVIH/iepa3ml9ulR2p+AEZovAh/1 lbfheo0Y9Pa3LJu1LdybNJV05ae5pC/XThoirkUfAR6/0DvGjfLD3Msiyd/xCm/+ Ydf4Vw2yhaBtt6PkztO7O/3LXA1T25EvxI2SDhIt/o/9aH86v9e89MbmiZAIKPyn +3GE5rjg2XXZdmB+kzseYBgQHNBjK09JxDDJkcDnw25E8Vyqhq4jG951Q1KaEYm2 Q8ffrXDoeLSvcyCWHczWsF8HDLSwbdYpgaeUdVqhYskCbckE9zDJPlf7nItkXHtS w6jEGi0fhnfhpb60ZhA7d3IE8Aq3y9Ityv6fpWn+mGGj08vIKuFzBdihrjyv6/g= =GssY -----END PGP SIGNATURE----- --Apple-Mail=_006389B6-E19D-4E46-BE76-2CB7E73F72D8--