Subject: [Spud] endpoint control

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Tue, 28 Jun 2016 10:41:52 +0000

Hi Brian,

I think Mobile Throughput Guidance would be a good candidate for PLUS path-to-endpoint signalling. The latest (albeit expired) MTG draft [1] is bound to TCP Options, and was considering use of TCP-AO for authentication; PLUS could allow MTG for both TCP and UDP-based flows. However it seems that proposed PLUS mechanism:

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

...may not provide the guarantee that (1) the MTG information was indeed injected by the cellular network and (2) that it has not been modified by another node. Have I got that right? Or would such an authentication/integrity check applicable to path data be in scope of PLUS?

Cheers,
Kevin
Vodafone R&D

[1] https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-03.txt , expired

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 28 Jun 2016 10:59:33 +0000

Hi Kevin,

On 28/06/2016 11:41, "Spud on behalf of Smith, Kevin, (R&D) Vodafone
Group" <[email-masked] on behalf of [email-masked]> wrote:
>>(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.
>
>...may not provide the guarantee that (1) the MTG information was indeed
>injected by the cellular network and (2) that it has not been modified by
>another node. Have I got that right?

Yes, you are right.  See also section 5.2 of [1].

Cheers, t

[1] https://www.iab.org/wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_4.pdf

---

From: Brian Trammell <[email-masked]>
Date: Tue, 28 Jun 2016 14:20:35 +0200

> On 28 Jun 2016, at 12:41, Smith, Kevin, (R&D) Vodafone Group <[email-masked]> wrote:
> 
> Hi Brian,
> 
> ...may not provide the guarantee that (1) the MTG information was indeed injected by the cellular network and (2) that it has not been modified by another node. Have I got that right?

Correct. It doesn't provide that guarantee at all, by design.

> Or would such an authentication/integrity check applicable to path data be in scope of PLUS?

As I see it now, not at first. The cases where the endpoint reliably has an way to authenticate a middlebox are limited (though mobile access networks are one such case), and IMO the mechanism should be as general as possible.

I will point out that integrity and authentication of information from a middlebox where the sending endpoint can authenticate the middlebox can trivially be implemented on top of this proposed mechanism: the definition of the exposed information could be "content plus MAC", where the MAC can be verified using the middlebox's certificate. But these can be implemented in information elements atop PLUS, without requiring additional support in the PLUS header.

In a mobile access network, on the upstream path this would look like:

user terminal --[ PLUS mobile-foo: 00000000 ]--> access network --[ PLUS mobile-foo CCCCCCMM ]--> server

(where mobile-foo is whatever you want the access network to be able to say, 00000000 is scratch space, C is content and M is MAC.)

The server can act on the throughput guidance (should it choose to, see spud-req 5.9), but since it's the user terminal that has a relationship with the access network, the server may need to feed the content and MAC back to the user terminal (see spud-req 5.5 and 6.4) for verification.

Cheers,

Brian

> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 28 Jun 2016 09:19:10 -0700

On 28-Jun-2016 05:20 am, Brian Trammell <[email-masked]> wrote:
> As I see it now, not at first. The cases where the endpoint reliably has an way to authenticate a middlebox are limited (though mobile access networks are one such case),

How so?

-d

>  and IMO the mechanism should be as general as possible.
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jun 2016 10:37:06 -0700

Hi Kevin,

That is an interesting use case. Do you see any reason (other than
maybe current deployability) that these can't be done in HBH options
instead of TCP options?

Thanks,
Tom

---

From: Youjianjie <[email-masked]>
Date: Wed, 29 Jun 2016 08:47:25 +0000

Hi Brian, Kevin,

> -----邮件原件-----
> 发件人: Spud [mailto:[email-masked]] 代表 Brian Trammell
> 发送时间: 2016年6月28日 20:21
> 收件人: Smith, Kevin, (R&D) Vodafone Group
> 抄送: [email-masked]
> 主题: Re: [Spud] endpoint control
> 
> 
> > I think Mobile Throughput Guidance would be a good candidate for PLUS
> path-to-endpoint signalling. The latest (albeit expired) MTG draft [1] is bound
> to TCP Options, and was considering use of TCP-AO for authentication; PLUS
> could allow MTG for both TCP and UDP-based flows. However it seems that
> proposed PLUS mechanism:
> >
> >> (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.
> >
> As I see it now, not at first. The cases where the endpoint reliably has an way
> to authenticate a middlebox are limited (though mobile access networks are
> one such case), and IMO the mechanism should be as general as possible.

IIUC, in MTG case, the middlebox (i.e. mobile edge server) which inserts the throughput guidance information is explicitly known to the endpoint. They negotiate the keys in advance. The content from path is encrypted and protected by default. 
In PLUS, the general case is for transparent middleboxes. Only type and length are protected. 
But PLUS doesn't exclude exchanging keys for some specific middlebox on path with the endpoint server. To some extent, the latter case could correspond to the MTG case, except that the content in the PLUS header can be only verified (content + MAC) without encryption. 

Thanks,
Jianjie

> I will point out that integrity and authentication of information from a
> middlebox where the sending endpoint can authenticate the middlebox can
> trivially be implemented on top of this proposed mechanism: the definition of
> the exposed information could be "content plus MAC", where the MAC can be
> verified using the middlebox's certificate. But these can be implemented in
> information elements atop PLUS, without requiring additional support in the
> PLUS header.
> 
> (where mobile-foo is whatever you want the access network to be able to say,
> 00000000 is scratch space, C is content and M is MAC.)
> 
> The server can act on the throughput guidance (should it choose to, see
> spud-req 5.9), but since it's the user terminal that has a relationship with the
> access network, the server may need to feed the content and MAC back to the
> user terminal (see spud-req 5.5 and 6.4) for verification.
> 
> Cheers,
> 
> Brian
> 
> > Cheers,
> > Kevin
> > Vodafone R&D
> >
> > [1]
> https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-03.tx
> t , expired
> >

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Wed, 29 Jun 2016 10:45:50 +0000

Hi Tom, 

> Do you see any reason (other than maybe current deployability) that these can't be done in HBH options instead of TCP options?

Probably down to forwarding performance too, as Hop-by-Hop must be processed by all network devices. And deployability as you say; because IPv6 is unfortunately not prevalent yet in mobile core networks...

https://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05 recommends using other extension headers instead, due to a denial of service threat. But these are intended for the destination and not interim nodes, and we'd need to check that EH are consistently passed across a range of vendors' routers.

Many thanks,
Kevin

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: 28 June 2016 18:37
To: Smith, Kevin, (R&D) Vodafone Group
Cc: Brian Trammell ([email-masked]); [email-masked]
Subject: Re: [Spud] endpoint control

On Tue, Jun 28, 2016 at 3:41 AM, Smith, Kevin, (R&D) Vodafone Group <[email-masked]> wrote:
> https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidanc
> e-03.txt , expired
>
Hi Kevin,

That is an interesting use case. Do you see any reason (other than maybe current deployability) that these can't be done in HBH options instead of TCP options?

Thanks,
Tom

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 Jun 2016 16:14:01 -0700

On 6/29/2016 3:45 AM, Smith, Kevin, (R&D) Vodafone Group wrote:
> https://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05 recommends using other extension headers instead, due to a denial of service threat.
It's not even a WG doc yet and it recommends some fairly severe changes
to IPv6.

Let's not assume its conclusions have been adopted just yet.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Jun 2016 16:26:47 -0700

> Probably down to forwarding performance too, as Hop-by-Hop must be processed by all network devices. And deployability as you say; because IPv6 is unfortunately not prevalent yet in mobile core net…
The first problem is being relaxed in 2460bis draft. It allows HBH to
be ignored by network devices, which should cover the case where there
are "too many options to parse" in a DOS attack.

Tom

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 Jun 2016 17:04:08 -0700

On 6/29/2016 4:26 PM, Tom Herbert wrote:
> ...

That doc recognizes that many devices do this, not that this is OK.

It only recommends not defining *new* HBH EHs - and not even in 2119
language.

It does not deprecate existing HBH EHs.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Jun 2016 17:33:22 -0700

> That doc recognizes that many devices do this, not that this is OK.
Here is the wording that I believed was agreed on in 6man for next
version of the 2460bis draft:

"NOTE: While RFC2460 required that all nodes must process the
Hop-by-Hop Options header, it is now expected that nodes only process
the Hop-by-Hop Options header if explicitly configured to do so. Nodes
that do not process or examine the Hop-by-Hop Options header must
ignore it,
and it must be passed on unchanged if forwarded."

As I understand it, the use of "expected" here instead of "SHOULD" or
"MAY" is necessary since 2460 is being proposed to become a full
standard and the protocol behavior can't change in that process. But
for all practical purposes this allows nodes to ignore HBH. Without
this allowance HBH would never be deployable.

Tom

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Thu, 30 Jun 2016 09:33:33 +0000

Thanks for the pointers Tom and Joe - good to see more direction on HBH. I hold to my initial point for practical reasons: PLUS is a worthy research option until HBH options are respected properly, and (more importantly) operators can support HBH via IPv6 adoption.

All best,
Kevin

PS Tom's HBH thread for reference: https://www.ietf.org/mail-archive/web/ipv6/current/msg24729.html 

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: 30 June 2016 01:33
To: Joe Touch
Cc: Smith, Kevin, (R&D) Vodafone Group; Brian Trammell ([email-masked]); [email-masked]
Subject: Re: [Spud] endpoint control

On Wed, Jun 29, 2016 at 5:04 PM, Joe Touch <[email-masked]> wrote:
>> be ignored by network devices, which should cover the case where 
>> there are "too many options to parse" in a DOS attack.
>
Here is the wording that I believed was agreed on in 6man for next version of the 2460bis draft:

"NOTE: While RFC2460 required that all nodes must process the Hop-by-Hop Options header, it is now expected that nodes only process the Hop-by-Hop Options header if explicitly configured to do so. Nodes that do not process or examine the Hop-by-Hop Options header must ignore it, and it must be passed on unchanged if forwarded."

As I understand it, the use of "expected" here instead of "SHOULD" or "MAY" is necessary since 2460 is being proposed to become a full standard and the protocol behavior can't change in that process. But for all practical purposes this allows nodes to ignore HBH. Without this allowance HBH would never be deployable.

Tom

---

From: Brian Trammell <[email-masked]>
Date: Thu, 30 Jun 2016 17:33:40 +0200

hi Dan,

(sorry it took me a while to get back to you here; need better email AQM)...

> On 28 Jun 2016, at 18:19, 🔓Dan Wing <[email-masked]> wrote:
> 
> 

Well, you need the endpoint to know which and what kinds of middleboxes its traffic is likely to encounter on the way to the other endpoint. There are three cases I can think of here:

1. An enterprise device can authenticate the enterprise firewall and/or VPN gateway.

2. A mobile handset can authenticate infrastructure in the mobile access network.

3. A server in a data center can authenticate infrastructure in the data center network.

(You could extend 1 to include home access networks as well, but getting the in-home devices and the gateways to authenticate each other reliably is an area that still needs some work to keep from being a giant support-call generator.)

In all three of these cases, the authentication relationship doesn't cross an administrative domain boundary. In an Internet context, this is what I mean by "limited". Note that it *doesn't* cover the case where a data center server says something to the mobile access network, or the handset and the server cooperate to say something to the same network, because as soon as you cross the admin domain boundary the device-to-device authentication problem quickly becomes intractable.

Building a common framework for making this kind of authentication work is a very interesting problem, and if PLUS designs a protocol correctly this framework can run on top of PLUS. But I think it's a different problem than the one PLUS is trying to solve.

Cheers,

Brian

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 30 Jun 2016 10:41:48 -0700

On 30-Jun-2016 08:33 am, Brian Trammell <[email-masked]> wrote:
> Building a common framework for making this kind of authentication work is a very interesting problem,

Yes.  I was hoping you had a solution.  If we can solve that, we can achieve secure DHCP, among other things.

-d

> and if PLUS designs a protocol correctly this framework can run on top of PLUS. But I think it's a different problem than the one PLUS is trying to solve.
> 
> Cheers,
> 
> Brian
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 30 Jun 2016 11:11:31 -0700

>> Building a common framework for making this kind of authentication work is a very interesting problem,
The also would be a nice way to define domains of information
exposure. For instance, in the case of a mobile client talking to its
network there seems to be a case for beneficial, granular, possibly
domain specific signaling. But as packets leave the trusted domain I
don't believe we arbitrarily want to expose such localized information
to the outside world. Even if it's authenticated this still would be
exposing potentially sensitive information to untrusted parties. For
example, if my mobile carrier gives me a deal on optimizing cat videos
I might trust them enough and believe there is enough benefit to mark
packets as carrying cat videos; but I wouldn't want to do this if it
means blabbing to the whole Internet that I'm watching cat videos.

Tom

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 30 Jun 2016 13:56:10 -0700

> means blabbing to the whole Internet that I'm watching cat videos.

Yep, agreed that is all good and useful.  Could be achieved "as easily as" (1) a new DHCP option that indicates the key for that communication with the local network.  But that is a different trust model than what I understood Brian was mentioning originally, though.

(1) as in, this isn't the only piece missing.

-d

---

From: Brian Trammell <[email-masked]>
Date: Thu, 30 Jun 2016 23:05:25 +0200

> On 30 Jun 2016, at 19:41, 🔓Dan Wing <[email-masked]> wrote:
> 
> 
> Yes.  I was hoping you had a solution.

Sadly, no. I do believe the problem can be scoped in such a way that a useful solution is possible... but I don't know what it looks like.

>  If we can solve that, we can achieve secure DHCP, among other things.

Yep. I think this is an entirely different problem, very much worth tackling. A solution would mesh nicely with PLUS, but also be applicable in situations where PLUS doesn't buy you anything (such as, as you say, secure DHCP).

Given that, I think it makes sense to carve out a facility in PLUS that use this other solution to authenticate network elements would use. And there, I think protected-presence, unprotected-content scratch space, with encrypted feedback in case it's the wrong endpoint listening, is the right way to go.

Cheers,

Brian