RE: Middlebox introspection/self-describing packets

[Dave Dolson <[e-mail]>]

Within the context of PLUS, we have attempted to assemble a list of benefits provided by on-path middleboxes.
Please see https://tools.ietf.org/html/draft-dolson-plus-middlebox-benefits-02

>From the abstract:

   A primary goal of this document is to provide information to working
   groups developing new transport protocols, in particular the PLUS and
   QUIC working groups, to aid understanding of what might be gained or
   lost by design decisions that may affect (or be affected by)
   middlebox operation.

The authors hope this will provide context for discussion about what sorts of middlebox functions are worth supporting.
We believe many important diagnostic and network protection mechanisms require some visibility into the transport connection, without violating privacy.

Please take a look.

-Dave



________________________________
From: QUIC [[e-mail]] on behalf of Martin Duke [[e-mail]]
Sent: Wednesday, March 08, 2017 6:43 PM
To: Brian Trammell
Cc: Eric Rescorla; IETF QUIC WG
Subject: Re: Middlebox introspection/self-describing packets

I have a substantially different position on middlebox inspection. First is the load balancing point, which many people have already made.

Second, service providers have an interest in (1) measuring the quality of service they provide to customers, (2) enforcing bandwidth limitations, etc. on users, and (3) identifying application types to provide QoS where it matters. I think (1) and (2) can be done without a meaningful loss of privacy, although (3) is highly problematic. To that end, there are a number of open issues looking to expose some transport state to middleboxes:
- Packet number echo to allow RTT measurements (#269)
- ECN to allow a non-loss rate-limiting signal (replacing TCP zero-window) (#68)
- Public flag bits to indicate flow-control and loss-detection causes of throttling, to aid in troubleshooting (#279) - I believe it was someone from Orange in Tokyo who asked "how am I going to troubleshoot this?"
- Replacing CONNECTION_CLOSE to an authenticated Public Reset to clear connection state on middleboxes. (#353)

No one has yet demonstrated that any of these are meaningful losses of privacy. They also require no modifications to the packet itself.

For all the above reasons I am somewhat concerned about all of the surreptitious connection-ID changes, but I think all of these features are valuable regardless of how those discussions turn out.

On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell <[e-mail]<mailto:[e-mail]>> wrote:
hi ekr,

The point in this space I'd use is “expose nothing without necessity, or clear benefit with mutual cooperation of the endpoints, but ensure exposed information is efficiently usable.”

> On 8 Mar 2017, at 22:38, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:
>
> There's recently been some back and forth on the headers PR about the
> value of having packets be self-describing so that middleboxes can parse
> them.
>
> To take a concrete example, consider the connection_id. In general, it seems
> that mostly packets in a given direction either need connection_ids or don't
> (assuming that the point of connection_id is partly to handle unexpected
> NAT rebinding.), so this seems like a prime thing to negotiate. Jana argued
> in the PR that the reason to have a bit is to allow middleboxes to know how
> to parse the packet.

Taking the case of Connection ID, specifically, it does seem to be a candidate for moving to negotiation, saving one header bit pretty much everywhere. Connection ID is designed for load balancers, and one could define negotiation to be mandatory on the client side: if the server gives you a connection ID, then the client MUST return it. Otherwise, any device trying to observe the Connection ID would have to keep the has-a-Connection-ID state observed during the negotiation, and it wouldn't have access to that state when the Connection ID is used during rebinding.

In this case, saving the bit costs you the possibility of client-side choice on whether to not return the Connection ID, which seems to me to violate the mutual cooperation principle.

Cheers,

Brian


>
> It seems like it would be good to come to agreement about our attitude towards
> middlebox inspection. I have been generally taking the position that we should
> conceal as much as possible from middleboxes and only expose what is needed
> to make the protocol work (i.e., if possible I would encrypt conn_id and packet
> number). It seems like perhaps not everyone shares that objective, so I thought
> I would ask what principles other people thought they were adhering to.
>
> Jana? MT? Others?
>
> -Ekr
>
>
>