Re: [tsvwg] Regarding DTLS and UDP options

Joe Touch <touch@isi.edu> Mon, 17 April 2017 20:35 UTC

Return-Path: <touch@isi.edu>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5419F12945D for <tsvwg@ietfa.amsl.com>; Mon, 17 Apr 2017 13:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 6Y0Njo93FBKB for <tsvwg@ietfa.amsl.com>; Mon, 17 Apr 2017 13:35:02 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 6E4BD12785F for <tsvwg@ietf.org>; Mon, 17 Apr 2017 13:35:02 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3HKYJ3v008412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Apr 2017 13:34:20 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>
References: <CACL_3VFeJs7KzG9Bchh15bfZ3CmaOPWcfisEreNoGYK5CsEJ+g@mail.gmail.com> <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <CACL_3VFkr3mGe-yTbvHrTZcKVCpEv3FeSOyoShUxCK5+9Tdqqg@mail.gmail.com> <c79fe3d0-8567-ea7d-72fc-bd33732df60e@isi.edu> <CACL_3VHmoCSo23OWqQFq7upw749CqMK7iazXrBKZARzwbzY5mw@mail.gmail.com> <f97f08d4-0070-437a-e22a-8782497c76eb@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <a0f656e8-e847-db54-6046-2078364d428b@isi.edu> <CALx6S36HYHdbGoJHNb+mVY6reu9RLikLxDJqrPgwO9tF1EfSgQ@mail.gmail.com>
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>
From: Joe Touch <touch@isi.edu>
Message-ID: <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu>
Date: Mon, 17 Apr 2017 13:34:18 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CALx6S36HYHdbGoJHNb+mVY6reu9RLikLxDJqrPgwO9tF1EfSgQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: v3HKYJ3v008412
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/AJXUMEIUzhYfhkB8wG3xdMVKXRU>
Subject: Re: [tsvwg] Regarding DTLS and UDP options
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Apr 2017 20:35:04 -0000


On 4/17/2017 1:29 PM, Tom Herbert wrote:
> On Mon, Apr 17, 2017 at 12:11 PM, Joe Touch <touch@isi.edu> wrote:
>> FYI - draft 08 has just been uploaded to address this issue in the
>> security considerations section.
>>
>> I would like to ask that the chairs to ask the WG to consider adopting
>> this as a standards track doc.
>>
> Joe,
>
> The draft lists intended status as experimental, but above you're
> asking for adoption for standard track? 

That's correct.

> I would be worried about
> making this standard if it retroactively defines all cases where IP
> length is greater than UDP length as now containing UDP options.

It does exactly that, but has checksums to validate when that happens.

>
> One thing that might be missing from the draft is middle box handling.
This is already discussed extensively in the document, including in
response to previous TSVWG discussion. That's why we now default to
using the OCS and a length validation. Do you have specific concerns?

> I suspect your intent is that options are meant only for end to end
> consumption 

That's frankly true of all transport options, not just these in UDP.

> and so middleboxes must pass packets with UDP options,
> should not attempt to parse the UDP options, and must not modify
> options.
We already addressed that in the doc.

Joe

>
> Tom
>
>> Joe
>>
>> A new version of I-D, draft-touch-tsvwg-udp-options-08.txt
>> has been successfully submitted by Joe Touch and posted to the
>> IETF repository.
>>
>> Name:           draft-touch-tsvwg-udp-options
>> Revision:       08
>> Title:          Transport Options for UDP
>> Document date:  2017-04-17
>> Group:          Individual Submission
>> Pages:          25
>> URL:            https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-08.txt
>> Status:         https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
>> Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-08
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-08
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-08
>>
>>
>> On 4/17/2017 1:59 AM, Gorry Fairhurst wrote:
>>> Thanks Joe,
>>>
>>> That seems to be exactly the question the WG asked to explore. I agree
>>> your next update should add a small susbsection on how DTLS should be
>>> handled.
>>>
>>> Gorry
>>>
>>> On 15/04/2017, 00:56, Joe Touch wrote:
>>>> Hi, all,
>>>>
>>>> Christian Huitema a question about the interaction between DTLS and UDP
>>>> options during my remote presentation at IETF 98.
>>>>
>>>> I took a closer look and consulted with Eric Rescorla (DTLS author). He
>>>> and I agreed as follows:
>>>> - DTLS would currently not cover UDP options; DTLS protects only the UDP
>>>> payload
>>>> - the situation is analogous to TCP options, which are not covered by
>>>> TLS
>>>> I.e., both TLS and DTLS are transport *payload* security only, despite
>>>> their names.
>>>>
>>>> Christian noted that this may be a reason QUIC prefers UDP (to avoid the
>>>> need to protection transport options), however QUIC does not (and
>>>> cannot) deprecate UDP payloads that are smaller than the IP payload.
>>>> That would require a change to RFC 768.
>>>>
>>>> I'll add a clarification on this point to the next rev of the UDP
>>>> options document.
>>>>
>>>> Joe