| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on January 12, 2006.
Copyright © The Internet Society (2005).
This document contains a number of mechanisms that may be used in order to enable General Internet Messaging Protocol for Signaling (GIMPS) messages to traverse different types of Network Address Translators that may be located along the path between two adjecent NSLP hosts.
1.
Introduction
2.
Terminology
3.
Problem Statement
4.
Assumptions
5.
Traversal of GaNATs in the absence TLS or IPsec
5.1
NSLP-unaware GaNATs
5.1.1
NI-side NSLP-unaware GaNATs
5.1.2
NR-side NSLP-unaware GaNATs
5.2
NSLP-aware GaNATs
5.3
Combination of NSLP-aware and NSLP-unaware GaNATs
6.
GaNATs in the presence of TLS or IPSec
6.1
NSLP-unaware GaNATs
6.1.1
NI-side NSLP-unaware GaNATs
6.1.2
NR-side NSLP-unaware GaNATs
6.1.3
Additional GIMPS peer processing
6.2
NSLP-aware GaNATs
7.
NSIS-unaware NATs
8.
Security Considerations
8.1
Service Denial Attacks
8.2
Network Intrusions
9.
Acknowledgments
10.
IAB Considerations
11.
IANA Considerations
12.
Normative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
Network Address Translators (NATs) modify certain fields in the IP header of the IP packets that traverse them. In the context of signalling as defined by the NSIS group, this behaviour, if not properly addressed, may lead to the installation of inconsistent and meaningless state at network nodes with respect to the actual traffic that traverses these nodes.
This document proposes a collection of algorithms that have to be implemented in order to enable GIMPS signalling, and the data flows to which this signalling refers, to traverse NATs in a way that preserves the consistency of state that is installed in the network, and in a manner transparent to signalling applications. The document is organised as follows. The next section introduces the terminology that is used throughout this document. Section 3 (Problem Statement) provides a detailed discussion of the problems that are addressed by this document. Section 4 (Assumptions) list the assumptions on which the proposed mechanisms are based. Section 5 (Traversal of GaNATs in the absence TLS or IPsec) presents the proposed mechanisms for the case where no TLS or IPsec protection is required for the signalling traffic between two NSLP peers, and Section 6 (GaNATs in the presence of TLS or IPSec) presents the proposed mechanisms where such protection is required.
| TOC |
The terminology, abbreviations and notational conventions that are used throughout the document are as follows.
| TOC |
According to [1] (Schulzrinne, H. and R. Handcock, “GIMPS: General Internet Messaging Protocol for Signalling,” May 2005.), all GIMPS messages carry IP addresses in order to define the data flow to which the signalling refers. Moreover, certain GIMPS messages also carry the IP address of the sending peer, in order to enable the receiving peer to address subsequent traffic to the sender. Packets that cross an addressing boundary, say from addressing space S1 to S2, have the IP addresses in the IP header translated from space S1 to S2 by the NAT; if GIMPS payloads are not translated in a consistent manner, the MRI in a GIMPS packet that crosses the boundary, e.g. from address space S1 to S2, refers to a flow that does not exist in S2. In fact, the flow is invalid in S2 because at least one of the involved IP addresses belongs to S1. Moreover, the IP address of the sending peer may also be invalid in the addressing space of the receiving peer. The purpose of this document is to describe a way for GIMPS messages to be translated in a way consistent with the translation that NATs apply to the IP headers of both signalling and data traffic.
A NAT may either be NSIS-unaware or NSIS-aware. The case of NSIS-unaware NATs is discussed in Section 7 (NSIS-unaware NATs). If the NAT is NSIS-aware, it is typically also able to support at least one NSLP. Note that there exists an NSLP, namely the NATFW NSLP [2] (Stiemerling, M., Tschofenig, H., and C. Aoun, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” May 2005.), that specifically addresses NAT traversal for data flows. Inevitably, the NATFW NSLP also provides the necessary mechanisms for the related signalling to traverse the NATs involved. Therefore, we can further divide NSIS-aware NATs into two categories, namely GIMPS-and-NATFW-aware NATs and GIMPS-aware-and-NATFW-unaware NATs. In the sequel, we call the latter simply GIMPS-aware NATs (GaNATs). A GIMPS-and-NATFW-aware NAT performs NAT traversal according to the NATFW NSLP; the case of NAT traversal in the presence of such NATs is therefore beyond the scope of this document.
As is natural, a NATFW-aware NAT only translates the relevant fields for the NATFW signalling traffic in a way consistent with the relevant data flow. Consequently, GIMPS signalling in the presence of NATFW-unaware NATs and for NSLPs other than the NATFW NSLP remains an open problem. This document precisely addresses this problem, by proposing mechanisms that operate at the GIMPS layer.
In general, a given data flow between a data sender (DS) and a data receiver (DR) may have to traverse a number of NATs, some of which may be GIMPS-and-NATFW-aware, some may be GIMPS-aware, and some may be NSIS-unaware. Additionally, NSLP signalling for such a data flow may be required to traverse through a subset of those NATs. Whether or not the routing inftrastructure and state of the network causes the signalling for such a data flow to traverse the same NATs as the flow depends, among other things, on the signalling application. While signalling of a QoS NSLP, for example, might not traverse any of the NATs that are traversed by the data flow, the signalling of the NATFW NSLP traverses at least those NATs that implement the NATFW NSLP (otherwise the signalling path would no longer be coupled to the data path, as this coupling is defined by the GIMPS QUERY/RESPONSE discovery mechanism). It is desirable for every possible combination of NATs, either on the data or the signalling path, to be functional and secure.
Due to the GIMPS QUERY/RESPONSE discovery mechanism (according to which QUERY messages are simply forwarded if the current node does not support the required NSLP), two GIMPS nodes identify themselves as NSLP peers only if they both implement the same NSLP, say NSLP X. This means that, if one or more X-unaware NATs are between them, then the two X peers are not able to discover each other at all. This is because, even in the unlikely event that the bindings necessary for the GIMPS traffic to traverse the in-between NAT(s) exist, the NLI.IA Object included in the RESPONSE message sent by the downstream X-aware peer will be invalid (i.e. the IP address will be unreachable) in the address space of the upstream X peer. In order to overcome this limitation, either the two X peers need to cope with the in-between NAT(s), or, if the NAT(s) are GaNATs, they (the GaNATs) need to apply additional processing in order to transparently create and maintain the required consistency. Additionally, if X-aware NATs are on the data path (where X is any NSLP except NATFW), then these NATs should process X traffic in a way the preserves consistency after address translation. This processing deviates from the processing of X-aware non-NAT nodes. In the following sections we propose certain processing rules that aim to overcome the limitation of two adjacent X peers not being able to execute X in the presence of in-between NAT(s). We do not consider the case where X=NATFW and all NAT(s) on the path are NATFW-aware. This case is handled by the NATFW NSLP.
Note that we have to deal with a number of different situations, depending on whether X is supported by the GaNATs. Thus, we have the following three subcases.
In the following sections, we discuss the three cases separately.
| TOC |
The discussion in this document is based on the following assumptions. Note that X denotes a fixed NSLP, other than the NATFW NSLP.
Note that this assumption is not necessarily met by "normal" data path coupled signalling. This is because, under "normal" data path coupled signalling, the signalling traffic is "coupled" to the data traffic at nodes that implement X. Thus, under "normal" path coupled signalling, it is not an error condition (e.g. a "route change"), for example, if the set of on-path (non-X) GIMPS nodes changes, as long as adjacent X peers remain the same.
+-----+
+----+GaNAT|-----+
| | A | |
| +-----+ |
+------+ +------+ +--+---+ +------+
+--+ |X NSLP| | IP | | IP | |X NSLP| +--+
|DS+-+peer +--+router| |router+--+peer 2+-+DR|
+--+ +------+ +---+--+ +--+---+ +------+ +--+
| +-----+ |
| |GaNAT| |
+----+ B +-----+
+-----+
| Figure 1: Network with more than one NAT at an addressing boundary |
Figure 1 (Network with more than one NAT at an addressing boundary) illustrates the importance of assumptions (3) and (4). With regard to that figure, suppose that a (D-mode) signalling session has been setup between the two adjacent X NSLP peers 1 and 2 and that both signalling and data traffic follows the path X NSLP peer 1 -> IP router -> GaNAT A -> IP router -> X NSLP peer 2. Suppose now that, after some time, X peer 1 decides to set up a C-mode connection with peer 2. Suppose moreover that the left IP router decides to forward the C-mode signalling traffic on the link towards GaNAT B. Thus, signalling traffic now follows the alternative path X NSLP peer 1 -> IP router -> GaNAT B -> IP router -> X NSLP peer 2. Note that this change in forwarding between the two adjacent X NSLP peers does not trigger a "route change" at the GIMPS layer because (a) it does not destroy the adjacency of peer 1 and 2 and (b) it does not destroy the coupling of the path taken by signalling traffic to that taken by data traffic (at X-aware nodes). Nevertheless, assumptions (3) and (4) mandate that this situation does not occur. However, even if such a situation occurs, the proposals in this document still work.
If assumption (1) does not hold, X has to provide additional mechanisms for the traversal of (Ga)NATs. These mechanisms must be compatible with the mechanisms described in this document. Assumptions (2), (3) and (4) hold if, at an addressing boundary, only one NAT exists. Due to security and management reasons, this is likely to be the case in many settings.
| TOC |
This section describes the operation of GIMPS-aware NATs when no cryptographic protection of signalling data is requested by two NSLP peers. The situation when such protection is required is discussed in Section 6 (GaNATs in the presence of TLS or IPSec).
Recall that by GaNAT we mean a NAT that implements GIMPS but does not implement the NATFW NSLP. In this section we discuss the possibility of two NSIS peers that implement a given NSLP, denoted as X, to discover each other and subsequently exchange signalling messages in the presence of one or more GaNATs in between. Note that X may be any NSLP including the NATFW NSLP (however, if X=NATFW we do not consider X-aware GaNATs).
Note that we have to deal with three subcases, namely (a) the case where all GaNAT(s) are X-unaware, (b) the case where all GaNAT(s) are X-aware (and X is not the NATFW NSLP), and (c) the case where a combination of X-aware and X-unaware GaNATs are between to X peers. We discuss the three cases separately.
This section describes the algorithm that an X-unaware GaNAT must execute in order to enable the signalling traffic of two X peers to traverse the GaNAT in a transparent (for the two peers) manner. The notation A.B denotes the field B of data structure A.
Note that we have to deal with two types of GaNATs, namely those that are located at the NSIS initiator (NI-side), and those that are located at the NSIS responder (NR-side). This distinction arises due to the fact that NI-side and NR-side GaNATs obtain the destination IP address for forwarded packets in different ways.
For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT executes the following algorithm.
should be forwarded on the downstream link, with [IP header].SourceIPAddress = IPGaNATds.
Issues: there is a question of whether this NAT binding should
also enable data traffic in the opposite direction to traverse the
NAT; in order to be able to demultiplex upstream traffic that
carries data that belongs to different flows, the GaNAT should keep
the necessary per-flow state. From a signalling point of view,
however, upstream data traffic that corresponds (on the application
level) to the downstream flow to which this GIMPS session refers, is
a separate flow for which, dependent on the application, there may
or there may not exist a signalling session. If such a signalling
session exists, then the GaNAT acts as an NR-side GaNAT for this
session. Thus, during the processing of this signalling care has to
be taken not to establish a NAT binding for a flow for which a NAT
binding already exists. Finally, security issues arise when traffic,
for which no signalling exists, is allowed to traverse a GaNAT.
Another issue is about refreshing the NAT binding. A NAT binding that was
established as a result of GIMPS signalling should remain in place as long
as the associated GIMPS state in the GaNAT remains valid. If GIMPS signalling
refers to a NAT binding that already exists, then the timeout of the NAT binding
should occur according to the NAT policy, in a manner independing from GIMPS
processing. (If signalling persists after the deletion of a NAT binding,
then the NAT binding may be re-installed and then timeout together with GIMPS state).
Note: the above step will fail if ST indicates security.
That is, if traffic is encrypted, then the GaNAT cannot construct
P', and if traffic is integrity-protected, performing this
step will cause an error at the receiving X peer. However, recall that,
in this section, we only discuss the scenario where such cryptographic
protection is not required.
Brief discussion of the algorithm: The fact that the GaNAT replaces the X peer's NLI.IA with its own IP address (in both directions), causes the peers to send subsequent signalling messages to the GaNAT, in the belief that they talk to the their adjacent X peer. The GaNAT transparently forwards the signalling traffic and appropriately translates the fields in the GIMPS header, by making use of the state it creates bindings.
Due to the presence of the GaNATs, no data traffic can be sent from DS to DR until all necessary bindings are in place. The MRI that the NR sees includes as destination address the IP address of the DR (as expected), but as source address the IPGaNATds of the GaNAT that is closest to the NR.
The case of NR-side GaNATs is more subtle, since, in this setting, the DS does not learn the IP address of the DR (which is assumed to be on the same side of the GaNATs as the NR) and the NI does not learn the address of the NR. In this setting we assume that each NR-side GaNAT that is in between two X peers, a priori knows the IP address of the downstream GaNAT. The last GaNAT of this chain is assumed to know the IP address of the DR. In order to clarify this assumption, see, for example, Figure 2 (Network with NR-side GaNATs (the public Internet is assumed to be between NI and X NSLP peer 1)). In this figure, GaNAT A is assumed to know the IP address of GaNAT B, GaNAT B is assumed to know the IP address of GaNAT C, and GaNAT C is assumed to know the IP address of the DR. A given GaNAT that knows such an address, in effect anticipates to receive a signalling message from the upstream direction that refers to a data flow that terminates in a downstream node. In other words, such a GaNAT may typically have already a NAT binding in place for the data traffic. We call the IP address of the next downstream GaNAT (or, if the GaNAT is the last in the chain, the DR) the "pending" IP address. In the following description it is denoted by IPNext. How IPNext is made known to each GaNAT (e.g. how the NAT binding for the data traffic is installed in the GaNAT) is outside the scope of this document.
+--+ +------+ +-----+ +-----+ +-----+ +------+ +--+ +--+
+NI+--+X NSLP+---+GaNAT+---+GaNAT+---+GaNAT+---+X NSLP+--+NR+--+DR|
+--+ |peer 1| | A | | B | | C | |peer 2| +--+ +--+
+------+ +-----+ +-----+ +-----+ +------+
| Figure 2: Network with NR-side GaNATs (the public Internet is assumed to be between NI and X NSLP peer 1) |
For every arriving IP packet P, an X-unaware, NR-side GaNAT executes the following algorithm.
Steps 2,3, 4 and 5 of the algorithm are analogous to the corresponding steps of the algorithm executed by X-unaware, NI-side GaNATs, which was described in Section 5.1.1 (NI-side NSLP-unaware GaNATs)
Recall that X may be any NSLP except NATFW. The difference of X-aware GaNATs and X-unaware GaNATs is that the former perform X processing in addition to the processing of the X-unaware GaNATs. Another way to see this is by observing that X-aware GaNATs should provide an "MRI translation service" (MRITS) in addition to normal GIMPS and X processing. The motivation behind the MRITS is for GIMPS to hide from the NSLP that signalling messages traverse an addressing boundary. In other words, the purpose of the MRITS it to make X believe that it is operating in a single IP addressing space. When and how the MRITS is invoked for a particular packet depends on (i) the direction of the packet (i.e. downstream or upstream) and (ii) the location of the GaNAT (i.e. NI-side or NR-side). It should also be noted that certain NSLP layer tasks must be carried out in consistency with the placement of the MRITS. This is to prevent events triggered by X to cause installation of inconsistent state. In order to clarify this, consider the scenario of the QoS NSLP running in a GaNAT that operates according to the mechanisms described in this section. Since the GaNAT only presents a single addressing space to the NSLP (say, the internal addressing space), the packet classifier of the GaNAT's QoS provisioning subsystem should classify packets based on internal addresses only (i.e. it should first translate packets that carry external addresses and then classify them). Whether the MRITS presents internal-only or external-only addresses to the NSLP is not significant, as long as NSLP layer operations are carried out consistently. In the remainder of this section we present the case where internal addresses are presented to the NSLP.
The MRITS is obviously invoked only on GIMPS packets that carry NSLP identifier = X. (For other GIMPS packets the GaNAT may adopt the role of an X-unaware GaNAT. Also, for non-GIMPS packets, normal NAT behaviour applies - whatever "normal" may mean.) Although the MRITS is part of GIMPS processing, in order to clarify our discussion, we view it as a somewhat separate processing step (i.e. like a subroutine). For NI-side, X-aware GaNATs, it holds that
The converse holds for NR-side X-aware GaNATs. In particular,
Figure 3 (Operation of the MRI Translation Service) illustrates this idea.
+----------------+ +----------------+
| +------+ | | +------+ |
| |NSLP X| | | |NSLP X| |
| +-+---++ | | +-+--+-+ |
| | | | | | | |
| | +-+---+ | | +----++ | |
| | |MRITS| | | |MRITS| | |
| | +---+-+ | | ++----+ | |
| | | | | | | |
| +-+-----+-+ | | ++------+-+ |
| | GIMPS | | | | GIMPS | |
u/s | +-+-----+-+ | d/s u/s | ++------+-+ | d/s
-----+----+ +-----+----- -----+---+ +-----+-----
link +----------------+ link link +----------------+ link
NI-side NR-side
X-aware X-aware
GaNAT GaNAT
| Figure 3: Operation of the MRI Translation Service |
The reason for this construction is to give X the impression that it works only with flows that originate and terminate in the internal address space. We now describe the operation of the MRITS and GIMPS in X-aware GaNATs. An NI-side X-aware GaNAT operates according to the following rules.
An NR-side X-aware GaNAT operates according to the following rules.
In the absence of an adversary, a combination of NSLP-aware and NSLP- unaware GaNATs should work without further specification. However, in the presence of an adversary, additional security issues may arise from the combination. These issues may introduce opportunities for attack that do not exist in setting where the on-path GaNATs are either all X-aware or all X-unaware.
| TOC |
This section discusses GaNAT traversal for GIMPS in the case where two peers that run a particular NSLP, say NSLP X, require cryptographic protection of the signalling traffic they exchange. As with the case where no cryptographic protection of signalling traffic is required, the case of the in-between GaNAT(s) being X-unaware is different from the case of them being X-aware.
If the two X peers require a C-mode protocol stack that indicates cryptographic protection, then, after the stack has been agreed by both peers and the underlying cryptographic protection is applied to messages, the GaNAT will be unable to translate the GIMPS header fields, in a way similar to the way described in Section 5.1.1 (NI-side NSLP-unaware GaNATs). An approach to cope with this, is to inform the X peers about the presence of the NAT during discovery. This information will enable the X peers, rather than the GaNAT(s) to perform the translation of the fields involved, after the necessary cryptographic operations have been completed. In this scenario, the burden imposed on the GaNAT is considerably less, as the only type of GIMPS messages that it needs to process in a special way, are the GIMPS QUERY and GIMPS RESPONSE messages.
In order to support the scenario of X-unaware GaNATs, a new GIMPS payload type has to be defined that encodes the aforementioned information. We call this payload type the "NAT Traversal Object" (NTO). The NTO is an optional payload in the GIMPS header of a GIMPS QUERY, and is added, and processed, by the GaNAT(s) through which the QUERY traverses. The information in the NTO must enable the two X peers to locally translate the MRI in the same way as it would have been translated by the in-between GaNAT(s) if no cryptographic protection was applied to the signalling traffic. Note that there may be more than one GaNAT between the two X peers. We now describe the algorithm that an X-unaware GaNAT must execute in order to enable the two X peers to reach this goal.
The two types of GaNATs, namely those at the NSIS initiator (NI) side, and those at the NSIS responder (NR) side, follow different algorithms.
For every arriving IP packet P, an X-unaware, NI-side GaNAT executes the following algorithm.
should be forwarded on the upstream link, with [IP header].SourceIPAddress = IPGaNATus.
Issues: there is a question of whether this NAT binding should
also enable data traffic in the opposite direction to traverse the
NAT; in order to be able to demultiplex upstream traffic that
carries data that belongs to different flows, the GaNAT should keep
the necessary per-flow state. From a signalling point of view,
however, upstream data traffic that corresponds (on the application
level) to the downstream flow to which this GIMPS session refers, is
a separate flow for which, dependent on the application, there may
or there may not exist a signalling session. If such a signalling
session exists, then the GaNAT acts as an NR-side GaNAT for this
session. Thus, during the processing of this signalling care has to
be taken not to establish a NAT binding for a flow for which a NAT
binding already exists. Finally, security issues arise when traffic,
for which no signalling exists, is allowed to traverse a GaNAT.
As is the case with NR-side NSLP-unaware GaNATs without security, an NR-side NSLP-unaware GaNAT must know a "pending" IP address, as described in Section 5.1.2 (NR-side NSLP-unaware GaNATs). This IP address is denoted as IPNext.
For every arriving IP packet P, an NSLP-unaware, NR-side GaNAT executes the following algorithm.
The remaining steps of the algorithm are analogous to the algorithm of NSLP-unaware, NI-side GaNATs, which was described in the previous section.
In the presence of GaNATs on the signalling path between two NSLP peers, and if cryptographic protection of the signalling traffic between these two peers is required, the translation of the GIMPS header fields that need to be translated for consistency, must be carried out by the X peers. The GIMPS processing that performs this task, is described next. Note that this processing is in addition to the processing described in [1] (Schulzrinne, H. and R. Handcock, “GIMPS: General Internet Messaging Protocol for Signalling,” May 2005.) and that we assume that the in-between GaNATs adopt the behaviour described in the two preceding sections.
A GIMPS peer that receives a GIMPS packet that carries (a) an NSLPID for a supported NSLP, and (b) an NTO in its header, executes the following algorithm, before the processing described in [1] (Schulzrinne, H. and R. Handcock, “GIMPS: General Internet Messaging Protocol for Signalling,” May 2005.) takes place.
and forwards G' to GIMPS for further processing. If G is a GIMPS QUERY and local policy demands the installation of state without the reception of a GIMPS CONFIRM message, then the peer must store the NTO carried by G together with the routing state information about the sending GIMPS peer. If G is a GIMPS CONFIRM and local policy demands the installation of state only after reception of a valid CONFIRM, then the peer stores, after validating the cookie in the CONFIRM, the NTO carried by G together with the routing state information about the sending GIMPS peer.
and forwards GR' to GIMPS for further processing. If the cookie in GR' is verified sucessfully, the peer stores the NTO carried by GR together with the routing state information about the sending GIMPS peer.
A peer that receives a GIMPS packet P (in this case, the packet will be a cryptographically protected GIMPS packet) the peer does the following substitutions after the cryptographic processing is (successfully) completed and before the processing described in [1] (Schulzrinne, H. and R. Handcock, “GIMPS: General Internet Messaging Protocol for Signalling,” May 2005.) takes place.
A peer that intends to send a GIMPS packet (in this case, cryptographic protection will be required for the packet), the peer does the following after the processing described in [1] (Schulzrinne, H. and R. Handcock, “GIMPS: General Internet Messaging Protocol for Signalling,” May 2005.) and before the packet is passed to the process that applies the cryptographic protection. Note that the NTO refers to the NTO that is stored together with the routing state information of the peer that is to receive the packet.
The cryptographic protection applies to of signalling messages terminates at NSLP-aware GaNATs. The processing performed by such GaNATs is therefore identical to the processing described in Section 5.2 (NSLP-aware GaNATs), with the exception that the GaNATs additionally perform cryptographic operations. In this case, there is no requirement for the NSLP to perform any translation for the purposes of NAT traversal.
| TOC |
The following may serve as indications for the existence of an NSIS-unaware NAT between two GIMPS peers. These indications can only be detected by the receiver of a GIMPS message. The first occasion these indications may be detected is with the reception of a GIMPS QUERY, typically by the downstream peer. (Note that != denotes inequality).
Note that these are only indications. In the presence of an adversary, a GIMPS peer may be tricked into believing that an NSIS-unaware NAT exists between itself and one of its neighbouring peers, while in reality this may not be the case.
When a downstream GIMPS peer detects such an indication, it may notify the upstream peer about the error. It may include additional information that enables the upstream peer to construct a GIMPS packet in such a way that, after it traverses the NSIS-unaware NAT, the IP addresses in the MRI field and the NLI.IA object are consistent with those in the IP header (which match the addressing space of the receiving peer). However, this requires the specification of new data structures and formats, processing rules, and requires the peers to maintain additional state.
Unfortunately, this approach is likely to fail in many circumstances. In order to see this, consider the behaviour of an NSIS-unaware NAT when it receives an IP packet. The packet either
With NSIS-unaware NATs it is a matter of local policy (i.e. the rules that exist in case (2) above) whether or not traffic will be allowed to traverse the NAT. This obviously applies to both signalling and data traffic, as an NSIS-unaware NAT is unable to distinguish the two types of traffic. It may be the case that GIMPS node A is unable to contact GIMPS node B which is "behind" a NAT, even if communication in from B to A may be possible because such communication would match a policy rule; typically, in a scenarios where A is towards the NI and B is towards the NR, the NAT would have this behaviour.
Another approach to deal with NSIS-unaware NATs is similar to the NAT traversal approach taken by IKEv2, i.e. by encapsulating GIMPS messages into UDP datagrams, rather than directly into IP datagrams. This technique requires the inclusion of additional fields into a GIMPS QUERY, as follows. The sender adds (a hash of) its own IP address and the IP address of what it believes to be the DR into the GIMPS payload. The receiver of this GIMPS messages compares these addresses to the [IP header].SourceIPAddress and the [IP header].DestinationIPAddress respectively. If at least one of them is unequal, the receiver deduces that a NAT is between sender and receiver. After the detection of a NAT, the remainder of the communication is encapsulated into UDP datagrams that are addressed to a specified port.
Unfortunately, the IKEv2 NAT traversal mechanism cannot be used "as is" for NAT traversal in GIMPS. This is because of a number of reasons, including the following.
| TOC |
The mechanisms proposed in this document give rise to a number of threats that must be considered. In the following, a subset of these threats is mentioned.
As described in Section 5.1 (NSLP-unaware GaNATs) and Section 6.1 (NSLP-unaware GaNATs), NSLP-unaware GaNATs create some state whenever they receive a GIMPS QUERY message. This state is necessary in order for the GaNAT to be able to map a GIMPS RESPONSE that arrives from the downstream direction to the corresponding GIMPS QUERY and thereby to perform the required translation.
The threat here is an attacker flooding the GaNAT with maliciously constructed GIMPS QUERIES with the aim of exhausting the GaNAT's memory. The attacker might use a variety of methods to construct such GIMPS QUERIES, including the following.
How vulnerable a GaNAT is to the above service denial attack depends on a variaty of factors, including the following.
In order to decrease the exposure of a GaNAT to service denial attacks, the following recommendations are made.
The service denial threats mentioned in this section do not apply to an NSLP-aware GaNAT, as such a GaNAT is required, in accordance with its local policy, to verify the validity of the cookie(s) before allocating any state, including the state required by the mechanisms in this document.
Although the primary goal of a NAT is to perform address translation between two addressing spaces, NATs are sometimes also used to provide a security service similar to the security service provided by firewalls. That is, a NAT can be configured so that it does not forward packets from the external into the internal network, unless it determines that the packets belong to a communication session that was originally initiated from an internal node and are, as such, solicited.
If an NSLP-unaware GaNAT performs the above security-relevant function in addition to address translation, then the presence of GIMPS signalling and, in particular the mechanisms described in this document, might allow an adversary cause the installation of NAT bindings in the GaNAT using these mechansisms. These NAT bindings would then enable the adversary to inject unsolicited traffic into the internal network, a capability that it may not have in the absence of the mechanisms described in this document.
The administrator of an NSLP-unaware GaNAT should therefore make security-concious decisions regarding the operation of the GaNAT. An NSLP-aware GaNAT, on the other hand, follows an NSLP policy which indicates the required security mechanisms. This policy should account for the fact that this NSLP-aware node performs also NAT and the associated packet filtering.
| TOC |
The authors would like to thank Robert Hancock, Cedric Aoun and Martin Stiemerling for their feedback. Furthermore, we would like to mention that this document builds on top of a previous document regarding migration scenarios.
| TOC |
[Editor's Note: A future version of this document will provide information regarding IAB considerations.
| TOC |
This document does not require actions by the IANA.
| TOC |
| [1] | Schulzrinne, H. and R. Handcock, “GIMPS: General Internet Messaging Protocol for Signalling,” draft-ietf-nsis-ntlp-06 (work in progress), May 2005. |
| [2] | Stiemerling, M., Tschofenig, H., and C. Aoun, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” draft-ietf-nsis-nslp-natfw-06 (work in progress), May 2005. |
| TOC |
| Andreas Pashalidis | |
| Siemens | |
| Otto-Hahn-Ring 6 | |
| Munich, Bavaria 81739 | |
| Germany | |
| Email: | Andreas.Pashalidis@siemens.com |
| Hannes Tschofenig | |
| Siemens | |
| Otto-Hahn-Ring 6 | |
| Munich, Bavaria 81739 | |
| Germany | |
| Email: | Hannes.Tschofenig@siemens.com |
| TOC |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright © The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.