One document matched: draft-muthu-ippm-twamp-nat-00.txt
Network Working Group M. Perumal
Internet-Draft G. Mirsky
Intended status: Standards Track Ericsson
Expires: January 7, 2017 July 6, 2016
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
Perumal & Mirsky Expires January 7, 2017 [Page 1]
Internet-Draft NAT Considerations for IPPM Protocols July 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Description . . . . . . . . . . . . . . . . . . . . . 3
3.1. Traversal Problem . . . . . . . . . . . . . . . . . . . . 3
3.2. Application Level Gateway (ALG) Problem . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Guidelines for Operating Across NATs . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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:
Perumal & Mirsky Expires January 7, 2017 [Page 2]
Internet-Draft NAT Considerations for IPPM Protocols July 2016
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.
Perumal & Mirsky Expires January 7, 2017 [Page 3]
Internet-Draft NAT Considerations for IPPM Protocols July 2016
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
Perumal & Mirsky Expires January 7, 2017 [Page 4]
Internet-Draft NAT Considerations for IPPM Protocols July 2016
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
Perumal & Mirsky Expires January 7, 2017 [Page 5]
Internet-Draft NAT Considerations for IPPM Protocols July 2016
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<http://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<http://www.rfc-editor.org/info/rfc5357>.
9.2. Informative References
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A.
Heffernan, "DNS extensions to Network Address Translators
(DNS_ALG)", RFC 2694, DOI 10.17487/RFC2694, September
1999, <http://www.rfc-editor.org/info/rfc2694>.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
DOI 10.17487/RFC2993, November 2000,
<http://www.rfc-editor.org/info/rfc2993>.
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027,
DOI 10.17487/RFC3027, January 2001,
<http://www.rfc-editor.org/info/rfc3027>.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235,
DOI 10.17487/RFC3235, January 2002,
<http://www.rfc-editor.org/info/rfc3235>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <http://www.rfc-editor.org/info/rfc4787>.
Perumal & Mirsky Expires January 7, 2017 [Page 6]
Internet-Draft NAT Considerations for IPPM Protocols July 2016
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
Authors' Addresses
Muthu Arul Mozhi Perumal
Ericsson
Ferns Icon
Doddanekundi, Mahadevapura
Bangalore, Karnataka 560037
India
Email: p.muthu.arul.mozhi@ericsson.com
Greg Mirsky
Ericsson
Email: gregory.mirsky@ericsson.com
Perumal & Mirsky Expires January 7, 2017 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 04:16:48 |