Subject: [tsvwg] FW: New Version Notification for draft-chen-tsvwg-crosslayer-cooperation-00.txt

From: "Chenhao (philips)" <[email-masked]>
Date: Sun, 27 Mar 2016 03:47:12 +0000

Hi all,

We have submitted a cross-layer cooperation draft. It mainly discuss the requirement of cross-layer design in the encrypted traffic scenario. Other scenario  such as 4k/8k video streaming transmission is also considered. Any comments and suggestions from you will be warmly welcome.

Best regards,

Hao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 21, 2016 9:15 PM
To: Chenhao (philips); Yinyue (Michael); Ge Chen
Subject: New Version Notification for draft-chen-tsvwg-crosslayer-cooperation-00.txt

A new version of I-D, draft-chen-tsvwg-crosslayer-cooperation-00.txt

has been successfully submitted by Hao Chen and posted to the IETF repository.

Name:               draft-chen-tsvwg-crosslayer-cooperation

Revision:  00

Title:                  Cross-layer Cooperation for Encrypted Traffic

Document date:       2016-03-20

Group:               Individual Submission

Pages:               7

URL:            https://www.ietf.org/internet-drafts/draft-chen-tsvwg-crosslayer-cooperation-00.txt

Status:         https://datatracker.ietf.org/doc/draft-chen-tsvwg-crosslayer-cooperation/

Htmlized:       https://tools.ietf.org/html/draft-chen-tsvwg-crosslayer-cooperation-00

Abstract:

   This memo mainly considers the requirement and feasibility of cross-

   layer design in the encrypted traffic scenario.

   By permitting the interaction between the encrypted application layer

   and non-encrypted transport/network layer, the network layer may

   schedule service flow more properly and the application layer may

   know the network status information well, which actually optimize the

   network bandwidth.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Melinda Shore <[email-masked]>
Date: Sat, 26 Mar 2016 20:30:02 -0800

