Subject: ACKs in encrypted tunnel

From: Bret Jordan <[email-masked]>
Date: Wed, 15 Nov 2017 11:26:27 +0800

So my understanding is that all ACKs and notices about lost packets, frames, etc will be communicated inside the encrypted tunnel with QUIC.

What is our plan to enable network operators to help troubleshoot network problems with QUIC? 

When running a large network the network team / network operators are often asked to help identify problems when an application is not working or is sluggish. If all information is inside the encrypted tunnel, are we just saying “end user and application support person, you figure it out?” 

This seems like a huge problem.  I mean the network does not always work flawlessly and it seems like we are removing all the abilities for network operators to ensure any level of SLA or OLA.  

Bret 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

---

From: Roni Even <[email-masked]>
Date: Wed, 15 Nov 2017 03:31:12 +0000

Hi,
This is discussed in the spin bit that was presented yesterday
Roni

From: QUIC [mailto:[email-masked]] On Behalf Of Bret Jordan
Sent: יום ד 15 נובמבר 2017 05:26
To: [email-masked]
Subject: ACKs in encrypted tunnel

Bret

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050<tel:7415%200050>

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Nov 2017 03:37:37 +0000

Also, if the end point(s) consent to give you the keys, nothing stops you from inspecting a particular flow.  It requires the active cooperation of at least one party to the connection, but if someone’s calling you for help, that’s presumably the case.

