Re: [Spud] endpoint control

[🔓Dan Wing <[e-mail]>]

On 30-Jun-2016 11:11 am, Tom Herbert <[e-mail]> wrote:
> 
> On Thu, Jun 30, 2016 at 10:41 AM, 🔓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,
>> 
> 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.

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


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