Network Address Translator (NAT) Considerations for IP Performance Metrics (IPPM) Active Measurement Protocols

One of the primary reasons for standardizing techniques for collecting IP Performance Metrics (IPPM) one-way and two-way active measurements is to create an environment where IPPM metrics can be collected across a broad mesh of Internet paths. This together with the deployment of open servers is expected to make IPPM measurements a commonplace across those Internet paths. The One-way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) is designed to effectively support active measurements in a variety of environments, from publicly accessible measurement beacons running on arbitrary hosts to network monitoring deployments within private corporate networks. With the proliferation of Internet of Things (IoT), it is expected that IPPM measurements will be obtained by the service provider from a variety of devices not imagined before, such as sensors, smart phones, vehicles, customer premises equipment (CPE) and residential gateways. Such devices are likely to be behind NATs, deployed at the customer premise or hosted by the service provider (known as Carrier Grade NATs). NATs are considered a 'necessary evil' of the Internet and a 'fact of life' (see ). They generally operate by modifying the IP address and port information (within the network/transport header) of packets en-route. describes the common characteristics of protocols broken by NAT: Bundled session applications such as FTP, H.323, SIP and RTSP, which use a control connection to establish a data flow are also usually broken by NAT devices enroute. This is because these applications exchange address and port parameters within control session to establish data sessions and session orientations. NAT cannot know the inter-dependency of the bundled sessions and would treat each session to be unrelated to one another. Applications in this case can fail for a variety of reasons. Two most likely reasons for failures are: (a) addressing information in control payload is realm-specific and is not valid once packet crosses the originating realm, (b) control session permits data session(s) to originate in a direction that NAT might not permit. Both OWAMP and TWAMP negotiate the sender and receiver addresses and port numbers used by the test session in their control protocol. Therefore, they also suffer from the same problems described above, when operating across a NAT.

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 . In this document, the term "NAT" refers to both "Basic NAT" and "Network Address/Port Translator (NAPT)" (see section 3 of ). Basic NAT and NAPT are two variations of NAT in that translation in Basic NAT is limited to IP addresses alone, whereas translation in NAPT is extended to include IP addresses and transport identifiers (such as a TCP/UDP port).

The following sections describe the problems NAT causes for TWAMP. The problems NAT causes for OWAMP are very similar and is left out for brevity.

The following diagram shows the presence of NATs on the TWAMP-Test session path between two hosts, Host A and Host B, one playing the roles of Control-Client and Session-Sender, and the other playing the roles of Server and Session-Reflector.

| Server | | Client | | | | | | | | Session | | Session | | Sender |<--+-------TWAMP-Test------+-->| Reflector | +----------+ | | +-----------+ NAT A NAT B Addr 192.0.2.1 | 50.1.1.1 60.1.1.1 | 198.51.100.1 Port 50000 55000 58000 52000 <---Private---><--------Public--------><----Private----> ]]> To initiate a test session, the Control-Client sends a Request-TW-Session command to the Server. The Sender Address and Receiver Address fields carried inside this message contain, respectively, the sender and receiver addresses of the endpoints of the Internet path over which a TWAMP-Test session is requested. As shown in the above diagram, when there is NAT in this path, these addresses may not be valid since they may be addresses from private realm and not the corresponding public addresses which map to them. The Request-TW-Session command also carries the Sender Port and Receiver Port. The Sender Port is the UDP port from which TWAMP-Test packets will be sent and the port to which TWAMP-Test packets will be sent by the Session-Reflector. The Receiver Port is the desired UDP port to which TWAMP-Test packets will be sent by the Session-Sender or the port where the Session-Reflector is asked to receive test packets. These ports may not be valid in the presence of NAT. The Session-Reflector then responds with an Accept-Session message containing a Port field. This Port field indicates the port number where the Session-Reflector expects to receive packets from the Session-Sender. This port also may not be valid in the presence of NAT.

When a protocol is unable to operate through a NAT, the use of an Application Level Gateway (ALG) may permit operation of that protocol . ALGs typically operate inside routers along with the NAT component. An example is a DNS-ALG that interacts with the NAT component to modify the contents of a DNS response. In a similar way, a TWAMP-ALG could be used along with the NAT component to rewrite the private addresses and ports carried inside the control protocol with the NAT translated addresses and ports. This would however work only when TWAMP operates in the unauthenticated mode. notes that if DNS packets are encrypted/authenticated per DNSSEC, then DNS-ALG will fail because it won't be able to perform payload modifications. Similarly, when TWAMP operates in the authenticated or encrypted mode, modifications of the TWAMP-Control payload by the TWAMP-ALG will cause TWAMP integrity protection to fail.

Since NAT behaviour is not standardized, a solution capable of collecting IPPM one-way and two-way active measurements across all types of NATs may not be feasible. However, it may be feasible to come up with solutions, guidelines and best practices that work for certain deployments. Any such proposal MUST have the following characteristics. REQ1: It MUST be backward compatible with the current version of OWAMP and TWAMP, described respectively in and . REQ2: It MUST NOT compromise on the security properties of OWAMP and TWAMP.

To be done.

Solutions, guidelines and best practices for collecting IPPM one-way and two-way active measurements across NATs MUST NOT introduce new security vulnerabilities compromising the security properties of OWAMP and TWAMP.

This document does not require any action from IANA.

To be done