[Spud] 答复: endpoint control

Hi Brian,

I'm wondering how the endpoint verifies the information provided by the device on path? Is it also assumed that the key is provided by the superstrate transport between the device on path and the endpoint?

Thanks,
Jianjie

> -----邮件原件-----
> 发件人: Brian Trammell [mailto:ietf@trammell.ch]
> 发送时间: 2016年6月22日 18:45
> 收件人: Youjianjie
> 抄送: Aaron Falk; spud
> 主题: Re: [Spud] endpoint control
> 
> 
> > On 22 Jun 2016, at 11:35, Youjianjie <youjianjie@huawei.com> wrote:
> >
> > Hi Brian,
> >
> > Thanks for your prompt reply. Please see my comments below:
> >
> >> -----邮件原件-----
> >> 发件人: Brian Trammell [mailto:ietf@trammell.ch]
> >> 发送时间: 2016年6月22日 16:56
> >> 收件人: Youjianjie
> >> 抄送: Aaron Falk; spud
> >> 主题: Re: [Spud] endpoint control
> >>
> >> hi Jianjie,
> >>
> >>> On 22 Jun 2016, at 09:09, Youjianjie <youjianjie@huawei.com> 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: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
> >>> https://www.ietf.org/mailman/listinfo/spud
> >>>
> >