Internet Draft C.Aoun
Category Informational M. Wakley
T.Sassenberg
Nortel Networks
Expires on July 28 2003 February 28 2003
A NAT package for MGCP NAT traversal
< draft-aoun-mgcp-nat-package-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Network Address translators impact several application protocols in
the internet; this document discusses how the MGCP protocol could
work through NATs. Only the signaling protocol message traversal is
discussed in this version of the document. The VoIP streams NAT
traversal are already documented and researched within the MIDCOM
WG.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1 Overview.......................................................2
2 Conventions used in this document..............................2
3 MGCP NAT complications.........................................2
Aoun, Wakley, Sassenberg Informational - Expires August 2003 1
A NAT package for MGCP NAT traversal February 2003
4 NAT package description........................................4
5 NAT traversal fragmentation considerations.....................6
6 Applicability statement........................................7
7 IANA consideration.............................................7
8 Security Considerations........................................7
9 Changes since draft-aoun-mgcp-nat-package-00.txt...............7
10 References.....................................................7
11 Acknowledgments................................................8
12 Author's Addresses.............................................8
13 Intellectual Property Statement................................8
14 Full Copyright Statement.......................................8
1 Overview
Network Address translators ([NAT]) impact several application
protocols in the Internet. [NAT-COMP] provides a good reference on
the impact of NATs on certain protocols. This document defines how
the MGCP [MGCP] protocol could work in networks where NATs are
deployed, whether a single one of them or several in a chain.
Typical examples of NAT deployments include (but are not restricted
to):
-Deployment of a NAT in the customer premise network
-Deployment of a NAT in the ISP
-Deployment of NATs in both the customer premise network and the ISP
(i.e. there is a chain of NATs that is traversed).
Only the signaling protocol interface is discussed in this version
of the draft (i.e. the MGCP message traversal through NATs). The
MGCP controlled, VoIP streamsÆ NAT traversal is already documented
and researched within the MIDCOM IETF WG [MDCMFW]. The next version
of the draft will provide an overview of the VoIP media traversal
solutions discussed in the MIDCOM WG [MDCMFW].
2 Conventions used in this document
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 RFC-2119.
3 MGCP NAT complications
When Media Gateways (MGW) controlled with the MGCP protocol are
deployed behind NATs, the Media Gateway Controller (MGC) should be
allowed to control the MGW transparently (or almost transparently).
When the MGW establishes MGCP communication with its MGC, the NAT
creates a bind which includes the private IP address and port of the
MGCP client on the MGW and the public IP address and port allocated
by the NAT (case a). In some NAT implementations the binding could
also include the IP address of the MGC (case b) or both the IP
address and port of the MGC (case c).
Aoun, Wakley, Sassenberg Informational - Expires August 2003 2
A NAT package for MGCP NAT traversal February 2003
NATs behaving as in :
-case a) are known as full cone NATs
-case b) are known as restricted cone NATs
-case c) are known as restricted port cone NATs
These NATs belong to the traditional NAT family [TNAT] and are
documented in [STUN]. The created NAT bind will have an associated
watch dog inactivity timer. In the event that no packets are sent
from the MGW to the MGC through the bind over the established
duration, the bind will be removed by the NAT.
When the bind is removed by the NAT, the MGC will no longer be able
to contact the MGW.
3.1 Proposed keep alive mechanism
There are 2 possible ways to reuse existing MGCP messages as keep
alives:
a) Use the audit message (AUEP, AUdit EndPoint) sent by the MGC to
which the MGW will reply, thus the response to the AUEP will
serve as the keep alive.
b) Use an event notification message, where the event is persistent.
The event in this case being that the MGW watch dog inactivity
timer has timed-out.
Method a) meets the requirement by sending a response to the audit
request but requires the MGC host to have an inactivity timer (which
is already required but with a bigger auditing period) as well as
processing the audit message, and processing the audit response
message. Moreover, this method doesnÆt allow the MGC to reach its
controlled MGW after fail-over.
Method b) requires the MGW to notify the MGC each time the
inactivity watch dog timer times out. This method allows the MGC to
communicate with the MGW when the MGC recovers from a failure and
keeps the bind active by generating a message from the MGW to the
MGC.
3.2 Method of operation of the proposed keep alive mechanism
This draft provides a solution to the NAT expiration problem by
defining a timer and a persistent package/event.
The MGW must define a "keep alive" timer. The duration of the "keep
alive" timer is determined by the NAT bind's watch dog inactivity
timer. The MGW must enable the "keep alive" timer after successful
registration (i.e. when an RSIP message has been acknowledged by the
MGC). The MGW must reset the "keep alive" timer each time the MGW
Aoun, Wakley, Sassenberg Informational - Expires August 2003 3
A NAT package for MGCP NAT traversal February 2003
sends an MGCP message. The MGW must disable the "keep alive" timer
if it becomes Disconnected.
Expiry of the "keep alive" timer must cause the MGW to generate a
MGCP Notification of the persistent event defined below.
If the MGW doesnÆt receive a response to the Notify message after
several retransmissions, the standard MGCP algorithm applies (i.e.
transition into the disconnected state).
When retransmitting the Notify message (due to lack of
acknowledgment) the retransmission timer should not be exponentially
backed off but instead the retransmission timer should reuse the
inactivity watch dog timer (else the NAT bind could expire as the
exponentially backed off retransmission timer could be bigger than
the NAT bind timer).
The keep alive expiry persistent event abides by the persistent
event rules as defined in [MGCP].
4 NAT package description
Package Name : NAT Package
PackageID : NAT
Version : 1
This package is a new MGCP package. In its first version, only one
event is defined (keep alive).
Events MUST always be prefixed with the "NAT" package name.
4.1 Properties
None
4.2 Events
Keep Alive
EventID : NAT/ka
Event Type : Persistent
This event must be reported by the MGW when its keep alive timer
expires. The timer is reset each time the MGW sends any MGCP
message (including MGW responses to commands from the call agent,
such as "200 xxx OK" acknowledgements).
Aoun, Wakley, Sassenberg Informational - Expires August 2003 4
A NAT package for MGCP NAT traversal February 2003
On timer expiry, the event must be reported from a virtual
endpoint on the gateway named 'nat-timeout'.
4.3 Signals
None
4.4 Statistics
None
4.5 Procedures
The keep alive timeout is a gateway specific event, rather than a
call processing event that could occur on a normal endpoint.
Therefore, since the "all of" wildcard convention cannot be used
with the MGCP Notify (NTFY) message, a virtual endpoint is used
to report the event.
The virtual endpoint, named 'nat-timeout', does not need to be
under the supervision of a NotificationRequest in order to report
the event. As per the persistent event definition, a RequestID
of 0 must be used to report the event if the endpoint is not
under the supervision of a NotificationRequest.
Note that the sending of the keep alive event itself constitutes
an outgoing MGCP message and hence the keep alive timer must be
reset when this NTFY is sent.
If no response is received from the MGC, the normal
retransmission algorithm for the message should be applied
(bearing in mind that each of the retransmissions will also reset
the keep alive timer).
If the MGC replies to the MGWÆs notify message (notifying the
inactivity timer expiration) with a negative acknowledgment (i.e.
error code 522, unknown event), the negative acknowledgment
should be ignored and the keep alive operations continue as
defined above.
Gateways that implement this package MUST provide control of
operation through a provisioning system. This should include the
ability to enable or disable the keep alive timer completely, and
allow configuration of the timer duration in seconds.
4.6 Use Cases: Example Message Flow
The keep alive timer must be reset each time the MGW sends any
MGCP message. For example:
Aoun, Wakley, Sassenberg Informational - Expires August 2003 5
A NAT package for MGCP NAT traversal February 2003
200 123 OK (keep alive timer reset)
If the timer expires (no MGCP message is sent by the MGW for the
duration of the keep alive timer), the MGW reports the keep alive
event:
------>
NTFY 456 nat-timeout@mgw.nortel.com MGCP 1.0
X: 0
O: NAT/ka
The call agent acknowledges:
<------
200 456 OK
5 NAT traversal fragmentation considerations
NATs have known issues with fragmentation ([NAT-COMP]):
-In case the fragments get to the NAT, the NAT may not be able to
correlate the received fragment with an existing bind; only the
initial fragment including the transport headers will be forwarded
and the rest of fragments will be dropped.
-Certain NATs (not all low end NATs support this behavior)
install a state, containing the IP packet ID and the
source address and destination pair of the packet, when
the packet has the more-fragments bit enabled (i.e. packet
has been fragmented). This is used to correlate fragments
received with the same specified packet ID and same source
and destination address pair. Even with that there might
be some issues in case the initial fragment doesnÆt arrive
in sequence and all other fragments that arrived first
will be dropped.
-When 2 clients (in our case MGWs) behind the same NAT are trying to
reach the same remote end (i.e. the MGC in this case), they might
use the same packet ID. If this happens when fragments reach the
MGC, the MGC could get confused during reassembly of the packets as
there are no ways to identify to which remote end does the fragment
belong.
3 ways to engineer your network to avoid NAT fragmentation problems,
listed by order of priority:
-Fragment at the data link layer if applicable (case of PPP)
-In case the MTU could be extended, extend the MTU to the data
link MTU size, after analyzing the related jitter impacts.
Aoun, Wakley, Sassenberg Informational - Expires August 2003 6
A NAT package for MGCP NAT traversal February 2003
-Minimize the size of the MGCP datagram, below the MTU, either by
using fragmentation at the MGCP level (which is not yet defined) or
by avoiding the aggregation of MGCP commands in single transaction
messages (this needs to be configured locally when the MGW is known
to be behind a NAT).
6 Applicability statement
The mechanism discussed in this draft, to maintain MGWs behind NATs
reachable by their MGC, is applicable ONLY when the MGCP messages
are sent and received on the same address and port.
7 IANA consideration
As the NAT package doesnÆt exist, the MGCP NAT package will follow
the IANA MGCP package reservation process as defined in [MGCP]. The
authors of the draft will request from IANA a specific MGCP NAT
package identifier.
8 Security Considerations
Security considerations in [MGCP] apply to the introduced keep alive
mechanism in this document.
9 Changes since draft-aoun-mgcp-nat-package-01.txt
Minor editing updates.
10 References
[MGCP] F. Andreasen et all, Media Gateway Control Protocol
(MGCP)version 1.0, RFC 3435, January 2003
[MDCMFW] P.Srisuresh et all, Middlebox communication
architecture and framework, RFC 3303, August 2002
[NAT] Holdrege, M. and Srisuresh, P., IP Network Address
Translator (NAT) Terminology and Considerations, RFC 2663,
August 1999
[NAT-COMP] Holdrege, M. and Srisuresh, P., Protocol
Complications with the IP Network Address Translator, RFC 3027,
January 2001
[STUN] Rosenberg, J.et all, STUN - Simple Traversal of UDP
Through NATs, draft-ietf-midcom-stun-05.txt, work in progress
[TNAT] Srisuresh, P and Egevang, K., Traditional IP Network
Address Translator, RFC 3022, January 2001
Aoun, Wakley, Sassenberg Informational - Expires August 2003 7
A NAT package for MGCP NAT traversal February 2003
11 Acknowledgments
The authors would like to thank Flemming Andreasen, Kevin Boyle,
Bill Foster, Louis Levay, Tony Macdonald, Julian Mitchell, Craig
Telke, Richard Willis and Dan Wing for their useful comments and
suggestions related to this draft.
12 Author's Addresses
Cedric Aoun
Nortel Networks
France
Email: cedric.aoun@nortelnetworks.com
Martin Wakley
Nortel Networks
Email: mwakley@nortelnetworks.com
Tania Sassenberg
Nortel Networks
Email: tanisas@nortelnetworks.com
13 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in RFC 2026. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
14 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
Aoun, Wakley, Sassenberg Informational - Expires August 2003 8
A NAT package for MGCP NAT traversal February 2003
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Aoun, Wakley, Sassenberg Informational - Expires August 2003 9