Re: [Spud] endpoint control

[Brian Trammell <[e-mail]>]

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:

(1) the presence and content of end-to-end PLUS header information
(2) the presence and length of path-modifiable PLUS header information, by treating the content as a length-N byte array of zeroes.

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
>