NSIS A. Fessi Internet-Draft M. Stiemerling Expires: November 23, 2004 NEC S. Thiruvengadam H. Tschofenig Siemens May 25, 2004 Security Threats for the NAT/Firewall NSLP draft-fessi-nsis-natfw-threats-00 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. This Internet-Draft will expire on November 23, 2004. 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 identifies different security threats that need to be addressed for the NAT/firewall 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. Fessi, et al. Expires November 23, 2004 [Page 1] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Attacks related to authentication and authorization . . . . . 5 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' 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 the NTLP . . . . . . . . . . . . . . . . . 11 4.2 Flooding with 'reserve' messages from inside . . . . . . . 11 5. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 12 6. Message Modification . . . . . . . . . . . . . . . . . . . . . 13 7. Session Invalidation . . . . . . . . . . . . . . . . . . . . . 14 8. Session Modification . . . . . . . . . . . . . . . . . . . . . 15 9. Misuse of unreleased sessions . . . . . . . . . . . . . . . . 17 10. Data traffic injection . . . . . . . . . . . . . . . . . . . 18 11. Misuse of mobility in NAT handling . . . . . . . . . . . . . 19 12. Eavesdropping and traffic analysis . . . . . . . . . . . . . 21 13. Security Considerations . . . . . . . . . . . . . . . . . . 22 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 15.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 15.2 Informative References . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . 27 Fessi, et al. Expires November 23, 2004 [Page 2] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 1. Introduction This document provides an analysis of the security threats that are specific for the NAT/firewall NSLP. The NAT/firewall NSLP is used to install the required policy rules (firewall pinhole and/or NAT binding) on the middleboxes 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. Fessi, et al. Expires November 23, 2004 [Page 3] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 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, we use the same terminology as in [1], [3] and [4]. Fessi, et al. Expires November 23, 2004 [Page 4] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 3. Attacks related to authentication and authorization As described in [1] the NSIS message to install policy rules at a middlebox is the 'create session' message. The 'create session' message travels from the Data Sender (DS) towards 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' message from the DR the requested policy rules on the middleboxes are installed to allow the traversal of a data flow. +-----+ +-----+ +-----+ | DS | | MB | | DR | +-----+ +-----+ +-----+ | | | | Create | Create | |-------------------->+-------------------->| | | | | 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 cases together i.e. DS and/or DR is behind a chain of NATs and firewalls. Figure 2 shows such a possible scenario: Fessi, et al. Expires November 23, 2004 [Page 5] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 +-------------------+ +--------------------+ | | | | | 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' 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. However 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 Fessi, et al. Expires November 23, 2004 [Page 6] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 is executed. Otherwise, following kind of attacks 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 request installing any policy rules and allow all traffic go through. 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: +------------------------------+ | | | +------+ create | | | NI_1 | ------\ +-----+ create +-----+ | +------+ \------> | 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 by an other mean such as the NSLP or the application layer. 3.3 Data Receiver (DR) behind a firewall In this case a 'create session' message is coming from an entity DS outside the network towards DR inside the network. Fessi, et al. Expires November 23, 2004 [Page 7] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 +------------------------------+ | | +-----+ create +-----+ create +-----+ | | DS | -------------> | FW | -------------> | DR | | +-----+ <------------- +-----+ <------------- +-----+ | path succeeded | path succeeded | | | +------------------------------+ Figure 5: DR behind a firewall According to [1] (Section 3.2.1) "Policy rules at middleboxes MUST be only installed upon receiving a successful response of type 'path succeeded'". This means that the middlebox waits until the Data Receiver DR confirms the request of the Data Sender DS with a 'path succeeded' message. This confirmation implicates that DR 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 could be sniffing the application layer signaling and thus knows the address and port number where DR is excepting the data flow. Thus it could pretend to be DS and send a 'create session' 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' message back and the middlebox will install policy rules that will allow Mallory to inject its data into the network. Fessi, et al. Expires November 23, 2004 [Page 8] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 Application Layer signaling <------------------------------------> / \ / +-----------------\------------+ / | \ | +-----+ +-----+ +-----+ | | DS | -> | FW | | DR | | +-----+ / +-----+ +-----+ | create / | | +-----+ / +-------------------------------+ | M |---------- +-----+ Figure 6: DR behind a firewall with an adversary In real networks, operators will probably not rely on DR if it checks the IP address of the DS correctly. Thus we have to assume the worst case with an attack such as in Figure 6. 3.4 Data Receiver (DR) behind a NAT Reminder to the NAT handling solution: We will describe briefly the NSIS message flow required here to install to necessary rules for the traversal of a data flow from DS towards DR. For detailed description please refer to [1] Section 3.2.2. DR sends a 'reserve external address' message to get itself a publicly reachable address. The NAT reserves an external address and port number and sends them back to DR. The NAT adds an entry in its reservation list which looks as follow: (DR_ext <=> DR_int) (*). The NAT sends a 'return external address' message back to DR with the address DR_ext. DR informs DS about the public address that it has recently received (for instance by some application layer signaling). Now DS sends the 'create session' message towards DS_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' message. Fessi, et al. Expires November 23, 2004 [Page 9] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 At the arrival of the 'path succeeded' message from DR, the NAT installs the policy rule to forward the data flow correctly from DS to DR. Possible attack: If DS is not correctly authenticated, an attacker Mallory could send a 'create session' 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. Application Layer signaling <------------------------------------> / \ / +-----------------\------------+ / | reserve \ | +-----+ +-----+ <----------- +-----+ | | DS | -> | NAT | -----------> | DR | | +-----+ / +-----+ rtn_ext_addr +-----+ | create / | | +-----+ / +-------------------------------+ | M |---------- +-----+ Figure 7: DR behind a NAT with an adversary Fessi, et al. Expires November 23, 2004 [Page 10] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 4. Denial-of-Service Attacks In this section we describe several ways how an adversary could launch a DoS attack to networks running NSIS for middlebox configuration to exhaust their resources. 4.1 Flooding with 'create session' messages from outside 4.1.1 Attacks due to NSLP state A 'create session' message requests the NSLP to store some state information such as Session-ID and flow identifier. The policy rules requested in the 'create session' message will be installed at the arrival of a confirmation from the Data Receiver with a 'path succeeded' message. The 'path succeeded' 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' messages. For each of these messages the middlebox needs to store state information such as the policy rules to be loaded, i.e. the middlebox could run out of memory. 4.1.2 Attacks due to authentication complexity This kind of attack is possible if authentication is based on mechanisms that require computing power e.g. digital signatures. 4.1.3 Attacks to the NTLP Flooding a middlebox with 'create session' messages affects also the NTLP. The 'path succeeded' message needs to take the same route as the previous 'create session' message. Thus the NTLP needs to store routing information for each 'create session' message. This kind of attack is also described in [2] Section 4.8. 4.2 Flooding with 'reserve' 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' 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. Fessi, et al. Expires November 23, 2004 [Page 11] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 5. Man-in-the-Middle Attacks Figure 8 illustrates a possible man-in-the-middle attack using the 'reserve external address' message. This message travels from DR towards the public Internet. The message might be not intercepted by any NAT (either because there are no NATs or because there are only NSIS unaware NATs). In this case the 'reserve external address' message might be caught by an adversary Mallory that sends back a 'return external address' message with its own address. As a consequence DR will think that the address of Mallory is its public address and will inform DS about it. DS will send the data traffic to Mallory. The data traffic from DS to DR will re-directed to Mallory. Mallory will be able to read, modify or block the data traffic. +-----+ +-----+ +-----+ +-----+ | DS | | M | | FW | | DR | +-----+ +-----+ +-----+ +-----+ | | | | | | reserve | reserve | | | <------------------ | <------------ | | | | | | | ret_ext_addr | ret_ext_addr | | | ------------------> | ------------> | | | | | | data traffic | | | |===============>| data traffic | | |===================================> | Figure 8: Man in the middle attack using the 'reserve' message' Fessi, et al. Expires November 23, 2004 [Page 12] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 6. Message Modification Any NSIS node along the path 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 destination could hijack or disrupt the communication. Note however that message integrity is not an obvious issue, since NSIS nodes are supposed to modify NSIS messages according to the protocol specification, which breaks end-to-end message integrity. 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' message to fit their needs and/or local policy (See also [1] section 3.2.7: Calculation of Lifetimes) Fessi, et al. Expires November 23, 2004 [Page 13] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 7. Session Invalidation A malicious NSIS node could tear down an existing valid session by using the delete session message. Fessi, et al. Expires November 23, 2004 [Page 14] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 8. Session Modification 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 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. The signalling messages start from the DS and goes through a series of routers towards the DR. We assume that an off-path adversary is connected to one of the routers along the path (here Router 3). We also assume that the adversary knows the Session ID of the NSIS session initiated by the DS. Knowing the Session-ID, the adversary now sends signalling messages towards the DR. When the signaling message hits Router3 then existing state information can be modified. The adversary can modify or delete the established reservation causing unexpected behavior to 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]. Fessi, et al. Expires November 23, 2004 [Page 15] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 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. Fessi, et al. Expires November 23, 2004 [Page 16] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 9. Misuse of unreleased sessions Assume that DS is transferring data to DR through a series of middleboxes. The Data Sender might not correctly send a 'delete session' request to remove the established packet filter state at the middleboxes along the path. An intruder might use these packet filter states to communicate with DR due to the IP-spoofing capability. In fact, an adversary can always inject data due to the IP-spoofing capability even at the same time when the session is used by DS (see also Section 10). Fessi, et al. Expires November 23, 2004 [Page 17] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 10. Data traffic injection Due to the IP-spoofing capability an adversary is able to inject its own data traffic in conformance with the firewall policies. IP-spoofing is a general problem for packet filters. Awareness for the limitations of non-cryptographic packet filters is important. Fessi, et al. Expires November 23, 2004 [Page 18] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 11. 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 <======================== Figure 10: Misuse of mobility in NAT binding When DR moves 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 Figure 10 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 Figure 11 2. Third party flooding by redirecting packets to arbitrary hosts 3. Service disruption by redirecting to non-existing hosts Fessi, et al. Expires November 23, 2004 [Page 19] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 +----------+ +----------+ +----------+ | NAT | |End host | |Malicious | | | | | |End host | +----------+ +----------+ +----------+ | | | | | | | Data Traffic | | |--------->----------| | | | | | | Spurious | | | NAT binding update | |---------<----------+--------<------------| | | | | | | | Data Traffic | | |--------->----------+-------->------------| | | | | | | | | | Figure 11: Connection Hijacking Fessi, et al. Expires November 23, 2004 [Page 20] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 12. 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 already mentiened in Section 10. An adversary could learn authorization tokens included in 'create session' 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 allows an adversary to learn per flow information about the data traffic which might violate user's preference for privacy. This kind of attacks has been also described in [6] Section 4.3. Fessi, et al. Expires November 23, 2004 [Page 21] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 13. Security Considerations The entire document highlights security threats that need to be mitigated for the NAT/Firewall NSLP. It also addresses security issues related to packet filters. Note that the list of threats in this document is not complete. More threats might appear during implementation and deployment. Fessi, et al. Expires November 23, 2004 [Page 22] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 14. Contributors Many parts of this documents are the result of some discussions within the NAT/firewall-NSLP-team including: Cedric Aoun, Marcus Brunner, Miquel Martin and Joao Girao. Fessi, et al. Expires November 23, 2004 [Page 23] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 15. References 15.1 Normative References [1] Stiemerling, M., Tschofenig, H. and M. Martin, "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-01 (work in progress), February 2004, . [2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", draft-ietf-nsis-threats-04 (work in progress), February 2004, . [3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-draft-ietf-nsis-ntlp-00 (work in progress), October 2003, . [4] Brunner, M., "Requirements for Signaling Protocols", draft-ietf-nsis-requirements (work in progress), April 2004, . [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 15.2 Informative References [6] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and X. Fu, "Security Implications of the Session Identifier", June 2003, . [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, . [8] Bless, R., "Mobility and Internet Signaling Protocols", draft-manyfolks-signaling-protocol-mobility-00 (work in progress), January 2004, . [9] Bosch, S., "NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-01 (work in progress), October 2003, . Fessi, et al. Expires November 23, 2004 [Page 24] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 Authors' Addresses Ali Fessi Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany EMail: ali.fessi@netlab.nec.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.com Fessi, et al. Expires November 23, 2004 [Page 25] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 Appendix 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. Fessi, et al. Expires November 23, 2004 [Page 26] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 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 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 assignees. 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 Fessi, et al. Expires November 23, 2004 [Page 27] Internet-Draft Security Threats for the NAT/Firewall NSLP May 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Fessi, et al. Expires November 23, 2004 [Page 28]