Re: [Spud] endpoint control

[Brian Trammell <[e-mail]>]

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

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