Subject: [saag] SAAG: Q re. https://tools.ietf.org/html/draft-wing-quic-network-req-00

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jun 2016 13:20:55 -0700

In Berlin there is a BOF for QUIC targeted to be WG forming. Today, QUIC
does not provide the same level of flow behavior visibility to the network
as TCP/HTTPs does. A lot of this visibility is used by middleboxes like
firewall to provide eg: DoS protection. If QUIC would take over from TCP
in the Internet and controlled networks, this would cause regression in
security for which no known alternatve solutions exist AFAIK.

An ask was raised for the target QUIC WG charter to discuss network-interaction/
flow visibility, but the mayority of people active in QUIC expressed a dedicated
desinterest in including this topic.

The problem and proposed solutions are nicely summarized in subject draft.

I am wondering how any part of the security area in the IETF is interested
in or would have opinions about how to deal with this problem.

Cheers
    Toerless

---

From: Ted Hardie <[email-masked]>
Date: Wed, 15 Jun 2016 14:05:33 -0700

Hi Toerless,

I've cc'ed Jana, so he's aware of this message, but I also wanted to point
out some of the comments Jana made to Joe and Dan on the ietf-quic list:

QUIC currently has most of the QUIC header fields encrypted and
> authenticated (invisible to the network), and some header fields
> authenticated but not encrypted (visible to the network but tamper
> resistant). The fields that are exposed have well-defined use cases ---
> Connection ID, for example, is visible and can be used by load-balancers to
> direct traffic belonging to a QUIC connection to the same server. I expect
> that these fields will be debated and discussed in the wg, and I think
> these considerations will be quite helpful when that conversation is
> underway. It'll be good to identify precisely which fields of QUIC that
> aren't currently exposed should be exposed (or vice versa), to have a
> debate in more concrete terms.
>

A lot the issues raised in the draft can already be handled by a box that
understands QUIC's format (in fact, using the Connection ID allows you to
scope consent better than a 5-tuple based would), but not many boxes do
yet.  Hopefully, if we do get the WG approved and the formats standardized,
that number will go up.

I understand Joe is also concerned about ossification of the format around
early versions, so I'd encourage folks interested in this from a middlebox
point of view to continue to treat this as evolving.

regards,

Ted

On Wed, Jun 15, 2016 at 1:20 PM, Toerless Eckert <[email-masked]> wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jun 2016 14:46:33 -0700

Thanks, Ted,

Inline

> yet.  Hopefully, if we do get the WG approved and the formats standardized,

Would it not be fair to have the working group charted to discuss/analyze those
type of statements instead of assuming them to be resolved by declaration ?
Thats effectively what the ask was against the charter.

> point of view to continue to treat this as evolving.

Good point. Yes, if QUIC is intentional or unintental hostile to middleboxes
by repeat change of middlebox relevant parts of its signature then this does
introduce an ongoing problem for middleboxes trying to secure the network.

Cheers
   Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Wed, 15 Jun 2016 15:03:57 -0700

On Wed, Jun 15, 2016 at 2:46 PM, Toerless Eckert <[email-masked]> wrote:

> Howdy,

As Jana's message points out, the ideal would be to discuss them in
concrete terms when we're talking about a specific protocol.  I think Joe
and Dan have made a stab at requirements that are more general than QUIC,
but QUIC has to answer those requirements with bits on the wire.  The
working group will, of course, be deciding what the bits on the wire are.

regards,

Ted

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jun 2016 15:11:08 -0700

Thanks, Ted

> working group will, of course, be deciding what the bits on the wire are.

If the working group does not want to acknowledge in the charter the need to
be at least on par with TCP when it comes to eg: enabling firewall protection, then
there is little chance of getting to the level of discussing the bits required to
do that, right ?

Cheers
    Toerless

---

From: Ted Hardie <[email-masked]>
Date: Wed, 15 Jun 2016 15:29:52 -0700

> there is little chance of getting to the level of discussing the bits
I'm not sure that "on par with TCP" is the right bar to set here.  QUIC
offers facilities that are not quite the same as TCP's, and those may get
used in ways that differ from TCP's.  This isn't about hostility to anyone;
it's about the trade-offs that need to be made.  The working group will
make those trade-offs (if it is chartered, obviously) and express them as
bits on the wire.

regards,

Ted

Cheers
> > > > > firewall to provide eg: DoS protection. If QUIC would take over
> from
> > > TCP
> > > > > flow visibility, but the mayority of people active in QUIC
> expressed a
> > > > > dedicated

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jun 2016 16:24:51 -0700

Thanks Ted

I still do not understand why you would not approve of a statement 
for the WG charter wrt. to reviewing the interaction (implicit) between QUIC
and middleboxes, eg: compare with TCP and explicitly weigh security vs. functionality
benefits.

Cheers
    Toerless

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 Jun 2016 16:51:34 -0700

Toerless,

(I am surprised to see this post on SAAG; folks in SAAG who are interested
in QUIC are quite likely on [email-masked] already. I'd like to respond to
this email thread here, but there is an ongoing thread in [email-masked]
about this draft; I suggest that we continue this discussion on that list.)

It's wrong at best to characterize the response to the draft on the QUIC
list as a "dedicated disinterest", when the response is really a
stipulation that "there's nothing to be done with this draft yet." It's
also wrong at best to say that that's the opinion of "the majority of the
people active in QUIC", when there are exactly 3 people who responded to
the draft on the QUIC list, all in their capacities as individuals.

It is disingenuous to suggest that there's no interest in solving for
middleboxes in QUIC, when the QUIC charter states one of the goals as
"Enabling deployment over unmodified Internet paths". If middleboxes exist
on path in the Internet, then this goal covers them. I think the sentiment
I've heard on the list (and agreed with) is that the problem the draft is
stating is not yet precisely defined in terms of the QUIC protocol, and
it's not clear that the sub-problems in the draft all need solving.
Specifically, the bits you are asking for may already be there. For the
ones that aren't already there, the wg will have to decide if it cares or
not.

But the interest is in a concrete conversation around engineering a
solution to a specific problem, not around an abstract one about a broad
functional problem, such as "enable firewall protection".

- jana

On Wed, Jun 15, 2016 at 3:29 PM, Ted Hardie <[email-masked]> wrote:

>> > > by repeat change of middlebox relevant parts of its signature then
>> this
>> > > does
>> > > > > In Berlin there is a BOF for QUIC targeted to be WG forming.
>> Today,
>> > > QUIC
>> > > > > The problem and proposed solutions are nicely summarized in
>> subject
>> > > draft.
>> > > > >

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jun 2016 18:13:10 -0700

Thanks, Jana

1. Every customer with a firewall or similar network security device
will want to understand how QUIC will compare to TCP/HTTPs in terms of attacks,
how well the security device can protect against them and if QUIC has
taken the necessary steps not to regress behind TCP in the achievable security,
or if it does, why so. Who should produce the answer to these questions in your
opinion ?

I can not find in the tentative charter anything that tells me if the WG will produce
answer to these questions, and i wonder why this would be contentuous.

2. On average, discussions on a non-security area WG are mostly full of stuff
irrelevant for security experts. Therefore saag is providing a forum for those
groups to reach out to a broad base of IETF security experts and focus
specifically on security issues. Without such a mechanism, security experts
would be extremely thin stretched tracking a lot WG mailing lists and filtering
out security aspects. Likewise, this ia AFAIK the main reason why SAAG meetings
at the IETF have presentations/review of all those WGs wrt. to their security
aspects.

Cheers
    Toerless