Subject: [quicwg/base-drafts] Updated ICMP PMTU section (#1412)

From: Igor Lubashev <[email-masked]>
Date: Mon, 04 Jun 2018 19:54:40 -0700

Per request of the editors, here is a draft PR for ICMP PMTU section.
I am deliberately not including text for #1243 here.  (That can be a subsequent PR.)
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1412

-- Commit Summary --

  * Updated ICMP PMTU section

-- File Changes --

    M draft-ietf-quic-transport.md (101)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1412.patch
https://github.com/quicwg/base-drafts/pull/1412.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412

---

From: ianswett <[email-masked]>
Date: Sat, 09 Jun 2018 09:12:59 -0700

ianswett commented on this pull request.

This looks good, but I'd like someone who's more of an expert in ICMP to read it, so I'm adding @martinduke 

> @@ -3228,6 +3261,18 @@ increases in the size of probe packets. As QUIC probe packets need not contain
 application data, aggressive increases in probe size carry fewer consequences.

+## Responding to ICMP "Unreachable" messages {#icmp-unreach}
+
+When a QUIC endpoint receives an ICMP "Unreachable" message during a handshake,
+the response SHOULD be identical to receiving an ICMP TPB message that announces
+a Path MTU smaller than 1280 octets (see {{icmp-pmtu}}).
+
+When an ICMP "Unreachable" message is received after the handshake, the QUIC
+endpoint should send a PATH_CHALLENGE frame ({{frame-path-challenge}}).  Sending
+PATH_CHALLENGE frames on the same path due to ICMP "Unreachable" messages should
+be rate limited.

To what?  How about one outstanding PATH_CHALLENGE at once?

-As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps to
-mitigate this risk. For instance, an application could:
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by this endpoint with at least 1-2^32
+probability and it is still outstanding (not acknowledged and not deemed lost).
+If a QUIC endpoint does not perform this minimum validation, it SHOULD treat the
+packet as an ICMP message without an on-path proof.
+
+As noted in {{?RFC5927}}, using ICMP messages without an on-path proof exposes
+the protocol implementation to off-path attacks and requires mitigations.
+
+Even ICMP messages without an on-path proof SHOULD undergo some validation, such
+as:
 
 * Set the IPv4 Don't Fragment (DF) bit on a small proportion of packets, so that

I thought we were recommending setting DF on all packets?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#pullrequestreview-127371213

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Jun 2018 09:51:18 -0700

martinthomson commented on this pull request.

Thanks for doing this Igor.

This is a lot of new words, but generally good.  I think that we probably need to do something to break this up a little.

I also think that implementations will not be able to save anything of the IP ID, and won't be inclined to save anything from the packet.  So we might want to suggest a mode switch when a packet is received.

> @@ -3157,9 +3157,9 @@ header, protected payload, and any authentication fields.
 All QUIC packets SHOULD be sized to fit within the estimated PMTU to avoid IP
 fragmentation or packet drops. To optimize bandwidth efficiency, endpoints
 SHOULD use Packetization Layer PMTU Discovery ({{!PLPMTUD=RFC4821}}).  Endpoints
-MAY use PMTU Discovery ({{!PMTUDv4=RFC1191}}, {{!PMTUDv6=RFC8201}}) for
-detecting the PMTU, setting the PMTU appropriately, and storing the result of
-previous PMTU determinations.
+MAY use classical PMTU Discovery ({{!PMTUDv4=RFC1191}}, {{!PMTUDv6=RFC8201}})

"classical" isn't a useful description of the mechanism.  If you need to distinguish this between PLPMTUD, talk about using ICMP feedback.

> -Traditional ICMP-based path MTU discovery in IPv4 {{!PMTUDv4}} is potentially
-vulnerable to off-path attacks that successfully guess the IP/port 4-tuple and
-reduce the MTU to a bandwidth-inefficient value. TCP connections mitigate this
-risk by using the (at minimum) 8 bytes of transport header echoed in the ICMP
-message to validate the TCP sequence number as valid for the current
-connection. However, as QUIC operates over UDP, in IPv4 the echoed information
-could consist only of the IP and UDP headers, which usually has insufficient
-entropy to mitigate off-path attacks.
+ICMP error messages used in classical Path MTU discovery may be classified into
+messages with an on-path proof and without an on-path proof.  ICMP messages with
+an on-path proof are the messages sent in accordance with {{!ICMPv6=RFC4443}},
+which requires ICMPv6 error messages to contain "as much of invoking packet as
+possible without the ICMPv6 packet exceeding the minimum IPv6 MTU", and
+{{!RFC1812}}, which states that ICMPv4 error messages "SHOULD contain as much of
+the original datagram as possible without the length of the ICMP datagram
+exceeding 576 bytes".  ICMP messages without an on-path prooff are sent in

typo: prooff

How does one make this determination?

 * Set the IPv4 Don't Fragment (DF) bit on a small proportion of packets, so that
-most invalid ICMP messages arrive when there are no DF packets outstanding, and
-can therefore be identified as spurious.
+  most invalid ICMP messages arrive when there are no DF packets outstanding,
+  and can therefore be identified as spurious.
+
+* Store IP ID field of the sent datagrams to validate that ICMP message is
+  refering to an outstanding packet.

More IPv4 advice, which should be called out as such.  I don't think that senders will remember this if it is not predictable.

> +  most invalid ICMP messages arrive when there are no DF packets outstanding,
+  and can therefore be identified as spurious.
+
+* Store IP ID field of the sent datagrams to validate that ICMP message is
+  refering to an outstanding packet.
+
+Any ICMP messages that fail validation MUST be discarded.
+
+It is important that any problems are detected quickly during the connection
+handshake, because the client may be able to mitigate them by switching to
+alternative IP addresses or protocols.  Hence, an endpoint SHOULD reduce Path
+MTU in response to an ICMP Packet Too Big (PTB) message during a handshake,
+unless then would cause a reduction to a Path MTU value smaller than 1280
+octets.
+
+If during a handshake a client receives an ICMP TPB message that requests it to

PTB?

> +  refering to an outstanding packet.
+
+Any ICMP messages that fail validation MUST be discarded.
+
+It is important that any problems are detected quickly during the connection
+handshake, because the client may be able to mitigate them by switching to
+alternative IP addresses or protocols.  Hence, an endpoint SHOULD reduce Path
+MTU in response to an ICMP Packet Too Big (PTB) message during a handshake,
+unless then would cause a reduction to a Path MTU value smaller than 1280
+octets.
+
+If during a handshake a client receives an ICMP TPB message that requests it to
+reduce Path MTU to a value smaller than 1280 octets, then:
+
+* If the client has another IP address for the server to try, the client should
+  restart the connection to another IP.

SHOULD?

> +  and can therefore be identified as spurious.
+
+* Store IP ID field of the sent datagrams to validate that ICMP message is
+  refering to an outstanding packet.
+
+Any ICMP messages that fail validation MUST be discarded.
+
+It is important that any problems are detected quickly during the connection
+handshake, because the client may be able to mitigate them by switching to
+alternative IP addresses or protocols.  Hence, an endpoint SHOULD reduce Path
+MTU in response to an ICMP Packet Too Big (PTB) message during a handshake,
+unless then would cause a reduction to a Path MTU value smaller than 1280
+octets.
+
+If during a handshake a client receives an ICMP TPB message that requests it to
+reduce Path MTU to a value smaller than 1280 octets, then:

I think that this disagrees with the conclusion of the working group - we agreed that a PMTU of 1280 was necessary to support QUIC and that the response to a reduction in size was to ignore the signal.  If the signal is true, this causes the connection to fail, but that's OK.

-* Any reduction in PMTU due to a report contained in an ICMP packet is
+If an ICMP PTB message is received after handshake, and the claimed Path MTU is
+at least 1280 octets for messages with on-path validation or 1392 for messages

Where did this 1392 come from?

SHOULD?

If "SHOULD", how does an endpoint decide to do this (or not).  If it is purely a rate-limiting thing, then maybe different words would help.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#pullrequestreview-127640520

---

From: MikkelFJ <[email-masked]>
Date: Mon, 11 Jun 2018 10:11:55 -0700

mikkelfj commented on this pull request.

I also wondered ...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r194478406

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 11 Jun 2018 11:19:15 -0700

igorlord commented on this pull request.

That was one of the original proposals.  But I agree -- this is not the best idea.  I'll revise.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r194499005

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 10:50:59 -0700

@igorlord pushed 28 commits.

3cb44ee  Set TLS extension codepoint to 0xffa5
8081d70  What if invariants change?
74a0e43  Which witch?
33b7f3a  Things, properties
342e647  Fix variable-length fields in picture
93b9900  Add PUSH_PROMISE xref
df786b9  Rewrap
9f171d0  Remove sequence number from NEW_CONNECTION_ID
b052fa4  Remove Flags (#1398)
e7b9cca  Coalescing guidance
9ef7802  HTTP/QUIC specific, not HTTP-specific
9c327ec  Include decryption failures
5d6ab28  fix typo
984efe0  fix typo (#1434)
1d02e03  Don't cite octet indices any more
b421f5b  No mixing CIDs
4567f7b  Move Draft Version Identification section
1a1fc7f  Kazuho's suggestion
8002125  Statement of idempotency
d52a00e  Say why
9d92555  Remove stream sequencing requirement; obsoleted by implicit-open of streams
df94970  Re-"framing"
d2756b6  "End Header Block" does not exist
3f4d7f9  Expand Primitives section
49c2b08  exercise editorial discretion
73fb978  Fix sentence: make clear what fails with PROTOCOL_VIOLATION code
05ecc25  Describe QPACK Feedback mechanisms (#1410)
de84e82  Updated ICMP PMTU section: incorporating feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412/files/160afb012b00075d8716df39414edc138029e332..de84e82636bd7ffd6df51eb1caf3cf9670bd62eb

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 11:50:41 -0700

I'll rewrite this completely.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196186262

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 11:53:57 -0700

How strongly do you feel against word "classical"?  It is used in other RFCs for the purpose I am using it here.  See https://tools.ietf.org/html/rfc4821 and https://tools.ietf.org/html/rfc5320.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196187281

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 12:00:28 -0700

You are right.  This needs revising.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196189355

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 13:35:45 -0700

+

This is specifically done during the handshake.  The language here is trying to stay in agreement with the decision that PMTU < 1280 does not support QUIC.  Which ones of the statements is the concern:
1. to switch IPs (but stick w/ QUIC), if multiple IPs are available for the server?
2. to switch protocols, if we have an on-path validation of the signal?

Would you rather see all PMTU<1280 signals ignored (and not switch to TCP, if available, for example)?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196216169

---

From: martinduke <[email-masked]>
Date: Mon, 18 Jun 2018 14:02:25 -0700

martinduke requested changes on this pull request.

There a bunch of nits, but I have three higher-level comments:

1) There are no MUSTs in the ICMP stuff because you don't always control that in user space. We reached consensus before that PLPMTUD was a SHOULD and all ICMP stuff was a MAY; we should socialize this in the whole group if we upend that now. You've slipped in some SHOULDs that muddy those waters.

2) The added clarification around handshake/non-handshake, and the explicit call for some validation of QUIC headers, if available, is valuable.

3) A big part of this PR is a rewrite of how to handle it when ICMP gives you only 8 bytes. I found the original text to be more clear and concise than the new text, but perhaps we can discuss what the motivation for this rewrite is.

How about "ICMP-based"? This eliminates all ambiguity and saves people the trouble of clicking through references to know what we're talking about.

I disagree with the statement that some ICMP messages have no proof.  The 8-byte trailer is sufficient as a proof for TCP, and even if the QUIC case there is enough entropy if we store the right things.

-* Any reduction in PMTU due to a report contained in an ICMP packet is
-provisional until QUIC's loss detection algorithm determines that the packet is
-actually lost.
+Any ICMP messages that fail validation MUST be discarded.

The problem with MUSTs in this section is that some user space implementations may not have any control over ICMP handling logic.

+Any reduction in Path MTU due to a report contained in an ICMP Packet Too Big
+message (PTB) provisional until QUIC's loss detection algorithm determines that

... SHOULD be provisional...

-### Special Considerations for Packetization Layer PMTU Discovery
+#### ICMP PTB During Handshake  {#icmp-ptb-during-handshake}
+
+It is important that any problems are detected quickly during the connection
+handshake, because the client may be able to mitigate them by switching to
+alternative IP addresses or protocols.  Hence, an endpoint SHOULD reduce Path
+MTU in response to an ICMP PTB message during a handshake, unless then would
+cause a reduction to a Path MTU value smaller than 1280 octets.
+
+If a client receives an ICMP PTB message that requests it to reduce Path MTU to
+a value smaller than 1280 octets during a handshake, then:
+
+* If the client has another IP address for the server to try, the client should

SHOULD

+* Otherwise, if the client can fail over to another protocol, and the ICMP
+  packet has on-path validation, the client should retry connecting with another

SHOULD

-### Special Considerations for Packetization Layer PMTU Discovery
+#### ICMP PTB During Handshake  {#icmp-ptb-during-handshake}

I like how you separate the handshake issues here, but these also apply to PLPMTUD, yes?

-### Special Considerations for Packetization Layer PMTU Discovery
+#### ICMP PTB During Handshake  {#icmp-ptb-during-handshake}
+
+It is important that any problems are detected quickly during the connection
+handshake, because the client may be able to mitigate them by switching to
+alternative IP addresses or protocols.  Hence, an endpoint SHOULD reduce Path

This is a significant change. The spec suggests ("SHOULD") that PLPMTUD be used. ICMP-based PMTUD is strictly a MAY.

-The PADDING frame provides a useful option for PMTU probe packets. PADDING
+#### ICMP PTB After Handshake   {#icmp-ptb-after-handshake}
+
+If an ICMP PTB message is received after handshake, and the claimed Path MTU is
+at least 1280 octets for messages with on-path validation or 1392 for messages
+without on-path validations, the Path MTU SHOULD be set accordingly.  Otherwise,

Same comment: we're elevating ICMP response from a MAY to a SHOULD.

Zooming out a bit, I think the original text of this section is a bit clearer about what the real problem is. I do think it could use a paragraph like "endpoints SHOULD use fields from the QUIC header, if provided in the ICMP message, to validate that a QUIC packet in flight might have generated the ICMP message." And leave the rest unchanged.

-* Set the IPv4 Don't Fragment (DF) bit on a small proportion of packets, so that
-most invalid ICMP messages arrive when there are no DF packets outstanding, and
-can therefore be identified as spurious.

I guess you deleted this because it didn't meet your 1/2^32 standard?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#pullrequestreview-129725968

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 14:30:44 -0700

Somewhat arbitrary, examining various tunneling protocols out there to see what seems like a conservative-enough number that is not too small to be significantly concerned with degraded performance.  This number would certainly need a wg consensus.

The goal was to make sure that in the common case (no attack), we can switch to a workable PMTU immediately.

Of course, if the wg believes that 1280 is "large enough" to use it immediately, this would simplify things.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196232146

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 14:31:09 -0700

Fixing and rewriting this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196232260

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 14:43:52 -0700

I'd say that not just the QUIC header but, more importantly, the QUIC encrypted section, since it has more entropy.

But, I agree, instead of coming up with metrics, we should just leave the specifics undefined.  I like your wording.  Will adapt and incorporate.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196235331

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 14:44:36 -0700

(As for an 8-byte proof, it is sufficient for TCP but not QUIC.  Hence this entire discussion.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196235506

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 14:47:06 -0700

The language in this section says that validation is a SHOULD.  But if that validation fails, discarding is a MUST.  (And if the validation is not done, since it is not mandatory, then the signal SHOULD be treated as a signal without an on-path proof.)

Do you still think this is a problem?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196236060

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 21:50:07 +0000 (UTC)

PLPMTUD take time to do its work (it is loss/timeout-based).  The purpose of this discussion is to identify conditions, when you can trust ICMP immediately and not have to resort to PLPMTUD (especially during handshake).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196236756

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 14:54:26 -0700

Yes, this would need to be reconfirmed.  I do believe that we should encourage implementations to use the best available signal, including ICMP, especially when we have reasons to trust it.  Performance is important for QUIC, and it is double-important for handshake, and ICMP works much faster than PLPMTUD.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196237806

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 18 Jun 2018 14:57:36 -0700

LOL.  Mostly because I received comments that we recommend DF to be set on all packets, and this is going against that recommendation.

(But being pedantic, that standard was for on-path proof, while this discussion is for validation packets w/o on-path proof.)

More importantly, the entire standard thing is gone now.  I will further revise it to use your latest feedback as to the wording (ie. "use the data from the packet" instead of prescribing standards or which data to use).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196238564

---

From: janaiyengar <[email-masked]>
Date: Mon, 18 Jun 2018 16:56:28 -0700

janaiyengar commented on this pull request.

Thanks for getting this going, @igorlord ! A few comments, mostly editorial.

I think the context does make it clear, but @martinduke's suggestion seems reasonable.

> @@ -3187,40 +3187,76 @@ QUIC packets on the affected path.  This could result in termination of the
 connection if an alternative path cannot be found.

-### IPv4 PMTU Discovery {#v4-pmtud}
+### Classical ICMP-based path MTU discovery {#icmp-pmtu}

ditto. Also, Capitalize This Section Title.

> @@ -3187,40 +3187,76 @@ QUIC packets on the affected path.  This could result in termination of the
 connection if an alternative path cannot be found.

-### IPv4 PMTU Discovery {#v4-pmtud}
+### Classical ICMP-based path MTU discovery {#icmp-pmtu}
+
+ICMP error messages used in classical Path MTU discovery may be classified into
+messages with an on-path proof and without an on-path proof.  ICMP messages with
+an on-path proof are the messages sent in accordance with {{!ICMPv6=RFC4443}},

the messages -> messages

> +### Classical ICMP-based path MTU discovery {#icmp-pmtu}
+
+ICMP error messages used in classical Path MTU discovery may be classified into
+messages with an on-path proof and without an on-path proof.  ICMP messages with
+an on-path proof are the messages sent in accordance with {{!ICMPv6=RFC4443}},
+which requires ICMPv6 error messages to contain "as much of invoking packet as
+possible without the ICMPv6 packet exceeding the minimum IPv6 MTU", and
+{{!RFC1812}}, which states that ICMPv4 error messages "SHOULD contain as much of
+the original datagram as possible without the length of the ICMP datagram
+exceeding 576 bytes".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).

This sentence is a bit hard to follow. Also, it's possible that the ICMP message was received after the sender deemed it lost, since the sender may have been too earnest in marking it lost. Perhaps remove the requirement that it not be marked as lost yet? How about the following: "To validate an ICMP message containing on-path proof, the proof MUST be from a QUIC packet that is not yet acknowledged."

+ICMP error messages used in classical Path MTU discovery may be classified into
+messages with an on-path proof and without an on-path proof.  ICMP messages with
+an on-path proof are the messages sent in accordance with {{!ICMPv6=RFC4443}},
+which requires ICMPv6 error messages to contain "as much of invoking packet as
+possible without the ICMPv6 packet exceeding the minimum IPv6 MTU", and
+{{!RFC1812}}, which states that ICMPv4 error messages "SHOULD contain as much of
+the original datagram as possible without the length of the ICMP datagram
+exceeding 576 bytes".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8

To perform the on-path validation -> To validate a received ICMP message

+which requires ICMPv6 error messages to contain "as much of invoking packet as
+possible without the ICMPv6 packet exceeding the minimum IPv6 MTU", and
+{{!RFC1812}}, which states that ICMPv4 error messages "SHOULD contain as much of
+the original datagram as possible without the length of the ICMP datagram
+exceeding 576 bytes".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum

the outstanding => outstanding

+possible without the ICMPv6 packet exceeding the minimum IPv6 MTU", and
+{{!RFC1812}}, which states that ICMPv4 error messages "SHOULD contain as much of
+the original datagram as possible without the length of the ICMP datagram
+exceeding 576 bytes".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum
+validation, it SHOULD treat the packet as an ICMP message without an on-path

SHOULD -> MUST

> +the original datagram as possible without the length of the ICMP datagram
+exceeding 576 bytes".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum
+validation, it SHOULD treat the packet as an ICMP message without an on-path
+proof.
+
+As noted in {{?RFC5927}}, using ICMP messages without an on-path proof exposes

an on-path proof -> on-path proof

> +exceeding 576 bytes".  ICMPv4 messages without an on-path proof are sent in
+accordance with the minimum requirments of {{!ICMP=RFC0792}} and contain fewer
+octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum
+validation, it SHOULD treat the packet as an ICMP message without an on-path
+proof.
+
+As noted in {{?RFC5927}}, using ICMP messages without an on-path proof exposes
+the protocol implementation to off-path attacks and requires mitigations.

the protocol implementation -> an endpoint

> +octets past the IP header (typically only 8 octets).
+
+The minimum required validation of ICMP messages with an on-path proof invoves
+verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum
+validation, it SHOULD treat the packet as an ICMP message without an on-path
+proof.
+
+As noted in {{?RFC5927}}, using ICMP messages without an on-path proof exposes
+the protocol implementation to off-path attacks and requires mitigations.
+
+ICMP messages without an on-path proof SHOULD undergo as much validation as

an on-path proof -> on-path proof

> +verifying that the message was sent by a network element that has observed a
+QUIC packet that is still outstanding (not acknowledged and not deemed lost).
+To perform the on-path validation, the sender would need to remember at least 8
+octets from the encrypted portion of outstanding QUIC packets.  Alternatively,
+the sender would need to remember a 64-bit hash of the first 64 octets of the
+outstanding QUIC packets.  If a QUIC endpoint does not perform this minimum
+validation, it SHOULD treat the packet as an ICMP message without an on-path
+proof.
+
+As noted in {{?RFC5927}}, using ICMP messages without an on-path proof exposes
+the protocol implementation to off-path attacks and requires mitigations.
+
+ICMP messages without an on-path proof SHOULD undergo as much validation as
+possible.  For example, such validation could include storing IP ID fields of
+sent datagrams to validate that received ICMP messages are refering to
+outstanding packets.

This paragraph seems quite redundant. I would replace it with one sentence with recommendation for what state a sender can store to validate proof in ICMP messages.

then -> they

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#pullrequestreview-129770367

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 19 Jun 2018 07:53:09 -0700

Re-reading PLPMTUD, the draft says explicitly that it is an extension to the classical (ICMP-based) PMTU discovery process and its prescriptions are to be used in cases where ICMP-based PMTU discovery cannot be done.  So say that PLPMTUD is a SHOULD is effectively saying that ICMP is a SHOULD (as much as practicable).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196457957

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 19 Jun 2018 08:48:55 -0700

@janaiyengar is suggesting that not doing (or not being able to do) a validation means it is a ~~SHOULD~~ MUST to treat the signal as not having an on-path proof.  It makes sense to me.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#discussion_r196480657

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 25 Jun 2018 21:25:24 -0700

I've made updates per feedback received.  There are two points of discussion left (that I know of):

1. This is promoting ICMP processing to a SHOULD.  I think this is a correct thing to do, since PLPMTUD claims itself to be an extension of ICMP-based PMTUD process.  Of course, implementations w/o access to ICMP would not be able to implement this SHOULD, but this is ok albeit unfortunate -- the very definition of a SHOULD (skipping on MAY is not "unfortunate").

2. I am using a mostly made up number (1392) as "conservative enough to be believed w/o on-path proof".  It was a compromise between "small enough for most Internet tunnels" and "not that small that someone would go into troubles of maliciously reducing PMTU of the victim to that number".  This may need a discussion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1412#issuecomment-400174137