[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

QUIC                                                             M. Duke
Internet-Draft                                         F5 Networks, Inc.
Intended status: Informational                         November 25, 2019
Expires: May 28, 2020


              Network Address Translation Support for QUIC
                       draft-duke-quic-natsupp-00

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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 28, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Duke                      Expires May 28, 2020                  [Page 1]


Internet-Draft              QUIC NAT Support               November 2019


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  QUIC and NAT Rebinding  . . . . . . . . . . . . . . . . . . .   3
   4.  The Lure of the Connection ID . . . . . . . . . . . . . . . .   3
     4.1.  Resource Conservation . . . . . . . . . . . . . . . . . .   3
     4.2.  "Helping" with routing infrastructure issues  . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   4
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Network Address Translators (NATs) are a widely deployed means of
   multiplexing multiple private IP addresses over scarce IPv4 public
   address space by replacing those addresses and using ports to
   distinguish those connections.  The new address can also guarantee
   that packets move through a proxy throughout the life of a
   connection, so that the connection can continue with the required
   state at that proxy.

   QUIC [QUIC-TRANSPORT] is a protocol, operating over UDP, that
   provides many transport-like services to the application layer.
   Among these services is the mapping of multiple endpoint IP addresses
   to a single connection through use of a Connection ID (CID).
   Connection IDs are opaque byte fields that are expressed consistently
   across all QUIC versions [QUIC-INVARIANTS].  This feature may appear
   to present opportunities to optimize NAT port usage and simplify the
   work of the QUIC server.  In fact, NAT behavior that relies on CID
   may instead cause connection failure when endpoints change Connection
   ID, and disable important protocol security features.

   The remainder of this document explains how QUIC supports NATs better
   than other connection-oriented protocols, why NAT use of Connection
   ID might appear attractive, and how NAT use of CID can create serious
   problems for the endpoints.  The conclusion of this document is that
   NATs should retain their existing 4-tuple-based operation and refrain
   from parsing or otherwise using QUIC connection IDs.





Duke                      Expires May 28, 2020                  [Page 2]


Internet-Draft              QUIC NAT Support               November 2019


2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  QUIC and NAT Rebinding

   An explicit goal of QUIC is to be robust to NAT rebinding.  When a
   connection is idle for a long time, the NAT may guess it has
   terminated and assign the client port to a new connection.  If either
   endpoint attempts to resume communication, the packet will be
   assigned a new IP and/or port.  As TCP defines a connection by its
   address and port 4-tuple, the packet will not appear to belong to any
   existing connection at the receiver.

   As QUIC endpoints identify their connections using a CID that is
   encoded in every packet, new IP addresses and ports will not affect
   delivery as long as no routing function in the path is dependent on
   source IP address and port.

4.  The Lure of the Connection ID

   There are a few reasons that CID-aware NATs may appear attractive.

4.1.  Resource Conservation

   NATs sometimes hit an operational limit where they exhaust available
   public IP addresses and ports, and must evict flows from their
   address/port mapping.  CIDs offer a way to multiplex many connections
   over a single address and port.

   However, QUIC endpoints may negotiate new connection IDs inside
   cryptographically protected packets, and begin using them at will.
   Therefore, leveraging Connection IDs will cause sudden connection
   breakage when an incoming packet uses CIDs with no clear mapping.

4.2.  "Helping" with routing infrastructure issues

   One problem in QUIC deployment is router and switch server
   infrastructures that direct traffic based on address-port 4-tuple
   rather than connection ID.  The use of source IP address means that a
   NAT rebinding or address migration will deliver packets to the wrong
   server.  For the reasons described above, routers and switches will
   not have access to negotiated CIDs.  This is a particular problem for
   low-state load balancers, and a QUIC extension exists [QUIC-LB] to
   allow some server-load balancer coordination for routable CIDs.




Duke                      Expires May 28, 2020                  [Page 3]


Internet-Draft              QUIC NAT Support               November 2019


   A NAT at the front of this infrastructure might save the effort of
   converting all these devices by decoding routable connection IDs and
   rewriting the packet IP addresses to allow consistent routing by
   legacy devices.

   Unfortunately, the change of IP address or port is an important
   signal to QUIC endpoints.  It requires a review of path-dependent
   variables like congestion control parameters.  It can also signify
   various attacks that mislead one endpoint about the best peer address
   for the connection (see section 9 of [QUIC-TRANSPORT]).  The QUIC
   PATH_CHALLENGE and PATH_RESPONSE frames are intended to detect and
   mitigate these attacks and verify connectivity to the new address.
   Obviously, this mechanism cannot work if the NAT is bleaching peer
   address changes.

5.  Security Considerations

   This document proposes no change in behavior in the internet, so
   there are no new security implications.  Note, however, that ignoring
   the recommendations here could prevent existing security mechanisms
   in QUIC from working properly.

6.  IANA Considerations

   There are no IANA requirements.

7.  Informative References

   [QUIC-INVARIANTS]
              Thomson, M., "Version-Independent Properties of QUIC",
              draft-ietf-quic-invariants-latest (work in progress).

   [QUIC-LB]  Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC
              Connection IDs", draft-duke-quic-load-balancers-latest
              (work in progress).

   [QUIC-TRANSPORT]
              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", draft-ietf-quic-
              transport-latest (work in progress).

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.






Duke                      Expires May 28, 2020                  [Page 4]


Internet-Draft              QUIC NAT Support               November 2019


Appendix A.  Acknowledgments

   Thanks to Dmitri Tikhonov, who first recognized that certain NAT
   behaviors could create problems for QUIC.

Author's Address

   Martin Duke
   F5 Networks, Inc.

   Email: martin.h.duke@gmail.com








































Duke                      Expires May 28, 2020                  [Page 5]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/