Subject: [Spud] endpoint control

From: Aaron Falk <[email-masked]>
Date: Mon, 20 Jun 2016 17:38:44 -0400

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?

Thanks,

—aaron

---

From: Brian Trammell <[email-masked]>
Date: Tue, 21 Jun 2016 11:35:34 +0200

hi Aaron,

On 06/20/2016 11:38 PM, Aaron Falk wrote:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Youjianjie <[email-masked]>
Date: Wed, 22 Jun 2016 07:09:58 +0000

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:[email-masked]] 代表 Brian Trammell
发送时间: 2016年6月21日 17:36
收件人: Aaron Falk
抄送: spud
主题: Re: [Spud] endpoint control

hi Aaron,

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

[email-masked]<mailto:[email-masked]>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 22 Jun 2016 10:56:14 +0200

hi Jianjie,

> On 22 Jun 2016, at 09:09, Youjianjie <[email-masked]> wrote:
> 
> Hi Brian,
> 
> 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

---

From: Youjianjie <[email-masked]>
Date: Wed, 22 Jun 2016 09:35:56 +0000

Hi Brian,

Thanks for your prompt reply. Please see my comments below:

> -----邮件原件-----
> 发件人: Brian Trammell [mailto:[email-masked]]
> 发送时间: 2016年6月22日 16:56
> 收件人: Youjianjie
> 抄送: Aaron Falk; spud
> > (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?
> 
> 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.
> 

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

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

---

From: Brian Trammell <[email-masked]>
Date: Wed, 22 Jun 2016 12:44:55 +0200

> On 22 Jun 2016, at 11:35, Youjianjie <[email-masked]> wrote:
> 
> Hi Brian,
> 

Yes. This is assumed to be provided by the superstrate transport.
> 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

---

From: Youjianjie <[email-masked]>
Date: Thu, 23 Jun 2016 08:03:02 +0000

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

> 发送时间: 2016年6月22日 18:45
> >>> space" in
> >> okay-to-modify state is enforced by a MAC which only verifies the
> >> length but not the content of the scratch space.
> >>>
> >> 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.
> >>
> > 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
> >
> >> 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
> >>>
> >>> 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?
> >>>
> >> signal to the endpoint. We have two mechanisms we've been thinking
> >> about for this:
> >>>
> >>> space" in
> >> okay-to-modify state is enforced by a MAC which only verifies the
> >> length but not the content of the scratch space.
> >>>
> >> 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
> >> from the PLUS-exposed information; it's what's in the encrypted

---

From: Brian Trammell <[email-masked]>
Date: Thu, 23 Jun 2016 10:11:16 +0200

> On 23 Jun 2016, at 10:03, Youjianjie <[email-masked]> wrote:
> 
> Hi Brian,
> 
> I'm wondering how the endpoint verifies the information provided by the device on path?

In the basic mechanism I've outlined here, it doesn't. If there exists some relationship between the endpoint and the device on path, then the information provided with in the PLUS header can itself be MAC'd with a key exchanged when that relationship is established.

> Is it also assumed that the key is provided by the superstrate transport between the device on path and the endpoint?

No, that doesn't really make any sense, because the transport is end-to-end (as was the original intent of the network/transport layer separation). Any key for authenticating and verifying endpoint-provided information would have to reside in the PLUS layer on the endpoint.

I think at this point mechanisms for *establishing* these relationships are out of scope for a future PLUS WG (at least, they were left out of the charter deliberately), since we're really talking about the design of new multiparty cryptographic protocols. But I notice that the mechanism we're discussing here two primitives (provide information to the path that at least the remote endpoint can verify is authentic, retrieve information from the path with sender permission) on top of which such protocols could be designed.

Cheers,

Brian

---

From: Youjianjie <[email-masked]>
Date: Thu, 23 Jun 2016 08:55:30 +0000

Hi Brian,

Thanks for the reply. 

> I think at this point mechanisms for *establishing* these relationships are out
> of scope for a future PLUS WG (at least, they were left out of the charter
> deliberately), since we're really talking about the design of new multiparty
> cryptographic protocols. But I notice that the mechanism we're discussing here
> two primitives (provide information to the path that at least the remote
> endpoint can verify is authentic, retrieve information from the path with
> sender permission) on top of which such protocols could be designed.

(1) If the information is provided to the path, why the remote endpoint needs to verify authentic? Is this information also useful for the remote endpoint? 

(2) Even if the retrieved information from the path with sender permission, the receiver cannot verify the information (i.e. content) is authentic? 

Thanks,
Jianjie

> 发送时间: 2016年6月23日 16:11
> In the basic mechanism I've outlined here, it doesn't. If there exists some
> relationship between the endpoint and the device on path, then the
> information provided with in the PLUS header can itself be MAC'd with a key
> exchanged when that relationship is established.
> 
> > Is it also assumed that the key is provided by the superstrate transport
> between the device on path and the endpoint?
> 
> No, that doesn't really make any sense, because the transport is end-to-end (as
> was the original intent of the network/transport layer separation). Any key for
> authenticating and verifying endpoint-provided information would have to
> reside in the PLUS layer on the endpoint.
> 
> I think at this point mechanisms for *establishing* these relationships are out
> of scope for a future PLUS WG (at least, they were left out of the charter
> deliberately), since we're really talking about the design of new multiparty
> cryptographic protocols. But I notice that the mechanism we're discussing here
> two primitives (provide information to the path that at least the remote
> endpoint can verify is authentic, retrieve information from the path with
> sender permission) on top of which such protocols could be designed.
> 
> Cheers,
> 
> Brian
> 
> > Thanks,
> > Jianjie
> >
> >> -----邮件原件-----
> >>>> 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.
> >>>>>
> >>>> 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).
> >>>>
> >>> How is the secret shared between both endpoints? The endpoints need
> >>> to
> >> establish a connection to exchange keys?
> >>
> >> 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
> >>
> >>>> 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.
> >>>>>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 23 Jun 2016 11:15:46 +0200

