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

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Thu, 16 Jun 2016 12:40:26 +0000

Hi Jianjie,

On 16/06/2016 04:31, "Lurk on behalf of Youjianjie" <[email-masked]
on behalf of [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

---

From: Daniel Migault <[email-masked]>
Date: Thu, 16 Jun 2016 13:26:49 +0000

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. 
 
Could you specify what role the Key Manager has as well as interactions between:
   -  the Key Manger and Key Server 
   - the Key Manager and the Edge Server  
 
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 ?

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]
Subject: Re: [Lurk] Is this scenario covered by LURK?

Hi Jianjie,

On 16/06/2016 04:31, "Lurk on behalf of Youjianjie" <[email-masked] on behalf of [email-masked]> wrote:
>deliver the content. The content provider participates the delivery of 
>a content, providing necessary traffic management, such as FW, IPS.
>
>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

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]
https://www.ietf.org/mailman/listinfo/lurk

---

From: Youjianjie <[email-masked]>
Date: Fri, 17 Jun 2016 02:42:29 +0000

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]

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

> 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

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

> (Nokia - GB)

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

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

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

---

From: Daniel Migault <[email-masked]>
Date: Fri, 17 Jun 2016 18:50:44 +0000

Hi,

Thanks for providing the picture. If I correctly get it, the Key Manager works as a proxy that concentrates the queries from the different edge servers. The key manager is the only node of the content provider  interacting with the key server of the content owner.
I do not think we have specific text related to that yet, but I do not think anything that prevents from doing it: lurk is used between the edge servers and the key manager – I would see that as the container use case - as well as between the key manager and the key server – which I would then see as the content provider / content owner use case.
I will add some text to cover this use case more precisely. Thanks for submitting the use case!

BR,
Daniel

From: Lurk [mailto:[email-masked]] On Behalf Of Youjianjie
Sent: Thursday, June 16, 2016 10:42 PM
To: Daniel Migault; Fossati, Thomas (Nokia - GB); [email-masked]
Subject: [Lurk] 答复: Is this scenario covered by LURK?

Hi Daniel, Thomas,

Thanks,

Jianjie

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

---

From: Youjianjie <[email-masked]>
Date: Mon, 20 Jun 2016 06:48:37 +0000

Hi Daniel,

I think in both container use case and content provider / content owner use case (https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-01), the edge server (not the key server) is expected to deliver content traffic.

The figure below is supposed that the TLS connection is terminated at the content owner side (not the edge server). The edge server is on the data path, it can do traffic management if it is trusted and authorized.

Further comments are welcome.

Thanks,

Jianjie

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

Hi,

BR,
Daniel

From: Lurk [mailto:[email-masked]] On Behalf Of Youjianjie
Sent: Thursday, June 16, 2016 10:42 PM
To: Daniel Migault; Fossati, Thomas (Nokia - GB); [email-masked]<mailto:[email-masked]>
Subject: [Lurk] 答复: Is this scenario covered by LURK?

Hi Daniel, Thomas,

Thanks,

Jianjie

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Jun 2016 11:17:27 -0400

Youjianjie:

I’m sorry, but I do not get it.  In your diagram, the TLS Connection terminates at the same place as the Content Server/Key Server.  So, LURK is not needed for the Key Server to perform operation on behalf of the Content Server, and the Edge Servers do not need key operations because they do not terminate the TLS Connection.

Russ

Begin forwarded message:

> From: Youjianjie <[email-masked]>
> Date: June 16, 2016 at 10:42:29 PM EDT
> To: Daniel Migault <[email-masked]>, "Fossati, Thomas (Nokia - GB)" <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> Hi Daniel, Thomas,
>

---

From: Youjianjie <[email-masked]>
Date: Tue, 21 Jun 2016 01:42:10 +0000

Hi Russ,

In the diagram below, the TLS connection terminates at the content server side. The edge server (in the context here, e.g. middle-box)  is on the data path, and it needs the key because it needs to do some policy control on the traffic flow.

Thanks,
Jianjie

发件人: Lurk [mailto:[email-masked]] 代表 Russ Housley
发送时间: 2016年6月20日 23:17
收件人: Youjianjie
抄送: IETF LURK
主题: [Lurk] Fwd: Is this scenario covered by LURK?

Youjianjie:

Russ

Begin forwarded message:

From: Youjianjie <[email-masked]<mailto:[email-masked]>>
Subject: [Lurk] 答复: Is this scenario covered by LURK?
Date: June 16, 2016 at 10:42:29 PM EDT
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]>>

Hi Daniel, Thomas,

Thanks,
Jianjie

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Jun 2016 12:31:08 -0400

I do not think this group should include this use case in the document.

Russ