From: QUIC [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:31 AM
To: Bret Jordan <[email-masked]>; [email-masked]
Subject: RE: ACKs in encrypted tunnel

Hi,

From: QUIC [mailto:[email-masked]] On Behalf Of Bret Jordan
Sent: יום ד 15 נובמבר 2017 05:26
To: [email-masked]<mailto:[email-masked]>
Subject: ACKs in encrypted tunnel

Bret

---

From: Bret Jordan <[email-masked]>
Date: Wed, 15 Nov 2017 11:40:56 +0800

Is the spin bit going to be enough? I am not sure it is. 

Bret 

> On Nov 15, 2017, at 11:31 AM, Roni Even <[email-masked]> wrote:
> 
> Hi,

---

From: Bret Jordan <[email-masked]>
Date: Wed, 15 Nov 2017 11:41:40 +0800

I am not sure that is really realistic.

Bret 

> On Nov 15, 2017, at 11:37 AM, Mike Bishop <[email-masked]> wrote:
>

---

From: Kyle Rose <[email-masked]>
Date: Wed, 15 Nov 2017 11:46:03 +0800

Can you describe an example problem and debugging workflow in which
publicly-visible ACKs were indispensable in helping to locate a
network problem?

Kyle

On Wed, Nov 15, 2017 at 11:41 AM, Bret Jordan <[email-masked]> wrote:
> Also, if the end point(s) consent to give you the keys, nothing stops you
> from inspecting a particular flow.  It requires the active cooperation of at
> least one party to the connection, but if someone’s calling you for help,
> that’s presumably the case.
>
>
>
> So my understanding is that all ACKs and notices about lost packets, frames,
> etc will be communicated inside the encrypted tunnel with QUIC.
>
>
>
> When running a large network the network team / network operators are often
> asked to help identify problems when an application is not working or is
> sluggish. If all information is inside the encrypted tunnel, are we just
> saying “end user and application support person, you figure it out?”
>
>
>
> This seems like a huge problem.  I mean the network does not always work
> flawlessly and it seems like we are removing all the abilities for network
> operators to ensure any level of SLA or OLA.
>
>
>
> Bret
>
>
>

---

From: <[email-masked]>
Date: Wed, 15 Nov 2017 05:54:19 +0000

Hi Mike,

We would not have this discussion if this was the case.

Regards
Emile

De : QUIC [mailto:[email-masked]] De la part de Bret Jordan
Envoyé : mercredi 15 novembre 2017 11:42
À : Mike Bishop
Cc : Roni Even; [email-masked]
Objet : Re: ACKs in encrypted tunnel

Bret

On Nov 15, 2017, at 11:37 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
Also, if the end point(s) consent to give you the keys, nothing stops you from inspecting a particular flow.  It requires the active cooperation of at least one party to the connection, but if someone’s calling you for help, that’s presumably the case.

From: QUIC [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:31 AM
To: Bret Jordan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: ACKs in encrypted tunnel

Hi,

Bret

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Roni Even <[email-masked]>
Date: Wed, 15 Nov 2017 07:39:15 +0000

This will allow the Service provider to review the content (also change). This is not what we want and I assume that this is not what you want
Roni

From: Mike Bishop [mailto:[email-masked]]
Sent: יום ד 15 נובמבר 2017 05:38
To: Roni Even; Bret Jordan; [email-masked]
Subject: RE: ACKs in encrypted tunnel

Hi,

Bret

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Nov 2017 08:21:28 +0000

No; the provider is able to review the contents of the individual flow they’ve been invited to inspect for testing purposes.  No one is going to disclose their private keys, but if they have a reproducible problem they might well be willing to identify the derived symmetric keys which protected the session they’re asking you to investigate.

From: Roni Even [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 3:39 PM
To: Mike Bishop <[email-masked]>; Bret Jordan <[email-masked]>; [email-masked]
Subject: RE: ACKs in encrypted tunnel

From: Mike Bishop [mailto:[email-masked]]
Sent: יום ד 15 נובמבר 2017 05:38
To: Roni Even; Bret Jordan; [email-masked]<mailto:[email-masked]>
Subject: RE: ACKs in encrypted tunnel

Hi,

Bret

---

From: Roland Zink <[email-masked]>
Date: Wed, 15 Nov 2017 11:00:42 +0100

Not sure about that. The end user doesn't know how to do this and the OS 
are trying to ensure that this will not happen. Assuming it is easy to 
get the keys from users then this is a security problem. So we must 
assume keys are not available.

Roland

Am 15.11.2017 um 04:37 schrieb Mike Bishop:
>
> Also, if the end point(s) consent to give you the keys, nothing stops 
> you from inspecting a particular flow.  It requires the active 
> cooperation of at least one party to the connection, but if someone’s 
> calling you for help, that’s presumably the case.
>
> *From:*QUIC [mailto:[email-masked]] *On Behalf Of *Roni Even
> *Sent:* Wednesday, November 15, 2017 11:31 AM
> *To:* Bret Jordan <[email-masked]>; [email-masked]
> *Subject:* RE: ACKs in encrypted tunnel
>
> Hi,
>
> *From:*QUIC [mailto:[email-masked]] *On Behalf Of *Bret Jordan
> *Sent:* יום ד 15 נובמבר 2017 05:26
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* ACKs in encrypted tunnel
>
> So my understanding is that all ACKs and notices about lost packets, 
> frames, etc will be communicated inside the encrypted tunnel with QUIC.
>
> When running a large network the network team / network operators are 
> often asked to help identify problems when an application is not 
> working or is sluggish. If all information is inside the encrypted 
> tunnel, are we just saying “end user and application support person, 
> you figure it out?”
>
> This seems like a huge problem.  I mean the network does not always 
> work flawlessly and it seems like we are removing all the abilities 
> for network operators to ensure any level of SLA or OLA.
>
> Bret
>
> <tel:7415%200050>

---

From: Martin Duke <[email-masked]>
Date: Wed, 15 Nov 2017 14:57:52 -0800

There are some issues open for additional bits to signal loss and flow
control limitations, but I believe the rough consensus is that RTT (plus
the packet numbers available in cleartext) are sufficient for v1.

As the person who filed several of those issues, my opinion is that other
signals would require their own analysis of information leakage and the WG
will probably not take action in the limited time for v1.

On Wed, Nov 15, 2017 at 2:00 AM, Roland Zink <[email-masked]> wrote:

> are trying to ensure that this will not happen. Assuming it is easy to get
> the keys from users then this is a security problem. So we must assume keys
> are not available.
>
>
> Roland
>
>
>
> from inspecting a particular flow.  It requires the active cooperation of
> at least one party to the connection, but if someone’s calling you for
> help, that’s presumably the case.
>
>
>
> *From:* QUIC [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Roni Even
> *To:* Bret Jordan <[email-masked]> <[email-masked]>;
> [email-masked]
> *From:* QUIC [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Bret Jordan
> *To:* [email-masked]
> often asked to help identify problems when an application is not working or
> is sluggish. If all information is inside the encrypted tunnel, are we just