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

[Martin Duke <[e-mail]>]

Responses inline:

On Thu, Jan 30, 2020 at 10:53 AM Mirja Kuehlewind <
[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.




>
>
>
>
> 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.


>
>
> - 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.


>
>
> 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.

>