Draft: draft-ietf-quic-manageability

Commentary: This section contains a series , of assumed editorial comments . ( The issue is copied from the QUIC WG list ) . “ Even thought this bit is fixed in the QUICv1 specification , ” This seems like the wrong word : /thought / though/ “ observers can not reliably use “ -Maybe we could avoid “ reliably ” , e.g. : /cannot depend on this bit as/ ... “ first octet in the short packet header . ” would probably benefit from an indication of bit ordering and cross - reference to the QUIC spec . Sect 2.4 : “ In the nominal case ” - this use of “ nominal ” was unusual to me , the word is used differently in different English - speaking regions - in some it might mean “ marginal ” or only correct at the current time - in other regions it might mean something else . Is “ normal ” acceptable in this sentence ? Section 2.3 : “ We therefore consider ” - who is the “ we ” , suggest something like “ These are considered ... ” “ in the clear ” - would be simpler as “ without encryption ” or “ observable on - path ” ? The term “ exposes ” is used several times , without saying to whom , which I think in the context of this document , could be clearer as “ exposes this , making it visible to an on - path observer ” . Also this form of wording is consistent with sect 2.7 . This also could help explain this in a more positive light to someone wishing to manage a network . Sect 2.4 : “ The amount of 0 - RTT protected data is limited by the initial congestion window , typically around 10 packets [ RFC6928 ] . ” I suggest this should instead be reference to a section in the QUIC spec . ( This does in turn point to 6928 , but I think the dependency here is on what QUIC says . ) Sect 2.8 ” : ... ” any manipulation of ... will be detected ” I think the word “ manipulation ” hints like it is illicit , can we use neutral language by saying something like “ any change by network devices on - path ” ? Sect 3.1 : “ First , it only provides one bit of information and is quite prone to collide with UDP - based protocols other than those that this static bit is meant to allow multiplexing with . “ This seems to lack a little polish ( “ quite prone ” , “ meant to ” ) . Sect 3.3.1 . /through passive measurement / by observation by an on - path observer/ ... I think this applies , whether it is measurement , filtering , whatever , so we could use the same term . /which each one byte of zeros/ ... seems an odd set of words to me . Section 4.1 : “ Keying state off the connection ID may therefore cause undetectable and unrecoverable loss of state in the middle of a connection . Use of connection ID specifically discouraged for NAT applications . ” ... I did n’t find /Keying state/ very helpful ... maybe some other words would be clearer . The second sentence seems to miss /is/ ? Sect 4.6 : “ Distinguishing ACK packets is trivial in TCP , “ well , this is not really trivial , because there are pure ACKs and  which makes this complicated . RFC3449 says more . 
 thank you very much for opening individual issues ! Just checking that this issue here is supposed to be a meta - issue to track the individual other ones you opened ? 
 This one is a bunch of editorial NiTs . The editors might like to scan these and check if these are purely text comments they can correct . If there are specifics they wish to pull - out as issues as more than simple text changes , I 'd expect this to be closed and they can make separate issues for those that require discussion . 
 All suggestions except the following accepted without comment ; many thanks for the detailed review ! I 'm going to consider The term “ exposes ” is used several times , without saying to whom as a stylistic suggestion , and decline to address . I do n't think there 's a better way to say this without making the flow much more awkward . Please reopen this issue after closure if you disagree strongly . 
 Thanks  I am quite willing to read it this way , this issue should be closed ,    , some small  's suggestions .
