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

[Brian Trammell <[e-mail]>]

> On 10 Jun 2016, at 16:57, Tom Herbert <[e-mail]> wrote:
> 
>>> 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.

Reflecting off an echo server doesn't give you return routability.

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

You're raising an issue with any protocol that runs over UDP in an Internet with echo servers in it, and my understanding is the arrangement you're proposing here is:

ip
 (EH for path exposure)
udp
  dtls
     (new protocols)

whereas the one I think works is:

ip
udp
  plus for path exposure
    dtls
      (new protocols)

I don't see how these are any different with respect to how they have to handle the echo server attack. What am I missing here?

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

My impression is that HBH options were being more or less deprecated, because they're largely unimplementable in hardware, due to unpredictable header chain lengths and header chain walking time. Am I incorrect here?

(FWIW, sticking this in UDP makes it possible to provide constant offsets when no extension headers are in use and when the superstrate uses the path MTU correctly.)

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

Good to know; this makes this idea more deployable. :)

Regards,

Brian

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