Re: [Stackevo-discuss] [tsvwg] [Stackevo] draft-byrne-opsec-udp-advisory

Joe Touch <touch@isi.edu> Fri, 24 July 2015 17:52 UTC

Return-Path: <touch@isi.edu>
X-Original-To: stackevo-discuss@ietfa.amsl.com
Delivered-To: stackevo-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD501A872B; Fri, 24 Jul 2015 10:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt6CiZI-Hz9P; Fri, 24 Jul 2015 10:52:54 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277111A8707; Fri, 24 Jul 2015 10:52:54 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6OHqEH2013101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Jul 2015 10:52:15 -0700 (PDT)
To: Dave Taht <dave.taht@gmail.com>
References: <CAD6AjGRA0-z6H9b2UEBSoOmkdmcVuCkfxhfaOuzZ2jgwLm+fZA@mail.gmail.com> <55AEED07.9080804@isi.edu> <CAD6AjGSgnSBo_RxMoecvMTvWGMQhv1CGu6Pc0gAes0zOBRB1Gg@mail.gmail.com> <EA4C43BE752A194597B002779DF69BAE23DB842D@ESESSMB303.ericsson.se> <DFB2C14B-9C6D-4393-A9B4-434D58C9DED7@trammell.ch> <CAD6AjGTuHwW+RY3hc6+DmY=T2RT847HZ_RNbNmByumc45zQ-8A@mail.gmail.com> <7CFB38B0-F4E9-4C49-AEA0-FFA3E5BD41B0@trammell.ch> <CAD6AjGQiBs6BTs5g10o3JBeNBaYywBwAiwi27sm8wfJ=Rg=Aiw@mail.gmail.com> <8916881C-11C8-43C8-9466-1261CD4AF878@trammell.ch> <55B2723C.4090203@isi.edu> <CAA93jw6jUp5_cXqz5xc1s-EuZamfaRXkbEX61oEAy0c7FEXgdg@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <55B27B4E.5030908@isi.edu>
Date: Fri, 24 Jul 2015 10:52:14 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAA93jw6jUp5_cXqz5xc1s-EuZamfaRXkbEX61oEAy0c7FEXgdg@mail.gmail.com>
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: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/qUN_G71el_8tGxIxCijEcZ5yHiU>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, touch@isi.edu, stackevo-discuss@iab.org, "draft-byrne-opsec-udp-advisory@tools.ietf.org" <draft-byrne-opsec-udp-advisory@tools.ietf.org>, Brian Trammell <ietf@trammell.ch>, Ca By <cb.list6@gmail.com>
Subject: Re: [Stackevo-discuss] [tsvwg] [Stackevo] draft-byrne-opsec-udp-advisory
X-BeenThere: stackevo-discuss@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IP Stack Evolution Discussion List <stackevo-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo-discuss/>
List-Post: <mailto:stackevo-discuss@iab.org>
List-Help: <mailto:stackevo-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2015 17:52:55 -0000

Hi, Dave,

Yes, I should have included UDPLite in the list below and it's a very
direct replacement for UDP when used as you indicate.

However, one goal of a transition out of UDP might be to include
integrated congestion control, for which either SCTP or DCCP would be a
better alternative.

It would be interesting to know if you've tested UDPLite through
consumer-grade NATs or across any CGNs - i.e., network devices that need
to keep transport-based state, not just firewalls.

Joe

On 7/24/2015 10:43 AM, Dave Taht wrote:
> I note that udplite is widely available, understood by bsd and linux,
> passed by at least a few firewalls, and if you don't use the reduced
> checksum feature, indistinguishable from udp... and one line of app
> code to use...
> 
> ... and widely underused. I did quite a bit of testing of it on ipv6
> paths, and even converted a few tools like mosh and netperf to use it
> for a while. Attempting to at least measure how well udplite gets
> around would be a starting place for a new protocol, and at least
> probing for the ability to use it in, say, quic might make some
> headway.
> 
> My overall objection, however, to a new connectionless protocol for
> "good udp applications" is that we had no idea how many crap udp
> applications we had at the time we wrote them.
> 
> On Fri, Jul 24, 2015 at 7:13 PM, Joe Touch <touch@isi.edu> wrote:
>> I'm left with the following questions:
>>
>> - if you want a new UDP protocol number, why not just us 33 (DCCP)?
>>
>> - if NATs would not be an issue to a new transport, why has it inhibited
>> all the recent attempts? (DCCP, SCTP)
>>
>> Although I appreciate the implications on TAPS for "do what I mean"
>> negotiation of alternate transports, TAPS doesn't solve either of the
>> issues above.
>>
>> AFAICT, they both highlight:
>>
>> a) why this is hard
>>
>> b) why this doesn't actually need a new IANA transport protocol codepoint
>>
>> Joe
>>
> 
> 
>