Re: [Spud] endpoint control

[Brian Trammell <[e-mail]>]

> On 30 Jun 2016, at 19:41, 🔓Dan Wing <[e-mail]> wrote:
> 
> 
> On 30-Jun-2016 08:33 am, Brian Trammell <[e-mail]> wrote:
>> 
>> 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 <[e-mail]> wrote:
>>> 
>>> 
>>> On 28-Jun-2016 05:20 am, Brian Trammell <[e-mail]> wrote:
>>>> 
>>>>> On 28 Jun 2016, at 12:41, Smith, Kevin, (R&D) Vodafone Group <[e-mail]> wrote:
>>>>> 
>>>>> 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?
>>>> 
>>>> 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),
>>> 
>>> How so?
>>> 
>>> -d
>> 
>> 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,
> 
> 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


> -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
>> 
>>>> 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
>>>> 
>>>>> Cheers,
>>>>> Kevin
>>>>> Vodafone R&D
>>>>> 
>>>>> [1] https://www.ietf.org/archive/id/draft-flinck-mobile-throughput-guidance-03.txt , expired
>>>>> 
>>>>> _______________________________________________
>>>>> Spud mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/spud
>>>> 
>>>> _______________________________________________
>>>> Spud mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/spud
>>> 
>>> 
>> 
> 
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud