Draft: draft-ietf-quic-manageability

Commentary: Feel free to close this if it 's out of scope , but creating a proxy that attempts to passively observe QUIC is much more complex and potentially problematic than TLS over TCP . For example , all major OS 's have mature TCP implementations , whereas a MITM would have to pull in its own QUIC implementation . If it does so , it would be important that 's it 's both conformant to IETF specifications and have good performance . This is the full L7 termination case , which is possible , but a lot of work , and we should heavily encourage anyone doing this to use an existing("good " ) implementation . A potential MITM option is to attempt to terminate the handshake , but then only observe ApplicationData packets . However , this could go wrong in many ways , so I believe it should be strongly discouraged . QUIC is designed as an end - to - end protocol and efforts to change that are likely to end very poorly . For example , if the length of the CID changes , then the offset of the header changes and a middlebox who does n't track all CIDs both peers may be unable to decrypt packets . I 'm sure there are more gotchas , particularly with the introduction of extensions . It may also be worth pointing out that QUIC frames are not TLV , so any frames(ie : extensions ) that are not understood cause all other frames to be unparseable . Thanks to for the specific examples of ways this could fail . 
 Still trying to figure out what my thinking is her , but it sounds a bit like you propose something like " If you want to implement a QUIC MITM , please terminate the whole connection up to L7 and use an existing library . " Note sure that is actually giving quite there right message .... 
 As a user 's guide to the wire image , one of the base assumptions we make is that access to the wire image is read only . We should definitely be more explicit about this . We also need an explicit statement that MITM is out of scope for this doc and if you want to , terminate at L7 and congrats , now everything in -transport and -tls ( and , realisitically , -http ) applies .
Paragraph (version A):
Of course, network management is not a one-size-fits-all endeavour:
practices considered necessary or even mandatory within enterprise
networks with certain compliance requirements, for example, would be
impermissible on other networks without those requirements.  This
document therefore does not make any specific recommendations as to
which practices should or should not be applied; for each practice,
it describes what is and is not possible with the QUIC transport
protocol as defined.
Paragraph (version B):
Since QUIC's wire image WIRE-IMAGE is integrity protected and not
modifiable on path, in-network operations are not possible without
terminating the QUIC connection, for instance using a back-to-back
proxy.  Proxy operations are not in scope for this document.  QUIC
proxies must be fully-fledged QUIC endpoints, implementing the
transport as defined in QUIC-TRANSPORT and QUIC-TLS as well as proxy-
relevant semantics for the application(s) running over QUIC (e.g.
HTTP/3 as defined in QUIC-HTTP).
Paragraph (version B):
Network management is not a one-size-fits-all endeavour: practices
considered necessary or even mandatory within enterprise networks
with certain compliance requirements, for example, would be
impermissible on other networks without those requirements.  This
document therefore does not make any specific recommendations as to
which practices should or should not be applied; for each practice,
it describes what is and is not possible with the QUIC transport
protocol as defined.
Paragraph (version A):
In this section, we discusses those aspects of the QUIC transport
protocol that have an impact on the design and operation of devices
that forward QUIC packets.  Here, we are concerned primarily with
QUIC's unencrypted wire image WIRE-IMAGE, which we define as the
information available in the packet header in each QUIC packet, and
the dynamics of that information.  Since QUIC is a versioned
protocol, the wire image of the header format can also change from
version to version.  However, at least the mechanism by which a
receiver can determine which version is used and the meaning and
location of fields used in the version negotiation process is
invariant QUIC-INVARIANTS.
Paragraph (version B):
In this section, we discusses those aspects of the QUIC transport
protocol that have an impact on the design and operation of devices
that forward QUIC packets.  Here, we are concerned primarily with the
unencrypted part of QUIC's wire image WIRE-IMAGE, which we define as
the information available in the packet header in each QUIC packet,
and the dynamics of that information.  Since QUIC is a versioned
protocol, the wire image of the header format can also change from
version to version.  However, at least the mechanism by which a
receiver can determine which version is used and the meaning and
location of fields used in the version negotiation process is
invariant QUIC-INVARIANTS.