Subject: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-09.txt

From: Joe Touch <[email-masked]>
Date: Tue, 16 May 2017 15:20:07 -0700

Hi, all,

This version (09) includes changes to address DOS concerns raised by Tom
Herbert.

I would like the chairs to initiate a call for WG adoption, intended
towards Standards Track, updating RFC 786.

Joe

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-touch-tsvwg-udp-options-09.txt
Date: 	Tue, 16 May 2017 15:14:12 -0700
From: 	[email-masked]
To: 	Joseph Touch <[email-masked]>, Joe Touch <[email-masked]>

A new version of I-D, draft-touch-tsvwg-udp-options-09.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	09
Title:		Transport Options for UDP
Document date:	2017-05-16
Group:		Individual Submission
Pages:		27
URL:            https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-09.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-09
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-09
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-09

Abstract:
   Transport protocols are extended through the use of transport header
   options. This document experimentally extends UDP by indicating the
   location, syntax, and semantics for UDP transport layer options.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 May 2017 15:33:51 -0700

PS - I had forgotten to address multicast in this version.

I'm anticipating "SHOULD NOT" use in that case, except where you know
the receiver's capabilities via other means, but that too would be
subject to what the WG decides if adopted.

Joe

On 5/16/2017 3:20 PM, Joe Touch wrote:
>
> Hi, all,
>
> This version (09) includes changes to address DOS concerns raised by
> Tom Herbert.
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 16 May 2017 17:31:42 -0700

Joe,

>From the draft:

"[NOTE: Tom Herbert suggested we declare "more than 3 consecutive
NOPs" a fatal error to reduce the potential of using NOPs as a DOS
attack, but IMO there are other equivalent ways (e.g., using RESERVED
or other UNASSIGNED values) and the "no more than 3" creates its own
DOS vulnerability)"

RFC4942 discusses this for IPv6 options in "2.1.9.5.  Misuse of Pad1
and PadN Options".  PadN might also be nice to have in UDP options.

Tom

On Tue, May 16, 2017 at 3:20 PM, Joe Touch <[email-masked]> wrote:
> I would like the chairs to initiate a call for WG adoption, intended towards
> Standards Track, updating RFC 786.
>
> Joe
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-09.txt
> Status:
> https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-09
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-09
>
> Abstract:

---

From: Joe Touch <[email-masked]>
Date: Wed, 17 May 2017 10:33:49 -0700

Hi, Tom,

> and PadN Options".  PadN might also be nice to have in UDP options.

IMO, at best, PadN merely serves to eat an option codepoint.

At worst, PadN provides a covert channel (if not checked) or results in
nearly the same processing cost (if checked).

I don't like the idea of dropping "unusual" patterns - either a pattern
should be prohibited or allowed.

The biggest problem, AFAICT, is that these prohibitions all end up
amplifying the DOS impact, e.g., by requiring more checks during processing.

We can certainly discuss this further if others want, once this is
accepted as a WG document.

Joe