Network Address Translator (NAT) Considerations for IP Performance Metrics
(IPPM) Active Measurement ProtocolsEricssonFerns IconDoddanekundi, MahadevapuraBangaloreKarnataka560037Indiap.muthu.arul.mozhi@ericsson.comEricssongregory.mirsky@ericsson.com
Transport
Network Working GroupInternet-DraftIPPMOWAMPTWAMP 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.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.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