Re: [Spud] endpoint control

[Brian Trammell <[e-mail]>]

> On 27 Jun 2016, at 12:06, Youjianjie <[e-mail]> wrote:
> 
> Hi Brian,
> 
> Further comments below:
> 
> Thanks,
> Jianjie
>> -----邮件原件-----
>> 发件人: Brian Trammell [mailto:[e-mail]]
>> 发送时间: 2016年6月23日 17:16
>> 收件人: Youjianjie
>> 抄送: Aaron Falk; spud
>> 主题: Re: [Spud] endpoint control
>> 
>> 
>>> On 23 Jun 2016, at 10:55, Youjianjie <[e-mail]> wrote:
>>> 
>>> Hi Brian,
>>> 
>>> Thanks for the reply.
>>> 
>>>> I think at this point mechanisms for *establishing* these
>>>> relationships are out of scope for a future PLUS WG (at least, they
>>>> were left out of the charter deliberately), since we're really
>>>> talking about the design of new multiparty cryptographic protocols.
>>>> But I notice that the mechanism we're discussing here two primitives
>>>> (provide information to the path that at least the remote endpoint
>>>> can verify is authentic, retrieve information from the path with sender
>> permission) on top of which such protocols could be designed.
>>> 
>>> (1) If the information is provided to the path, why the remote endpoint
>> needs to verify authentic? Is this information also useful for the remote
>> endpoint?
>> 
>> It may be; one could envision future transports over PLUS where part of the
>> header is exposed but integrity protected, and the rest is encrypted. Integrity
>> protection of the PLUS-exposed information reduces redundancy in the
>> encrypted headers in this case.
>> 
>> The other reason to do this is to detect and react to unauthorized meddling in
>> the PLUS header: this would appear as an error to the receiver's transport layer,
>> which could then reset the connection. In this way the receiver acts as the
>> verifier on behalf of all devices on path.
> 
> Here, does the unauthorized meddling means "type or length" of the reserved space in the PLUS header is modified by the middle-box? However if "content" of the reserved space is modified, it is reasonable?

The reserved space is in this case intended to be modified by on-path devices. If we lived in a world in which it was reasonable to assume that we could exchange keys with and maintain certificates for every potential middlebox on path, we could use that cryptographic context to verify this information. But we don't, so we can't. Building multiparty cryptographic protocols that would be suited to this sort of thing is an area of open research; once designed, such a thing could run on top of this unprotected facility provided by PLUS.

> So if the sender wants some information from path, it should specify the type and length first in the header, then path fills the content accordingly. If the information is verified by the receiver, it will be signaled back to the sender by the receiver.

Precisely.

Cheers,

Brian

