Subject: New drafts: draft-kuehlewind-quic-manageability-00 and draft-kuehlewind-quic-applicability-00

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 13 Mar 2017 11:58:40 +0100

Hi all,

as some of you have probably already noticed that we submitted two new drafts 
draft-kuehlewind-quic-manageability-00 and 
draft-kuehlewind-quic-applicability-00 
which are replacements for draft-kuehlewind-quic-appman as discussed in Tokyo. 

Beside the split we also added a little more content but given that the protocol is still very much in change, there are still quite a few editor notes or incomplete sections. Still we’d be very happy about feedback and additional input from others and are also still looking for additional authors!

See you in Chicago!
Mirja and Brian

> Anfang der weitergeleiteten Nachricht:
> 
> Von: [email-masked]
> Betreff: New Version Notification for draft-kuehlewind-quic-manageability-00.txt
> Datum: 9. März 2017 um 12:12:51 MEZ
> An: "Mirja Kuehlewind" <[email-masked]>, "Brian Trammell" <[email-masked]>, "Dan Druta" <[email-masked]>, "Mirja Kühlewind" <[email-masked]>
> 
> 
> A new version of I-D, draft-kuehlewind-quic-manageability-00.txt
> has been successfully submitted by Mirja Kuehlewind and posted to the
> IETF repository.
> 
> Name:		draft-kuehlewind-quic-manageability
> Revision:	00
> Title:		Manageability of the QUIC Transport Protocol
> Document date:	2017-03-09
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-manageability-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-kuehlewind-quic-manageability/
> Htmlized:       https://tools.ietf.org/html/draft-kuehlewind-quic-manageability-00
> 
> 
> Abstract:
>   This document discusses manageability of the QUIC transport protocol,
>   focusing on caveats impacting network operations involving QUIC
>   traffic.  Its intended audience is network operators, as well as
>   content providers that rely on the use of QUIC-aware middleboxes,
>   e.g. for load balancing.
> 
> 
> 
> 
> 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
> 
> Anfang der weitergeleiteten Nachricht:
> 
> Von: [email-masked]
> Betreff: New Version Notification for draft-kuehlewind-quic-applicability-00.txt
> Datum: 8. März 2017 um 16:30:57 MEZ
> An: "Mirja Kuehlewind" <[email-masked]>, "Brian Trammell" <[email-masked]>, "Mirja Kühlewind" <[email-masked]>
> 
> 
> A new version of I-D, draft-kuehlewind-quic-applicability-00.txt
> has been successfully submitted by Brian Trammell and posted to the
> IETF repository.
> 
> Name:		draft-kuehlewind-quic-applicability
> Revision:	00
> Title:		Applicability of the QUIC Transport Protocol
> Document date:	2017-03-08
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-applicability-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/
> Htmlized:       https://tools.ietf.org/html/draft-kuehlewind-quic-applicability-00
> 
> 
> Abstract:
>   This document discusses the applicability of the QUIC transport
>   protocol, focusing on caveats impacting application protocol
>   development and deployment over QUIC.  Its intended audience is
>   designers of application protocol mappings to QUIC, and implementors
>   of these application protocols.
> 
> 
> 
> 
> 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: Martin Thomson <[email-masked]>
Date: Thu, 16 Mar 2017 15:52:33 +1100

Thanks for putting these together.

# Bit ticket feedback

I think that these drafts need to consider the protocol as a package,
not focus on individual parts.  Thus, you should talk about HTTP/QUIC
and its properties, not talk about a transport protocol.  That means
referencing the HTTP mapping document for introductory matters and
only referencing other documents when it is relevant to a particular
point.

Take for example the fallback section in the applicability draft.  If
you were to talk about the specifics of HTTP/QUIC, then you only need
to talk about having HTTP/2 or HTTP/1.1 as a backstop.

There is probably some advice that could be given that would be
generic, but I suspect that without actually having more usage
examples to drive this from, we would just get those laughably wrong
(not all, but some).

