NSIS A. Fessi Internet-Draft M. Stiemerling Expires:November 23, 2004January 14, 2005 NEC S. Thiruvengadam H. Tschofenig SiemensMay 25,C. Aoun Nortel Networks July 16, 2004 Security Threats for theNAT/FirewallNATFW NSLPdraft-fessi-nsis-natfw-threats-00draft-fessi-nsis-natfw-threats-01 Status of this Memo This document is an Internet-Draft and isin full conformance withsubject to all provisions ofSection 10section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims ofRFC2026.which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 athttp://www.ietf.org/ietf/1id-abstracts.txt.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 onNovember 23, 2004.January 14, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Opening a firewall pinhole or creating a NAT binding is a very security sensitive issue. This memo identifiesdifferentsecurity threats and security requirements that need to be addressed for theNAT/firewallNATFW NSLP. Generic security threats to the NSIS protocols have been already discussed in the NSIS Working Group.This security threats documents is specicific to NAT/firewall NSLP.Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .34 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Attacks related to authentication and authorization . . . . .54 3.1 Data Sender (DS) behind a firewall . . . . . . . . . . . . 6 3.2 Data Sender (DS) behind a NAT . . . . . . . . . . . . . . 7 3.3 Data Receiver (DR) behind a firewall . . . . . . . . . . . 7 3.4 Data Receiver (DR) behind a NAT . . . . . . . . . . . . . 9 4. Denial-of-Service Attacks . . . . . . . . . . . . . . . . . . 11 4.1 Flooding with'create session'CREATE messages from outside . . . . . . . . 11 4.1.1 Attacks due to NSLP state . . . . . . . . . . . . . . 11 4.1.2 Attacks due to authentication complexity . . . . . . . 11 4.1.3 Attacks to theNTLP . .endpoints . . . . . . . . . . . . . . . 114.2 Flooding with 'reserve' messages from inside .4.1.4 Attacks to the NTLP . . . . . .11 5. Man-in-the-Middle Attacks. . . . . . . . . . . 12 4.2 Flooding with REA messages from inside . . . . . . .12 6. Message Modification. . . 12 5. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . .13 7. Session Invalidation12 6. Message Modification . . . . . . . . . . . . . . . . . . . . .14 8.13 7. SessionModification . . . .Modification/Deletion . . . . . . . . . . . . . . . .. 15 9.14 8. Misuse of unreleased sessions . . . . . . . . . . . . . . . .17 10.15 9. Data traffic injection . . . . . . . . . . . . . . . . . . .18 11.. 17 10. Misuse of mobility in NAT handling . . . . . . . . . . . . .19 12.18 11. Eavesdropping and traffic analysis . . . . . . . . . . . . .21 13.20 12. Security Considerations . . . . . . . . . . . . . . . . . .22 14. Contributors . .21 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .23 15.21 14. References . . . . . . . . . . . . . . . . . . . . . . . . .24 15.121 14.1 Normative References . . . . . . . . . . . . . . . . . . . .24 15.221 14.2 Informative References . . . . . . . . . . . . . . . . . . .2421 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .25 A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2622 Intellectual Property and Copyright Statements . . . . . . . .2724 1. Introduction This document provides an analysis of the security threats that are specific for theNAT/firewallNATFW NSLP. TheNAT/firewallNATFW NSLP is used to install the required policy rules (firewall pinhole and/or NAT binding) onthemiddleboxes along the path to allow the traversal of a data flow. Opening a pinhole in the firewall or creating a NAT binding is a very security sensitive issue. Thus, we need to examine carefully who is allowed to install these policy rules and what security threats need to be addressed. In this document we will analyze different types of possible attacks to networks running NSIS for middlebox configuration. 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 [5].Furtheremore,Furthermore, we use the same terminology as in [1], [3] and [4]. 3. Attacks related to authentication and authorization As described in [1] the NSIS messageto installwhich installs policy rules at a middlebox is the'create session'CREATE message. The'create session'CREATE message travels from the Data Sender (DS)towardstoward the Data Receiver (DR). The packet filter or NAT binding is marked as pending by the middleboxes along the path. If it is confirmed with a'path succeeded'success RESPONSE message from the DR the requested policy rules on the middleboxes are installed to allow the traversal of a data flow. +-----+ +-----+ +-----+ | DS | | MB | | DR | +-----+ +-----+ +-----+ | | | |CreateCREATE |CreateCREATE | |-------------------->+-------------------->| | | | | Succeeded/Error | Succeeded/Error | |<--------------------+<--------------------| | | | ==========================================> Direction of data traffic Figure 1: CREATE Mode In this section we will consider some simple scenarios for middlebox configuration: o Data Sender (DS) behind a firewall o Data Sender (DS) behind a NAT o Data Receiver (DR) behind a firewall o Data Receiver (DR) behind a NAT A real scenario could include a combination of one or more casestogether i.e.together, i.e., DS and/or DR is behind a chain of NATs and firewalls. Figure 2 shows such a possible scenario: +-------------------+ +--------------------+ | | | | | Network A | | Network B | | | | | | +-----+ | //-----\\ | +-----+ | | | MB2 |--------+----| INET |----+--------| MB3 | | | +-----+ | \\-----// | +-----+ | | | | | | | | +-----+ | | +-----+ | | | MB1 | | | | MB4 | | | +-----+ | | +-----+ | | | | | | | | +-----+ | | +-----+ | | | DS | | | | DR | | | +-----+ | | +-----+ | | | | | +-------------------+ +--------------------+ MB: Middle box (NAT or Firewall or a combination) DS: Data Sender DR: Data Receiver Figure 2: Several middleboxes per network 3.1 Data Sender (DS) behind a firewall +------------------------------+ | | | +-----+ create +-----+ | | DS | --------------> | FW | | +-----+ +-----+ | | +------------------------------+ Figure 3: DS behind a firewall DS sends a'create session'CREATE message to request the traversal of a data flow. It is up to network operators to decide how far they can trust users inside their networks.HoweverHowever, there are several reasons why they should not.We list some of them in Appendix A. As already mentiened in [1] Section (3.2.1), the middlebox MUST first check authentication and authorization before any further processing is executed. Otherwise,The followingkind ofattacks are possible: o DS could open a firewall pinhole with a source address different from its own host. o DS could open firewall pinholes for incoming data flows that are not supposed to enter the network. o DS could requestinstallinginstallation of any policy rules and allow all traffic go through. SECURITY REQUIREMENT: As already mentioned in [1] Section (3.2), the middlebox MUST authenticate and authorize the neighboring NAT/FW NSLP node which requests an action. Authentication and authorization of the initiator SHOULD be provided to NATs and Firewalls along the path as motivated with Section 2.2.3 of [1]. 3.2 Data Sender (DS) behind a NAT The case 'DS behind a NAT' is analogous to the case 'DS behind a firewall'. It is worth mentioning that authentication based on IP address is not possible if NATs are deployed. Figure 4 illustrates such a scenario: +------------------------------+ | | | +------+createCREATE | | | NI_1 | ------\ +-----+createCREATE +-----+ | +------+ \------> | NAT| -----------> ||-------->| MB | | +-----+ +-----+ | +------+ | | | NI_2 | | | +------+ | +------------------------------+ Figure 4: Several NIs behind a NAT In this case the middlebox MB does not know who is the NSIS Initiator since both NI_1 and NI_2 are behind a NAT. Authentication needs to be provided byanothermeanmeans such as the NSLP or the application layer. SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure that the neighboring NAT/FW NSLP node is authorized to request an action. Authentication and authorization of the initiator (which is the DR in this scenario) MAY be provided to the middleboxes. 3.3 Data Receiver (DR) behind a firewall In this case a'create session'CREATE messageis comingcomes from an entity DS outside the network towards the DR inside the network. +------------------------------+ | | +-----+createCREATE +-----+createCREATE +-----+ | | DS | -------------> | FW | -------------> | DR | | +-----+ <------------- +-----+ <------------- +-----+ |path succeededsuccess RESPONSE |path succeededsuccess RESPONSE | | | +------------------------------+ Figure 5: DR behind a firewall According to [1] (Section3.2.1)3.3) "Policy rules at middleboxes MUST be only installed upon receiving a successful response of type'path succeeded'".success RESPONSE". This means that the middlebox waits until the Data Receiver DR confirms the request of the Data Sender DS with a'path succeeded'success RESPONSE message. This is, however, only necessary o if the policy rule creation/deletion/update at a firewall along the path cannot be authorized and o if the middlebox is still forwarding the signaling message towards the end host (without state creation/deletion/modification). This confirmationimplicatesimplies thatDRthe data receiver is expecting the data flow. At this point we differentiate 2 cases: 1. DR knows the IP address of the DS (for instance because of some previous application layer signaling) and is expecting the data flow. 2. DR might be expecting the data flow (for instance because of some previous application layer signaling) but does not know the IP address of the Data Sender DS. For the second case, Figure 6 illustrates a possible attack: an adversary Mallory M could be sniffing the application layer signaling and thus knows the address and port number where DR isexceptingexpecting the data flow. Thus it could pretend to be DS and send a'create session'CREATE message towards DR with the data flow description (M -> DR). Since DR does not know the IP address of DS, it is not able to recognize that the request is coming from the "wrong guy". It will send a'path succeeded'success RESPONSE message back and the middlebox will install policy rules that will allow Mallory M to inject its data into the network. Application Layer signaling <------------------------------------> / \ / +-----------------\------------+ / | \ | +-----+ +-----+ +-----+ | | DS | -> | FW | | DR | | +-----+ / +-----+ +-----+ |createCREATE / | | +-----+ / +-------------------------------+ | M |---------- +-----+ Figure 6: DR behind a firewall with an adversaryIn real networks, operatorsNetwork administrators will probably not rely on a DRif it checksto check the IP address of theDS correctly.DS. Thus we have to assume the worst case with an attack such as in Figure 6. Many operators might not allow NSIS signaling message to traverse the firewall in Figure 6 without proper authorization. In this case the threat is not applicable. SECURITY REQUIREMENT: A binding between the application layer and the NSIS signaling SHOULD be provided. 3.4 Data Receiver (DR) behind a NATReminder to the NAT handling solution:We will describe briefly the NSIS message flowrequired herethat takes place to installtothe necessary rules for the traversal of a data flow from DS towards DR. For detailed description please refer to [1] Section3.2.2.3.3. DR sends a'reserve external address'RESERVE-EXTERNAL-ADDRESS (REA) message to getitselfapubliclypublic reachableaddress.address that can be used by potential DSs. The NAT reserves an external address and port number and sends them back to DR. The NAT adds an address mapping entry in its reservation list whichlookslinks the public and private addresses asfollow:follows: (DR_ext <=> DR_int) (*). The NAT sends a RESPONSE message with 'return external address'messageobject back to the DR with the address DR_ext. DR informs DS about the public address that it has recentlyreceived (for instancereceived, for instance, bysomemeans of application layersignaling).signaling. Now DS sends the'create session'CREATE message towardsDS_ext.DR_ext. When the 'create session' message arrives at the NAT, the NAT looks up its reservation list and finds the entry (*). Now the NAT knows the address of DS and stores it as a part of the policy rule to be loaded. It forwards the message towards DR and waits for the confirmation with the'path succeeded'success RESPONSE message. At the arrival of the'path succeeded'success RESPONSE message from DR, the NAT installs the policy rule to forward the data flow correctly from DS to DR. Possible attack:If DSWe assume that the adversary obtains the external address allocated at the NAT (possibly by eavesdropping on the application layer signaling) and triggers the CREATE message before the NAT binding expires. The CREATE message isnot correctly authenticated, anassumed to travel from DS to DR through NAT. An attacker Mallory M could send a'create session'CREATE message to install a NAT binding to forward the data flow from M to DR instead of from DS to DR. This kind of attack is equivalent to the attack described in Section 3.3 above. In order for this attack to work the following pre-requisities need to hold: The adversary needs to be authorized to create a NAT binding at the NAT. The adversary needs to know when a DR creates a NAT binding at the DR. A certain timing is required and some specific information, such as the message routing identifier and session identifier must be known Application Layer signaling <------------------------------------> / \ / +-----------------\------------+ / |reserveREA \ | +-----+ +-----+ <----------- +-----+ | | DS | -> | NAT | -----------> | DR | | +-----+ / +-----+ rtn_ext_addr +-----+ |createCREATE / | | +-----+ / +-------------------------------+ | M |---------- +-----+ Figure 7: DR behind a NAT with an adversary SECURITY REQUIREMENT: TBD 4. Denial-of-Service Attacks In this section we describe several ways how an adversary could launch aDoSDenial of service (DoS) attacktoon networks running NSIS for middlebox configuration to exhaust their resources. 4.1 Flooding with'create session'CREATE messages from outside 4.1.1 Attacks due to NSLP state A'create session'CREATE message requests the NSLP to store some state information such as Session-ID and flow identifier. The policy rules requested in the'create session'CREATE message will be installed at the arrival of a confirmation from the Data Receiver with a'path succeeded'success RESPONSE message. The'path succeeded'success RESPONSE message includes the session ID. So the NSLP looks up the NSIS session and installs the requested policy rules. An adversary from outside could launch a DoS attack with arbitrary'create session'CREATE messages. For each of these messages the middlebox needs to store state information such as the policy rules to be loaded,i.e.i.e., the middlebox could run out of memory. This kind of attack is also mentioned in [2] Section 4.8. SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the 'create-session' message before storing state information. 4.1.2 Attacks due to authentication complexity This kind of attack is possible if authentication is based on mechanisms that require computingpower e.g.power, for example, digital signatures. For a more detailed treatment of this kind of attack, the reader is encouraged to see [2]. SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new denial of service attacks based on authentication or key management mechanisms. 4.1.3 Attacks to the endpoints The NATFW NSLP requires firewalls to forward NSLP messages, a malicious node may keep sending NSLP messages to a target. This may consume the access network resources of the victim, drain the battery of the victim's terminal and may force the victim to pay for the received although undesired data. This threat may be more particularly be relevant in networks where access link is a limited resource, for instance in cellular networks, and where the terminal capacities are limited. SECURITY REQUIREMENT: A NATFW NSLP aware firewall or NAT MUST be able to block unauthorized signaling message, if this threat is a concern. 4.1.4 Attacks to the NTLP Flooding a middlebox with'create session'CREATE messages affects also the NTLP. The'path succeeded'success RESPONSE message needs to take the same route as the previous'create session'CREATE message. Thus the NTLP needs to store routing information for each'create session'CREATE message. This kind of attack is also described in [2] Section 4.8. SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new denial of service attacks based on authentication or key management mechanisms. 4.2 Flooding with'reserve'REA messages from inside Although we are more concerned with possible attacks from outside the network, we need also to consider possible attacks from inside the network. An adversary inside the network could send arbitrary'reserve'RESERVE-EXTERNAL-ADDRESS messages. At a certain point the NAT will run out of port numbers and the access for other users to the outside will be disabled. SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state creation for the RESERVE-EXTERNAL-ADDRESS message. Furthermore, the NAT/FW NSLP implementation MUST prevent denial of service attacks involving the allocation of an arbitrary number of NAT bindings or the installation of a large number of packet filters. 5. Man-in-the-Middle Attacks Figure 8 illustrates a possible man-in-the-middle attack using the 'reserve external address' (REA) message. This message travels from DR towards the public Internet. The message mightbenot be intercepted by any NAT(eithereither because there are no NATs or because there areonlyNSISunaware NATs). In this case the 'reserve external address' message might be caught by an adversaryunaware. Mallorythat sends backM returns a'return external address'faked RESPONSE message with an IP address of itsownchoosing. This IP address is meant to be used by the DR as the public external IP address.AsMalory might insert it own IP address in the response, the IP address of a third party or the address of aconsequenceblack hole. In the first case, the DRwill thinkthinks that the address of Mallory M is its public address and will inform the DS about it. As a consequence, the DS will send the data traffic toMallory.Mallory M. The data traffic from the DS to the DR will re-directed toMallory.Mallory M. Mallory M will be able to read, modify or block the data traffic. Eavesdropping and modification is only possible if the data traffic is itself unprotected. +-----+ +-----+ +-----+ +-----+ | DS | | M | | FW | | DR | +-----+ +-----+ +-----+ +-----+ | | | | | |reserveREA |reserveREA | | | <------------------ | <------------ | | | | | | | ret_ext_addr | ret_ext_addr | | | ------------------> | ------------> | | | | | | data traffic | | | |===============>| data traffic | | |===================================> | Figure 8:Man in the middleMITM attack using the'reserve' message'RESERVE-EXTERNAL-ADDRESS message Please note that the NSIS aware firewall in Figure 8 might not be present when DR communicates directly with the adversary. SECURITY REQUIREMENT: Mutual authentication between neighboring NATFW NSLP MUST be provided. To ensure that only legitimate nodes along the path act as NSIS entities the initiator MUST authorize the responder. In the example in Figure 8 the firewall FW must perform an authorization with the neighboring entities. 6. Message Modification AnyNSISon-path subverted nodealong the pathen route to the destination could easily modify, inject or just drop an NSIS message.Message modification could allow a malicious user for instance to open a pinhole for its advantage. If message integrity is not provided, any malicious node along the path to the destinationIt could also hijack or disrupt the communication.Note however that message integrity is not an obvious issue, since NSIS nodes are supposed to modifySECURITY REQUIREMENT: Message integrity, replay protection and data origin authentication between neighboring NAT/FW NSLPs MUST be provided. Message modification by a subverted NSISmessages according to the protocol specification, which breaks end-to-end message integrity.node could create arbitrary pinholes or NAT bindigs. For example: o NATs need to modify the source/destination of the data flow in the 'create session' message. o Each middlebox along the path may change the requested lifetime in the'create session'CREATE message to fit their needs and/or local policy(See(see also[1]section3.2.7: Calculation3.2.7 ofLifetimes) 7. Session Invalidation A malicious[1] with regard to calculation of refresh interval). SECURITY REQUIREMENT: None. Malicous NSISnode could tear down an existing valid session by using the delete session message. 8.NATs and Firewalls will not be addressed. 7. SessionModificationModification/Deletion The Session ID is included in signaling messages as a reference to the established state. If an adversary is able to obtain the Session Identifier for example by eavesdropping on signaling messages, it would be able to add the same Session Identifier to a new a signaling message and effect some modifications. Consider the scenario described in Figure 9. Here an adversary pretends to be 'DS in mobility'. Thesignallingsignaling messages start from the DS andgoesgo through a series of routers towards the DR. We assume that an off-path adversary is connected to one of the routers along the old path (here Router 3). We also assume that the adversary knows the Session ID of the NSIS session initiated by the DS. Knowing theSession-ID,Session ID, the adversary now sends signalling messages towards the DR. When the signaling messagehitsreaches Router3 then existing state information can bemodified.modified or even deleted. The adversary can modify or delete the established reservation causing unexpected behaviortofor the legitimate user. The source of the problem is that the Router 3 (cross-over router) is unable to decide whether the new signaling message was initiated from the owner of the session. In this scenario, the adversary need not even be located in the DS-DR path. This problem and the solution approaches are described in more detail in [6]. Session ID(SID-x) +--------+ +--------+ +-------->--------+ Router+------------>++-------->+ DR | Session ID(SID-x)| | 4 | | | +---+----+ +--------+ +--------+ | Router | +------+ 3 +******* | +---+----+ * | * | Session ID(SID-x) * Session ID(SID-x) +---+----+ +---+----+ | Access | | Access | | Router | | Router | | 1 | | 2 | +---+----+ +---+----+ | * | Session ID(SID-x) * Session ID(SID-x) +----+------+ +----+------+ | DS | | Adversary | | | | | +-----------+ +-----------+ Figure 9: State Modification by off-path adversary Summary: Off-path adversary's knowledge of Session-ID could cause session modification/deletion.9.SECURITY REQUIREMENT: TBD: This is not a NAT/FW NSLP specific problem but a GIMPS problem. The initiator MUST be able to demonstrate ownership of the session it wishes to modify. 8. Misuse of unreleased sessions Assume that DSis transferring data to(N1) initiates NSIS session with DR (N2) through a series ofmiddleboxes. The Data Sendermiddleboxes as in Figure 10. When the DS is sending data to DR, it mightnot correctly send a 'delete session' requesthappen that the DR disconnects from the network (crashes or moves out of the network in mobility scenarios). In such cases, it is possible that another node N3 (which recently entered the network protected by the same firewall) is assigned the same IP address that was previously allocated toremoveN2. The DS could take advantage of theestablished packet filter state atfirewall policies installed already, if themiddleboxes alongrefresh interval time is very high. The DS can flood thepath. An intruder might use these packet filter statesnode (N3), which will consume the access network resources of the victim forcing it tocommunicatepay for unwanted traffic as shown in Figure 11. Public Internet +--------------------------+ | | | | +-------+ CREATE +---+-----+ +-------+ | | |-------------->------| |---->---| | | | N1 |--------------<------| FW |----<---| N2 | | | | success RESPONSE | | | | | | |==============>======| |====>===| | | +-------+ Data Traffic +---+-----+ +-------+ | | | | | +--------------------------+ Figure 10: Before mobility Public Internet +--------------------------+ | | | | +-------+ +---+-----+ +-------+ | | | | | | | | | N1 |==============>======| FW |====>===| N3 | | | | Data Traffic | | | | | | | | | | | | +-------+ +---+-----+ +-------+ | | | | | +--------------------------+ Figure 11: After mobility Also, this threat is valid for the other direction as well. The DS which is communicating with the DRduemay disconnect from the network and this IP address may be assigned to a new node that had recently entered the network. This new node could pretend to be theIP-spoofing capability. In fact, an adversary can always injectDS and send dataduetraffic to theIP-spoofing capability even atDR in conformance with the firewall policies and cause service disruption. SECURITY REQUIREMENT: Data origin authentication is needed to mitigate this threat. However, the described threat is applicable only for thesametime until the policy rules are deleted due to NSLP soft state. Awareness for this threat is important especially when thesessionrefresh interval time isused by DS (see also Section 10). 10.high. It should be noted, that networks supporting mobility should remove any state at middleboxes when a mobile node is diconnecting, thus leaving a clean state. 9. Data traffic injectionDueThis attack takes place where there exists trust relationship between machines. It is common in corporate networks, where internal machines trust each other and authentication is only based on IP address. Hence by spoofing a connection, an attacker is able to reach theIP-spoofing capability antarget machines, using the existing firewall rules. The adversary is able to inject its own data traffic in conformance with the firewallpolicies. IP-spoofingpolicies simultaneously along with the genuine DS. SECURITY REQUIREMENT: Since IP spoofing is a generalproblem for packet filters. Awareness for the limitationslimitation of non-cryptographic packet filters no security requirement needs to be created for the NAT/FW NSLP. Techniques such as ingress filtering (described below) and data origin authentication (such as provided with IPsec based VPNs) can help mitigate this threat. This issue is, however, outside the scope of this document. Ingress Filtering: Consider the scenario shown in Figure 12. In this scenario the DS isimportant. 11.behind a router (R1) and a malicious node (M) is behind another router (R2). The DS communicates with the DR through a firewall (FW). The DS initiates NSIS signaling and installs firewall policies at FW. But the malicious node is also able to send data traffic using DS's source address. If R2 implements ingress filtering, these spoofed packets will be blocked. But this ingress filtering may not work in all scenarios. If both the DS and the malicious node are behind the same router, then the ingress filter will not be able to detect the spoofed packets as both the DS and the malicious node are in the same address range. +-----------------------------------+ | +------------------+ | | | | | | | | | | | +-------+ +---+---+ | | | | DS +>--+ R1 +->+ | | | | | | | | | | | +-------+ +---+---+ | | | | | v | | | | | | | +------------------+ | +---+---+ +-------+ | | | | | | | +---+ FW +-->--| DR | | +------------------+ | | | | | | | ****| |*****| | | | | * +---+---+ +-------+ | | +-------+ +---+---+ * | | | | M | | R2 | * | | | | |***| |*** | | | +-------+ +---+---+ | | | | | | | | | | +------------------+ | +-----------------------------------+ ---->---- = genuine data traffic ********* = spoofed data traffic Figure 12: Ingress filtering 10. Misuse of mobility in NAT handling Since NSIS allows end hosts to be mobile it is possible that an NSIS node behind a NAT needs to update its NAT binding in case of address change. Whenever a host behind a NAT initiates a data transfer, it is assigned an external IP and port number. In typical mobility scenarios, the DR might also obtain a new address according to the topology and it should convey the NAT binding updates. The NAT is assumed to modify these NAT bindings based on the new IP address conveyed by the endhost. Public Private Address Internet space +----------+ +----------+ +----------| NAT |------------------|End host | | | | | +----------+ +----------+ | | | +----------+ \--------------------|Malicious | |End host | +----------+ data traffic <======================== Figure10:13: Misuse of mobility in NAT binding For this description , we assume that a NAT binding state can be changed with the help of NSIS signalling. When the DRmovesis receiving data traffic, if it happens to move to a new location, it sends an NSIS signalling message to modify the NAT binding. It would use the Session-ID and the new flow-id to update the state. The NAT updates the binding and the DR continues to receive the data traffic. Consider the scenario in Figure1013 where an the endhost(DR) and the adversary are behind a NAT. The adversary pretending that it is the end host could generate a spurious signaling message to update the state at the NAT. This could be done for these purposes: 1. Connection hijacking by redirecting packets to the attacker as in Figure1114 2. Third party flooding by redirecting packets to arbitrary hosts 3. Service disruption by redirecting to non-existing hosts +----------+ +----------+ +----------+ | NAT | |End host | |Malicious | | | | | |End host | +----------+ +----------+ +----------+ | | | | | | | Data Traffic | | |--------->----------| | | | | | | Spurious | | | NAT binding update | |---------<----------+--------<------------| | | | | | | | Data Traffic | | |--------->----------+-------->------------| | | | | | | | | | Figure11:14: Connection Hijacking12.SECURITY REQUIREMENT: A NAT/FW signaling message MUST be authenticated, authorized, integrity protected and replay protected between neighboring NAT/FW NSLP nodes. 11. Eavesdropping and traffic analysis By collecting NSLP messages, an adversary is able to learn policy rules for packet filters and knows which ports are open. It can use this to inject its own data traffic due to the IP spoofing capability as alreadymentienedmentioned in Section10.9. An adversary could learn authorization tokens included in'create session'CREATE messages and use them to launch reply-attacks or to create a session with its own address as source address. (cut-and-paste attack)Furthermore, traffic analysis allowsAs shown in Section 4.3 of [6] a solution of Section 7 might require confidentiality protection of signaling messages SECURITY REQUIREMENT: The threat of eavesdropping itself does not mandate the usage of confidentiality protection since an adversaryto learn per flow information about thecan also eavesdrop on datatraffic which might violate user's preference for privacy. This kindtraffic. In the context ofattacks has beena particular security solutions (e.g., authorization tokens) it might be necessary to offer confidentiality protection. Confidentiality protection alsodescribed in [6] Section 4.3. 13.needs to be offered to the refresh period. 12. Security Considerations The entire document highlights security threats that need to be mitigated for theNAT/FirewallNATFW NSLP. It also addresses security issues related to packet filters.Note thatSecurity requirements have been derived from thelist of threats in thisrelevant threats. 13. Acknowledgments This document isnot complete. More threats might appear during implementation and deployment. 14. Contributors Many parts of this documents arethe result ofsomediscussionswithin the NAT/firewall-NSLP-team including: Cedric Aoun,with many individuals. The authors would like to thank especially: Marcus Brunner, MiquelMartin andMartin, Frank Le, JoaoGirao. 15.Girao, and Elwyn Davis. 14. References15.114.1 Normative References [1] Stiemerling, M., Tschofenig, H. and M. Martin, "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",draft-ietf-nsis-nslp-natfw-01draft-ietf-nsis-nslp-natfw-03 (work in progress),FebruaryJuly 2004, <reference.I-D.ietf-nsis-nslp-natfw.xml>. [2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",draft-ietf-nsis-threats-04draft-ietf-nsis-threats-05 (work in progress),FebruaryJune 2004, <reference.I-D.ietf-nsis-threats.xml>. [3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling",draft-draft-ietf-nsis-ntlp-00draft-draft-ietf-nsis-ntlp-02 (work in progress),October 2003,May 2004, <reference.I-D.draft-ietf-nsis-ntlp.xml>. [4] Brunner, M., "Requirements for Signaling Protocols", draft-ietf-nsis-requirements (work in progress), April 2004, <reference.I-D.ietf-nsis-.requirements.xml>. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997.15.214.2 Informative References [6] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and X. Fu, "Security Implications of the Session Identifier", June 2003, <reference.I-D.tschofenig-nsis-sid.xml>. [7] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. Tschofenig, "NAT/Firewall NSLP Migration Considerations", draft-aoun-nsis-nslp-natfw-migration-01 (work in progress), February 2004, <reference.I-D.aoun-nsis-nslp-natfw-migration.xml>. [8] Bless, R., "Mobility and Internet Signaling Protocols", draft-manyfolks-signaling-protocol-mobility-00 (work in progress), January 2004, <reference.I-D.manyfolks-signaling-protocol-mobility.xml>. [9] Bosch, S., "NSLP for Quality-of-Service signaling",draft-ietf-nsis-qos-nslp-01draft-ietf-nsis-qos-nslp-03 (work in progress),October 2003,May 2004, <reference.I-D.ietf-nsis-qos-nslp.xml>. Authors' Addresses Ali Fessi Network Laboratories, NEC Europe Ltd.Kurfuersten-Anlage 36 Heidelberg 69115 GermanyEMail:ali.fessi@netlab.nec.dealifessi@web.de URI: Martin Stiemerling Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 13 EMail: stiemerling@ccrle.nec.de URI: Srinath Thiruvengadam Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: srinath@mytum.de Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Hannes.Tschofenig@siemens.comAppendix A. There are several reasons why network operator should not trust users inside their networks. Just to mention some of them: o The internal user could be a malicious entity such as a virus or a worm that has succeeded to intrude into the network. This entity could for instance send arbitrary 'create session' messages and allow all traffic go through. o In some scenarios such as mobility scenarios or ad-hoc networks, the user could be a visitor that it just happened that he visits the network. o In some cases users inside a network have the motivation to harm other users inside the same network e.g. by trying to re-direct data traffic to themselves (see also section ?) or to interrupt the sessions of other users (section ?). o Different users might have different access right to set up policy rules at the middlebox.Cedric Aoun Nortel Networks France EMail: cedric.aoun@nortelnetworks.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of anyintellectual propertyIntellectual 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;neithernor does it represent that it has made any independent effort to identify any such rights. Information on theIETF'sprocedures with respect to rights instandards-track and standards-related documentationRFC documents can be found inBCP-11.BCP 78 and BCP 79. Copies ofclaims of rightsIPR disclosures madeavailable for publicationto 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 byimplementorsimplementers or users of this specification can be obtained from the IETFSecretariat.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 rightswhichthat may cover technology that may be required topracticeimplement this standard. Please address the information to the IETFExecutive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 purposeat ietf-ipr@ietf.org. Disclaimer ofdeveloping 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 assignees.Validity This document and the information contained hereinisare 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 FORCEDISCLAIMSDISCLAIM 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 Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.