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
> https://www.ietf.org/mailman/listinfo/spud