From nobody Sun Nov 1 22:06: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 556371B480C; Sun, 1 Nov 2015 22:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ZohekUx4lr_i; Sun, 1 Nov 2015 22:05:59 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 F0AE01B480B; Sun, 1 Nov 2015 22:05:58 -0800 (PST) Received: from dhcp-25-140.meeting.ietf94.jp ([133.93.25.140]:46769) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1Zt8Fg-0002i8-DW; Mon, 02 Nov 2015 06:05:56 +0000 To: Joe Touch References: From: Bob Briscoe Message-ID: <5636FD40.4030101@bobbriscoe.net> Date: Mon, 2 Nov 2015 06:05:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tsvwg , spud 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: Mon, 02 Nov 2015 06:06:01 -0000 Joe, Before starting measurements, I would recommend searching the Web for the manuals of middleboxes that might block such packets. For instance, with a quick search of "UDP header length inconsistency" I found Alcatel-Lucent's "Brick" Intrusion Detection System blocks such packets. Whether or not there is a buffer overflow vulnerability in any host, there will be firewalls and IDSs that block these packets in case someone is probing for such vulnerabilities. bob On 14/08/15 19:35, C. M. Heard wrote: > On 7/22/2015 09:52 AM, Joe Touch wrote: >> 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. > In an off-list e-mail exchange with Joe a couple of weeks ago, I noted > that every host stack implementation whose code I have inspected simply > ignores bytes that are past the UDP length but within the IP payload > length. The BSD-derived stacks trim the excess bytes before the data > is passed to the application via the sockets interface. However, one > embedded stack I have seen (which does not use a sockets API) makes > all data available to the application, including the UDP header, and > lets the application deal with excess bytes as it sees fit. > > I have zero information on the behavior of middleboxes (NAT/NAPT). > > Assuming that Joe's tests confirm these observations for both end > systems and middleboxes, then the proposed UDP option trailer should be > incrementally deployable as long as all options therein can be safely > ignored if not understood. The degree of utility (or, at least, the > length of time needed to make them useful) will of course depend > strongly on whether middleboxes trim the trailer or leave it intact; > if the prevalent middlebox practice is to trim it, then they won't be > useful without updating middleboxes as well as end systems. > > Also, Joe, if you and your students have the time and resources to look at > what middleboxes do with UDP packets where the IP header indicates a > shorter length than the UDP header, that would be useful information, as it > could open up a possible means to incorporate fragmentation in the UDP > layer, independent of whether or not an options trailer is present. > > Mike Heard > > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ From nobody Sun Nov 1 22:43: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 54BC91A007E for ; Sun, 1 Nov 2015 22:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 4iTi5DKExXF7 for ; Sun, 1 Nov 2015 22:43:41 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 8311B1A0060 for ; Sun, 1 Nov 2015 22:43:41 -0800 (PST) Received: by iofz202 with SMTP id z202so134498695iof.2 for ; Sun, 01 Nov 2015 22:43:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZzWflqOtGFgsi60B9v374faCHl04S4w7CtKkrkLGmqE=; b=D2BN1bwD9yF2uwlBW5u+vNP2uqZPohf3VsnGqk/YNJdx2NUc6sh9z6hMcne+9STlhG rLdljAiOctL/i/t+rdNLLcHheniRVL/+JbZQhO8WWMkQnKSsrXF1qYk0CMK8PkD8Rzye ddGH1ZNWe4NoMN6JfiiMNsD6LvBqDoZWNGyDx0oDq8WcRjFq/wtcGaN7hZ2c/pBKGkVj uHGTvP61hxeiaw3TPygbqyvvVIcWupcdlp/PdM16F5R1pC5pNMgZKls8quXUIuUUpUen obvkDuTQ2fWdfH4SLLSbKTmHkw/GQbHYJEVtJU2fokl7vBmW3xCoIGlXiMDAKgDxImxs 6//A== 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=ZzWflqOtGFgsi60B9v374faCHl04S4w7CtKkrkLGmqE=; b=igC1VkChx+U7p2tV4tPFVvbHxZB0vBd+hV8rSby5E5xstTijjcnCxej7PJBWOBAaXG 9XdjIT13nogOXHnD0OQBH9ih6Wh82XjA+ohBh7CBkzs+7EMQ9VGCkGROuSR0sxmfz6Ug Qd8Qwkdqv8zduAfxuJVghuLoopou5Trvk+iijLaj6xtuHs3MEvup1+J3P9G2SZNdhtdQ 7Bwr+nV1dTMCpOgzedadgPFM5zJTZ/MwySlrlvTiAh3zXqbl938YnZ7tx/5RbK9OsfVF J3jDMg29EvcipiiC5oPqRRXHt/f+Fhpshbz01wo7WCElG6Cf4DAWKaCYzR8EAKyoIlw5 DjJg== X-Gm-Message-State: ALoCoQl5Q4L1BhcMPb6duKXp0bk4ohIZ3aOhbohqoS57892uUm6OXYMokkD++IrRJ/KeMYSk/B7v MIME-Version: 1.0 X-Received: by 10.107.156.81 with SMTP id f78mr23691071ioe.107.1446446620959; Sun, 01 Nov 2015 22:43:40 -0800 (PST) Received: by 10.107.41.83 with HTTP; Sun, 1 Nov 2015 22:43:40 -0800 (PST) In-Reply-To: <5636FD40.4030101@bobbriscoe.net> References: <5636FD40.4030101@bobbriscoe.net> Date: Mon, 2 Nov 2015 15:43:40 +0900 Message-ID: From: Tom Herbert To: Bob Briscoe Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: spud , tsvwg , 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 List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 06:43:42 -0000 On Mon, Nov 2, 2015 at 3:05 PM, Bob Briscoe wrote: > Joe, > > Before starting measurements, I would recommend searching the Web for the > manuals of middleboxes that might block such packets. > Please look at NIC offloads also. I am pretty certain that the most common flavor of checksum offload will break in this proposal since devices use the value in the UDP length field as the length of the payload to compute the checksum over. UDP Fragmentation Offload would similarly be broken, although we can probably live without that (but we can't live without checksum offload!). Tom From nobody Sun Nov 1 22:44:35 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 145B51A008E for ; Sun, 1 Nov 2015 22:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 QUokKeUeNGwf for ; Sun, 1 Nov 2015 22:44:31 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::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 233E11A0078 for ; Sun, 1 Nov 2015 22:44:31 -0800 (PST) Received: by obbwb3 with SMTP id wb3so87988838obb.0 for ; Sun, 01 Nov 2015 22:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pPJiJzEWB5/7pzqqK92S6Amig1r41ZjQ+vhkvMaqEd0=; b=nt9NEBLDpcjrA3yRUbY7w7MsWyXPFvxz61vWYLIW9gMR7RoiLglsB2JeAG7jOHRftc 2vzp0Q39BaiIBhXhuMaULEAIlZfUXxvnT9SJyCKAWz8hqfn6MIjE5ITcpYOonHM8ydmK wTnFzLKO9EBPslh1AWBdlm+skBCTZpDCnQUl+hkeW9cFOBnzvtUphZ7Z8W+FTlAvzJtF 5Bw6dvOQVFoj4V5ng6k+VDZ8AwnQLD/Fu+2HAqGz69q6m83i9WNAn6J6zLRkiJ3pyG8B 2OsBj7cXqLuvireq4bo4IR7BEO0k1qD4jawQzXCTQHAwA+n4QYfy/ET9/wlBvFfTJxtE Osag== 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=pPJiJzEWB5/7pzqqK92S6Amig1r41ZjQ+vhkvMaqEd0=; b=kl3zopGYcUp2/XO3pZD/KoINA8/ROelxhEPsxcVHY4gdPt5IELorJ6kdo4KERuuXJf 8E4T20cMHsz2LYeJS1WJ1+Lu8WO9k5iP4Ncjl+AB3NFtCjlIMUBxiNLjLgmXy0qIokE1 KnChdCF58f0lD5zBIgTypVGJEYQUxTSph/qzXyz8q3r6xtA73iLFjwI9j+hN854FvWts r+YxoS0IWw+SULLMvtfJo5A01dy4NxiXXIeR7Isxf9AbKOmvmCvm9/tUNBJZePVrx+GC GEp7rvt1s6JNg57ghs8tMmWgIqOOOuY7RAsZ9mVN+493xSbsZIFBdEUuA2SXv/1Oc7Tk uyHA== X-Gm-Message-State: ALoCoQksJzTn18y7sywAL0NO6izuO+Rmvee26DxO2akjGu5TMsvMWvgPGwgVq++gnGyom036UGHL MIME-Version: 1.0 X-Received: by 10.60.97.68 with SMTP id dy4mr13647768oeb.21.1446446670357; Sun, 01 Nov 2015 22:44:30 -0800 (PST) Received: by 10.76.144.165 with HTTP; Sun, 1 Nov 2015 22:44:30 -0800 (PST) In-Reply-To: <5636FD40.4030101@bobbriscoe.net> References: <5636FD40.4030101@bobbriscoe.net> Date: Mon, 2 Nov 2015 15:44:30 +0900 Message-ID: From: Jana Iyengar To: Bob Briscoe Content-Type: multipart/alternative; boundary=089e013a15dcf972f40523891b6f Archived-At: Cc: spud , tsvwg , 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 List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 06:44:33 -0000 --089e013a15dcf972f40523891b6f Content-Type: text/plain; charset=UTF-8 What Bob said. Also, what problem is this draft seeking to solve, especially given that there's no negotiation of options support possible? - jana On Sun, Nov 1, 2015 at 10:05 PM, Bob Briscoe wrote: > Joe, > > Before starting measurements, I would recommend searching the Web for the > manuals of middleboxes that might block such packets. > > For instance, with a quick search of "UDP header length inconsistency" I > found Alcatel-Lucent's "Brick" Intrusion Detection System blocks such > packets. > > Whether or not there is a buffer overflow vulnerability in any host, there > will be firewalls and IDSs that block these packets in case someone is > probing for such vulnerabilities. > > > > bob > > > On 14/08/15 19:35, C. M. Heard wrote: > >> On 7/22/2015 09:52 AM, Joe Touch wrote: >> >>> 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. >>> >> In an off-list e-mail exchange with Joe a couple of weeks ago, I noted >> that every host stack implementation whose code I have inspected simply >> ignores bytes that are past the UDP length but within the IP payload >> length. The BSD-derived stacks trim the excess bytes before the data >> is passed to the application via the sockets interface. However, one >> embedded stack I have seen (which does not use a sockets API) makes >> all data available to the application, including the UDP header, and >> lets the application deal with excess bytes as it sees fit. >> >> I have zero information on the behavior of middleboxes (NAT/NAPT). >> >> Assuming that Joe's tests confirm these observations for both end >> systems and middleboxes, then the proposed UDP option trailer should be >> incrementally deployable as long as all options therein can be safely >> ignored if not understood. The degree of utility (or, at least, the >> length of time needed to make them useful) will of course depend >> strongly on whether middleboxes trim the trailer or leave it intact; >> if the prevalent middlebox practice is to trim it, then they won't be >> useful without updating middleboxes as well as end systems. >> >> Also, Joe, if you and your students have the time and resources to look at >> what middleboxes do with UDP packets where the IP header indicates a >> shorter length than the UDP header, that would be useful information, as >> it >> could open up a possible means to incorporate fragmentation in the UDP >> layer, independent of whether or not an options trailer is present. >> >> Mike Heard >> >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > --089e013a15dcf972f40523891b6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What Bob said.
Also, what problem is this draft seekin= g to solve, especially given that there's no negotiation of options sup= port possible?