# Applicability

The fact that this is encrypted is very prominent in the introduction.
I expect that this is more of interest to the other document.

## Section 2 (Fallback)

The point on fallback is that you will lose something, but you should
not allow fallback to another protocol to degrade security guarantees.
That is, you might lose performance (holb, multiplexing, etc...), but
you shouldn't lose any expectation of confidentiality or integrity, if
requirements for those things have been established.

   TCP by default does not support 0-RTT session resumption.

Not sure what "defaults" for TCP might even be.  The point that this
paragraph seems to be trying to make is that falling back might result
in some degradation of performance.

The same paragraph is also saying that if you can't guarantee some
level of security, then you SHOULD fail:

   Moreover, while encryption (in this case TLS) is
   inseparable integrated with QUIC, TLS negotiation over TCP can be
   blocked.  In case it is RECOMMENDED to abort the connection

I'm not sure why it's only a SHOULD though.  I'm fairly sure that most
clients will treat this as fatal already.

This section doesn't need to be hopeful, or lobby for particular
changes.  We can use the mailing list for that.

## Section 3 (0-RTT)

0-RTT is more than one packet, contrary to what this text implies by
talking about the "first packet" (note that the first packet is the
ClientHello, which can be replayed ad nauseum to no ill effect).

The discussion of loss here suggests a misunderstanding of the
problem.  The risk here is that the 0-RTT data can be replayed to a
server on **a different connection** and - absent any
application-layer means of detecting this - could be processed twice.
Loss and retransmission of these packets is benign.

Mark Nottingham talks about the relevance of idempotency at the HTTP
layer and its relevance to this subject.  I suggest that you read
draft-nottingham-httpbis-retry-01.  I don't think that you need to
change the view here, though you might like to change to using some
other terminology (replay protection, for instance).

## Section 4 (Multiplexing)

We should probably spend a lot more time discussing the virtues of
having multiple connections and whether it is possible to obtain
different treatment for packets on the same flow.

The editor's note is speculative and can be removed.

## Section 5 (Prioritization)

The second paragraph here is speculative and can be removed.

## Section 8 (Versioning)

I think that the key point to make here is that unlike other transport
protocols, QUIC includes version negotiation.  I like that you point
out that very little is guaranteed to be stable between versions.
Making a special point about TLS isn't that interesting and I would
remove that.

# Manageability

This draft is obviously a lot further behind.  It's also obviously
scrambling to keep up, since it's much more exposed to some of the
recent changes in the transport doc.  I think that it is generally the
right level of information to have.  There are a few errors and
omissions, but frankly - given where we are at - I'm surprised that
this has tracked the drafts so well.

## what can network management learn from looking at QUIC

I think that this needs to be clearer about the distinction between
*this* version of QUIC and the version-agnostic parts of QUIC.  The
increment between the two is small, but relevant.

