Re: [Spud] endpoint control

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

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


>  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