- jana

On Sun, Nov 1, 2015 at 10:05 P= M, Bob Briscoe <ietf@bobbriscoe.net> wrote:
Joe,

Before starting measurements, I would recommend searching the Web for the m= anuals of middleboxes that might block such packets.

For instance, with a quick search of "UDP header length inconsistency&= quot; I found Alcatel-Lucent's "Brick" Intrusion Detection Sy= stem blocks such packets.

Whether or not there is a buffer overflow vulnerability in any host, there = will be firewalls and IDSs that block these packets in case someone is prob= ing for such vulnerabilities.



bob


On 14/08/15 19:35, C. M. Heard wrote:
On 7/22/2015 09:52 AM, Joe Touch wrote:
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.
In an off-list e-mail exchange with Joe a couple of weeks ago, I noted
that every host stack implementation whose code I have inspected simply
ignores bytes that are past the UDP length but within the IP payload
length.=C2=A0 The BSD-derived stacks trim the excess bytes before the data<= br> is passed to the application via the sockets interface.=C2=A0 However, one<= br> embedded stack I have seen (which does not use a sockets API) makes
all data available to the application, including the UDP header, and
lets the application deal with excess bytes as it sees fit.

I have zero information on the behavior of middleboxes (NAT/NAPT).

Assuming that Joe's tests confirm these observations for both end
systems and middleboxes, then the proposed UDP option trailer should be
incrementally deployable as long as all options therein can be safely
ignored if not understood.=C2=A0 The degree of utility (or, at least, the length of time needed to make them useful) will of course depend
strongly on whether middleboxes trim the trailer or leave it intact;
if the prevalent middlebox practice is to trim it, then they won't be useful without updating middleboxes as well as end systems.

Also, Joe, if you and your students have the time and resources to look at<= br> what middleboxes do with UDP packets where the IP header indicates a
shorter length than the UDP header, that would be useful information, as it=
could open up a possible means to incorporate fragmentation in the UDP
layer, independent of whether or not an options trailer is present.

Mike Heard




--
________________________________________________________________
Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud

