Draft: draft-ietf-quic-transport

Commentary: We were n't being consistent . This should help . 
 said : 
 The first here is in the process of being addressed , see . I agree regarding " strong " , but also agree regarding what to do about it . My proposal is to let close this issue . 
 said : 
 Proposed resolution is 
 This is an improvement . Thanks .
Paragraph (version B):
Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201)
relies on reception of ICMP messages (e.g., IPv6 Packet Too Big
messages) that indicate when an IP packet is dropped because it is
larger than the local router MTU.  DPLPMTUD can also optionally use
these messages.  This use of ICMP messages is potentially vulnerable
to attacks by entities that cannot observe packets but might
successfully guess the addresses used on the path.  These attacks
could reduce the PMTU to a bandwidth-inefficient value.
Paragraph (version B):
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
from packet injection as specified in RFC8201 and Section 5.2 of
RFC8085.  This validation SHOULD use the quoted packet supplied in
the payload of an ICMP message to associate the message with a
corresponding transport connection (see Section 4.6.1 of DPLPMTUD).
ICMP message validation MUST include matching IP addresses and UDP
ports (RFC8085) and, when possible, connection IDs to an active QUIC
session.  The endpoint SHOULD ignore all ICMP messages that fail
validation.
Paragraph (version A):
The server MUST include the value from the Source Connection ID field
of the packet it receives in the Destination Connection ID field.
The value for Source Connection ID MUST be copied from the
Destination Connection ID of the received packet, which is initially
randomly selected by a client.  Echoing both connection IDs gives
clients some assurance that the server received the packet and that
the Version Negotiation packet was not generated by an off-path
attacker.
Paragraph (version B):
The server MUST include the value from the Source Connection ID field
of the packet it receives in the Destination Connection ID field.
The value for Source Connection ID MUST be copied from the
Destination Connection ID of the received packet, which is initially
randomly selected by a client.  Echoing both connection IDs gives
clients some assurance that the server received the packet and that
the Version Negotiation packet was not generated by an entity that
did not observe the Initial packet.
Paragraph (version A):
In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys
(Initial keys) as described in QUIC-TLS.  This protection does not
provide confidentiality or integrity against on-path attackers, but
provides some level of protection against off-path attackers.
Paragraph (version B):
In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys
(Initial keys) as described in QUIC-TLS.  This protection does not
provide confidentiality or integrity against attackers that can
observe packets, but provides some level of protection against
attackers that cannot observe packets.
Paragraph (version B):
Clients MUST discard Retry packets that have a Retry Integrity Tag
that cannot be validated; see the Retry Packet Integrity section of
QUIC-TLS.  This diminishes an attacker's ability to inject a Retry
packet and protects against accidental corruption of Retry packets.
A client MUST discard a Retry packet with a zero-length Retry Token
field.
Paragraph (version B):
Attackers are additionally categorized as either on-path attackers or
off-path attackers.  An on-path attacker can read, modify, or remove
any packet it observes such that it no longer reaches its
destination, while an off-path attacker observes the packets, but
cannot prevent the original packet from reaching its intended
destination.  Both types of attackers can also transmit arbitrary
packets.  This definition differs from that of Section 3.5 of SEC-
CONS in that an off-path attacker is able to observe packets.
Paragraph (version B):
An off-path attacker can create modified copies of packets that it
has observed and inject those copies into the network, potentially
with spoofed source and destination addresses.
Paragraph (version B):
For the purposes of this discussion, it is assumed that an off-path
attacker has the ability to inject a modified copy of a packet into
the network that will reach the destination endpoint prior to the
arrival of the original packet observed by the attacker.  In other
words, an attacker has the ability to consistently "win" a race with
the legitimate packets between the endpoints, potentially causing the
original packet to be ignored by the recipient.