Re: [tsvwg] Regarding DTLS and UDP options

Tom Herbert <tom@herbertland.com> Mon, 17 April 2017 20:29 UTC

Return-Path: <tom@herbertland.com>
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 18B56129462 for <tsvwg@ietfa.amsl.com>; Mon, 17 Apr 2017 13:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 bBGD959aRfnO for <tsvwg@ietfa.amsl.com>; Mon, 17 Apr 2017 13:29:30 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 22B8F128C82 for <tsvwg@ietf.org>; Mon, 17 Apr 2017 13:29:30 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id f133so114265843qke.2 for <tsvwg@ietf.org>; Mon, 17 Apr 2017 13:29:30 -0700 (PDT)
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:from:date:message-id:subject:to :cc; bh=sZ1s4CrxgxYh6iPR/EmOoABcoldrgVs+FVzUSkBaT60=; b=bZmndVb7X4j7j9h1TfFYRNL3L+uj1DfqIJbG1cA93fvB/69C5OxQiym7hJKtV/9Uxv 14B07hekAi41HhzEImoBFmXPnTfPMGk1Dr36Ygo38NxLr8ZogPxAREguLf5c+Sxvyb4u vePGZ4PzHXYeCDt8oujihpNwKW+yFx/ZWCbw1B2hu0FE6kpEFW+gDIlaKJOZZXzy8B+D J68GUFcNNeEK3zXyq7doLZFpP7K3gdzP2TgS0P8G9Gck3zM8Qu4yfR3zlLX9KXfzwqV/ zm8o38xwnq583dYsyvkOjuDQudF0QdWAEFEuhKRSGJ6Cp8RuIfwsB2YcZEXxfdX9dxZM q6LA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sZ1s4CrxgxYh6iPR/EmOoABcoldrgVs+FVzUSkBaT60=; b=ju7j1JYS0TdpnywQ79VJlGLF7OsSlQ5O3D2lhW0xMvnOaBJ8I65CuWt5wgYY2Fy6qk V2jq+BUstw1J2/OAc8/hnOk7LyO6bRxEfSroPw/P3lLMgQAuAGbz9bMGGFcyluRCpYBO X7DA2N2n/GaI4arKv4JCbWwCeWL1+/SRsvedadwd4lJbRtpgXO7xr7jGcwYlVC59uGeZ lngyomKbawCPyxddzp08tvsJDfEq66vUW3LCImE0mliMWXGAT6pWTDmsxKtMd9mOqKQF KNevd7NSMZrE01X9Jh0w6eKPZCqTUOPRJmmYzkazEGfECQYX/k5wf+rrSj7nAx8TP9jQ RCOg==
X-Gm-Message-State: AN3rC/6fLQQk1w00mJcbZITDAdw7yzfHDNu7TVF1mBE+qEM7BRpjroIX UZvLPFEmLOUTHdoEqkpUicUIPXG8fg==
X-Received: by 10.55.20.145 with SMTP id 17mr9826626qku.244.1492460969139; Mon, 17 Apr 2017 13:29:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Mon, 17 Apr 2017 13:29:28 -0700 (PDT)
In-Reply-To: <a0f656e8-e847-db54-6046-2078364d428b@isi.edu>
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>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 17 Apr 2017 13:29:28 -0700
Message-ID: <CALx6S36HYHdbGoJHNb+mVY6reu9RLikLxDJqrPgwO9tF1EfSgQ@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/YXQC_gZ6hOZ2CfaDcYE2_s34sHI>
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:29:32 -0000

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? 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.

One thing that might be missing from the draft is middle box handling.
I suspect your intent is that options are meant only for end to end
consumption and so middleboxes must pass packets with UDP options,
should not attempt to parse the UDP options, and must not modify
options.

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
>