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

[Martin Duke <[e-mail]>]

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.

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

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.

Martin

On Wed, Jan 29, 2020 at 1:28 AM Mirja Kuehlewind <
[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]> on behalf of Martin Duke <
> [e-mail]>
> *Date: *Tuesday, 28. January 2020 at 19:29
> *To: *IETF QUIC WG <[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]>
> 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]>
>
>
>
>
> 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.
>
> The IETF Secretariat
>