This draft addresses an extremely interesting problem without
giving sufficient detail to understand exactly what's being
proposed.  For example, it's not clear whether you're proposing
protocol modification (replicating header data in adjacent layers)
or an implementation modification.  If it's an implementation
modification, then you'll be able to avoid developing new headers
for the entire protocol stack (ahem) but you won't be able to
do much about middleboxes which perform any kind of traffic
inspection.  I can't even tell if what you're proposing involves
key sharing (please don't) or exposing encrypted information
(please don't).

As an aside, I'm always sorry when a document that proposes something
with profound implications for security and privacy has an empty
security considerations section.

Anyway, as I wrote earlier I really cannot tell from the draft what's
actually being proposed.  I have a strong bias towards solving this
sort of problem with explicit signaling, which is something that's
come up quite a bit in the past (and in the present, with PCP).  It's
a good problem to work on but would benefit from a much greater
level of detail in the discussion.

Melinda

---

From: "Chenhao (philips)" <[email-masked]>
Date: Mon, 28 Mar 2016 21:39:44 +0000

Hi Melinda,

Thanks a lot for your detailed comments. Please see my reply in-line.

Best regards,

Hao

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Sunday, March 27, 2016 6:30 AM
To: [email-masked]
Subject: Re: [tsvwg] FW: New Version Notification for draft-chen-tsvwg-crosslayer-cooperation-00.txt

This draft addresses an extremely interesting problem without giving sufficient detail to understand exactly what's being proposed.  For example, it's not clear whether you're proposing protocol modification (replicating header data in adjacent layers) or an implementation modification.  If it's an implementation modification, then you'll be able to avoid developing new headers for the entire protocol stack (ahem) but you won't be able to do much about middleboxes which perform any kind of traffic inspection.  I can't even tell if what you're proposing involves key sharing (please don't) or exposing encrypted information (please don't).

[Hao] The purpose of this draft is to propose protocol modification rather than an implementation modification. Replicating header data in adjacent layers could be one possible method but not necessary the only way. We believe that the encrypted field(OTT controlled ) and non-encrypted field(Operator controlled) need a way to share part of the information. What kind of information should be shared and in which way to share it(the specific field used to held the shared information) both requires discussion and consensus with the OTTs and Operators involving in, and that is exactly what this draft want to propose.

As an aside, I'm always sorry when a document that proposes something with profound implications for security and privacy has an empty security considerations section.

[Hao] This very initial version does not involve any specific singling interaction so currently the security consideration section is left empty. It could be filled in when we have some consensus on the type and way of information sharing between encrypted and non-encrypted fields.

Anyway, as I wrote earlier I really cannot tell from the draft what's actually being proposed.  I have a strong bias towards solving this sort of problem with explicit signaling, which is something that's come up quite a bit in the past (and in the present, with PCP).  It's a good problem to work on but would benefit from a much greater level of detail in the discussion.

[Hao] To my understanding, this draft does not mention any explicit signaling. Anyway, we welcome your further comments if you feel like it is a worthwhile work to do. Thanks again.

Melinda

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 29 Mar 2016 15:17:41 +0000

I agree on both the fact the problem the draft is trying to address is extremely interesting but
It does not contain sufficient details to understand what the authors want to propose

Moreover the draft seems to imply that also the transport information are encrypted (i.e. a la QUIC)
and not in clear as in TCP. Is this a correct assumption or I have misunderstood it?

All in all
the tricky part here IMO is how to allow this crosslayer collaboration without leaking any privacy information

Salvatore

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: den 27 mars 2016 06:30
To: [email-masked]
Subject: Re: [tsvwg] FW: New Version Notification for draft-chen-tsvwg-crosslayer-cooperation-00.txt

Melinda

---

From: Tom Herbert <[email-masked]>
Date: Tue, 29 Mar 2016 11:51:17 -0700

>From the draft:

"For example, by permitting transport layer to access the data of
application layer to exchange information and enable interaction,
network devices is able to learn OTT information contents to implement
bandwidth optimization."

If this is saying that we (speaking for servers on the Internet) have
to leak information about our client's encrypted "information
contents" I think this is going to be a very hard sell, after all the
whole point of encryption is exactly to prevent network devices from
accessing user data.

Any data we expose about flows is potentially subject to malicious use
against us. Even with TLS we are still subject to a variety of attacks
because of flow specific information sent in the clear. Besides that,
there is no general trust relationship between hosts and devices, why
would a network device believe anything a random host says about the
nature of encrypted data?

So my suggestions for the draft are:

- Provide more detail for the requirements of network devices.
Precisely what information is needed for network devices to do their
job.
- Why aren't (or are) existing mechanisms (diffserv, ECN, segment
routing) sufficient?
- Security considerations section needs to be fleshed out (like those
that I pointed out above, but there are probably many more issues that
need to be considered)..

Thanks,
Tom

On Sat, Mar 26, 2016 at 8:47 PM, Chenhao (philips)
<[email-masked]> wrote:
> Hi all,
>
>
>
> We have submitted a cross-layer cooperation draft. It mainly discuss the
> requirement of cross-layer design in the encrypted traffic scenario. Other
> scenario  such as 4k/8k video streaming transmission is also considered. Any
> comments and suggestions from you will be warmly welcome.
>
>
>
>
>
> Best regards,
>
> Hao
>
>
>
> Subject: New Version Notification for
> draft-chen-tsvwg-crosslayer-cooperation-00.txt
>
>
>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-chen-tsvwg-crosslayer-cooperation-00.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-chen-tsvwg-crosslayer-cooperation/
>
> Htmlized:
> https://tools.ietf.org/html/draft-chen-tsvwg-crosslayer-cooperation-00
>
>
>
>
>
> Abstract:
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
>
>
> The IETF Secretariat
>
>

---

From: "Chenhao (philips)" <[email-masked]>
Date: Thu, 31 Mar 2016 09:39:33 +0000

Hi Salvatore,

Thanks a lot for your comments, please see my reply inline.

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Salvatore Loreto
Sent: Tuesday, March 29, 2016 5:18 PM
To: Melinda Shore; [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] FW: New Version Notification for draft-chen-tsvwg-crosslayer-cooperation-00.txt

I agree on both the fact the problem the draft is trying to address is extremely interesting but It does not contain sufficient details to understand what the authors want to propose

Moreover the draft seems to imply that also the transport information are encrypted (i.e. a la QUIC) and not in clear as in TCP. Is this a correct assumption or I have misunderstood it?

[Hao] we didn’t mention or imply the encryption of transport information. We just consider the application layer encryption here.

All in all

[Hao] If your ‘cross-layer collaboration without leaking any privacy information’ means the forbidden of any information interaction between the encryption and non-encryption fields, there might be a paradox. So why don’t we just try not to be ‘tricky’ while think about this problem in another way like more open? Actually interaction between OTT and Operator would benefit each other. So if operator could provide some network information to OTT to help improve the user experience, I think OTT would also be willing to offer a little information to Operator without sacrificing privacy as well. This kind of win-win information interaction should not be seen as privacy leaking because 1) OTT always holds the initiative and 2) the operator will never try to access any encrypted information on its own. One possible way is to insert a thin layer into the adjacent layer for information interaction(e.g replicating header data). Which kind of information will be put into this thin layer and its specific format should be discussed/determined by OTT and Operator together.