Paragraph (version A):
"fixed bit": the second most significant bit of the first octet
most QUIC packets of the current version is currently set to 1,
for endpoints to demultiplex with other UDP-encapsulated
protocols.  Even thought this bit is fixed in the QUICv1
specification, endpoints may use a version or extension that
varies the bit.  Therefore, observers cannot reliably use it as an
identifier for QUIC.
Paragraph (version B):
"fixed bit": the second most significant bit of the first octet
most QUIC packets of the current version is currently set to 1,
for endpoints to demultiplex with other UDP-encapsulated
protocols.  Even thought this bit is fixed in the QUICv1
specification, endpoints may use a version or extension that
varies the bit.  Therefore, observers cannot depend on it as an
identifier for QUIC.
Paragraph (version A):
In the nominal case, the QUIC handshake can be recognized on the wire
through at least four datagrams we'll call "QUIC Client Hello", "QUIC
Server Hello", and "Initial Completion", and "Handshake Completion",
for purposes of this illustration, as shown in fig-handshake.
Paragraph (version B):
The QUIC handshake can normally be recognized on the wire through at
least four datagrams we'll call "QUIC Client Hello", "QUIC Server
Hello", and "Initial Completion", and "Handshake Completion", for
purposes of this illustration, as shown in fig-handshake.
Paragraph (version A):
The content of QUIC Initial packets are encrypted using Initial
Secrets, which are derived from a per-version constant and the
client's destination connection ID; they are therefore observable by
any on-path device that knows the per-version constant.  We therefore
consider these as visible in our illustration.  The content of QUIC
Handshake packets are encrypted using keys established during the
initial handshake exchange, and are therefore not visible.
Paragraph (version B):
The content of QUIC Initial packets are encrypted using Initial
Secrets, which are derived from a per-version constant and the
client's destination connection ID; they are therefore observable by
any on-path device that knows the per-version constant.  They are
therefore considered visible in this illustration.  The content of
QUIC Handshake packets are encrypted using keys established during
the initial handshake exchange, and are therefore not visible.
Paragraph (version A):
The Client Hello datagram exposes version number, source and
destination connection IDs in the clear.  Information in the TLS
Client Hello frame, including any TLS Server Name Indication (SNI)
present, is obfuscated using the Initial secret.  Note that the
location of PADDING is implementation-dependent, and PADDING frames
may not appear in a coalesced Initial packet.
Paragraph (version B):
The Client Hello datagram exposes version number, source and
destination connection IDs without encryption.  Information in the
TLS Client Hello frame, including any TLS Server Name Indication
(SNI) present, is obfuscated using the Initial secret.  Note that the
location of PADDING is implementation-dependent, and PADDING frames
may not appear in a coalesced Initial packet.
Paragraph (version A):
In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only
present if necessary to increase the size of the datagram with 0RTT
data to at least 1200 bytes.  Additional datagrams containing only
0-RTT protected long header packets may be sent from the client to
the server after the Client Hello datagram, containing the rest of
the 0-RTT data.  The amount of 0-RTT protected data is limited by the
initial congestion window, typically around 10 packets RFC6928.
Paragraph (version B):
In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only
present if necessary to increase the size of the datagram with 0RTT
data to at least 1200 bytes.  Additional datagrams containing only
0-RTT protected long header packets may be sent from the client to
the server after the Client Hello datagram, containing the rest of
the 0-RTT data.  The amount of 0-RTT protected data is limited by the
initial congestion window, typically around 10 packets (see
Section 7.2 of QUIC-RECOVERY).
Paragraph (version A):
Version Negotiation packets are not intrinsically protected, but QUIC
versions can use later encrypted messages to verify that they were
authentic.  Therefore any manipulation of this list will be detected
and may cause the endpoints to terminate the connection attempt.
Paragraph (version B):
Version Negotiation packets are not intrinsically protected, but QUIC
versions can use later encrypted messages to verify that they were
authentic.  Therefore any modification of this list will be detected
and may cause the endpoints to terminate the connection attempt.
Paragraph (version A):
While the second most significant bit (0x40) of the first octet is
set to 1 in most QUIC packets of the current version (see public-
header), this method of recognizing QUIC traffic is NOT RECOMMENDED.
First, it only provides one bit of information and is quite prone to
collide with UDP-based protocols other than those that this static
bit is meant to allow multiplexing with.  Second, this feature of the
wire image is not invariant QUIC-INVARIANTS and may change in future
versions of the protocol, or even be negotiated during the handshake
via the use of transport parameters.
Paragraph (version B):
While the second most significant bit (0x40) of the first octet is
set to 1 in most QUIC packets of the current version (see public-
header and section 17 of QUIC-TRANSPORT), this method of recognizing
QUIC traffic is not reliable.  First, it only provides one bit of
information and is prone to collision with UDP-based protocols other
than those that this static bit is meant to allow multiplexing with.
Second, this feature of the wire image is not invariant QUIC-
INVARIANTS and may change in future versions of the protocol, or even
be negotiated during the handshake via the use of transport
parameters.
Paragraph (version A):
Work is currently underway in the TLS working group to encrypt the
SNI in TLS 1.3 TLS-ESNI.  This would make SNI-based application
identification impossible through passive measurement for QUIC and
other protocols that use TLS.
Paragraph (version B):
Work is currently underway in the TLS working group to encrypt the
SNI in TLS 1.3 TLS-ESNI.  This would make SNI-based application
identification impossible by on-path observation for QUIC and other
protocols that use TLS.
Paragraph (version A):
After decryption, the Initial Client packet can be parsed to detect
the CRYPTO frame that contains the TLS Client Hello, which then can
be parsed similarly to TLS over TCP connections.  The Initial client
packet may contain other frames, so the first bytes of each frame
need to be checked to identify the frame type, and if needed skip
over it.  Note that the length of the frames is dependent on the
frame type.  In QUIC version 1, the packet is expected to only carry
the CRYPTO frame and optionally padding frames.  However, PADDING
frames, which are each one byte of zeros, may also occur before or
after the CRYPTO frame.
Paragraph (version B):
After decryption, the Initial Client packet can be parsed to detect
the CRYPTO frame that contains the TLS Client Hello, which then can
be parsed similarly to TLS over TCP connections.  The Initial client
packet may contain other frames, so the first bytes of each frame
need to be checked to identify the frame type, and if needed skip
over it.  Note that the length of the frames is dependent on the
frame type.  In QUIC version 1, the packet is expected to only carry
the CRYPTO frame and optionally padding frames.  However, PADDING
frames, each consisting of a single zero byte, may also occur before
or after the CRYPTO frame.
Paragraph (version A):
RFC4787 requires a timout that is not less than 2 minutes for most
UDP traffic.  However, in pratice, timers are often lower, in the
range of 15 to 30 seconds.  In contrast, RFC5382 recommends a timeout
of more than 2 hours for TCP, given that TCP is a connection-oriented
protocol with well-defined closure semantics.  For network devices
that are QUIC-aware, it is recommended to also use longer timeouts
for QUIC traffic, as QUIC is connection-oriented.  As such, a
handshake packet from the server indicates the willingness of the
server to communicate with the client.
Paragraph (version B):
RFC4787 requires a timeout that is not less than 2 minutes for most
UDP traffic.  However, in pratice, timers are often lower, in the
range of 15 to 30 seconds.  In contrast, RFC5382 recommends a timeout
of more than 2 hours for TCP, given that TCP is a connection-oriented
protocol with well-defined closure semantics.  For network devices
that are QUIC-aware, it is recommended to also use longer timeouts
for QUIC traffic, as QUIC is connection-oriented.  As such, a
handshake packet from the server indicates the willingness of the
server to communicate with the client.
Paragraph (version A):
The QUIC header optionally contains a connection ID which can be used
as additional entropy beyond the 5-tuple, if needed.  The QUIC
handshake needs to be observed in order to understand whether the
connection ID is present and what length it has.  However, connection
IDs may be renegotiated during a connection, and this renegotiation
is not visible to the path.  Keying state off the connection ID may
therefore cause undetectable and unrecoverable loss of state in the
middle of a connection.  Use of connection ID specifically
discouraged for NAT applications.
Paragraph (version B):
The QUIC header optionally contains a connection ID which can be used
as additional entropy beyond the 5-tuple, if needed.  The QUIC
handshake needs to be observed in order to understand whether the
connection ID is present and what length it has.  However, connection
IDs may be renegotiated during after the handshake, and this
renegotiation is not visible to the path.  Using the connection ID as
a flow key field for stateful treatment of flows may therefore cause
undetectable and unrecoverable loss of state in the middle of a
connection.  Use of connection IDs is specifically discouraged for
NAT applications.
Paragraph (version A):
Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling.  Distinguishing ACK
packets is trivial in TCP, but not supported by QUIC, since
acknowledgment signaling is carried inside QUIC's encrypted payload,
and ACK manipulation is impossible.  Specifically, heuristics
attempting to distinguish ACK-only packets from payload-carrying
packets based on packet size are likely to fail, and are not
recommended to use as a way to construe internals of QUIC's operation
as those mechanisms can change, e.g., due to the use of extensions.
Paragraph (version B):
Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling.  Distinguishing pure ACK
packets is easy in TCP, but not supported by QUIC, since
acknowledgment signaling is carried inside QUIC's encrypted payload,
and ACK manipulation is impossible.  Specifically, heuristics
attempting to distinguish ACK-only packets from payload-carrying
packets based on packet size are likely to fail, and are not
recommended to use as a way to construe internals of QUIC's operation
as those mechanisms can change, e.g., due to the use of extensions.