Re: [Lurk] review of draft-cairns-tls-session-key-interface-01

[Daniel Migault <[e-mail]>]

Ok thank you for the feed back. I see you point and hope we can talk about this week. Any other feed backs for the transport layer in lurk is welcome.

BR, 
Daniel


-----Original Message-----
From: Fossati, Thomas (Nokia - GB) [mailto:[e-mail]] 
Sent: Sunday, April 03, 2016 12:45 PM
To: Daniel Migault; [e-mail]
Cc: [e-mail]
Subject: Re: review of draft-cairns-tls-session-key-interface-01

Hi Daniel,

On 03/04/2016 11:09, "EXT Daniel Migault" <[e-mail]>
wrote:
>MGLT: You are right and I share your opinion that with RSA only the MS 
>or EMS should be returned. I am planning to explain this during the BoF 
>and see if everyone agree with this. Actually this document very the 
>very early version of lurk. It describes the architecture, as well as a 
>first LURK implementation. Outside the architecture aspects, other 
>sections have been addressed in separate draft such as 
>[draft-mglt-lurk-tls-use-cases-00] for the use case,
>[draft-mglt-lurk-tls-requirements-00 ] for an analysis of the 
>authentication method performed with LURK, 
>[draft-mglt-lurk-tls-abstract-api-00] for a first protocol description.

OK, I'll go and have a look!

>- LURK has use cases that need high throughput: we really want to be 
>able to fill the pipe between the Edge and Key Server, and also treat 
>each transaction independently.  That's why a UDP based protocol is 
>attractive, vs. for example a HTTP2/TCP based one, which would incur 
>HOL on packet loss.  Also an efficient encoding like the CBOR/CoAP that 
>you are proposing looks really great to keep the overhead at a minimum.  
>I've never used CoAP in high throughput applications though (quite the 
>opposite, really), so I'm not sure whether its default congestion 
>control algorithm is OK for this scenario?  Have you done any experiment?
>
>MGLT: Thanks for your input. This is also something I would like to 
>discuss during the BoF. Instead of having one transaction per request, 
>we could also use a HTTPS session and tunnel all transaction through 
>that tunnel. Do you think that is a bad idea? I am really open to any 
>suggestion, so your comment is very useful. Actually, the reason the 
>draft [draft-mglt-lurk-tls-abstract-api-00] has this misleading title 
>abstract API, is that it remains focused on the LURK protocol aspects 
>and does not deal yet on the transport aspect.

What I meant was to use one application layer transaction per LURK call.
A single mutually authenticated & encrypted tunnel (DTLS, IPsec, etc.) between the Edge and the Key Server, once established, could sit there for quite a long time and carry as many CoAP transactions as needed.

I think HTTPS over TCP would be a suboptimal transport for LURK because of the HOL blocking problem I was hinting in the other email: a single packet loss incident could potentially stop lots of "nearby" transactions.  We should really try to avoid that.

(I'm around if you want to talk more.)

Cheers, t