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,
<reference.I-D.ietf-nsis-nslp-natfw.xml>.
[2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-04 (work in progress), February 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-00
(work in progress), October 2003,
<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.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-01 (work in progress), October 2003,
<reference.I-D.ietf-nsis-qos-nslp.xml>.
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]