Re: New Version Notification for draft-duke-quic-natsupp-00.txt

[Mirja Kuehlewind <[e-mail]>]

Hi Martin,

short reply: sounds good! Otherwise see inline.

Mirja

From: Martin Duke <[e-mail]>
Date: Monday, 10. February 2020 at 21:52
To: Mirja Kuehlewind <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: New Version Notification for draft-duke-quic-natsupp-00.txt

Responses inline:

On Thu, Jan 30, 2020 at 10:53 AM Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>> wrote:

I somehow was initially only think about out-going packet and no incoming packets… so, yes, the NAT needs to discard this packet. However, you say the NAT is out of addresses/ports, thus not using the CID would have meant that it would have to discard the connection right at the beginning. Not sure if that is any better…?

It's a good point that immediately dropping is not great either. However,
·         this would create an ossification vector where CID changes may break the protocol.
·         it's better for QUIC to fail right away (enabling TCP fallback) than to black hole suddenly.
[MK] Right, the second point here is actually important. Probably also something to mention in the draft.


Section 4.2.
- Server deployment has 4-tuple routing and it is expensive to change
- IT installs a NAT at the front of the infrastructure that stores a mapping of CIDs to inbound source address and port.

This step was also not fully clear to me from the draft. Now that I look at it again, I understand what’s meant but I think it could be clearer in the draft.

So is 4-tuple routing actually common? Why is the 4-tuple used instead of only routing based on the destination address/port?

Yes it's common. If we're fronting a single website there may be a single destination IP and well-known port, so the destination doesn't add any entropy.

[MK] That makes sense.


- If a packet arrives with a known CID but a different source address/port, the NAT will rewrite the source/address port to the old value, and thus the packet will route to the correct back-end server. Thus the infrastructure is robust to NAT rebinding, if not intentional migration with a new CID.
- While this "works", it has security implications as discussed.

I think you need to further explain the attack case here in the draft – that an attacker might spoof the IP address and therefore can DDoS a target as the server might keep sending a large amount of data to that new IP address. However, I think this should probably be discussed in the security section of the transport draft a bit more as this is only possible because of migration which is a new feature in QUIC.

I believe Eric Kinnear has already written a ton about how to handle new addresses in the transport draft. I'll rewrite the paragraph as you suggest.

[MK] Thanks!

However, given that if someone anyway decided to implement this setup, the endpoints have no way to detect that an address changed and was respectively re-written then again, should we maybe start think about a way to improve the situation…?

The signal here is that absolutely nothing in the packet has changed, so I'm not sure how endpoints could possibly detect this.
Yes, but maybe there are other things. Not proposing this as a solution but e.g. one could detect an address change using TURN… anyway I guess you are right that there is not easy way…