> 
>>> (2) Even if the retrieved information from the path with sender permission,
>> the receiver cannot verify the information (i.e. content) is authentic?
>> 
>> Correct.
>> 
>> Cheers,
>> 
>> Brian
>> 
>>> Thanks,
>>> Jianjie
>>> 
>>>> -----邮件原件-----
>>>> 发件人: Spud [mailto:[e-mail]] 代表 Brian Trammell
>>>> 发送时间: 2016年6月23日 16:11
>>>> 收件人: Youjianjie
>>>> 抄送: Aaron Falk; spud
>>>> 主题: Re: [Spud] endpoint control
>>>> 
>>>> 
>>>>> On 23 Jun 2016, at 10:03, Youjianjie <[e-mail]> wrote:
>>>>> 
>>>>> Hi Brian,
>>>>> 
>>>>> I'm wondering how the endpoint verifies the information provided by
>>>>> the
>>>> device on path?
>>>> 
>>>> In the basic mechanism I've outlined here, it doesn't. If there
>>>> exists some relationship between the endpoint and the device on path,
>>>> then the information provided with in the PLUS header can itself be
>>>> MAC'd with a key exchanged when that relationship is established.
>>>> 
>>>>> Is it also assumed that the key is provided by the superstrate
>>>>> transport
>>>> between the device on path and the endpoint?
>>>> 
>>>> No, that doesn't really make any sense, because the transport is
>>>> end-to-end (as was the original intent of the network/transport layer
>>>> separation). Any key for authenticating and verifying
>>>> endpoint-provided information would have to reside in the PLUS layer on
>> the endpoint.
>>>> 
>>>> I think at this point mechanisms for *establishing* these
>>>> relationships are out of scope for a future PLUS WG (at least, they
>>>> were left out of the charter deliberately), since we're really
>>>> talking about the design of new multiparty cryptographic protocols.
>>>> But I notice that the mechanism we're discussing here two primitives
>>>> (provide information to the path that at least the remote endpoint
>>>> can verify is authentic, retrieve information from the path with sender
>> permission) on top of which such protocols could be designed.
>>>> 
>>>> Cheers,
>>>> 
>>>> Brian
>>>> 
>>>>> Thanks,
>>>>> Jianjie
>>>>> 
>>>>>> -----邮件原件-----
>>>>>> 发件人: Brian Trammell [mailto:[e-mail]]
>>>>>> 发送时间: 2016年6月22日 18:45
>>>>>> 收件人: Youjianjie
>>>>>> 抄送: Aaron Falk; spud
>>>>>> 主题: Re: [Spud] endpoint control
>>>>>> 
>>>>>> 
>>>>>>> On 22 Jun 2016, at 11:35, Youjianjie <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hi Brian,
>>>>>>> 
>>>>>>> Thanks for your prompt reply. Please see my comments below:
>>>>>>> 
>>>>>>>> -----邮件原件-----
>>>>>>>> 发件人: Brian Trammell [mailto:[e-mail]]
>>>>>>>> 发送时间: 2016年6月22日 16:56
>>>>>>>> 收件人: Youjianjie
>>>>>>>> 抄送: Aaron Falk; spud
>>>>>>>> 主题: Re: [Spud] endpoint control
>>>>>>>> 
>>>>>>>> hi Jianjie,
>>>>>>>> 
>>>>>>>>> On 22 Jun 2016, at 09:09, Youjianjie <[e-mail]>
>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Brian,
>>>>>>>>> 
>>>>>>>>> (1) For forward signaling, the sending endpoint must place
>>>>>>>>> "scratch space" in
>>>>>>>> the packet with a label on it stating that it's okay to modify;
>>>>>>>> this okay-to-modify state is enforced by a MAC which only
>>>>>>>> verifies the length but not the content of the scratch space.
>>>>>>>>> 
>>>>>>>>> Could you please elaborate how a MAC is used to enforce the
>>>>>>>>> okay-to-modify
>>>>>>>> state? Is it only applicable to L2 network?
>>>>>>>> 
>>>>>>>> Sorry, acronym collision. Here MAC = message authentication code,
>>>>>>>> not medium access control.
>>>>>>>> 
>>>>>>>>> Is it a designed field in the PLUS header?
>>>>>>>> 
>>>>>>>> There isn't a "PLUS header" yet; we're only talking about
>>>>>>>> potential mechanisms that could be implemented within one. Here,
>>>>>>>> the idea is that you have some encoding that allows you to place
>>>>>>>> labeled data in the PLUS header (from the SPUD prototype
>>>>>>>> experience, we like CBOR, but this is a technical detail).
>>>>>>>> 
>>>>>>>> Some of the types/keys in this data structure are designated
>>>>>>>> end-to-end, and some of the types/keys are designated
>> path-modifiable.
>>>>>>>> 
>>>>>>>> The MAC is generated by the sending endpoint using a secret
>>>>>>>> shared by both endpoints, and covers:
>>>>>>> 
>>>>>>> How is the secret shared between both endpoints? The endpoints
>>>>>>> need to
>>>>>> establish a connection to exchange keys?
>>>>>> 
>>>>>> Yes. This is assumed to be provided by the superstrate transport.
>>>>>>> 
>>>>>>>> (1) the presence and content of end-to-end PLUS header
>>>>>>>> information
>>>>>>> 
>>>>>>> Do you mean that this information is encrypted using the shared secret?
>>>>>> Only both endpoints can know the content?
>>>>>> 
>>>>>> No, the MAC is generated using the shared secret, so that it cannot
>>>>>> be forged by on-path devices. The information itself is in the clear.
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> Brian
>>>>>> 
>>>>>>>> (2) the presence and length of path-modifiable PLUS header
>>>>>>>> information, by treating the content as a length-N byte array of zeroes.
>>>>>>> 
>>>>>>> How does the middle-box along the path interpret the PLUS header?
>>>>>>> Does
>>>>>> the middle-box also need the secret? I used to think middle-box is
>>>> transparent.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Jianjie
>>>>>>> 
>>>>>>>> This MAC is then transmitted from the sender to the receiver in
>>>>>>>> encrypted form.
>>>>>>>> 
>>>>>>>> Additional MACs may also protect bits of the IP and UDP header,
>>>>>>>> in order to detect NAT and other sub-PLUS modifications, but
>>>>>>>> these are outside the scope of this question.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> 
>>>>>>>> Brian
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Jianjie
>>>>>>>>> 
>>>>>>>>> 发件人: Spud [mailto:[e-mail]] 代表 Brian Trammell
>>>>>>>>> 发送时间: 2016年6月21日 17:36
>>>>>>>>> 收件人: Aaron Falk
>>>>>>>>> 抄送: spud
>>>>>>>>> 主题: Re: [Spud] endpoint control
>>>>>>>>> 
>>>>>>>>> hi Aaron,
>>>>>>>>> 
>>>>>>>>> On 06/20/2016 11:38 PM, Aaron Falk wrote:
>>>>>>>>> Hi Brian-
>>>>>>>>> 
>>>>>>>>> In the charter and the draft-trammel-spud-req it says
>>>>>>>>> 
>>>>>>>>> Both endpoint-to-path and path-to-endpoint signaling happen
>>>>>>>>> completely under endpoint control.
>>>>>>>>> 
>>>>>>>>> Without additional elaboration, one could conclude that, e.g.,
>>>>>>>>> permission is
>>>>>>>> required before a path could signal to an endpoint.
>>>>>>>> Alternatively, it could be implying an endpoint has the freedom
>>>>>>>> to ignore any signaling
>>>>>> from the path.
>>>>>>>> I have been assuming the latter.  But now I wonder if you are
>>>>>>>> intentionally attempting to permit the former.  Could you clarify?
>>>>>>>>> 
>>>>>>>>> Our intention is the former: that permission is required before
>>>>>>>>> the path can
>>>>>>>> signal to the endpoint. We have two mechanisms we've been
>>>>>>>> thinking about for this:
>>>>>>>>> 
>>>>>>>>> (1) For forward signaling, the sending endpoint must place
>>>>>>>>> "scratch space" in
>>>>>>>> the packet with a label on it stating that it's okay to modify;
>>>>>>>> this okay-to-modify state is enforced by a MAC which only
>>>>>>>> verifies the length but not the content of the scratch space.
>>>>>>>>> 
>>>>>>>>> (2) For direct reverse signaling, a path element may not send a
>>>>>>>>> direct reverse
>>>>>>>> signaling packet to a sender unless it has also dropped a forward
>>>>>>>> packet from the sender to receiver. This second mechanism is less
>>>>>>>> about permission and more about reducing the attractiveness of
>>>>>>>> PLUS for amplification/reflection attacks.
>>>>>>>>> 
>>>>>>>>> In any case, endpoints (and path elements) can ignore whatever
>>>>>>>>> they want to
>>>>>>>> from the PLUS-exposed information; it's what's in the encrypted
>>>>>>>> transport layer headers that matters to the transport protocol on
>>>>>>>> the
>>>>>> endpoint.
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> 
>>>>>>>>> Brian
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> 
>>>>>>>>> —aaron
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Spud mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/spud
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>>> _______________________________________________
>>> Spud mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spud
>