--089e013a15dcf972f40523891b6f-- From nobody Mon Nov 2 00:15:48 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 5B2D11B3338; Sun, 1 Nov 2015 23:23:47 -0800 (PST) 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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8vkrWNzbn2O9; Sun, 1 Nov 2015 23:23:45 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D635C1ACEF2; Sun, 1 Nov 2015 23:23:45 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 98A45D7888; Sun, 1 Nov 2015 23:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=qaPGy3tNbJ3EqLCGHwg85pHMxbg=; b=S0 M+znRcNeYRu5gM3ydiBuuHkj1Sr1Wb6QUMWKAlvNUhqjrgUaUOeSqWrazZFVM3wS aNB/AatRUQ784ypeW8W4AEIsF944pEAkBSrEZpSdPFVol/8fFY9Dz5e7X48Gr4JA pRt/ZwTX/0TflK7t5rlDfV1DLu3c9dSjwTY4yQl2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=AJKrDqccfr2QOFE7Ca0pqgLwyKzd fj7Md+Si1vv4NBp24sKyJkUU8ycAw/5l97YKcgNqBMZKRDol4n2N2HhZcsgtU2Ha +98fL2LGUo3IxR/STVHtUnopeS6j18dgHEjCV3qxylLhYiHC7XbsWvMLK3kjGdst RGSguAn0vjrwGOA= Received: by cowbell.employees.org (Postfix, from userid 1736) id 8A731D7884; Sun, 1 Nov 2015 23:23:44 -0800 (PST) Date: Mon, 2 Nov 2015 07:23:44 +0000 From: Derek Fawcus To: Tom Herbert Message-ID: <20151102072344.GA83371@cowbell.employees.org> Mail-Followup-To: Tom Herbert , Bob Briscoe , spud , tsvwg , Joe Touch References: <5636FD40.4030101@bobbriscoe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-Mailman-Approved-At: Mon, 02 Nov 2015 00:15:47 -0800 Cc: Joe Touch , Bob Briscoe , tsvwg , spud 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: Mon, 02 Nov 2015 07:23:47 -0000 On Mon, Nov 02, 2015 at 03:43:40pm +0900, Tom Herbert wrote: > Please look at NIC offloads also. I am pretty certain that the most > common flavor of checksum offload will break in this proposal since > devices use the value in the UDP length field as the length of the > payload to compute the checksum over. I had assumed that is what was intended, i.e. that the bytes within the 'option area' were not protected by the UDP checksum; so I don't see how that would break NIC checksum offload. > UDP Fragmentation Offload would similarly be broken, How? DF From nobody Mon Nov 2 07:25: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 AB7811B46E5; Mon, 2 Nov 2015 07:25:54 -0800 (PST) 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 kMW4piI0UYRo; Mon, 2 Nov 2015 07:25:53 -0800 (PST) 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 001F81B47CD; Mon, 2 Nov 2015 07:25:51 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id tA2FOUX6019684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Nov 2015 07:24:31 -0800 (PST) To: Bob Briscoe References: <5636FD40.4030101@bobbriscoe.net> From: Joe Touch Message-ID: <5637802E.4090602@isi.edu> Date: Mon, 2 Nov 2015 07:24:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5636FD40.4030101@bobbriscoe.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: tA2FOUX6019684 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud , tsvwg , 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: Mon, 02 Nov 2015 15:25:54 -0000 We did find a few vendors that don't block those packets. On 11/1/2015 10:05 PM, Bob Briscoe wrote: > Joe, > > Before starting measurements, I would recommend searching the Web for > the manuals of middleboxes that might block such packets. > > For instance, with a quick search of "UDP header length inconsistency" I > found Alcatel-Lucent's "Brick" Intrusion Detection System blocks such > packets. Well, since "that which isn't prohibited ought to be permitted", IMO that' an error in their code. > Whether or not there is a buffer overflow vulnerability in any host, This would be an underflow issue, not an overflow one, FWIW. Joe > there will be firewalls and IDSs that block these packets in case > someone is probing for such vulnerabilities. > > > > bob > > On 14/08/15 19:35, C. M. Heard wrote: >> On 7/22/2015 09:52 AM, Joe Touch wrote: >>> 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. >> In an off-list e-mail exchange with Joe a couple of weeks ago, I noted >> that every host stack implementation whose code I have inspected simply >> ignores bytes that are past the UDP length but within the IP payload >> length. The BSD-derived stacks trim the excess bytes before the data >> is passed to the application via the sockets interface. However, one >> embedded stack I have seen (which does not use a sockets API) makes >> all data available to the application, including the UDP header, and >> lets the application deal with excess bytes as it sees fit. >> >> I have zero information on the behavior of middleboxes (NAT/NAPT). >> >> Assuming that Joe's tests confirm these observations for both end >> systems and middleboxes, then the proposed UDP option trailer should be >> incrementally deployable as long as all options therein can be safely >> ignored if not understood. The degree of utility (or, at least, the >> length of time needed to make them useful) will of course depend >> strongly on whether middleboxes trim the trailer or leave it intact; >> if the prevalent middlebox practice is to trim it, then they won't be >> useful without updating middleboxes as well as end systems. >> >> Also, Joe, if you and your students have the time and resources to >> look at >> what middleboxes do with UDP packets where the IP header indicates a >> shorter length than the UDP header, that would be useful information, >> as it >> could open up a possible means to incorporate fragmentation in the UDP >> layer, independent of whether or not an options trailer is present. >> >> Mike Heard >> >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ From nobody Mon Nov 2 07:29:37 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 8FDD01B4843; Mon, 2 Nov 2015 07:29:35 -0800 (PST) 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 I4p5Kz1ZJ47k; Mon, 2 Nov 2015 07:29:34 -0800 (PST) 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 A1EBE1B483E; Mon, 2 Nov 2015 07:29:34 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id tA2FSMWX020213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Nov 2015 07:28:24 -0800 (PST) To: Tom Herbert , Bob Briscoe References: <5636FD40.4030101@bobbriscoe.net> From: Joe Touch Message-ID: <56378116.2050709@isi.edu> Date: Mon, 2 Nov 2015 07:28:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: tA2FSMWX020213 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud , tsvwg , 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: Mon, 02 Nov 2015 15:29:35 -0000 On 11/1/2015 10:43 PM, Tom Herbert wrote: > On Mon, Nov 2, 2015 at 3:05 PM, Bob Briscoe wrote: >> Joe, >> >> Before starting measurements, I would recommend searching the Web for the >> manuals of middleboxes that might block such packets. >> > Please look at NIC offloads also. I am pretty certain that the most > common flavor of checksum offload will break in this proposal since > devices use the value in the UDP length field as the length of the > payload to compute the checksum over. That is the intended behavior. > UDP Fragmentation Offload would > similarly be broken, although we can probably live without that (but > we can't live without checksum offload!). We need to live without broken offloads because offloads are part of the protocol stack. They can't simply jump in and try to help without being very careful about corner cases like this. E.g., we've already seen an offload that merges TCP packets with different options, which ought to be clearly inappropriate. Joe From nobody Mon Nov 2 07:37: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 30AD21B488E; Mon, 2 Nov 2015 07:37:08 -0800 (PST) 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 Cpum-hw3HJxd; Mon, 2 Nov 2015 07:37:06 -0800 (PST) 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 76E351B488A; Mon, 2 Nov 2015 07:37:06 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id tA2FZh2K021034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Nov 2015 07:35:44 -0800 (PST) To: Jana Iyengar , Bob Briscoe References: <5636FD40.4030101@bobbriscoe.net> From: Joe Touch Message-ID: <563782CF.4010804@isi.edu> Date: Mon, 2 Nov 2015 07:35:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: tA2FZh2K021034 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud , tsvwg , 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: Mon, 02 Nov 2015 15:37:08 -0000 On 11/1/2015 10:44 PM, Jana Iyengar wrote: > What Bob said. > Also, what problem is this draft seeking to solve, especially given that > there's no negotiation of options support possible? See Section 3 of the doc. There is also interest in using this mechanism to allow UDP-Lite (or something very close thereto) to share the same transport protocol number as UDP. Joe > - jana > > On Sun, Nov 1, 2015 at 10:05 PM, Bob Briscoe > wrote: > > Joe, > > Before starting measurements, I would recommend searching the Web > for the manuals of middleboxes that might block such packets. > > For instance, with a quick search of "UDP header length > inconsistency" I found Alcatel-Lucent's "Brick" Intrusion Detection > System blocks such packets. > > Whether or not there is a buffer overflow vulnerability in any host, > there will be firewalls and IDSs that block these packets in case > someone is probing for such vulnerabilities. > > > > bob > > > On 14/08/15 19:35, C. M. Heard wrote: > > On 7/22/2015 09:52 AM, Joe Touch wrote: > > 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. > > In an off-list e-mail exchange with Joe a couple of weeks ago, I > noted > that every host stack implementation whose code I have inspected > simply > ignores bytes that are past the UDP length but within the IP payload > length. The BSD-derived stacks trim the excess bytes before the > data > is passed to the application via the sockets interface. > However, one > embedded stack I have seen (which does not use a sockets API) makes > all data available to the application, including the UDP header, and > lets the application deal with excess bytes as it sees fit. > > I have zero information on the behavior of middleboxes (NAT/NAPT). > > Assuming that Joe's tests confirm these observations for both end > systems and middleboxes, then the proposed UDP option trailer > should be > incrementally deployable as long as all options therein can be > safely > ignored if not understood. The degree of utility (or, at least, the > length of time needed to make them useful) will of course depend > strongly on whether middleboxes trim the trailer or leave it intact; > if the prevalent middlebox practice is to trim it, then they > won't be > useful without updating middleboxes as well as end systems. > > Also, Joe, if you and your students have the time and resources > to look at > what middleboxes do with UDP packets where the IP header indicates a > shorter length than the UDP header, that would be useful > information, as it > could open up a possible means to incorporate fragmentation in > the UDP > layer, independent of whether or not an options trailer is present. > > Mike Heard > > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud > > From nobody Mon Nov 2 08:17:50 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 98E471B491C; Mon, 2 Nov 2015 08:17:48 -0800 (PST) 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 Ffi1GgE4AtUK; Mon, 2 Nov 2015 08:17:47 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id EA9C41B4918; Mon, 2 Nov 2015 08:17:46 -0800 (PST) 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 E73B41B00351; Mon, 2 Nov 2015 16:24:57 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 2 Nov 2015 16:17:45 -0000 Message-ID: <2f12e2f48b58ff27ead9c4f390043421.squirrel@erg.abdn.ac.uk> In-Reply-To: <56378116.2050709@isi.edu> References: <5636FD40.4030101@bobbriscoe.net> <56378116.2050709@isi.edu> Date: Mon, 2 Nov 2015 16:17:45 -0000 From: gorry@erg.abdn.ac.uk To: "Joe Touch" 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: Tom Herbert , touch@isi.edu, Bob Briscoe , tsvwg , spud 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: Mon, 02 Nov 2015 16:17:48 -0000 Sorry I wasn't at the meeting yesterday in Japan - Block packets (perhaps firewalls, for instance), but also truncate (which may be more common on devices doing incremental checksum update). - I expect the default behaviour is either to copy UDP-L; which means you lose the options (i.e., truncate - sad but not disaster) or IP-L; which means you get all (the same as UDP-Lite). Gorry > > On 11/1/2015 10:43 PM, Tom Herbert wrote: >> On Mon, Nov 2, 2015 at 3:05 PM, Bob Briscoe wrote: >>> Joe, >>> >>> Before starting measurements, I would recommend searching the Web for >>> the manuals of middleboxes that might block such packets. >>> >> Please look at NIC offloads also. I am pretty certain that the most >> common flavor of checksum offload will break in this proposal since >> devices use the value in the UDP length field as the length of the >> payload to compute the checksum over. > > That is the intended behavior. > >> UDP Fragmentation Offload would >> similarly be broken, although we can probably live without that (but >> we can't live without checksum offload!). > > We need to live without broken offloads because offloads are part of the > protocol stack. They can't simply jump in and try to help without being > very careful about corner cases like this. > > E.g., we've already seen an offload that merges TCP packets with > different options, which ought to be clearly inappropriate. > > Joe > From nobody Mon Nov 2 08:28:17 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 BF8391B495C; Mon, 2 Nov 2015 08:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6gt5nks7U_Rx; Mon, 2 Nov 2015 08:28:12 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 64F701B495B; Mon, 2 Nov 2015 08:28:12 -0800 (PST) Received: from x104183.dynamic.ppp.asahi-net.or.jp ([122.249.104.183]:42371 helo=[192.168.1.118]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1ZtHxq-000527-8U; Mon, 02 Nov 2015 16:28:10 +0000 To: Joe Touch References: <5636FD40.4030101@bobbriscoe.net> <5637802E.4090602@isi.edu> From: Bob Briscoe Message-ID: <56378F16.4080700@bobbriscoe.net> Date: Mon, 2 Nov 2015 16:28:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5637802E.4090602@isi.edu> Content-Type: multipart/alternative; boundary="------------030408000603060704010305" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tsvwg , spud 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: Mon, 02 Nov 2015 16:28:15 -0000 This is a multi-part message in MIME format. --------------030408000603060704010305 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Joe, The point of my post was in response to: On 7/22/2015 09:52 AM, Joe Touch wrote: > I have students starting this fall who will look into this and do some tests. We have no information yet. so they could go looking for the most likely place where there might be problems. A little manual reading could give clues on where to look, to save searching loads of Internet paths. You might even find someone has already probed for this supposed 'vulnerability' (whether for research or for nefarious puposes), then your student wouldn't have to do any work other than get their data, or even just cite their paper. They could also search for phrases like "UDP Length Error" to find source code that checks for this, then see what the code does and what it is used in. I am just trying to make their job easier, so they can finish early and perhaps do something more useful. Here's some more links found in a few minutes of searching: These two show that by default checkpoint firewalls (very common) check for consistency betw the two lengths. Re: [FW-1] UDP length error Malformed Packet & UDP length error This one shows that a cisco router checks the UDP length of HSRP Hello packets is consistent before accepting it: Cisco Bug: CSCsc13766 - Both HSRP routers are active - UDP length error I'm not expecting comment on whether you think the alleged vulnerabilities these firms are preventing exist, or whether they ought to block such packets. I'm just saying they do. Bob On 02/11/15 15:24, Joe Touch wrote: > We did find a few vendors that don't block those packets. > > On 11/1/2015 10:05 PM, Bob Briscoe wrote: >> Joe, >> >> Before starting measurements, I would recommend searching the Web for >> the manuals of middleboxes that might block such packets. >> >> For instance, with a quick search of "UDP header length inconsistency" I >> found Alcatel-Lucent's "Brick" Intrusion Detection System blocks such >> packets. > Well, since "that which isn't prohibited ought to be permitted", IMO > that' an error in their code. > >> Whether or not there is a buffer overflow vulnerability in any host, > This would be an underflow issue, not an overflow one, FWIW. > > Joe > >> there will be firewalls and IDSs that block these packets in case >> someone is probing for such vulnerabilities. >> >> >> >> bob >> >> On 14/08/15 19:35, C. M. Heard wrote: >>> On 7/22/2015 09:52 AM, Joe Touch wrote: >>>> 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. >>> In an off-list e-mail exchange with Joe a couple of weeks ago, I noted >>> that every host stack implementation whose code I have inspected simply >>> ignores bytes that are past the UDP length but within the IP payload >>> length. The BSD-derived stacks trim the excess bytes before the data >>> is passed to the application via the sockets interface. However, one >>> embedded stack I have seen (which does not use a sockets API) makes >>> all data available to the application, including the UDP header, and >>> lets the application deal with excess bytes as it sees fit. >>> >>> I have zero information on the behavior of middleboxes (NAT/NAPT). >>> >>> Assuming that Joe's tests confirm these observations for both end >>> systems and middleboxes, then the proposed UDP option trailer should be >>> incrementally deployable as long as all options therein can be safely >>> ignored if not understood. The degree of utility (or, at least, the >>> length of time needed to make them useful) will of course depend >>> strongly on whether middleboxes trim the trailer or leave it intact; >>> if the prevalent middlebox practice is to trim it, then they won't be >>> useful without updating middleboxes as well as end systems. >>> >>> Also, Joe, if you and your students have the time and resources to >>> look at >>> what middleboxes do with UDP packets where the IP header indicates a >>> shorter length than the UDP header, that would be useful information, >>> as it >>> could open up a possible means to incorporate fragmentation in the UDP >>> layer, independent of whether or not an options trailer is present. >>> >>> Mike Heard >>> >>> >>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoe http://bobbriscoe.net/ > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------030408000603060704010305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Joe,

