Subject: Re: [quicwg/base-drafts] ICMP and ICMPv6 (Type: DestinationUnreachable) (#377)

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Mar 2018 07:36:20 -0700

@igorlord, the editor's discussed this and we think that it's a valid concern, but we want to make sure that your concerns are addressed properly. Do you think that you could propose text for 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/issues/377#issuecomment-372687149

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 13 Mar 2018 16:29:26 +0000 (UTC)

I will attempt to put together a proposal for us to discuss.

-- 
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/issues/377#issuecomment-372729114

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 18 Mar 2018 12:34:52 -0700

**Assumptions**

1. Handshake is powerless against an attacker that can observe a path and, while it cannot interfere with the path, it can deliver a packet back the the sender in less than 1-rtt.

2. It is important to detect path and endpoint problems very quickly at connection establishment, if the sender has alternatives to try (other IPs from DNS, or other protocols, or lower the MTU).

**Tools**

- _Ignore_. Ignore the signal.

- _Accept_. Accept the signal (and act accordingly right away), as long as it is not obviously bogus (you already received a valid ACK for the packet subject to the ICMP error, for example).

- _Validate_. Start an immediate path validation with a short timeout, unless the packet is obviously bogus (see above).

**ICMP Types**

- With "on-path proof".  These are ICMP packets that contain a large portion of the packet that triggered them.  They prove that the packet came from an on-path box.  These are ICMPv6 error packets and ICMP [https://datatracker.ietf.org/doc/rfc4884/](RFC 4884) error packets.

- Without "on-path proof".  These are ICMP error packets that only contain 8 octets of the original packet past the original IP header.  Per Section "8.4.1. Special Considerations for PMTU Discovery" of the Transport draft, the recommendation for adding as much entropy to the IP layer as possible (IP ID, DF flag, etc) should be applied.

**Recommendations**

1. Dealing with ICMP "unreachable" (path or port) or "too big" during handshake.  For ICMP with "on-path proof", Accept.  For ICMP w/o "on-path proof", Accept if can fail over to a different IP (that was not yet tried for this request); otherwise retry one more time.

2. Dealing with ICMP "unreachable" (path or port) not during handshake.   Validate.

3. Dealing with ICMP "too big" not during handshake.  Accept if it is not requesting an MTU lower than X, where X is relatively low" for ICMP with "on-path proof" and is relatively high for ICMP without "on-path proof".  If the requested MTU is lower than X, Validate (via PMTUD techniques).

-- 
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/issues/377#issuecomment-374037306

---

From: MikkelFJ <[email-masked]>
Date: Sun, 18 Mar 2018 12:50:30 -0700

Thanks for writing this up.

I think it would be useful with text on gateways that drop ICMP - ELB is/was reported to do this, and considerations for ICMP amplification attacks.

On the defenseless handshake - is there a way we could improve on this using public crypto - possible in a variant or future version? Client auth is delivered late in TLS - probably to have a secure line, faster crypto, and to add some privacy - though I'm not into the details yet. X25519 could possibly provide a fast early client auth handshake which could mitigate on path attacks - I'm far from sure - speculating.

-- 
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/issues/377#issuecomment-374038838

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 18 Mar 2018 17:10:37 -0700

Yes, it is an interesting discussion for what to do in case of blocked ICMP signals.  It would be a complimentary problem to the one discussed here (what to do in case an ICMP signal is received).

_defenseless handshake_. I am not a cryptographer, so I am happy to listen to the experts on what crypto could provide for faster auth.  However, I do want to note that a single packet is typically all the attacker needs.  It is very easy to forge a version negotiation packet, for example, and prevent a successful handshake.  I would prefer not to try to beef up version negotiation at this point, though, and see if we could get a design based on @ekr's proposal for version negotiation (Client Sends all supported versions in CI; Server picks a version and replies using that version).

-- 
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/issues/377#issuecomment-374069486

---

From: MikkelFJ <[email-masked]>
Date: Mon, 19 Mar 2018 02:40:01 -0700

In the case where you have an authenticated client, you are not necessarily vulnerable to vneg attacks because the client auth could be version specific. You could replace the version identifier with a nonce signed by the client and possibly some additional context to help identify the clients public key and identity - this is the tricky part.

-- 
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/issues/377#issuecomment-374153046

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Mar 2018 16:27:50 -0700

@mikkelfj The attacker can spoof Version Negotiation packet from the server.  It seems that unless the Server can also sign its Version Negotiation response (even in @ekr's style ver neg), including "we speak no common version" response,, defences would invariably have to rely on a timeout (to await the arrival of the actual packet from the server).  And waiting on a timer during handshake may be a suboptimal thing to do, in case the client has other options to try.

-- 
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/issues/377#issuecomment-374420299