Network Address Translator (NAT) Considerations for IP Performance Metrics (IPPM) Active Measurement Protocols
draft-muthu-ippm-twamp-nat-00

Abstract

This document describes the problems in obtaining IP Performance Metrics (IPPM) one-way and two-way active measurements across Internet paths that traverse Network Address Translators (NATs). It also documents the requirements, guidelines and best practices when such measurements are obtained across NATs.

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 http://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 January 7, 2017.

Copyright Notice

Copyright (c) 2016 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 (http://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.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Problem Description
• 3.1. Traversal Problem
• 3.2. Application Level Gateway (ALG) Problem
• 4. Requirements
• 5. Guidelines for Operating Across NATs
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgement
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

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 [RFC2993]). They generally operate by modifying the IP address and port information (within the network/transport header) of packets en-route. [RFC3027] 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.

2. Terminology

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 [RFC2119].

In this document, the term "NAT" refers to both "Basic NAT" and "Network Address/Port Translator (NAPT)" (see section 3 of [RFC4787]). 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).

3. Problem Description

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.

3.1. Traversal Problem

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.

           Host A                                      Host B
        +----------+                               +-----------+
        | Control  |<--------TWAMP-Control-------->| 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---->
         

Figure1: TWAMP across NAT

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.

3.2. Application Level Gateway (ALG) Problem

When a protocol is unable to operate through a NAT, the use of an Application Level Gateway (ALG) may permit operation of that protocol [RFC3235]. 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.

[RFC2694] 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.

4. Requirements

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 [RFC4656] and [RFC5357].

REQ2: It MUST NOT compromise on the security properties of OWAMP and TWAMP.

5. Guidelines for Operating Across NATs

To be done.

6. Security Considerations

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.

7. IANA Considerations

This document does not require any action from IANA.

8. Acknowledgement

To be done

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses