Subject: Re: [Lurk] 答复: 答复: Is this scenario covered by LURK?

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 20 Jun 2016 09:18:26 +0000

Thanks Jianjie.

I was slightly confused because in the discussion so far (and in the LURK drafts) "edge server" has been used with distinct semantics ― i.e. a HTTP edge cache that terminates TLS.  Instead, in your picture it's used to mean "traffic management middle-box": firewall, IDS, anti-spam/malware, load balancer, whatever.

IIUC, what you want to achieve is that these middle-boxes submit a chunk of encrypted bytes to the Key Server and get the clear-text back (sort of DPI by proxy if you like) while at the same time hiding topological details about the Gi-LAN (though this seems to be ancillary).

While I think this is an interesting idea, I'm concerned that pulling this use case in to the picture at this point in time would derail the working group focus in endless political discussions.

However, we should keep in the back of our mind the fact that LURK must evolve (both refining existing use cases and incorporating new ones as well) and thus it needs to be built with an extensible interface from the onset.

Cheers, t

PS: It'd be nice if you took some time to draft the interfaces so that we can have a more precise idea of what you have in mind?

From: Youjianjie <[email-masked]<mailto:[email-masked]>>
Date: Monday, 20 June 2016 07:26
To: "Fossati, Thomas (Nokia - GB)" <[email-masked]<mailto:[email-masked]>>, Daniel Migault <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: 答复: [Lurk] 答复: Is this scenario covered by LURK?

Hi Thomas,

It is the latter. In this figure, the edge server (e.g. middle-box) can manage the encrypted flows if it is trusted and authorized to have the key from Key server via Key manager.

We introduce a Key manager because there may be many edge servers in the network. It's better not to expose the topology of edge servers to the content owner if the Content Provider and the Content Owner are in different administrative domain.

Further comments are welcome.

Thanks,
Jianjie

发件人: Lurk [mailto:[email-masked]] 代表 Fossati, Thomas (Nokia - GB)
发送时间: 2016年6月19日 1:39
收件人: Youjianjie; Daniel Migault; Fossati, Thomas (Nokia - GB); [email-masked]<mailto:[email-masked]>
主题: Re: [Lurk] 答复: Is this scenario covered by LURK?

Hi Jianjie,

I've been staring at the picture for a while but I still don't understand whether what you call "Edge Server" is actually a cache that terminates the TLS connection on behalf of the content owner, or some other middle-box that needs to do traffic management and wants to talk to the Key Server to DPI the encrypted flows.

If the former, your "Key Manager" is really just a LURK proxy ― I don't think there is anything new to standardise once the LURK interfaces are defined.

If the latter, I don't seem to remember anyone presenting this use case either at the BoF, on list, or in the interim meeting.

Cheers, t

From: Youjianjie <[email-masked]<mailto:[email-masked]>>
Date: Friday, 17 June 2016 03:42
To: Daniel Migault <[email-masked]<mailto:[email-masked]>>, "Fossati, Thomas (Nokia - GB)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: 答复: [Lurk] Is this scenario covered by LURK?

Hi Daniel, Thomas,

Here’s a diagram illustrating the scenario I want to mean.

Please also see my comments inline below:

Thanks,

Jianjie

> -----邮件原件-----

> 发件人: Daniel Migault [mailto:[email-masked]]

> 发送时间: 2016年6月16日 21:27

> 收件人: Fossati, Thomas (Nokia - GB); Youjianjie; [email-masked]<mailto:[email-masked]>

> 主题: RE: [Lurk] Is this scenario covered by LURK?

> Hi Jianjie,

> Thank you for bringing a potential new use case. Currently LURK aims at

> providing an interface between Edge Servers and the Key Server in a context of

> TLS. If I am correct, the use case you provide introduces an additional element

> designated as a Key Manager.  From the description it is not clear to me what

> role the Key Manager has, and its relation with the Edge Servers and the Key

> Server.

The reason why we introduce a Key manager is that there're many edge servers in some cases. It's better not to expose the topology of edge servers to the content owner if the Content Provider and the Content Owner are in different administrative domain.

> Could you specify what role the Key Manager has as well as interactions

> between:

>    -  the Key Manger and Key Server

Key information needs to be interacted between them.

>    - the Key Manager and the Edge Server

Key information needs to be interacted between them.

> In addition, it might be also helpful to provide feed back why you think the use

> cases of the draft do not address your use case. Could you please point what is

> missing ?

Is the content owner also expected to deliver content traffic in the current use case doc?

https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-01

> BR,

> Daniel

> -----Original Message-----

> From: Lurk [mailto:[email-masked]] On Behalf Of Fossati, Thomas

> (Nokia - GB)

> Sent: Thursday, June 16, 2016 8:40 AM

> To: Youjianjie; [email-masked]<mailto:[email-masked]>

> Subject: Re: [Lurk] Is this scenario covered by LURK?

> Hi Jianjie,

> On 16/06/2016 04:31, "Lurk on behalf of Youjianjie" <[email-masked]<mailto:[email-masked][email-masked]>

> on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

> >Hi

> >I've a question about the scenario. I'm not sure if the following

> >scenario is covered by the LURK.

> >In this scenario, the Content Provider and the Content Owner are in

> >different administrative domain. Content owner is also responsible to

> >deliver the content. The content provider participates the delivery of

> >a content, providing necessary traffic management, such as FW, IPS.

> >For example, the edge server can be middle-box in the operator's network.

> >There may be multiple middle-boxes, which can be managed by a key

> >manager in the operator's network. In order to do traffic management,

> >the key manager needs to interact with the key server located in the

> >content owner domain, in order to do traffic management since the

> >packets are encrypted. Here, the interaction between key manager (e.g.

> >operator's

> >network) and key server (in content owner) needs to be standardized? Is

> >this use case in the scope of LURK?

> Could you spend a few more lines on the kind of interaction that you are

> envisaging between the key manager and the key server?

> Cheers, t

> _______________________________________________

> Lurk mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/lurk

---

From: Youjianjie <[email-masked]>
Date: Tue, 21 Jun 2016 02:56:31 +0000

Hi Thomas,

One way is the middle-box submits a chunk of encrypted bytes to the Key Manager and gets the clear-text back. The other way is the middle-box gets the key information from the Key Manager. I think both are possible.

I’m wondering if this use case could be merged into the existing use case document? If the use case is acceptable, we’ll describe the interface requirements for it.

Thanks,
Jianjie

发件人: Fossati, Thomas (Nokia - GB) [mailto:[email-masked]]
发送时间: 2016年6月20日 17:18
收件人: Youjianjie; Fossati, Thomas (Nokia - GB); Daniel Migault; [email-masked]
主题: Re: 答复: [Lurk] 答复: Is this scenario covered by LURK?

Thanks Jianjie.

Cheers, t

Hi Thomas,

Thanks,
Jianjie

Hi Jianjie,

Cheers, t

Hi Daniel, Thomas,

Thanks,

Jianjie