The description of key phase is incorrect.  It has nothing to do with
0-RTT (though 0-RTT once affected it, it doesn't now).  It is for
working out which key to use for the packet.

The fact that a connection ID might change is a little
under-emphasized.  Admitted, the -transport draft doesn't actually
define how this works, so maybe that can be added when we build that
function.

In Section 3.1:
   0-RTT connection establishment, however, provides no particular
   heuristic for differentiation from random background traffic at this
   time.

This is incorrect.  The client still sends a ClientHello, which is in
the clear.  The fact that other packets might be sent and that there
might be loss and reordering is relevant here though and probably
needs to be called out.  Those packets will look like random noise,
and the temptation will be to just drop them, after all, I suspect
that many servers will do the same.  But there's a risk there.

Similarly, this is incorrect:
   RTT can
   only be measured at connection establishment time, and only when
   1-RTT establishment is used.

We closed #185.  (Section 3.3)

In Section 3.3, this is incorrect, except under certain conditions:
   If the QUIC handshake was not observed by the defense system, the
   connection ID can be used as a confirmation signal as per
   [I-D.trammell-plus-statefulness].

This is (currently) only true in the following cases:
1. the server uses version negotiation
2. the server uses HelloRetryRequest (a stateless reject)
3. the server uses the client-selected connection ID (though I
wouldn't want to rely on that)
4. the connection ID is sent in both directions (Google servers
routinely avoid sending a connection ID)

Section 3.3 also eventually needs a discussion of the impact of
connection migration when it is combined with a change in connection
ID.  (Again, we don't have that feature now, so the omission is
clearly not a problem now.)  The stateful nature of the connection is
not visible to the path in that case.  In particular, this seems to be
highly speculative:
   However, it is
   questionable if connection migrations needs to be supported in a DDOS
   attack or if a defense system might simply rely on the fast
   resumption mechanism provided by QUIC

## what can network management do to affect QUIC

I think that the effect of dropping packets needs to be explored more.
This is probably the only tool a network has (aside from perhaps a
public reset), but it's a pretty powerful one.  We'll know more when
more is said about congestion control, of course.  If we find that
authenticated public resets aren't a strict requirement, that will
need to be added.

I don't know if you want to discuss how PMTUD might react to signals
from a network, or whether networks really care about using MTU as a
management tool.

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 17 Mar 2017 12:25:48 +0100

Hi Martin,

thanks a lot for your feedback! As you mentioned yourself there are still 
some speculative comments in both drafts and we will definitely remove them 
in future versions. In this case as we submitted those drafts, mainly to 
implement the split into two drafts, quite a couple of days before the -02 
versions of the other draft, we tried to already capture some aspects that 
where still under discussion but likely to make it into the drafts. But see 
below for details.

Mirja

> only referencing other documents when it is relevant to a particular

So I'm actually not sure here and that's something I'd like to discuss. I 
would guess that applicability together with H2 will anyway be discussed in 
the H2 mapping draft. However, no matter what, I'm sure there will be people 
that will try to use QUIC with other higher layer protocols and applications 
and I think we need to give some advise here as well, especially if there are 
know assumptions we made in the protocol design about the application 
behavior or capabilities. Also the group is supposed to potentially recharter 
at some point to write more mapping documents. I also saw this document also 
as capturing what we learned from h2 for future mapping.

> to talk about having HTTP/2 or HTTP/1.1 as a backstop.

That's what we had in the previous version but then Ted talked about what 
would you do if you use QUIC for DNS in some issue thread and we tried to 
generalize this a bit. Again I think the h2 mapping doc also needs to talk 
about the h2 case specifically.

> examples to drive this from, we would just get those laughably wrong

I disagree, writing down the assumption we make about application behavior 
when we made certain design decisions for the transport is a good thing.

> I expect that this is more of interest to the other document.

That's a little bit an artifact from the previous version where manageability 
was included. But why do you think this is not interesting for this document? 
I think the two most important points in this document (fallback and 0-RTT) 
are directly connected to the fact that quic is encrypted by default.
> requirements for those things have been established.

Good point. We were more focusing on the problem that you might even lose 
connectivity if you don't have an adequate way to fall-back. This is not the 
case for H2, but might be fore other applications. The point on performance 
is a separate point on should be spelled out as well. I'll add this.

> in some degradation of performance.

This was only meant to say that you have to negotiate it and the chances are 
high that this is simply not supported by the other end. We can spell it out 
to make it more meaningful.

> clients will treat this as fatal already.

I don't really see how to make this a MUST. If you have a service where you 
cannot risk to lose connectivity to your costumers, is it better to not even 
try to use QUIC directly but only try TLS over TCP and then fallback to 
unencrypted TCP if TLS is blocked?

I don't think this is a protocol level decision that e.g. influences 
interoperability; it's rather an economic decision.

> changes.  We can use the mailing list for that.

Yes, the word 'hope' is misplaced here. Do you proposed to remove this 
paragraph completely, or do you think it's useful to have a reference to 
manageability draft there?

> ClientHello, which can be replayed ad nauseum to no ill effect).

Yes, that's a mistake (was probably thinking to much about tcp syn data 
stll). Will fix that.