The point of my post was in response to:
On 7/22/2015 09:52 AM, Joe Touch wrote:

I have students starting this fall who will look into this and do some tests. We have no information yet.
so they could go looking for the most likely place where there might be problems. A little manual reading could give clues on where to look, to save searching loads of Internet paths.

You might even find someone has already probed for this supposed 'vulnerability' (whether for research or for nefarious puposes), then your student wouldn't have to do any work other than get their data, or even just cite their paper.

They could also search for phrases like "UDP Length Error" to find source code that checks for this, then see what the code does and what it is used in.

I am just trying to make their job easier, so they can finish early and perhaps do something more useful.



Here's some more links found in a few minutes of searching:

These two show that by default checkpoint firewalls (very common) check for consistency betw the two lengths.
Re: [FW-1] UDP length error
Malformed Packet & UDP length error

This one shows that a cisco router checks the UDP length of HSRP Hello packets is consistent before accepting it:
Cisco Bug: CSCsc13766 - Both HSRP routers are active - UDP length error

I'm not expecting comment on whether you think the alleged vulnerabilities these firms are preventing exist, or whether they ought to block such packets. I'm just saying they do.


Bob


On 02/11/15 15:24, Joe Touch wrote:
We did find a few vendors that don't block those packets.

On 11/1/2015 10:05 PM, Bob Briscoe wrote:

Joe,

Before starting measurements, I would recommend searching the Web for
the manuals of middleboxes that might block such packets.

For instance, with a quick search of "UDP header length inconsistency" I
found Alcatel-Lucent's "Brick" Intrusion Detection System blocks such
packets.

Well, since "that which isn't prohibited ought to be permitted", IMO
that' an error in their code.


Whether or not there is a buffer overflow vulnerability in any host,

This would be an underflow issue, not an overflow one, FWIW.

Joe


there will be firewalls and IDSs that block these packets in case
someone is probing for such vulnerabilities.



bob

On 14/08/15 19:35, C. M. Heard wrote:

On 7/22/2015 09:52 AM, Joe Touch wrote:

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.

In an off-list e-mail exchange with Joe a couple of weeks ago, I noted
that every host stack implementation whose code I have inspected simply
ignores bytes that are past the UDP length but within the IP payload
length.  The BSD-derived stacks trim the excess bytes before the data
is passed to the application via the sockets interface.  However, one
embedded stack I have seen (which does not use a sockets API) makes
all data available to the application, including the UDP header, and
lets the application deal with excess bytes as it sees fit.

