Network Working Group K. Dupont Internet-Draft April 4, 2019 Intended status: Standards Track Expires: October 6, 2019 NAT64 Handoff draft-dupont-6man-nat64handoff-00 Abstract This document describes a NAT64 extension which allows IPv4 hosts to learn the real IP address of hosts which they are communicating with and assume responsibility to maintain the authoritative connection tracking table. 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 October 6, 2019. 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 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. Dupont Expires October 6, 2019 [Page 1] Internet-Draft NAT64 Handoff April 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Communication model . . . . . . . . . . . . . . . . . . . . . 3 4. Packet formats . . . . . . . . . . . . . . . . . . . . . . . 4 5. Packet formats from NAT64 to server . . . . . . . . . . . . . 7 6. Packet formats from server to NAT64 . . . . . . . . . . . . . 7 7. Multiple connection tracking entry format . . . . . . . . . . 7 8. NAT64 operation . . . . . . . . . . . . . . . . . . . . . . . 8 9. Token validation . . . . . . . . . . . . . . . . . . . . . . 10 10. Server operation . . . . . . . . . . . . . . . . . . . . . . 11 11. Server side NAT . . . . . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 14. Normative References . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Due to shortage of IPv4 addresses various models of NAT are seeing widespread usage as a way to reach IPv4-only services. The use of NAT has some drawbacks. This document aims to address two of those drawbacks by providing an extension for NAT64. Connection tracking entries on the NAT can be expired due to idleness. When doing such expiry the NAT has no way of knowing if the entry was still in use and may cause connections between client and server to be interrupted. The server doesn't know the real IP address of the client. For the purpose of debugging software bugs and investigating abuse all clients using the same NAT device will appear indistinguishable to the server. This document provides a NAT64 extension which aims to solve these two drawbacks by allowing the server to assume responsibility to maintain the authoritative version of the connection tracking table and allowing the NAT64 to only maintain a cache in which entries can be purged without causing connections to be interrupted. 2. Terminology NAT64: A dual-stack host translating TCP and UDP according to [RFC6146] and implementing the NAT64 handoff protocol as specified in this document. Server: An IPv4 host implementing the server component of Dupont Expires October 6, 2019 [Page 2] Internet-Draft NAT64 Handoff April 2019 Client: An IPv6 host which initiates communication through a NAT64 capable NAT64. NAT64 handoff: The UDP based protocol specified in this document to exchange connection tracking between NAT64 and server. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Communication model The communication model involves a many-to-many relation between clients and NAT64 devices as well as a many-to-many relation between NAT64 devices and servers. Application data is transmitted and translated according to [RFC6146]. This document adds a control channel between NAT64 and server. There is a separate control channel per NAT64 and server pair. The control channel is uniquely identified by the pair of IPv4 addresses of the NAT64 and server. +--------+ +--------+ +--------+ +--------+ | Client | | Client | | Client | | Client | +--------+ +--------+ +--------+ +--------+ | | | | +-----------+-----+------+-------------+ | +------------V-----------+ | NAT64 | +------------------------+ | | Application | | Control | | +----------V---V---------+ | Server | +------------------------+ Figure 1: The communication model This protocol aims to move as much state as possible from the NAT64 to the server and change the remaining state still needed on NAT64 to serve as a cache which can be purged as needed and repopulated from the server. Protection against IP spoofing is done through the use of tokens in the control channel messages. These tokens are chosen by the NAT64 Dupont Expires October 6, 2019 [Page 3] Internet-Draft NAT64 Handoff April 2019 in order to allow the NAT64 to use a stateless algorithm to generate tokens. 4. Packet formats The NAT64 handoff packets are UDPv4 packets exchanged between a port on the IPv4 address of the NAT64 and the NAT64 handoff server port (TBD) on the IPv4 address of the server. The UDP payload consist of a sequence of messages. Message formats are determined by the first nibble of the message. Following message formats are defined: 0 - Reserved to avoid ambiguity in message parsing if NAT64 handoff and Teredo are ever accidentally or deliberately mixed on the same port. 1 - Reserved for future extensions. 2 - Reserved for future extensions. 3 - NAT64 handoff messages. 4 - IPv4 packet. 5 - Reserved for future extensions. 6 - IPv6 packet. 7-15 - Reserved for future extensions. An implementation of NAT64 handoff MUST support packet formats 3, 4, and 6. A packet containing a message of an unknown format MUST be silently dropped. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 3 | Type | Msg Data Len | Message Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Type 4-bit identifier of the type of message. Msg Data Len 8-bit unsigned integer. Length of the Message Data field of this message, in 16 bit units. Message Data Variable-length field. Message-Type-specific data. 0 - Reserved for future extensions Dupont Expires October 6, 2019 [Page 4] Internet-Draft NAT64 Handoff April 2019 1 - Protocol identifier 2 - No-op 3 - Invalid 4 - Token 5 - Token rotation 6 - Remote IPv6 address authenticator 7 - Connection tracking entry 8 - Mapped port hint 9-15 - Reserved for future extensions An implementation of the NAT64 handoff server component MUST understand messsage types 4, 5, 6, and 7 and SHOULD understand message types 1 and 8. An implementation of NAT64 with handoff extension MUST understand message types 4, 6, and 7. An implementation of either component MUST ignore messages of unknown types. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 3 | 1 | 72 | Message Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Message data must be the 144 octet string "[[ This is the NAT64 handoff protocol. The client is using " "IPv6. To know their real IP address you need to use this " "protocol or support IPv6. ]]" +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 3 | 4/5/6 | Msg Data Len | Message Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - For message types 4, 5, and 6 the NAT64 choose the contents of message data and its length. The length of message data MUST be an even number of octets and at most 510 octets. The message data SHOULD be generated as a Message Authentication Code of at least 16 octets using a secret key known only to the NAT64 itself. The server MUST accept message data of any length from 0 to 510 octets. Dupont Expires October 6, 2019 [Page 5] Internet-Draft NAT64 Handoff April 2019 For message type 4 message data SHOULD be a MAC of the server IPv4 address computed using a key known only to the NAT64. For message type 5 message data MUST be computed the same way as message type 4 but using the most recently expired key. For message type 6 message data should be a MAC of the server IPv4 address and client IPv6 address computed using a key known only to the NAT64. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 7 | 16 | Mapped port number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | NAT64 /96 prefix | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Client IPv6 address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client port number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 8 | 1 | Suggested port number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Not every concatenation of messages form a valid packet. With the exception of the multi-connection-tracking-entry format explained below a packet MUST NOT contain more than one message of each type. When a receiver parses a message containing multiple messages of same type it MAY pick one message of each type to process and ignore the rest. The sender MAY put the messages in a packet in any order. Any IPv4 or IPv6 packet included in a control channel packet MUST be the last message in the packet. The receiver MAY stop parsing once it sees an IPv4 or IPv6 packet. This also means that a sender is not allowed to include both an IPv4 and an IPv6 packet in the same control channel message. Dupont Expires October 6, 2019 [Page 6] Internet-Draft NAT64 Handoff April 2019 5. Packet formats from NAT64 to server All control channel packets from NAT64 to server MUST include a token message (message type 4). And they MUST include at least one of connection tracking entry (message type 7), IPv4 packet, IPv6 packet. Any IPv4 or IPv6 packet sent from NAT64 to server must be the before translation version of the packet. A packet with a connection tracking entry (messsage type 7), must include a protocol identifier (message type 1) and remote IPv6 address authenticator (message type 6). A packet with an IPv6 packet must include a remote IPv6 address authenticator (message type 6). It MAY include a mapped port hint (message type 8). 6. Packet formats from server to NAT64 All control channel packets from server to NAT64 MUST satisfy at least one of the following three requirements. Include a token message (message type 4) and an IPv4 packet before or after translation. Include a remote IPv6 address authenticator (message type 6) and a post-translation IPv6 packet. Include a remote IPv6 address authenticator (message type 6) and a connection tracking entry (messsage type 7). Packets of this format MAY include any IPv4 or IPv6 packet before or after translation. 7. Multiple connection tracking entry format Packets sent from NAT64 to server may follow the format in this section. This is the only packet format which permits multiple messages of the same type. The packet must contain a protocol identifier (message type 1) and a token (message type 4). The packet must contain one or more groups of messages in which each group consists of exactly one remote IPv6 address authenticator (message type 6) followed by one or more connection tracking entries (messsage type 7). The remote IPv6 address authenticator must be valid for all connection tracking entries in the group. The UDP payload MUST NOT exceed 1232 octets. Dupont Expires October 6, 2019 [Page 7] Internet-Draft NAT64 Handoff April 2019 The packet must not contain an IPv4 or IPv6 packet. 8. NAT64 operation Upon receiving a packet the NAT64 must first classify the packet as one of the following: Packet subject to NAT Control plane packet ICMP packet Packet with invalid destination IP IPv4 packets are classified as follows: Incoming packets with destination address different from the NAT64 public IPv4 address are considered as invalid destination. Packets with protocol number 1 are ICMP. Packets sent from UDP port (TBD) to the client side port (chosen by NAT64) are control packets. Packets with destination port 80 may be treated as HTTP. All other packets are subject to NAT. IPv6 packets are classified as follows: If destination address is within one of the NAT64 prefixes configured on this NAT64 and the first octet of the embedded IPv4 address is not 0 or 127 the packet is subject to NAT. Any other destination address is considered as invalid destination. IPv4 packets subject to NAT are handled as follows: If it is neither TCP nor UDP forward it over the control connection to the server. If it matches a cached connection tracking entry from the server perform translation. If it matches a NAT64 generated connection which has previously been used with this IPv4 address perform translation. Dupont Expires October 6, 2019 [Page 8] Internet-Draft NAT64 Handoff April 2019 If it matches a NAT64 generated connection which has not been used with this IPv4 address and no valid control packets have ever been received from that server IPv4 address the NAT64 can choose between performing translation and sending the packet over the control channel to the server. Otherwise send the packet over the control channel to the server. IPv6 packets subject to NAT are handled as follows: If it is neither TCP nor UDP forward it over the control connection to the server. If it matches a cached connection tracking entry from the server perform translation. If it matches a NAT64 generated connection entry which has previously been used with this IPv4 address perform translation. If a valid control packet has previously been received from this server IPv4 address forward it over the control connection to the server. If no NAT64 generated connection tracking entry exists for this source IPv6/port create an entry. Record that the entry (new or existing) has been used with this server IPv4 address. Perform translation. ICMP error messages containing a (truncated) IPv4 error are handled as follows: If the ICMP packet has invalid checksum it is silently dropped. If the embedded packet source address does not match the NAT64 public IPv4 address, the ICMP error is silently dropped. If the embedded IP payload is an ICMP packet, handle the packet according to [RFC0792] considering the NAT64 itself to be the final destination of the packet. If the embedded packet is a UDP packet from the client side port (chosen by NAT64) to the server side port (TBD) it's considered to be an undelivered control packet and is silently dropped. If the origin IP of the ICMP error matches the destination IP of the inner IP packet, and the ICMP error has type 3 and code 3, and the payload contains a valid token, the NAT64 must consider the handoff server to be down. The NAT64 must switch back to generating connection entries as if that server IPv4 address never Dupont Expires October 6, 2019 [Page 9] Internet-Draft NAT64 Handoff April 2019 supported handoff in the first place. Any previously cached connection entries from that server must be kept in cache and expired as if the server was still responding. Once the server is confirmed to be responding again the still cached connection entries must be sent to the server. If the embedded IP payload is not TCP or UDP forward the packet over the control connection to the source IP of the embedded IP payload. If the embedded IP payload matches a cached connection from the server perform translation. If the embedded IP payload matches a NAT64 generated connection previously used with the destination IP of the embedded IP packet perform translation. Otherwise forward the packet over the control connection to the source IP of the embedded IP payload. 9. Token validation When the NAT64 server component receives a packet with an unknown combination of token, NAT64 IPv4 address and port number, the server MUST validate it according to the following algorithm which requires no per-NAT64 state until validation succeeds. Compute a Message Authentication Code calculated over token, client IPv4 address, and client port. The server may rotate the MAC key 30 seconds after it was last used to send a validation packet. If the control channel packet contains an IPv4 packet and the MAC is found inside of that IPv4 packet the client is authenticated and the IPv4 address, port number, and token are stored by the server. Then proceed with processing the packet as an authenticated packet. Apply attenuation which is recommended to be implemented as follows: At server start time initialize a counter of packets to process to as two. On recepit of a packet if the counter is zero silently drop the packet and set the counter to 1 or 2 with a 50% probability each. Otherwise decrease the counter and continue processing. The server MAY use a per NAT64 counter if it has previously communicated with that NAT64 but the token is unknown. Generate an IPv4 validation packet to the NAT64 which will not match any connection tracking entry. That packet MUST include a Message Authentication Code calculated by server over token, client IPv4 address, and client port. The server may rotate the MAC key 30 seconds after it was last used to send a validation packet. Dupont Expires October 6, 2019 [Page 10] Internet-Draft NAT64 Handoff April 2019 The IPv4 validation packet MAY be formatted as a UDP packet from the NAT64 handoff server port (TBD) to UDP port 9 (discard) formatted as a control channel message containing remote IPv6 address authenticator and a no-next-header IPv6 packet using the previously computed MAC as IPv6 payload. The NAT64 must treat this as a packet not matching a known connection tracking entry and encapsulate the entire packet in a UDP packet sent back to the server. If the NAT64 implements attenuation against reflection attacks it must parse the received packet as a control channel packet and look for a valid token or remote IPv6 address authenticator, if either of those is found it must not drop the packet. 10. Server operation When the the server receives a packet with a valid token it is handled according to this section. When the server receives an IPv6 packet over the control connection it must look for a matching connection tracking entry and if none exists it must create one. When using the public IPv4 address of the NAT64 for the connection entry it must use a port number in the range 1024-65535 avoiding the following port numbers: 3544 NAT64 handoff server port (TBD) The source port of the current control channel packet. The server must then either: Translate the packet to IPv4 and deliver it directly Translate the packet to IPv4 and return it to the NAT64 Return the connection tracking entry and IPv6 packet to the NAT64 When the server receives an IPv4 packet over the control connection it must look for a matching connection tracking entry. If no matching connection tracking entry is found the server should return the packet to the NAT64 if it is a TCP or UDP packet and otherwise construct an appropriate ICMP error message which it can either deliver directly or send back over the control connection to the NAT64. If a match is found the server must then either: Dupont Expires October 6, 2019 [Page 11] Internet-Draft NAT64 Handoff April 2019 Translate the packet to IPv6 and deliver it directly Translate the packet to IPv6 and return it to the NAT64 Return the connection tracking entry and IPv4 packet to the NAT64 11. Server side NAT When the server creates new connection tracking entries it can choose between using the public IPv4 address of the NAT64 or an address from the ranges specified in [RFC1918] or [RFC6598]. A minimal server side implementation will always use the public IPv4 address of the NAT64 and never perform NAT itself. This will be limited to TCP and UDP support and will cost an extra roundtrip each time the NAT64 cache needs to be populated. It will be subject to the limitations in choice of port number for connection tracking entries outlined in this protocol. But it still allows a larger number of connections than relying entirely on the NAT64 as it won't be competing against servers on other IPv4 addresses for the same pool of port numbers. Using a local IP range on the server side has several advantages. But it requires server side NAT which also requires the server to run with the additional privileges needed to create a virtual network interface for this purpose. Advantages of server side NAT is that there is access to more IPv4 addresses thus a larger pool of available ports. And it is not subject to the requirements that the same port number be used for mappings towards all TCP and UDP ports server side. It also allows translation of all protocols needed by the server, not just TCP and UDP. It also completely avoids the use of cache entries on the NAT64 and the roundtrips needed to populate the cache. A mixed mode operation is also possible where the public IPv4 address of the NAT64 is used even with protocols not supported by the NAT64 and connections absent from the NAT64 cache. In this mode the NAT64 will tunnel IPv6 packets to the server. The server performs NAT and can either deliver the IPv4 packets directly or tunnel them back to the NAT64. IPv4 packets from the server are sent to the NAT64 which tunnels them to the server for translation. Once packets have been translated to IPv6 the server can either deliver them directly or tunnel them back to the NAT64. Dupont Expires October 6, 2019 [Page 12] Internet-Draft NAT64 Handoff April 2019 The extra roundtrip due to all the IPv4 packets needing to go from server to NAT64 and back to the server makes this mode less desirable. The extra roundtrip can be avoided at the cost of very complicated routing rules on the server. Whether to use this operation mode is choice made server side and the complexity of supporting it lies server side. The NAT64 is required to support this operation mode in case any server it communicates with makes use of it. The NAT64 side just needs to support the tunneling required for this. 12. Security Considerations This protocol addresses one security concern around NAT64 by making it harder for attacks to go through a NAT64 as a way to hide their IP address. Other security considerations regarding NAT64 still apply. The control channel introudced by this document operates over UDP and as such it needs to protect against reflection attacks. Control channel packets received by the NAT64 all contain either a token or a remote IPv6 address authenticator which can validate their authenticity and spoofed packets can be silently dropped. Control channel packets received by the server are required to be attenuated before processing if they do not contain a known valid token. If attenuation is implemented using the algorithm suggested by this document the attenuation factor will be 60%. That means if packets with spoofed source IP are sent to the server component only 40% of them will generate a response. The tokens and remote IPv6 address authenticators specified in this document not only serves as protection against reflections but also protect against: Connection cache poisoning Using control channel for injecting spoofed packets IPv4 hosts using the NAT64 to send traffic to IPv6 hosts which did not themselves initiate communication through the NAT64. Application layer security mechanisms such as those implemented by SSH and TLS will work the same with and without NAT64 handoff. 13. IANA Considerations One UDP port number for the NAT64 handoff server component needs to be allocated by IANA. Dupont Expires October 6, 2019 [Page 13] Internet-Draft NAT64 Handoff April 2019 Service Name: NAT64 handoff Transport Protocol(s): UDP Description: NAT64 handoff Reference: This document. Port Number: TBD -- To be assigned by IANA. 14. Normative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, . [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Author's Address Kasper Dupont Ellemosevaenget 31 Tranbjerg J. 8310 Denmark Email: kasperd@ntstm.30.mar.2019.kasperd.dk Dupont Expires October 6, 2019 [Page 14]