> Loss and retransmission of these packets is benign.

So we meant retransmission to include replay; I agree that's the wrong word 
and causes confusion. Will fix that.

> other terminology (replay protection, for instance).

Thanks! Probably good to give a reference to this draft anyway! I wasn't 
aware of this yet.

> The editor's note is speculative and can be removed.

We added this based on the mailing list discussions on 
draft-abilash-quic-network-00. Your are absolutely right that these 
speculations should be removed from the draft and discussed as issues on the 
protocols. However, I didn't really know so far how to phrase an issue on 
that because we didn't really discuss this at all so far and I didn't want to 
lose it.
> The second paragraph here is speculative and can be removed.

Here the point was to give application some guidance how to implement 
prioritization on the application level (and when it might be useful). Again 
this was not meant to be specific advise for h2 but other applications. 
However, while some prioritization can be implemented in the higher layer, 
prioritization of retransmission can only be done by quic.

The point regarding the interface is actually another question I have. Should 
this document talk about the quic transport interface. How much advise to we 
want to give? Do we maybe even want to talk about an abstract api?

> Making a special point about TLS isn't that interesting and I would

This was especially meant to be advise to people who already have in mind 
that they want to implement quic with a different crypto. Again, I've been 
seeing this as general guidance for quic transport (and not for quic+tls+h2). 
As such I've been trying to capture guidance for future mappings and future 
versions of quic.

> recent changes in the transport doc.

Yes!

  I think that it is generally the
> this has tracked the drafts so well.

Thanks!
> increment between the two is small, but relevant.

Yes, but that's also very much under discussion...
> working out which key to use for the packet.

Yes that's an artifact from an older version.

> define how this works, so maybe that can be added when we build that

Yes!

> that many servers will do the same.  But there's a risk there.

The difference is that you do see data before you've got an confirmation from 
the other end. But yes, you are right, the sentence above is not correct 
neither. Will fix.

>    1-RTT establishment is used.

Yes.

> We closed #185.  (Section 3.3)

after the draft was submitted.

> routinely avoid sending a connection ID)

This was meant to address the case where a middlebox doesn't see any of the 
handshake but see the middle of the connection. In this case, if presented, 
seeing the same connection id on the reverse path, gives you a good hit that 
both ends actually want to talk to each other.

>    resumption mechanism provided by QUIC

This was more a comment for DDOS system. Today we don't have this kind of 
connection migration. There is a 'fear' that if quic's connection migration 
is not visible to the DDOS system it cannot handle quic traffic sufficiently. 
However, what happens if the middlebox doesn't know about the migration? The 
connection will break in a DDOS scenario, and quic has to reconnect... i 
don't think that actually a problem. However, I didn't want to give a 
recommendation that those system should not track migration yet, because we 
are still discussing how migration will work.

> authenticated public resets aren't a strict requirement, that will

Agreed.

> from a network, or whether networks really care about using MTU as a

Yes, would probably be good to say something. Let me try to figure out what 
we could usefully say here.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Mar 2017 10:09:11 +1100

On 17 March 2017 at 22:25, Mirja Kühlewind
<[email-masked]> wrote:
> and I think we need to give some advise here as well, especially if there
> are know assumptions we made in the protocol design about the application
> behavior or capabilities. Also the group is supposed to potentially
> recharter at some point to write more mapping documents. I also saw this
> document also as capturing what we learned from h2 for future mapping.

There's a real risk of mis-applying lessons when all you have is one
example.  See our discussion about closing connections and how
preconceptions based on experience with TCP have coloured that
discussion.