I have zero information on the behavior of middleboxes (NAT/NAPT).

Assuming that Joe's tests confirm these observations for both end
systems and middleboxes, then the proposed UDP option trailer should be
incrementally deployable as long as all options therein can be safely
ignored if not understood.  The degree of utility (or, at least, the
length of time needed to make them useful) will of course depend
strongly on whether middleboxes trim the trailer or leave it intact;
if the prevalent middlebox practice is to trim it, then they won't be
useful without updating middleboxes as well as end systems.

Also, Joe, if you and your students have the time and resources to
look at
what middleboxes do with UDP packets where the IP header indicates a
shorter length than the UDP header, that would be useful information,
as it
could open up a possible means to incorporate fragmentation in the UDP
layer, independent of whether or not an options trailer is present.

Mike Heard




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------030408000603060704010305-- From nobody Mon Nov 2 08:44: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 D33FC1B498D; Mon, 2 Nov 2015 08:44:28 -0800 (PST) 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 1vxXdKgmNiF2; Mon, 2 Nov 2015 08:44:27 -0800 (PST) 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 C168F1B498A; Mon, 2 Nov 2015 08:44:27 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id tA2GhGA8001117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Nov 2015 08:43:17 -0800 (PST) To: gorry@erg.abdn.ac.uk References: <5636FD40.4030101@bobbriscoe.net> <56378116.2050709@isi.edu> <2f12e2f48b58ff27ead9c4f390043421.squirrel@erg.abdn.ac.uk> From: Joe Touch Message-ID: <563792A3.7060808@isi.edu> Date: Mon, 2 Nov 2015 08:43:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <2f12e2f48b58ff27ead9c4f390043421.squirrel@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: tA2GhGA8001117 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Tom Herbert , spud , Bob Briscoe , tsvwg , 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: Mon, 02 Nov 2015 16:44:29 -0000 On 11/2/2015 8:17 AM, gorry@erg.abdn.ac.uk wrote: > Sorry I wasn't at the meeting yesterday in Japan > > - Block packets (perhaps firewalls, for instance), but also truncate > (which may be more common on devices doing incremental checksum update). Sure, which ought to be safe. > - I expect the default behaviour is either to copy UDP-L; which means you > lose the options (i.e., truncate - sad but not disaster) or IP-L; which > means you get all (the same as UDP-Lite). For end systems, the only behavior we've seen so far is to copy the UDP portion (i.e., in legacy mode) and ignore the extension area. Joe > > Gorry >> >> On 11/1/2015 10:43 PM, Tom Herbert wrote: >>> On Mon, Nov 2, 2015 at 3:05 PM, Bob Briscoe wrote: >>>> Joe, >>>> >>>> Before starting measurements, I would recommend searching the Web for >>>> the manuals of middleboxes that might block such packets. >>>> >>> Please look at NIC offloads also. I am pretty certain that the most >>> common flavor of checksum offload will break in this proposal since >>> devices use the value in the UDP length field as the length of the >>> payload to compute the checksum over. >> >> That is the intended behavior. >> >>> UDP Fragmentation Offload would >>> similarly be broken, although we can probably live without that (but >>> we can't live without checksum offload!). >> >> We need to live without broken offloads because offloads are part of the >> protocol stack. They can't simply jump in and try to help without being >> very careful about corner cases like this. >> >> E.g., we've already seen an offload that merges TCP packets with >> different options, which ought to be clearly inappropriate. >> >> Joe >> From nobody Mon Nov 2 08:45: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 D25BB1B498D; Mon, 2 Nov 2015 08:45:36 -0800 (PST) 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 2qnTU8Ak2QVX; Mon, 2 Nov 2015 08:45:35 -0800 (PST) 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 E94311B497D; Mon, 2 Nov 2015 08:45:34 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id tA2Ghs7D001175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Nov 2015 08:43:55 -0800 (PST) To: Bob Briscoe References: <5636FD40.4030101@bobbriscoe.net> <5637802E.4090602@isi.edu> <56378F16.4080700@bobbriscoe.net> From: Joe Touch Message-ID: <563792CA.9040800@isi.edu> Date: Mon, 2 Nov 2015 08:43:54 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56378F16.4080700@bobbriscoe.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: tA2Ghs7D001175 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: spud , tsvwg , 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: Mon, 02 Nov 2015 16:45:37 -0000 On 11/2/2015 8:28 AM, Bob Briscoe wrote: > Joe, > > The point of my post was in response to: > > On 7/22/2015 09:52 AM, Joe Touch wrote: > >> I have students starting this fall who will look into this and do some tests. We have no information yet. > so they could go looking for the most likely place where there might be > problems. A little manual reading could give clues on where to look, to > save searching loads of Internet paths. > > You might even find someone has already probed for this supposed > 'vulnerability' (whether for research or for nefarious puposes), then > your student wouldn't have to do any work other than get their data, or > even just cite their paper. > > They could also search for phrases like "UDP Length Error" to find > source code that checks for this, then see what the code does and what > it is used in. > > I am just trying to make their job easier, so they can finish early and > perhaps do something more useful. Absolutely - thanks for the suggestion and pointers. Joe > > > > Here's some more links found in a few minutes of searching: > > These two show that by default checkpoint firewalls (very common) check > for consistency betw the two lengths. > Re: [FW-1] UDP length error > > Malformed Packet & UDP length error > > > This one shows that a cisco router checks the UDP length of HSRP Hello > packets is consistent before accepting it: > Cisco > Bug: CSCsc13766 - Both HSRP routers are active - UDP length error > > I'm not expecting comment on whether you think the alleged > vulnerabilities these firms are preventing exist, or whether they ought > to block such packets. I'm just saying they do. > > > Bob > > > On 02/11/15 15:24, Joe Touch wrote: >> We did find a few vendors that don't block those packets. >> >> On 11/1/2015 10:05 PM, Bob Briscoe wrote: >>> Joe, >>> >>> Before starting measurements, I would recommend searching the Web for >>> the manuals of middleboxes that might block such packets. >>> >>> For instance, with a quick search of "UDP header length inconsistency" I >>> found Alcatel-Lucent's "Brick" Intrusion Detection System blocks such >>> packets. >> Well, since "that which isn't prohibited ought to be permitted", IMO >> that' an error in their code. >> >>> Whether or not there is a buffer overflow vulnerability in any host, >> This would be an underflow issue, not an overflow one, FWIW. >> >> Joe >> >>> there will be firewalls and IDSs that block these packets in case >>> someone is probing for such vulnerabilities. >>> >>> >>> >>> bob >>> >>> On 14/08/15 19:35, C. M. Heard wrote: >>>> On 7/22/2015 09:52 AM, Joe Touch wrote: >>>>> 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. >>>> In an off-list e-mail exchange with Joe a couple of weeks ago, I noted >>>> that every host stack implementation whose code I have inspected simply >>>> ignores bytes that are past the UDP length but within the IP payload >>>> length. The BSD-derived stacks trim the excess bytes before the data >>>> is passed to the application via the sockets interface. However, one >>>> embedded stack I have seen (which does not use a sockets API) makes >>>> all data available to the application, including the UDP header, and >>>> lets the application deal with excess bytes as it sees fit. >>>> >>>> I have zero information on the behavior of middleboxes (NAT/NAPT). >>>> >>>> Assuming that Joe's tests confirm these observations for both end >>>> systems and middleboxes, then the proposed UDP option trailer should be >>>> incrementally deployable as long as all options therein can be safely >>>> ignored if not understood. The degree of utility (or, at least, the >>>> length of time needed to make them useful) will of course depend >>>> strongly on whether middleboxes trim the trailer or leave it intact; >>>> if the prevalent middlebox practice is to trim it, then they won't be >>>> useful without updating middleboxes as well as end systems. >>>> >>>> Also, Joe, if you and your students have the time and resources to >>>> look at >>>> what middleboxes do with UDP packets where the IP header indicates a >>>> shorter length than the UDP header, that would be useful information, >>>> as it >>>> could open up a possible means to incorporate fragmentation in the UDP >>>> layer, independent of whether or not an options trailer is present. >>>> >>>> Mike Heard >>>> >>>> >>>> >>>> >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoe http://bobbriscoe.net/ >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > From nobody Mon Nov 2 17:15: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 497131ACD72 for ; Mon, 2 Nov 2015 17:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 uuXEJAbeTAfy for ; Mon, 2 Nov 2015 17:15:37 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 F09521ACD58 for ; Mon, 2 Nov 2015 17:15:29 -0800 (PST) Received: by iodd200 with SMTP id d200so4804036iod.0 for ; Mon, 02 Nov 2015 17:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e7XQcWVlfAN7h2FOuAFDUntcJeKsLb3ez/r+DN4JjRI=; b=s8cGy5G3BJ6ZfawpjbKTdmnFhBxgkAAXXbipaXEr13yDv5Az4NarwyU3bT5jPDh6Jw 6tlJqyOztv7yCOgVAjRJHTQod639s4ZjpEquBAWqNU4gxrfbLXBu9AMjL2ycfvD5ebTr 7CbDMIAVJ1wb8MgDmPiShPRcRq9lmbPOBkaJ92GhlJEOaPJxtQEJBS9/VRnfFB4NBeMV t/I3TBWr+T0Y4D1ApHbqetevrhoEp4tbj1/rhqPkZ5nCfwdvJwxCJoexAwh/OSnaDi1Q ZQ2J0pJTUTdtNAN0zcGovzr9Gwp7TMwLEtLmSkVMm0zldmxB399AdQ/iyfpIUXrKfAkt wptg== 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=e7XQcWVlfAN7h2FOuAFDUntcJeKsLb3ez/r+DN4JjRI=; b=KjxCqMG4Ffz8wtHl2YDbvRGlcsipRH7l0szRqY/QcCL3zOWTGTUx8kjjRnspvQH8Am FMpEXqDPG3K+qkpY3/0m6o6/B8J6RldDvHGNFj7O4cPBu7gBcFdqbWclnanfCyRle3dM WDBczN2AuZikMYwYxBFqZwOwgrt0iQP/M18S+8QjjQc0doHl8rbFArTHU1tDB2AJTvOP 2IewaVmihsEjaV1nNmq85AkSxx02QoeLqhaDDmTVbtdoFDD89bQDGoI9ns0dl49Cpm1B Ys+hFV6FpWkUQrlD8pmuc7+HkOtFgx2hb19i59t6MThxPfhIJXerfpkGNYEb22+E9Fpf a/gQ== X-Gm-Message-State: ALoCoQlOH7KSXczIgwxbaeDsW+rNK+gGrSdRZyk0iOyvdeo3LDpNo3zezfhqzL2+g6HYAp+IpbH9 MIME-Version: 1.0 X-Received: by 10.107.156.81 with SMTP id f78mr28953946ioe.107.1446513329355; Mon, 02 Nov 2015 17:15:29 -0800 (PST) Received: by 10.107.41.83 with HTTP; Mon, 2 Nov 2015 17:15:29 -0800 (PST) In-Reply-To: <56378116.2050709@isi.edu> References: <5636FD40.4030101@bobbriscoe.net> <56378116.2050709@isi.edu> Date: Tue, 3 Nov 2015 10:15:29 +0900 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Bob Briscoe , tsvwg , spud 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: Tue, 03 Nov 2015 01:15:39 -0000 > We need to live without broken offloads because offloads are part of the > protocol stack. They can't simply jump in and try to help without being > very careful about corner cases like this. > > E.g., we've already seen an offload that merges TCP packets with > different options, which ought to be clearly inappropriate. > Checksum offload conforms to the requirements for host checksum field processing and Length field handling in RFC768 and RFC1122-- if this change maintains those requirements then there is no issue. It is not clear from the draft what the effect on checksum processing will be. My questions are: 1) What is the UDP payload length for number of bytes to checksum over? 2) What value is in the UDP length field when the checksum is performed? 3) What is the on-the-wire value of the UDP length field? If the use of UDP options is treated as a "truncation" of the UDP payload before the checksum calculation is performed then the answers to the above questions are the same and there is no incompatibility. The option bytes would not be covered by the UDP checksum however. Thanks, Tom From nobody Mon Nov 2 17:50:12 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 BA2FA1B2B9E; Mon, 2 Nov 2015 17:50:10 -0800 (PST) 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 SA-nTzLJdQjX; Mon, 2 Nov 2015 17:50:04 -0800 (PST) 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 4644F1B2BA6; Mon, 2 Nov 2015 17:50:04 -0800 (PST) Received: from [192.168.1.28] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tA31mt4J004493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Nov 2015 17:48:56 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Mon, 2 Nov 2015 17:48:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2C92D0E0-7269-4B53-9AA8-DB999597BBEA@isi.edu> References: <5636FD40.4030101@bobbriscoe.net> <56378116.2050709@isi.edu> To: Tom Herbert X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Bob Briscoe , tsvwg , spud 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: Tue, 03 Nov 2015 01:50:11 -0000 On Nov 2, 2015, at 5:15 PM, Tom Herbert wrote: >> We need to live without broken offloads because offloads are part of the >> protocol stack. They can't simply jump in and try to help without being >> very careful about corner cases like this. >>=20 >> E.g., we've already seen an offload that merges TCP packets with >> different options, which ought to be clearly inappropriate. > Checksum offload conforms to the requirements for host checksum field > processing and Length field handling in RFC768 and RFC1122-- if this > change maintains those requirements then there is no issue. >=20 > It is not clear from the draft what the effect on checksum processing > will be. My questions are: >=20 > 1) What is the UDP payload length for number of bytes to checksum over? The udp payload indicated by the udp length field, and the usual IP pseudohe= ader.=20 > 2) What value is in the UDP length field when the checksum is performed? The length before the trailer. =20 > 3) What is the on-the-wire value of the UDP length field? Same as #2 above. =20 >=20 > If the use of UDP options is treated as a "truncation" of the UDP > payload before the checksum calculation is performed It is.=20 > then the answers > to the above questions are the same and there is no incompatibility. > The option bytes would not be covered by the UDP checksum however. Correct. A separate "trailer checksum" would be required to protect the trai= ler.=20 Joe >=20 > Thanks, > Tom From nobody Mon Nov 2 18:05: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 E66DB1A1B5A for ; Mon, 2 Nov 2015 18:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 BrY6d3UYOj1H for ; Mon, 2 Nov 2015 18:04:56 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 E97FB1AC3FD for ; Mon, 2 Nov 2015 18:04:53 -0800 (PST) Received: by iody8 with SMTP id y8so5608302iod.1 for ; Mon, 02 Nov 2015 18:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qvKZYFUI8RsWlQdur33ahI+quC0WRjJnr5X371nRew0=; b=eDz5aE7anCZxd9CTlpxo0TSyiTB4MLAkygnT22hw2W8QZyoPG3Yed3OHswPcKh+RUM Eaz7G58yVj4pb29VTN8iOvgx1VucWxXi+oOpcP5DT2NsrDhFwoy+k+H3dfDrv52iXxO8 kZsUUI9JMN9pezwdsiP+mBSu3q5WFeepUMJjb6U2QTixX68bGpfFpJPd3iYT+Gi+Vt/5 S5V6iMbzwVGtkoUM2MED3LJSMQQhVRSjV16W4CZEaXevha/o8DWRLkBGE7i7xX8gjBIB XmmgldqcWF+kiIf816bmFAa9B2HLLN57tLHuao6R8vb+bIXM/cT5hPqTnZQHEwbYWbuR KQ8w== 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=qvKZYFUI8RsWlQdur33ahI+quC0WRjJnr5X371nRew0=; b=Vl+Mvl/wUU+JaeeBEhgaVZkzG6L2rxeQ9r+Wcm8PHlZQKfVJaHLYuCXvWDquFlBZaU RHtm7Ku0LA9s4pp3trQfRpDsP+1SXUSXUVrEgVzCoI7L5RM9vjRhgHy+Ir1/MuvZR97U zuEn9ImUrVO21SNHxczNZ5iFZnnJh/fXZhXHs4LFr/n5qrNWAhfWaMcTxkJZdZywtWp2 h9csOPE3sIJRQi/kIlEsqt32uxw+4Pfts/QUADKBuYVXSBMsqhCmqifM9RqV3WNie0Zn 79LPjx8KQHFWAzv/t8afXlGXHzYcSqN4xO9k+x0IZyWR2N4hD35aviBaYZItkdGe/fFk +OLw== X-Gm-Message-State: ALoCoQlZBQAiYJ41V3tIQJBYJp+sr+gdQojgchLhRcJw0ky3al4MrhvuuMNLYJbExij3I5RqowXl MIME-Version: 1.0 X-Received: by 10.107.31.138 with SMTP id f132mr26331336iof.84.1446516293226; Mon, 02 Nov 2015 18:04:53 -0800 (PST) Received: by 10.107.41.83 with HTTP; Mon, 2 Nov 2015 18:04:53 -0800 (PST) In-Reply-To: <2C92D0E0-7269-4B53-9AA8-DB999597BBEA@isi.edu> References: <5636FD40.4030101@bobbriscoe.net> <56378116.2050709@isi.edu> <2C92D0E0-7269-4B53-9AA8-DB999597BBEA@isi.edu> Date: Tue, 3 Nov 2015 11:04:53 +0900 Message-ID: From: Tom Herbert To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Bob Briscoe , tsvwg , spud 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: Tue, 03 Nov 2015 02:04:57 -0000 On Tue, Nov 3, 2015 at 10:48 AM, Joe Touch wrote: > > > On Nov 2, 2015, at 5:15 PM, Tom Herbert wrote: > >>> We need to live without broken offloads because offloads are part of the >>> protocol stack. They can't simply jump in and try to help without being >>> very careful about corner cases like this. >>> >>> E.g., we've already seen an offload that merges TCP packets with >>> different options, which ought to be clearly inappropriate. >> Checksum offload conforms to the requirements for host checksum field >> processing and Length field handling in RFC768 and RFC1122-- if this >> change maintains those requirements then there is no issue. >> >> It is not clear from the draft what the effect on checksum processing >> will be. My questions are: >> >> 1) What is the UDP payload length for number of bytes to checksum over? > > The udp payload indicated by the udp length field, and the usual IP pseudoheader. > >> 2) What value is in the UDP length field when the checksum is performed? > > The length before the trailer. > >> 3) What is the on-the-wire value of the UDP length field? > > Same as #2 above. > >> >> If the use of UDP options is treated as a "truncation" of the UDP >> payload before the checksum calculation is performed > > It is. > >> then the answers >> to the above questions are the same and there is no incompatibility. > >> The option bytes would not be covered by the UDP checksum however. > > Correct. A separate "trailer checksum" would be required to protect the trailer. > That's great. Can you add this description to the draft? One other question. In this model the options are really part of the IP payload and not the UDP payload (so presumably this solution is not UDP specific but can be applied to any protocol). Essentially this another way to extend IP and so it seems conceivable that these TLVs could alternatively be put into an IPv6 extension header to accomplish the same effect (at least for IPv6). Have you considered the tradeoffs for doing that? Thanks, Tom From nobody Mon Nov 2 23:40: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 6D1971A8886 for ; Mon, 2 Nov 2015 23:40:57 -0800 (PST) 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 zYLqrjaC_ieV for ; Mon, 2 Nov 2015 23:40:56 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id DE1481A7017 for ; Mon, 2 Nov 2015 23:40:55 -0800 (PST) Received: from dhcp-52-36.meeting.ietf94.jp (dhcp-52-36.meeting.ietf94.jp [133.93.52.36]) by trammell.ch (Postfix) with ESMTPSA id 95C0D1A0031 for ; Tue, 3 Nov 2015 08:40:54 +0100 (CET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <418C50B5-214C-4318-852F-8D59D0B7777F@trammell.ch> Date: Tue, 3 Nov 2015 16:40:46 +0900 To: spud@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Spud] Talking about SPUD in Yokohama 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, 03 Nov 2015 07:40:57 -0000 Greetings, all, The authors of draft-trammell-spud-req (well, some of us) will be in the = breakout room (513) from 9:00 to 11:00 tomorrow (Wednesday 4 November). = If you want to talk about the requirements for SPUD, drop by and talk to = us. Cheers, Brian= From nobody Tue Nov 3 07:46: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 2EF461A6F39; Tue, 3 Nov 2015 07:46:48 -0800 (PST) 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 Wv9RoVB4Mnez; Tue, 3 Nov 2015 07:46:43 -0800 (PST) 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 BD78B1A6F2F; Tue, 3 Nov 2015 07:46:42 -0800 (PST) Received: from [128.9.176.29] (c1-vpn3.isi.edu [128.9.176.29]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id tA3FjAga010133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2015 07:45:11 -0800 (PST) To: Tom Herbert References: <5636FD40.4030101@bobbriscoe.net> <56378116.2050709@isi.edu> <2C92D0E0-7269-4B53-9AA8-DB999597BBEA@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <5638D685.8040409@isi.edu> Date: Tue, 3 Nov 2015 07:45:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 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 , Bob Briscoe , tsvwg , 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: Tue, 03 Nov 2015 15:46:48 -0000 Hi, Tom, On 11/2/2015 6:04 PM, Tom Herbert wrote: > On Tue, Nov 3, 2015 at 10:48 AM, Joe Touch wrote: ... >> >>> The option bytes would not be covered by the UDP checksum however. >> >> Correct. A separate "trailer checksum" would be required to protect the trailer. >> > That's great. Can you add this description to the draft? Will do. > One other question. In this model the options are really part of the > IP payload and not the UDP payload Yes, basically. > (so presumably this solution is not > UDP specific but can be applied to any protocol). It requires a protocol that has a redundant length field. E.g., TCP does not, in fact few transport protocols do. > Essentially this > another way to extend IP I don't see that; IP declares a payload size and a protocol type. As far as IP is concerned the entire payload area belongs to the protocol type indicated. It's the protocol's decision how to handle that - for TCP, there's no separate length field (only a header length). For UDP, there's a *UDP payload* length, which means we can set it smaller than what IP has set aside and let *UDP* use the rest. > and so it seems conceivable that these TLVs > could alternatively be put into an IPv6 extension header to accomplish > the same effect (at least for IPv6). Have you considered the tradeoffs > for doing that? See above. Putting TLVs in the endpoint protocol is already commonly supported (TCP options are common). TLV parsing support for IPv6 has been much more difficult to come by in core routers. Joe From nobody Tue Nov 3 08:08:00 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 5DB571A01F4 for ; Mon, 2 Nov 2015 23:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wpLAE3hKAlgr for ; Mon, 2 Nov 2015 23:37:13 -0800 (PST) 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 9AC3B1A038C for ; Mon, 2 Nov 2015 23:37:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2CAFBD930D for ; Tue, 3 Nov 2015 08:37:12 +0100 (MET) 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 IWWN2j9HXbJk for ; Tue, 3 Nov 2015 08:37:12 +0100 (MET) Received: from dhcp-52-36.meeting.ietf94.jp (dhcp-52-36.meeting.ietf94.jp [133.93.52.36]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 82F13D9305 for ; Tue, 3 Nov 2015 08:37:09 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 3 Nov 2015 16:37:05 +0900 To: spud@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 08:07:59 -0800 Subject: [Spud] Talking about SPUD in Yokohama 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, 03 Nov 2015 07:37:15 -0000 Greetings, all, The authors of draft-trammell-spud-req (well, some of us) will be in the = breakout room (513) from 9:00 to 11:00 tomorrow (Wednesday 4 November). = If you want to talk about the requirements for SPUD, drop by and talk to = us. Cheers, Brian= From nobody Tue Nov 24 13:46: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 E0E851A8F46 for ; Tue, 24 Nov 2015 13:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.216 X-Spam-Level: X-Spam-Status: No, score=0.216 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585] 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 ZKd2WMMsM-Hy for ; Tue, 24 Nov 2015 13:46:27 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id EE85D1A8F45 for ; Tue, 24 Nov 2015 13:46:26 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 24 Nov 2015 16:46:29 -0500 From: Dave Dolson To: "spud@ietf.org" Thread-Topic: Crypto-security of SPUD Properties? Thread-Index: AdEnAZEJRa5bDsPLRgmkVQ1m6SXIMA== Date: Tue, 24 Nov 2015 21:46:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830DBDE51wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [Spud] Crypto-security of SPUD Properties? 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, 24 Nov 2015 21:46:30 -0000 --_000_E8355113905631478EFF04F5AA706E9830DBDE51wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was just reading the property binding section of https://tools.ietf.org/html/draft-trammell-spud-req-01.html#section-7.2 (Sorry, if this has been discussed) Is it intended that properties could be used to authoritatively indicate th= ings to the network? E.g., could network elements know with crypto-grade confidence that the ser= ver is an example.com server? I'm thinking of a use-case in which an server (at example.com) wants to pay= for a mobile user to receive content. The idea is that the user does not p= ay for the bits; the server pays. There are several reasons why the server might want to do so: - the price of purchased digital content (music, book, video) includes "fre= e delivery" - reversed-charges communication (along the lines of North American 1-800 = phone numbers) - delivery of advertising and promotional content. Obviously the mobile operator's charging device in the network wants to be = sure this property cannot be spoofed by other servers. I have some ideas about how the crypto would work. I don't know if those de= tails matter to SPUD, provided a property can crypto-sign a packet or tunne= l, something like an AH header. I think it might be possible to attach a property that is meaningless to an= y network device that a key hasn't been shared with. Does this seem like a reasonable thing to pursue in the context of SPUD? Is= there interest in adding this to the list of use-cases? David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830DBDE51wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was just reading the property binding section of <= o:p>

https://tools.ietf.org/html/draft-trammell-= spud-req-01.html#section-7.2

 

(Sorry, if this has been discussed)

 

Is it intended that properties could be used to auth= oritatively indicate things to the network?

 

E.g., could network elements know with crypto-grade = confidence that the server is an example.com server?

 

I’m thinking of a use-case in which an server = (at example.com) wants to pay for a mobile user to receive content. The ide= a is that the user does not pay for the bits; the server pays.

There are several reasons why the server might want = to do so:

- the price of purchased digital content (music, boo= k, video) includes “free delivery”

- reversed-charges communication (along the lines of= North American  1-800 phone numbers)

- delivery of advertising and promotional content.

 

Obviously the mobile operator’s charging devic= e in the network wants to be sure this property cannot be spoofed by other = servers.

 

I have some ideas about how the crypto would work. I= don’t know if those details matter to SPUD, provided a property can = crypto-sign a packet or tunnel, something like an AH header.

 

I think it might be possible to attach a property th= at is meaningless to any network device that a key hasn’t been shared= with.

 

Does this seem like a reasonable thing to pursue in = the context of SPUD? Is there interest in adding this to the list of use-ca= ses?

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_E8355113905631478EFF04F5AA706E9830DBDE51wtlexchp2sandvi_-- From nobody Tue Nov 24 16:08:37 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 903941AC3C5 for ; Tue, 24 Nov 2015 16:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.785 X-Spam-Level: X-Spam-Status: No, score=-14.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nErF_xTp1Qm4 for ; Tue, 24 Nov 2015 16:08:33 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B321E1AC3C4 for ; Tue, 24 Nov 2015 16:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8916; q=dns/txt; s=iport; t=1448410113; x=1449619713; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=jRVv0Y/SZo4DxknraH0rJcpgCCfBf7ulbR+MLZh37EU=; b=Sttp+QTP8bugjDgueX4cwjuSfSHJUYDDNzxL7HdDDf3CopxJIvbVus1H QMHpIRHa8HH4NvxfkYvVa2liFOuh8KjlesbFBGWhOd/w2bAnmf4pBtbLt acSthuQ85nVHi47tJOdnvQJvej22sPj24kYlhF1iNeSsTIoNmpw06aZgc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQDJ+lRW/5RdJa1egm5NU2+8KIIaA?= =?us-ascii?q?Q2BZyGFbgKBRDgUAQEBAQEBAYEKhDUBAQQjVhALDgoqAgJXBhOILg2tTJAmAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBGIZUghCCboRCRoJtL4EVBY4XiD6FJYgNgVtJh?= =?us-ascii?q?nuPR4NyHwEBQoQlHTQBAYUqAQEB?= X-IronPort-AV: E=Sophos; i="5.20,340,1444694400"; d="scan'208,217"; a="49834789" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Nov 2015 00:08:32 +0000 Received: from [10.24.97.248] ([10.24.97.248]) (authenticated bits=0) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tAP08Vmr002102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2015 00:08:32 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_BB04CCAB-A78B-4E44-B427-BC465FCA02E3" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Tue, 24 Nov 2015 16:08:31 -0800 Message-Id: <304335C3-C1F0-40E1-BC5E-EAB81B5B7B8F@cisco.com> References: To: Dave Dolson X-Mailer: Apple Mail (2.3096.5) X-Authenticated-User: dwing Archived-At: Cc: "spud@ietf.org" Subject: Re: [Spud] Crypto-security of SPUD Properties? 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, 25 Nov 2015 00:08:35 -0000 --Apple-Mail=_BB04CCAB-A78B-4E44-B427-BC465FCA02E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 24-Nov-2015 01:46 pm, Dave Dolson wrote:=20 > I was just reading the property binding section of=20 > = https://tools.ietf.org/html/draft-trammell-spud-req-01.html#section-7.2 = > =20 > (Sorry, if this has been discussed) > =20 > Is it intended that properties could be used to authoritatively = indicate things to the network? > =20 > E.g., could network elements know with crypto-grade confidence that = the server is an example.com server? > =20 > I=E2=80=99m thinking of a use-case in which an server (at example.com = ) wants to pay for a mobile user to receive = content. The idea is that the user does not pay for the bits; the server = pays. > There are several reasons why the server might want to do so: > - the price of purchased digital content (music, book, video) includes = =E2=80=9Cfree delivery=E2=80=9D > - reversed-charges communication (along the lines of North American = 1-800 phone numbers) > - delivery of advertising and promotional content. > =20 > Obviously the mobile operator=E2=80=99s charging device in the network = wants to be sure this property cannot be spoofed by other servers. > =20 > I have some ideas about how the crypto would work. I don=E2=80=99t = know if those details matter to SPUD, provided a property can = crypto-sign a packet or tunnel, something like an AH header. > =20 > I think it might be possible to attach a property that is meaningless = to any network device that a key hasn=E2=80=99t been shared with. > =20 > Does this seem like a reasonable thing to pursue in the context of = SPUD? Is there interest in adding this to the list of use-cases? This can be done with oauth, where the oauth "resource" is the network = resource such as bandwidth (to download a file) or performance (low = jitter or low delay for a game). Typically oauth is used when the = "resource" is your pictures stored on cloud service A and being made = accessible to cloud service B. -d --Apple-Mail=_BB04CCAB-A78B-4E44-B427-BC465FCA02E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 24-Nov-2015 01:46 pm, Dave Dolson <ddolson@sandvine.com> wrote:
I was just reading the = property binding section of 
https://tools.ietf.org/html/draft-trammell-spud-req-01.html#sec= tion-7.2
 
(Sorry, if this has been discussed)
 
Is it = intended that properties could be used to authoritatively indicate = things to the network?
 
E.g., could network elements know with crypto-grade = confidence that the server is an example.com server?
 
I=E2=80=99m= thinking of a use-case in which an server (at example.com) wants to pay for a mobile user = to receive content. The idea is that the user does not pay for the bits; = the server pays.
There are several reasons why the server might want to do = so:
- the = price of purchased digital content (music, book, video) includes =E2=80=9C= free delivery=E2=80=9D
- reversed-charges communication (along the lines of North = American  1-800 phone numbers)
- delivery of advertising and = promotional content.
 
Obviously the mobile operator=E2=80=99s charging device in = the network wants to be sure this property cannot be spoofed by other = servers.
 
I have some ideas about how the crypto would work. I don=E2=80=99= t know if those details matter to SPUD, provided a property can = crypto-sign a packet or tunnel, something like an AH header.
 
I think = it might be possible to attach a property that is meaningless to any = network device that a key hasn=E2=80=99t been shared with.
 
Does this = seem like a reasonable thing to pursue in the context of SPUD? Is there = interest in adding this to the list of use-cases?

This can be done with oauth, where the oauth = "resource" is the network resource such as bandwidth (to download a = file) or performance (low jitter or low delay for a game). =  Typically oauth is used when the "resource" is your pictures = stored on cloud service A and being made accessible to cloud service = B.

-d

= --Apple-Mail=_BB04CCAB-A78B-4E44-B427-BC465FCA02E3--