Salvatore

-----Original Message-----

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

Melinda

---

From: "Chenhao (philips)" <[email-masked]>
Date: Thu, 31 Mar 2016 13:25:43 +0000

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Tuesday, March 29, 2016 8:51 PM
To: Chenhao (philips)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] FW: New Version Notification for draft-chen-tsvwg-crosslayer-cooperation-00.txt

From the draft:

"For example, by permitting transport layer to access the data of application layer to exchange information and enable interaction, network devices is able to learn OTT information contents to implement bandwidth optimization."

If this is saying that we (speaking for servers on the Internet) have to leak information about our client's encrypted "information contents" I think this is going to be a very hard sell, after all the whole point of encryption is exactly to prevent network devices from accessing user data.

Any data we expose about flows is potentially subject to malicious use against us. Even with TLS we are still subject to a variety of attacks because of flow specific information sent in the clear. Besides that, there is no general trust relationship between hosts and devices, why would a network device believe anything a random host says about the nature of encrypted data?

[Hao] we are not saying information leakage. Actually 1) OTT always holds the initiative to decide which part of and in which way the information of encrypted field could be known by the non-encrypted field, and 2) the operator will never try to access any encrypted information on its own.

Precisely what information is needed for network devices to do their job.

routing) sufficient?

- Security considerations section needs to be fleshed out (like those that I pointed out above, but there are probably many more issues that need to be considered)..

[Hao] very useful suggestions and thanks for that. We will consider these suggestions in the next version and we welcome your further comments.

Thanks,

Tom

> We have submitted a cross-layer cooperation draft. It mainly discuss

> the requirement of cross-layer design in the encrypted traffic

> scenario. Other scenario  such as 4k/8k video streaming transmission

> is also considered. Any comments and suggestions from you will be warmly welcome.

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

> has been successfully submitted by Hao Chen and posted to the IETF

> repository.

> https://www.ietf.org/internet-drafts/draft-chen-tsvwg-crosslayer-coope

> ration-00.txt

> https://datatracker.ietf.org/doc/draft-chen-tsvwg-crosslayer-cooperati

> on/

>    This memo mainly considers the requirement and feasibility of

> cross-

>    By permitting the interaction between the encrypted application

> layer

>    know the network status information well, which actually optimize

> the

> Please note that it may take a couple of minutes from the time of

> submission until the htmlized version and diff are available at tools.ietf.org.