[Spud] 答复: endpoint control

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?

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

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