> That's a little bit an artifact from the previous version where
> manageability was included. But why do you think this is not interesting for
> this document? I think the two most important points in this document
> (fallback and 0-RTT) are directly connected to the fact that quic is
> encrypted by default.

I disagree.  Both of those are consequences of other aspects of the design.

> unencrypted TCP if TLS is blocked?

It's easy, you delete the word SHOULD and type the word MUST.

In HTTP, when you can't get TLS, you can't resolve an https:// URI.
We have a very clear rule that says that you prefer to fail than to
accept the risk of compromise.  This is critical to the functioning of
the protocol.

That might not be true for DNS over QUIC where the expectations for
security are - shall we say - lower.  But all this needs to say is
that if you have some security expectations and you find that fallback
would lead to them being in some way compromised, you fail.

> manageability draft there?

I'd remove the paragraph until we have something more concrete.

> that because we didn't really discuss this at all so far and I didn't want
> to lose it.

I'd recommend using an issue tracker for these sorts of things.

> prioritization of retransmission can only be done by quic.

That is where we come back to my earlier point.  I don't believe that
you can generically make sensible decisions about priority.  I believe
that this is why the working group decided to not include priority
signaling in the core transport.  I don't see how you can make any
better recommendation here.

> The point regarding the interface is actually another question I have.
> Should this document talk about the quic transport interface. How much
> advise to we want to give? Do we maybe even want to talk about an abstract
> api?

That's a big question.  If we do have anything, I suspect that it will
be useful to have a guide at some point.  What I'd do for this right
now is open an issue in the aforementioned tracker and sit on it.
We're too far away from settling on the details of the protocol to
come up with anything concrete right now.

> seeing this as general guidance for quic transport (and not for
> quic+tls+h2). As such I've been trying to capture guidance for future
> mappings and future versions of quic.

Revising the protocol to include a new cryptographic handshake
protocol is an exceptional circumstance that doesn't need optimizing
for.  If we have that many handshake protocols that it is a real
problem, we're in serious trouble.

> both ends actually want to talk to each other.

That only invalidates some of my points, leaving the last one.  I
think that you need to be very clear about what it is that you can see
here, the list above is probably a good thing to have.

> is not visible to the DDOS system it cannot handle quic traffic
> sufficiently. However, what happens if the middlebox doesn't know about the
> migration? The connection will break in a DDOS scenario, and quic has to
> reconnect... i don't think that actually a problem. However, I didn't want
> to give a recommendation that those system should not track migration yet,
> because we are still discussing how migration will work.

I see where you are going now.  That text probably just needs some
work.  Some expository text would be useful, I think.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 21 Mar 2017 16:30:01 -0700

> would lead to them being in some way compromised, you fail.

I am not sure that security expectations for DNS over QUIC should be
lower. I would expect DNS over QUIC to match the security of DNS over
TLS (RFC 7858).

We need consider the "game theory" aspects of any downgrade. If we allow
fall back to a non encrypted alternative, then we reward the attackers.
They block QUIC, observe the protocol silently switching to clear text,
get access to the data that they are seeking, and all that without
causing too many customer complaints. On the other hand, if blocking
QUIC just blocks the service, customers will complain, to the service
providers of course, but also very quickly to the intermediaries that
set the block. For these blockers, the support cost will be much higher.
And that means they will be less likely to block random services.

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Mar 2017 11:34:50 +1100

> lower. I would expect DNS over QUIC to match the security of DNS over

I did assumed that that did not exist, which might be unfair.

> And that means they will be less likely to block random services.

An excellent point.  Though you are condoning a denial of service
attack of a sort.  Not sure where I stand on the morality of that.

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 23 Mar 2017 13:26:30 +0100

I think one thing we easily can say it that if you fall back to TCP, you MUST fallback to TLS over TCP.

> Am 22.03.2017 um 01:34 schrieb Martin Thomson <[email-masked]>:
>