Subject: Re: [quicwg/base-drafts] Address change and consent to send (#161)

From: mbagnulo <[email-masked]>
Date: Thu, 02 Mar 2017 22:26:50 -0800

There is a number of other protocols that have the same issue, including MPTCP, SCTP, MobileIP and the usual solution is what Mirja proposes, a return routability check before sending packets to the new address. Some references where this has been documented include section 5 of RFC6181 for MPTCP, RFC4225 for MIPv6, RFC4218 for Shim6 and RFC5062 for SCTP.
So from the perspective of not making it worse than current protocols, a ping with a random number should be ok. If you add the skipping of packet numbers, then this is stronger. 
Probably, it would be worthwhile referring to BCP84 when describing this issue.

-- 
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/161#issuecomment-283876505

---

From: janaiyengar <[email-masked]>
Date: Thu, 02 Mar 2017 23:08:46 -0800

There are a few issues here

1. Amplification attack, where an attacker grows server's cwnd to a large value and then sends a spoofed packet with the victim's IP, causing a large amount of data to be dumped on the victim.
Solution: When a server observes a change in the client's IP address, it records the current cwnd, clamps the cwnd down to MIN_CWND, and sends a PING frame to the new IP. When a packet sent to the new IP address is acked, the cwnd is restored.

2. Optimistic ack attack, where the attacker optimistically acks the PING packet sent by the server to the victim's IP, causing the server to again unleash it's large cwnd on the victim.
Solution: On a change in the client's IP address, the server introduces a randomly sized gap in the packet sequence space. Any new data will now still be sent to the new client IP, but the sequence numbers will be discontiguous from transmissions to the old IP. Any acks for packets in the gap will result in an immediate termination of the connection. A malicious client will now have to either correctly guess the exact size of this gap or read packets going to the victim. 

Alternatively, we can add an optional random number to the PING frame, which when present means that the receiver MUST respond immediately with a PING frame carrying the same random number.

3. There's a slightly tricky issue hidden in here. Say a server observes an address change from IP A to B. What should a server do if it observes another address change while it's in the middle of validating one?
Solution: There are three possible scenarios.
(i) If the new IP is different than A, then restart validation of the newest IP. 
(ii) If the new IP is the same as A and the packet is reordered, then accept the packet and continue with the current validation. 
(iii) If the new IP is  the same as A and the packet is newer than the one that triggered the last validation, then close the connection, since this doesn't look like a NAT rebinding. (This could be a MITM, who changes the IP address of one client -> server packet, hoping that the server reduces its cwnd or latches on to this new IP, causing a DoS of sorts.)

-- 
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/161#issuecomment-283882554

---

From: Martin Thomson <[email-masked]>
Date: Fri, 03 Mar 2017 03:30:26 -0800

@janaiyengar, on point three, could that just be spontaneous multipath? :p

-- 
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/161#issuecomment-283931613

---

From: mirjak <[email-masked]>
Date: Fri, 03 Mar 2017 03:50:56 -0800

I really support to put a random number in the ping: that's easier and fast than you step 2 above.

-- 
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/161#issuecomment-283935057

---

From: mirjak <[email-masked]>
Date: Fri, 03 Mar 2017 03:54:10 -0800

For the multipath case I would assume that you tell the other beforehand which IP you are going 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/issues/161#issuecomment-283935552

---

From: Martin Thomson <[email-masked]>
Date: Fri, 03 Mar 2017 03:56:31 -0800

I wouldn't make ping include an optional random number, I would add a new explicit return routeability frame (or two).  I also wouldn't necessarily make the value random, just hard to guess (source address token lite).

-- 
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/161#issuecomment-283935974

---

From: mbagnulo <[email-masked]>
Date: Fri, 03 Mar 2017 04:25:52 -0800

About the multipath case, it is not always the case that you know the new address.
Suppose the client moves to a new location behind the NAT. 

-- 
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/161#issuecomment-283940778

---

From: mirjak <[email-masked]>
Date: Fri, 03 Mar 2017 04:53:34 -0800

In this case the old address goes away which I wouldn't call multipath anymore

-- 
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/161#issuecomment-283945787

---

From: mbagnulo <[email-masked]>
Date: Fri, 03 Mar 2017 05:45:56 -0800

:-)
Agree, let me rephrase. A new interface is up and the endpoint wants to establish a new subflow using the other interface. (e.g. wifi and 4g) and the new interface is behind a NAT. makes sense?

-- 
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/161#issuecomment-283956577