> On 23 Jun 2016, at 10:55, Youjianjie <[email-masked]> wrote:
> 
> Hi Brian,
> 
> Thanks for the reply.
> 

It may be; one could envision future transports over PLUS where part of the header is exposed but integrity protected, and the rest is encrypted. Integrity protection of the PLUS-exposed information reduces redundancy in the encrypted headers in this case.

The other reason to do this is to detect and react to unauthorized meddling in the PLUS header: this would appear as an error to the receiver's transport layer, which could then reset the connection. In this way the receiver acts as the verifier on behalf of all devices on path.

> (2) Even if the retrieved information from the path with sender permission, the receiver cannot verify the information (i.e. content) is authentic?

Correct.

Cheers,

Brian

---

From: Youjianjie <[email-masked]>
Date: Mon, 27 Jun 2016 10:06:07 +0000

Hi Brian,

Further comments below:

Thanks,
Jianjie
> 发送时间: 2016年6月23日 17:16
> >> I think at this point mechanisms for *establishing* these
> >> relationships are out of scope for a future PLUS WG (at least, they
> >> were left out of the charter deliberately), since we're really
> >> talking about the design of new multiparty cryptographic protocols.
> >> But I notice that the mechanism we're discussing here two primitives
> >> (provide information to the path that at least the remote endpoint
> >> can verify is authentic, retrieve information from the path with sender
> permission) on top of which such protocols could be designed.
> >
> > (1) If the information is provided to the path, why the remote endpoint
> needs to verify authentic? Is this information also useful for the remote
> endpoint?
> 
> It may be; one could envision future transports over PLUS where part of the
> header is exposed but integrity protected, and the rest is encrypted. Integrity
> protection of the PLUS-exposed information reduces redundancy in the
> encrypted headers in this case.
> 
> The other reason to do this is to detect and react to unauthorized meddling in
> the PLUS header: this would appear as an error to the receiver's transport layer,
> which could then reset the connection. In this way the receiver acts as the
> verifier on behalf of all devices on path.

Here, does the unauthorized meddling means "type or length" of the reserved space in the PLUS header is modified by the middle-box? However if "content" of the reserved space is modified, it is reasonable?

So if the sender wants some information from path, it should specify the type and length first in the header, then path fills the content accordingly. If the information is verified by the receiver, it will be signaled back to the sender by the receiver. 

> > (2) Even if the retrieved information from the path with sender permission,
> the receiver cannot verify the information (i.e. content) is authentic?
> 
> Correct.
> 
> Cheers,
> 
> Brian
> 
> > Thanks,
> > Jianjie
> >
> >> -----邮件原件-----
> >>> I'm wondering how the endpoint verifies the information provided by
> >>> the
> >> device on path?
> >>
> >> In the basic mechanism I've outlined here, it doesn't. If there
> >> exists some relationship between the endpoint and the device on path,
> >> then the information provided with in the PLUS header can itself be
> >> MAC'd with a key exchanged when that relationship is established.
> >>
> >> No, that doesn't really make any sense, because the transport is
> >> end-to-end (as was the original intent of the network/transport layer
> >> separation). Any key for authenticating and verifying
> >> endpoint-provided information would have to reside in the PLUS layer on
> the endpoint.
> >>
> >> I think at this point mechanisms for *establishing* these
> >> relationships are out of scope for a future PLUS WG (at least, they
> >> were left out of the charter deliberately), since we're really
> >> talking about the design of new multiparty cryptographic protocols.
> >> But I notice that the mechanism we're discussing here two primitives
> >> (provide information to the path that at least the remote endpoint
> >> can verify is authentic, retrieve information from the path with sender
> permission) on top of which such protocols could be designed.
> >>
> >> Cheers,
> >>
> >> Brian
> >>
> >>> Thanks,
> >>> Jianjie
> >>>
> >>>> -----邮件原件-----
> >>>>>> this okay-to-modify state is enforced by a MAC which only
> >>>>>> 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).
> >>>>>>
> >>>>> How is the secret shared between both endpoints? The endpoints
> >>>>> need to
> >>>>>> 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
> >>>>>>>
> >>>>>> 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.
> >>>>>> signal to the endpoint. We have two mechanisms we've been
> >>>>>> thinking about for this:
> >>>>>>>
> >>>>>> this okay-to-modify state is enforced by a MAC which only
> >>>>>> about permission and more about reducing the attractiveness of
> >>>>>> PLUS for amplification/reflection attacks.
> >>>>>>>

---

From: Brian Trammell <[email-masked]>
Date: Mon, 27 Jun 2016 12:12:55 +0200

> On 27 Jun 2016, at 12:06, Youjianjie <[email-masked]> wrote:
> 
> Hi Brian,
> 
> Further comments below:
> 
> Thanks,
> Jianjie
>> -----邮件原件-----

The reserved space is in this case intended to be modified by on-path devices. If we lived in a world in which it was reasonable to assume that we could exchange keys with and maintain certificates for every potential middlebox on path, we could use that cryptographic context to verify this information. But we don't, so we can't. Building multiparty cryptographic protocols that would be suited to this sort of thing is an area of open research; once designed, such a thing could run on top of this unprotected facility provided by PLUS.

> So if the sender wants some information from path, it should specify the type and length first in the header, then path fills the content accordingly. If the information is verified by the receiver…

Precisely.

Cheers,

Brian