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

[Mirja Kuehlewind <[e-mail]>]

Hi Martin,

see inline.

From: Martin Duke <[e-mail]>
Date: Wednesday, 29. January 2020 at 18:09
To: Mirja Kuehlewind <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: New Version Notification for draft-duke-quic-natsupp-00.txt

Hi Mirja,

For Section 4.1, here is the scenario I have in mind:
- the NAT is out of public addresses and ports and uses CIDs to multiplex clients over one port (which the draft is arguing it should not do)
-  NAT routes packets coming in from the internet with address/port A:B and CID C to client #1
- NAT routes packets coming in from the internet with address/port A:B and CID D to client #2
- Client #1 provides a new CID E to the server
- The NAT receives a packet for address/port A:B and CID E, and cannot disambiguate the two clients.

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…?


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?

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

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…?


If we decide this is worth writing up at all, I'll try to make it clearer. Or have I made a mistake somewhere?

Thanks for the comments. Let's discuss next week if this worth living as a separate document.

Sure.

Mirja



Martin

On Wed, Jan 29, 2020 at 1:28 AM Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>> wrote:
Hi Martin,

thanks for writing this up. I have two questions and a comment.

This part in section 4.1:
   “Therefore, leveraging Connection IDs will cause sudden connection
   breakage when an incoming packet uses CIDs with no clear mapping.”
Not sure I understand this correctly but would a NAT simply assign a new port/address when a new CID shows up..? Why would that break connectivity? Or what do you mean with that?

Regarding section 4.2:
You basically say that changing the port/address might break 4-tuple routing on the other end. But wouldn’t mean that any NAT rebinding would break connectivity and that’s a problem by the other end that should be solved there?

I think the most important part of the document is the last paragraph in section 4.2. I’d recommend to put that in an own section. However, I’m actually not convinced about the other two points (above). If that is the only point we would need to make, maybe that’s also something to put in the manageability document.

Mirja


From: QUIC <[e-mail]<mailto:[e-mail]>> on behalf of Martin Duke <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 28. January 2020 at 19:29
To: IETF QUIC WG <[e-mail]<mailto:[e-mail]>>
Subject: Fwd: New Version Notification for draft-duke-quic-natsupp-00.txt

At Gorry's suggestion, I took the NAT recommendations and put them in a short draft that NAT guys are more likely to read. If this seems extraneous, I'm happy to get that feedback.

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Mon, Nov 25, 2019 at 11:17 AM
Subject: New Version Notification for draft-duke-quic-natsupp-00.txt
To: Martin Duke <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-duke-quic-natsupp-00.txt
has been successfully submitted by Martin Duke and posted to the
IETF repository.

Name:           draft-duke-quic-natsupp
Revision:       00
Title:          Network Address Translation Support for QUIC
Document date:  2019-11-25
Group:          Individual Submission
Pages:          5
URL:            https://www.ietf.org/internet-drafts/draft-duke-quic-natsupp-00.txt
Status:         https://datatracker.ietf.org/doc/draft-duke-quic-natsupp/
Htmlized:       https://tools.ietf.org/html/draft-duke-quic-natsupp-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-duke-quic-natsupp


Abstract:
   Network Address Translators (NATs) are widely deployed to share
   scarce public IPv4 addresses among mutiple end hosts.  They overwrite
   IP addresses and ports in IP packets to do so.  QUIC is a protocol on
   top of UDP that provides transport-like services.  QUIC is better-
   behaved in the presence of NATs than older protocols, and existing
   UDP NATs should operate without incident if unmodified.  QUIC offers
   additional features that may tempt NAT implementers as potential
   optimizations.  However, in practice, leveraging these features will
   lead to new connection failure modes and security vulnerabilities.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat