[Spud] 答复: endpoint control

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? Is it a designed field in the PLUS header?

Thanks,
Jianjie

发件人: Spud [mailto:spud-bounces@ietf.org] 代表 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

Spud@ietf.org<mailto:Spud@ietf.org>

https://www.ietf.org/mailman/listinfo/spud