Re: [Spud] updated draft PLUS charter, rev. 1 June

Tom Herbert <tom@herbertland.com> Fri, 10 June 2016 14:57 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E01812D618 for <spud@ietfa.amsl.com>; Fri, 10 Jun 2016 07:57:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 iNbpLOEmffGU for <spud@ietfa.amsl.com>; Fri, 10 Jun 2016 07:57:47 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 E0FC612D0A9 for <spud@ietf.org>; Fri, 10 Jun 2016 07:57:46 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id e5so12286333ith.0 for <spud@ietf.org>; Fri, 10 Jun 2016 07:57:46 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=8yWqqe5at/6zp3Rg/y0Ok03E+H0v/EVfwlFlIggIYjs=; b=HyOPdyGwfcvOMNZA3Z9s2VvOC0yn7qGHd/K7kEYzmwMG9PIWJD+SXo7F/0zoEMDOvR Q83k+C/BGohJIKvkZRxPOJZPhjc12JSQhPEvR02EwxXNFEYsgMrGYJeSJE882qI93+A9 YwrBkvBCayhwjmEG4Ec7F6B7Sgkb3QZBuyWfKqOSqhAA0ZlBxBe5VagwTJseG7mY4kHh RaM5K3X+hJlA8BpMlSSYJe9oObGUhQ8VYkXNnKV79P26ikFaNL1T/qpgUNGSPl4ktypC kDWHUWCI480+iCqHk37xMPJ2sGJ2UKEaA11xRO0ZITWfAkxX8Gv6PDrJKrn3e/JVPh6a bfuw==
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-transfer-encoding; bh=8yWqqe5at/6zp3Rg/y0Ok03E+H0v/EVfwlFlIggIYjs=; b=MU1D5k1sTIdrlqS9ENLOIUPgbT6yQ1AVafa6EwbWLA7BYk9eABFmj30ZVstmdwKqAM zeN/HmRbaXkVEOJBa5dLYayg90Qj/Z/vrg99Zmyd/w1iPxKhdtf11M/95hj98v6vOlDx huwISqtOH6ffVua4vhhwn+3Eny0ledPshVB6tY8Q71Ub/H3V2LhsfMVrMLMAuyf4mZrJ WHdD5/DBwgUxI6xxbX2UCFyfnuP7IuH7r3eGc7xhrc/WLurQJrP8mCs3zwEJ+kLMLYjB /xxZ2QTM0SPdAo4lLYRc2Lnyeq4l2gozmkrh3CWiJrZlCfAuJBIctyUZurjXJq9hD3Km dPQA==
X-Gm-Message-State: ALyK8tJwlyb842ohP/Fj3/3NBcUPy0PeaHkb2PfdIcRfIfxasHsVUJ5USHLDJNWdROgD5Vlb3/WkARgC+YXxyQ==
MIME-Version: 1.0
X-Received: by 10.36.66.68 with SMTP id i65mr32254372itb.91.1465570666098; Fri, 10 Jun 2016 07:57:46 -0700 (PDT)
Received: by 10.107.31.202 with HTTP; Fri, 10 Jun 2016 07:57:45 -0700 (PDT)
In-Reply-To: <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch>
References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <CAD62q9UiLi1ffGPm=xEXOSH=sqZPv7hYiNBTGvAX52a9dhV8yg@mail.gmail.com> <CAD62q9U7XL8hDqY1VdzuvUvoz0Ec5DDLAS6=kaLxRExu7FY0Kg@mail.gmail.com> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <A4C63A75-9D7E-430E-B986-9981FB929D46@gmail.com> <CA+9kkMBhJ2oCJ1avnGUY4NYTX0VWA_g=YoJSiLcy6u9hJnH-eA@mail.gmail.com> <57573DCF.1030402@isi.edu> <F6BE4EE1-D320-421E-9D86-2F30B2A88792@tik.ee.ethz.ch> <CALx6S35Z7iEp2F7+1PHzAe0qu9st_CNXB9GCzF278HehFiv0Qg@mail.gmail.com> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <CALx6S35KXOioEK60p-m5tGE_H9MWbB=YhJ_sOcW0KP2vR80vvw@mail.gmail.com> <57574C38.6070402@isi.edu> <F44FFD3B-CE7E-45E8-9F04-233C56CA95A0@trammell.ch> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <CALx6S34jbmaV7vAxr1+-p2HW9i2oKv7Bb138MzsaP71zVh=PQw@mail.gmail.com> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch>
Date: Fri, 10 Jun 2016 07:57:45 -0700
Message-ID: <CALx6S37uONysFMNJgUs430eFEUuNTMuhcYKtCPBPMs5W6godVQ@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
To: Brian Trammell <ietf@trammell.ch>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/9wPQ-CMqsjla4mdbpWyAdDA69PA>
Cc: spud <spud@ietf.org>
Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jun 2016 14:57:48 -0000

>> This also potentially creates new attack vectors. Consider that an
>> attacker sends a well formed PLUS packet to a server running a UDP
>> Echo Protocol (RFC862). The server will happily reflect the data in a
>> UDP packet so that devices in the network now thinks it sees a PLUS
>> packets being sent from the server-- this is not correct.
>
> I'll point out that the operational error here is connecting a server running Echo to the Internet; it might be that there's lots of echo running out there that people don't care about because its amplification factor is a bit crap, though. And this attack doesn't work against a PLUS that meets requirement 6.6 in the spud-req draft.
>
Regardless of what we think of  Echo Server, it is a standard and it
is legitimate to deploy it on the Internet (DOS concerns can be
mitigated by rate limiting). Anti address spoofing does not help since
nothing is being spoofed, all address are properly routable, without
any sort of authentication between senders and network devices I don't
that there is anything we can put into in the UDP payload to resolve
this issue.

> I don't see how any of this is germane to the PLUS-in-UDP versus PLUS-in-DO question though.

Robustness, correctness, and security are germane to any discussion of
a proposed protocol.
>
>> Note that EH does not have these issues since IP protocol numbers have
>> global and unambiguous meaning. If an IPv6 packet contains 60 in a
>> next header field, then that next header may always be parsed to be
>> destination options.
>
> Using DO to communicate with middleboxes is also not really all that proper -- "destination" is IMO always distinct from "path" -- but since I'm basically saying we need to add a new layer to the stack on top of UDP headers, I probably shouldn't be talking about "proper". :)
>
I was not suggesting DO that was only an example of the invariant
property that IP protocol numbers have and UDP port numbers don't.
Hop-by-hop options are probably more appropriate for signaling to/from
network.

> So, this is all well and good; a little digging in ip6(7) and sendmsg(2) seems to indicate that I can at least get and set these with the IPV6_DSTOPT socket option, at least on Linux, but the types involved are still unclear from the documentation. I still think getting this right in a cross-platform way tends to indicate an over-UDP implementation. But that's an engineering question.
>
AFIACT all the major OSes (Linux, WIndows, IOS, BSDs) implement the
APIs in RFC3542. The caveat is that sending of particular options by
an unprivileged user can be restricted. As options are defined and
shown to be safe to use by unprivileged user they can be whitelisted
and allowed.

Tom

> Cheers,
>
> Brian
>>
>