Internet Draft C.Aoun
Category Informational Nortel Networks
Expires on September 2003 March 1st 2003
NSIS Network Address Translator implications
< draft-aoun-nsis-nat-imps-01.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
This Internet draft discusses Network Address Translators impacts on
in path directed signaling. The purpose of this memo is to provide
inputs to the NSIS WG on Middlebox specific considerations.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1 Overview.......................................................2
2 Conventions used in this document..............................2
3 Used terminology...............................................2
4 In path signaling NAT complications............................3
5 Proposed solution..............................................3
6 Peer to peer application applicability.........................7
Aoun Informational Expires April 2003 1
NSIS NAT implications March 2003
7 NSIS NAT and Firewall transitions issues.......................7
8 Security Considerations........................................9
9 Summary.......................................................10
10 References....................................................10
11 Acknowledgments...............................................10
12 AuthorÆs Addresses............................................10
13 Full Copyright Statement......................................11
1 Overview
In path directed signaling is used in the Internet to allocate
resources from network nodes. The allocated resources could be
bandwidth, packet filter pinhole, network address translator binds
and other resource types.
When an NSIS Initiator (NI) ([NSISFW]) sends an in path signaling
message to the NSIS Responder (NR) ([NSISFW]), it needs to know the
address of the NR. When a NAT is not in the path between the NI and
NR there is no issue for the NI to guess the NR address, however
when one of the NSIS NF co-hosts a NAT function it is a complicated
problem.
This Internet draft will address the above-mentioned matter by
providing dynamic means of discovering the ôcontact informationö of
NR behind NATs.
In addition the document covers generic NAT implications on NSIS for
both NSIS aware NATs and non NSIS aware NATs and their coexistence.
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 Used terminology
All the used NSIS terminology is consistent with [NSISFW]
NF: NSIS Forwarder
NI: NSIS Initiator
NR: NSIS Responder
NE: NSIS Element, one of the above 3 components
CASP: Common Application Signaling Protocol
Aoun Informational Expires September 2003 2
NSIS NAT implications March 2003
ALSP: Application Layer Signaling Protocol
4 In path signaling NAT complications
We shall discuss the in path signaling NAT complications by looking
at a simple network deployment.
The NI and NR are co-hosting an application client.
+-----------------------+ +------------+ +---------------------+
+ NI/AC1 ---------MB1/NF+----+The Internet+--+ MB2/NF-------NI/AC2 +
+ + +------------+ + a.b.c.d +
+-----------------------+ +---------------------+
Network x Network y
Application Server 1
Figure 1
In the used example Application Client 1 (AC1) and AC2 use
Application server 1 (AS 1) as their server for registration and
location purposes as well as to proxy their application messages.
MB1 and MB2 are Middle boxes, as defined in [MDCMFW], that apply NAT
functions and behave as an NSIS Forwarder as specified in [NSISFW].
When AC1 wants to establish an application session with AC2, it will
need to request from the Middleboxes on the data path an address and
port bind.
In order to do so it needs to know to which address and transport
port it needs to send the in path signalling message.
The Middleboxes on the path prevents that, unless having an existing
static bind already configured on the Middlebox and known by all NIs
that would communicate with the specified NR. This would introduce a
lot of operational complexity and would not scale.
5 Proposed solution
As shown in figure 1, several applications require an application
server for registration purposes or for continuous message proxying
purposes.
We could use this applicationÆs specificities to solve the above
problem.
When AC1 registers with AS1, AS1 would have a softstate giving the
status of AC1Æs reachability, which includes the last source address
and source port that brought the application Protocol Data Unit
(PDU).
The same applies to AC2.
When AC1 wishes to establish an application session with AC2, AS1
would provide AC2Æs ôcontact informationö. This contact information
Aoun Informational Expires September 2003 3
NSIS NAT implications March 2003
will be the address and source port on which AC2 could receive
application signalling.
As AC2 is deployed behind MB2, a bind already exists in MB2Æs NAT
mapping table.
Sample from MB2 NAT mapping table:
Protocol int address int port ext address ext port
UDP a.b.c.d w e.f.g.h x
AC2 ôcontact informationö consists of e.f.g.h and port x.
When AC1 receives AC2Æs contact information it will request the NI
API to send an in path signalling message to e.f.g.h as well as to
provide AC2Æs contact information within the messageÆs SDU.
When an NSIS NF receives the in path signalling message it will look
at the ôcontact informationö and then look at its NAT mapping table.
Based on the mapping it will find out that the destination of the
signalling message is a.b.c.d.
The NF will then forward the message to a.b.c.d which is the real
recipient of the NSIS message.
Figures 2 and 3, shows message sequences of the mode of operation
for the proposed method of signalling NEs when NATs are in the path.
Figure 2 shows how the æContact InformationÆ is gathered.
Figure 3 shows how an NE discovers the next hop NE in the path
towards the end destination, more information on next hop NE
discovery could be found in [CASP] within the SCOUT related
sections.
Analysis done in [CASP] and [CASP-NATFW] show that in order to
secure NSIS signalling, the discovery of the next hop peer NE needs
to be separate from installing policy rules on the NSIS aware NATs
and firewalls.
Once the next hop peer NE is discovered, a security association is
established with it as specified in [CASP] and then policy rule
installation will proceed as discussed in [CASP-NATFW].
Aoun Informational Expires September 2003 4
NSIS NAT implications March 2003
NE1/AC1 NF1 AS1 NF2 NE2/AC2
a.b.c.d
User apps
message
<--------
NAT bind
creation
User apps
message
<-------------
User apps message
Came from e.f.g.h:x, it
Is linked to AC2,
AC2 æContact InformationÆ =
e.f.g.h:x UDP
.
.Same done with AC1
.
.
Figure 2
Initiate user app
With AC2
----------------->
Initiate user app
With AC2
----------------->
NE1/AC1 NF1 AS1 NF2 NE2/AC2
a.b.c.d
AC2 æContact InformationÆ
e.f.g.h:x UDP
< ---------------
AC2 æContact InformationÆ
e.f.g.h:x UDP
< ---------------
NSIS Nxt hop discovery msg
AC2 æContact InformationÆ
e.f.g.h:x UDP
-------------------- >
NF1 will keep a state
Related to the msg originator
NSIS Nxt hop discovery msg
AC2 æContact InformationÆ
e.f.g.h:x UDP
-------------------------------->
æContact
InformationÆ maps to
a.b.c.d host.
Aoun Informational Expires September 2003 5
NSIS NAT implications March 2003
NE1/AC1 NF1 AS1 NF2 NE2/AC2
a.b.c.d
Need to transfer
message to
a.b.c.dNF2 keeps an
associated state to
the received message
including from where
message came from
(NF1)
NSIS Nxt hop discovery
msg AC2 æContact
InformationÆ a.b.c.d:w
UDP
------------>
RESPONSE
< ----------
RESPONSE
< ---------------
RESPONSE
<---------------
RESPONSE
< ---------------
Figure 3
RESPONSE message in figure 3, provides information on the next hop
NE, this may include the NE capabilities.
5.1 Proposed methodÆs implications on the NSIS framework
The integration of the proposed solution within NSIS would only
impact the Middlebox specific CASP client [CASP] or ALSP [2level].
Only NFs supporting the Middlebox specific client will need to
apply the operation depicted above.
5.2 Multi-homing considerations
In case there are several NATs a the edge of local network, it is
quite possible that the discovery phase of the æContact InformationÆ
was based on traversal of a specific NAT that is not the one in the
natural path of the remote application end point. Hence NSIS
signaling could traverse a different NAT than the one traversed by
the data flows exchange between the user application clients.
Aoun Informational Expires September 2003 6
NSIS NAT implications March 2003
To solve the multi-homing problem, proper anchoring mechanisms
should be used to ensure that the data flows will be traversing the
same NFs as the one traversed by the signaling.
Current known packet anchoring mechanisms:
a) Twice NAT, as defined in [NAT], translates both the
source and destination addresses (and transport ports)
b) Source routing
Option a) is quite controversial as the Internet architecture
evolution is going towards of getting rid of NATs.
Option b) is also controversial as source routing is not much
supported in the Internet today, but it could be less controversial
as the source routing is required within the local network.
In case a) is used, it implied that the NSIS-NATFW client supports
the concept of a local destination address/port pair.
When the NSIS-NAT/FW client provides an address/port pair to the
application client it will need to also provide a local destination
address/port pair. That local destination address/port pair will be
a recipient on a specific NSIS aware NAT. That NAT will obviously
be the same one as the one traversed by the NSIS signaling and the
used message to discover the æContact InformationÆ.
In case b) is used, the NSIS-NATFW will need to have the capability
to specify the next hop in a source route specific object. This
next hop will be specified within a source route option for data
packets being transmitted between the 2 user application clients.
6 Peer to peer application applicability
The proposed method is also applicable to peer to peer applications.
When an application client is peering with another one, it could
provide to its NSIS NI API the address and port from which it has
received the application signaling from the remote peer.
This information will be formatted as the ôcontact informationö and
sent within the CASP Middlebox specific client or the Middlebox
specific ALSP.
7 NSIS NAT and Firewall transitions issues
As there is no D day where all deployed NATs and Firewalls will
support NSIS, proper analysis should be done to understand how we
could minimize the co-existence issues between NSIS-NATFW clients
and existing none NSIS aware NATs and firewalls.
Aoun Informational Expires September 2003 7
NSIS NAT implications March 2003
7.1 Traversed Firewall is not NSIS aware
In case a NSIS unaware firewall is traversed by NSIS messages, NSIS
messages should be allowed to go through it, as well as the data
flows exchanged between the user application clients. This is not
necessarily an obvious task to perform in case the NSIS messages
canÆt be identified by the NSIS unaware firewall. Same applies for
the user application data flows.
7.1.1 NSIS message identification
NSIS message identification should be supported by existing
firewall. Currently firewalls support flow identification by
using the 5 tuple or a sub-set of it. We canÆt assume that the
firewall will support router alert option ([Ralert]) and even
if it did support it, it may mean something else.
7.1.2 User application Data flow identification
User application data flow identification, should be
deterministic at some level. Normally this means that the
application clients uses a combination of an address and
specific transport port range. This combination should be
configured on the firewall.
NE1/AC1 NSIS-unaware FW NSIS-NATFW FW NE2/AC2
a.b.c.d
Figure 5
7.1.3 NSIS-NATFW aware NF is deployed in the path
In case a NAT is deployed on the path and it is NSIS-NATFW
client aware ([CASP-NATFW]), then assigned bind should be
consistent with policy rules configured with the NSIS unaware
firewall.
NE1/AC1 NSIS-unaware FW NSIS-NATFW NAT NE2/AC2
a.b.c.d
Policy rules configured
To allow specific filters
For NSIS signaling and user
Application data flows
Figure 6
Aoun Informational Expires September 2003 8
NSIS NAT implications March 2003
7.2 Traversed NAT is not NSIS-NATFW aware
NE1/AC1 NSIS unaware NAT NE2/AC2
a.b.c.d
Figure 7
In case an NSIS unaware NAT is on the path of packets from AC2
towards AC1, the following could be applicable.
NE2 sends an NSIS message towards NE1, we assume that æContact
InformationÆ method is used. When the NSIS message reaches the NSIS
unaware NAT the NAT doesnÆt translate the filter attribute [CASP-
NATFW]. When NE1 receives the NSIS message it will know that there
is an NSIS unware NAT in the path, and will provide this information
within the response to NE2. All consequent NSIS messages between
NE1 and NE2 will now include this information.
NE2 will then provide the filter matching the data flows to be
exchanged between AC1 and AC2 and send this information within an
NSIS message to NE1. That NSIS message will be sent by using the
same transport protocol than the data flows to be exchanged between
the user application client (AC1 and AC2).
When NE1 will receive the NSIS message it will replace the filter
attribute with the source address and source transport port
information.
This implies that the NSIS-NATFW implementation on NE1 and NE2
supports the same transport protocol as the one used for the data
exchanges.
The generic requirement on NSIS will be that it should be
transported on several transport protocols, changing from one
transport protocol to the other should be based on specific events
as shown above.
8 Security Considerations
As the ôcontact informationö is provided by the application
protocol, proper authentication mechanisms MUST be put in place to
avoid having false ôcontact informationö that would generate man in
the Middle attacks.
The NSIS security mechanisms will not be required any modifications.
Aoun Informational Expires September 2003 9
NSIS NAT implications March 2003
9 Summary
This draft proposes a realistic solution that will allow NSIS NR to
be deployed behind NSIS NF co-hosting NAT functions.
This draft doesnÆt discuss all the specificities of the Middlebox
ALSP ([2level],[CASP-NATFW]), other implications should be
considered as the ones discussed in [CASP-NATFW].
In addition the draft provides inputs on transition issues when
deploying NSIS-NATFW signaling application with existing NAT and
Firewalls in the path.
10 References
[NSISFW] Ilya Freytsis et all, Next Steps in Signaling:
Framework, draft-ietf-nsis-fw-00.txt, work in progress
[2level] R. Braden and B. Lindell, A Two-Level Architecture for
Internet Signaling, draft-braden-2level-signaling-01.txt, work
in progress
[CASP] H. Schulzrinne et all, CASP - Cross-Application
Signaling Protocol, draft-schulzrinne-nsis-casp-01.txt, work in
progress
[CASP-NATFW] H. Tschofenig et all, A Firewall/NAT Traversal
Client for CASP, draft-tschofenig-nsis-casp-midcom-01.txt, work
in progress
[MDCMFW] P.Srisuresh et all, Middlebox communication
architecture and framework, RFC 3303,August 2002
[NAT] P. Srisuresh, ôIP Network Address Translator (NAT)
Terminology and Considerationsö, RFC 2663, Internet Engineering
Task Force, Aug. 1999
[Ralert] D. Katz, ôIP Router Alert optionö, RFC 2113, IETF,
February 1997
11 Acknowledgments
The authors would like to thank Louis-Nicolas Hamer for his
comments related to this draft.
12 AuthorÆs Addresses
Cedric Aoun
Nortel Networks
Aoun Informational Expires September 2003 10
NSIS NAT implications March 2003
France
Email: cedric.aoun@nortelnetworks.com
13 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
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 Informational Expires September 2003 11