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

[Brian Trammell <[e-mail]>]

Hi Joe, all,

Inline...

> On 08 Jun 2016, at 00:35, Joe Touch <[e-mail]> wrote:
> 
>> On 6/7/2016 3:19 PM, Tom Herbert wrote:
>>> On Tue, Jun 7, 2016 at 3:09 PM, Joe Touch <[e-mail]> wrote:
>>> 
>>>> On 6/7/2016 3:05 PM, Tom Herbert wrote:
>>>> The proper architectural solution is to place network layer
>>>> information like what is being proposed in the network layer :-)
>>>> Trying to make a network layer out of UDP fails on several accounts
>>>> (fragments don't contain UDP headers, ports do not have global
>>>> meaning, etc.). IPv6 extension headers are designed for carrying
>>>> information like this, I really hope there is more investigation as to
>>>> whether they are workable for signaling.

I know that Jen Linkova has done some measurement work on this with respect to on-path treatment; I forget the conclusions. Of course that leaves the question of userspace implementation open.

>>> It depends on what layer is actually doing the signaling. If it's
>>> on-path, I agree - that's network layer and should be somewhere besides
>>> the transport header. If'it's on-path but not from the endpoint it also
>>> begs the question of whether IP packet headers should be extended
>>> in-transit (I made the case long ago that this was valid for IPv6 but I
>>> think someone is working to close that loophole or already has).
>> There has been a long discussion in 6man for 2460bis as to whether
>> IPv6 extension headers can be added by middelboxes. The consensus
>> seems to be that is it not allowed primarily because such actions
>> change the size of the packet and hence mess up PMTU discovery. I
>> would think this rationale must apply if devices are allowed to change
>> UDP payload in flight. Devices should never increase the size of a
>> packet, if they wish to add information to a packet for transit across
>> one network then encapsulation is a good alternative.
> 
> Encapsulation doesn't magically solve the PTMU problem.
> 
> The only solution is to reserve space - e.g., for the IPv6 header to
> have included "NOP" or other variants of reserved space that can be
> overwritten.

In the earlier thread on how to enforce endpoint control over what middleboxes can say and when, this is the solution we foresaw: reserved space in the PLUS header whose type and length are MAC'd, but the content not (probably implemented as a MAC over a fixed-length array of zeroes), this treatment being a property of the type.

> UDP payloads should NEVER be modified in flight. Only the end system or
> its designee should ever do so.

In this pattern, the end system explicitly designates the set of PLUS-speaking devices on path to modify that value, in accordance with the type's definition.

> I sincerely hope we end up assuming DTLS
> or some such to ensure that this is the case.

That's my assumption.

I've been thinking of this in terms of a MAC using a key negotiated by the superstrate's crypto layer, which I assume is DTLS. But if we limit superstrates to those over DTLS, we can just use DTLS directly for this.

Cheers, 

Brian