draft-fessi-nsis-natfw-threats-01.txt		draft-fessi-nsis-natfw-threats-02.txt
	NSIS A. Fessi		NSIS A. Fessi
	Internet-Draft M. Stiemerling		Internet-Draft M. Stiemerling
	Expires: January 14, 2005 NEC		Expires: December 30, 2004 NEC
	S. Thiruvengadam		S. Thiruvengadam
	H. Tschofenig		H. Tschofenig
	Siemens		Siemens
	C. Aoun		C. Aoun
	Nortel Networks		Nortel Networks
	July 16, 2004		July 2004
	Security Threats for the NATFW NSLP		Security Threats for the NATFW NSLP
	draft-fessi-nsis-natfw-threats-01		draft-fessi-nsis-natfw-threats-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, I certify that any applicable
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		patent or other IPR claims of which I am aware have been disclosed,
	author represents that any applicable patent or other IPR claims of		and any of which I become aware will be disclosed, in accordance with
	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.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at
	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		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 14, 2005.		This Internet-Draft will expire on December 30, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	Opening a firewall pinhole or creating a NAT binding is a very		Opening a firewall pinhole or creating a NAT binding is a very
	security sensitive issue. This memo identifies security threats and		security sensitive issue. This memo identifies security threats and
	security requirements that need to be addressed for the NATFW NSLP.		security requirements that need to be addressed for the NATFW NSLP.
	skipping to change at page 2, line 18		skipping to change at page 2, line 16
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Attacks related to authentication and authorization . . . . . 4		3. Attacks related to authentication and authorization . . . . . 4
	3.1 Data Sender (DS) behind a firewall . . . . . . . . . . . . 6		3.1 Data Sender (DS) behind a firewall . . . . . . . . . . . . 6
	3.2 Data Sender (DS) behind a NAT . . . . . . . . . . . . . . 7		3.2 Data Sender (DS) behind a NAT . . . . . . . . . . . . . . 7
	3.3 Data Receiver (DR) behind a firewall . . . . . . . . . . . 7		3.3 Data Receiver (DR) behind a firewall . . . . . . . . . . . 7
	3.4 Data Receiver (DR) behind a NAT . . . . . . . . . . . . . 9		3.4 Data Receiver (DR) behind a NAT . . . . . . . . . . . . . 9
			3.5 NSLP message injection . . . . . . . . . . . . . . . . . . 11
	4. Denial-of-Service Attacks . . . . . . . . . . . . . . . . . . 11		4. Denial-of-Service Attacks . . . . . . . . . . . . . . . . . . 11
	4.1 Flooding with CREATE messages from outside . . . . . . . . 11		4.1 Flooding with CREATE messages from outside . . . . . . . . 11
	4.1.1 Attacks due to NSLP state . . . . . . . . . . . . . . 11		4.1.1 Attacks due to NSLP state . . . . . . . . . . . . . . 11
	4.1.2 Attacks due to authentication complexity . . . . . . . 11		4.1.2 Attacks due to authentication complexity . . . . . . . 12
	4.1.3 Attacks to the endpoints . . . . . . . . . . . . . . . 11		4.1.3 Attacks to the endpoints . . . . . . . . . . . . . . . 12
	4.1.4 Attacks to the NTLP . . . . . . . . . . . . . . . . . 12		4.1.4 Attacks to the NTLP . . . . . . . . . . . . . . . . . 12
	4.2 Flooding with REA messages from inside . . . . . . . . . . 12		4.2 Flooding with REA messages from inside . . . . . . . . . . 12
	5. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 12		5. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 13
	6. Message Modification . . . . . . . . . . . . . . . . . . . . . 13		6. Message Modification . . . . . . . . . . . . . . . . . . . . . 14
	7. Session Modification/Deletion . . . . . . . . . . . . . . . . 14		7. Session Modification/Deletion . . . . . . . . . . . . . . . . 15
			7.1 Misuse of mobility in NAT handling . . . . . . . . . . . . 16
	8. Misuse of unreleased sessions . . . . . . . . . . . . . . . . 15		8. Misuse of unreleased sessions . . . . . . . . . . . . . . . . 18
	9. Data traffic injection . . . . . . . . . . . . . . . . . . . . 17		9. Data traffic injection . . . . . . . . . . . . . . . . . . . . 20
	10. Misuse of mobility in NAT handling . . . . . . . . . . . . . 18		10. Eavesdropping and traffic analysis . . . . . . . . . . . . . 21
	11. Eavesdropping and traffic analysis . . . . . . . . . . . . . 20		11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 22
	12. Security Considerations . . . . . . . . . . . . . . . . . . 21		12. Security Considerations . . . . . . . . . . . . . . . . . . 22
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	14.1 Normative References . . . . . . . . . . . . . . . . . . . . 21		14.1 Normative References . . . . . . . . . . . . . . . . . . . . 22
	14.2 Informative References . . . . . . . . . . . . . . . . . . . 21		14.2 Informative References . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . 24		Intellectual Property and Copyright Statements . . . . . . . . 25
	1. Introduction		1. Introduction
	This document provides an analysis of the security threats that are		This document provides an analysis of the security threats that are
	specific for the NATFW NSLP. The NATFW NSLP is used to install the		specific for the NATFW NSLP. The NATFW NSLP is used to install the
	required policy rules (firewall pinhole and/or NAT binding) on		required policy rules (firewall pinhole and/or NAT binding) on
	middleboxes along the path to allow the traversal of a data flow.		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		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		security sensitive issue. Thus, we need to examine carefully who is
	skipping to change at page 11, line 4		skipping to change at page 11, line 4
	+-----+ / +-----+ rtn_ext_addr +-----+ |		+-----+ / +-----+ rtn_ext_addr +-----+ |
	CREATE / | |		CREATE / | |
	+-----+ / +-------------------------------+		+-----+ / +-------------------------------+
	| M |----------		| M |----------
	+-----+		+-----+
	Figure 7: DR behind a NAT with an adversary		Figure 7: DR behind a NAT with an adversary
	SECURITY REQUIREMENT: TBD		SECURITY REQUIREMENT: TBD
			3.5 NSLP message injection
			Malicious Hosts, locate either off-path or on-path, could inject
			arbitrary NATFW NSLP messages into the signaling path, causing
			several problems. These problems apply when no proper authorization
			and authentication scheme is available.
			By injecting a bogus CREATE message with lifetime set to zero, a
			malicious host could try to teardown NATFW NSLP session state
			partially or completely on a data path, causing a service
			interruption.
			By injecting a bogus responses message, for instance, timeout, a
			malicious host could try to teardown NATFW NSLP session state as
			well. This could affect the data path partially or complete, causing
			a service interruption.
			Other messages, such as TRIGGER, can be misused by malicious hosts,
			causing a service interruption. Following versions of this document
			will investigate the impact of these messages as well.
	4. Denial-of-Service Attacks		4. Denial-of-Service Attacks
	In this section we describe several ways how an adversary could		In this section we describe several ways how an adversary could
	launch a Denial of service (DoS) attack on networks running NSIS for		launch a Denial of service (DoS) attack on networks running NSIS for
	middlebox configuration to exhaust their resources.		middlebox configuration to exhaust their resources.
	4.1 Flooding with CREATE messages from outside		4.1 Flooding with CREATE messages from outside
	4.1.1 Attacks due to NSLP state		4.1.1 Attacks due to NSLP state
	skipping to change at page 15, line 35		skipping to change at page 16, line 35
	Figure 9: State Modification by off-path adversary		Figure 9: State Modification by off-path adversary
	Summary: Off-path adversary's knowledge of Session-ID could cause		Summary: Off-path adversary's knowledge of Session-ID could cause
	session modification/deletion.		session modification/deletion.
	SECURITY REQUIREMENT: TBD: This is not a NAT/FW NSLP specific problem		SECURITY REQUIREMENT: TBD: This is not a NAT/FW NSLP specific problem
	but a GIMPS problem. The initiator MUST be able to demonstrate		but a GIMPS problem. The initiator MUST be able to demonstrate
	ownership of the session it wishes to modify.		ownership of the session it wishes to modify.
			7.1 Misuse of mobility in NAT handling
			Another kind of session modification is related to mobility
			scenarios. 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
			For this description , we assume that a NAT binding state can be
			changed with the help of NSIS signalling. When the DR is 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 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
			+----------+ +----------+ +----------+
			| NAT | |End host | |Malicious |
			| | | | |End host |
			+----------+ +----------+ +----------+
			| | |
			| | |
			| Data Traffic | |
			|--------->----------| |
			| | |
			| | Spurious |
			| | NAT binding update |
			|---------<----------+--------<------------|
			| | |
			| | |
			| Data Traffic | |
			|--------->----------+-------->------------|
			| | |
			| | |
			| | |
			Figure 11: Connection Hijacking
			SECURITY REQUIREMENT: A NAT/FW signaling message MUST be
			authenticated, authorized, integrity protected and replay protected
			between neighboring NAT/FW NSLP nodes.
	8. Misuse of unreleased sessions		8. Misuse of unreleased sessions
	Assume that DS (N1) initiates NSIS session with DR (N2) through a		Assume that DS (N1) initiates NSIS session with DR (N2) through a
	series of middleboxes as in Figure 10. When the DS is sending data		series of middleboxes as in Figure 12. When the DS is sending data
	to DR, it might happen that the DR disconnects from the network		to DR, it might happen that the DR disconnects from the network
	(crashes or moves out of the network in mobility scenarios). In such		(crashes or moves out of the network in mobility scenarios). In such
	cases, it is possible that another node N3 (which recently entered		cases, it is possible that another node N3 (which recently entered
	the network protected by the same firewall) is assigned the same IP		the network protected by the same firewall) is assigned the same IP
	address that was previously allocated to N2. The DS could take		address that was previously allocated to N2. The DS could take
	advantage of the firewall policies installed already, if the refresh		advantage of the firewall policies installed already, if the refresh
	interval time is very high. The DS can flood the node (N3), which		interval time is very high. The DS can flood the node (N3), which
	will consume the access network resources of the victim forcing it to		will consume the access network resources of the victim forcing it to
	pay for unwanted traffic as shown in Figure 11.		pay for unwanted traffic as shown in Figure 13.
	Public Internet		Public Internet
	+--------------------------+		+--------------------------+
	| |		| |
	| |		| |
	+-------+ CREATE +---+-----+ +-------+ |		+-------+ CREATE +---+-----+ +-------+ |
	| |-------------->------| |---->---| | |		| |-------------->------| |---->---| | |
	| N1 |--------------<------| FW |----<---| N2 | |		| N1 |--------------<------| FW |----<---| N2 | |
	| | success RESPONSE | | | | |		| | success RESPONSE | | | | |
	| |==============>======| |====>===| | |		| |==============>======| |====>===| | |
	+-------+ Data Traffic +---+-----+ +-------+ |		+-------+ Data Traffic +---+-----+ +-------+ |
	| |		| |
	| |		| |
	+--------------------------+		+--------------------------+
	Figure 10: Before mobility		Figure 12: Before mobility
	Public Internet		Public Internet
	+--------------------------+		+--------------------------+
	| |		| |
	| |		| |
	+-------+ +---+-----+ +-------+ |		+-------+ +---+-----+ +-------+ |
	| | | | | | |		| | | | | | |
	| N1 |==============>======| FW |====>===| N3 | |		| N1 |==============>======| FW |====>===| N3 | |
	| | Data Traffic | | | | |		| | Data Traffic | | | | |
	| | | | | | |		| | | | | | |
	+-------+ +---+-----+ +-------+ |		+-------+ +---+-----+ +-------+ |
	| |		| |
	| |		| |
	+--------------------------+		+--------------------------+
	Figure 11: After mobility		Figure 13: After mobility
	Also, this threat is valid for the other direction as well. The DS		Also, this threat is valid for the other direction as well. The DS
	which is communicating with the DR may disconnect from the network		which is communicating with the DR may disconnect from the network
	and this IP address may be assigned to a new node that had recently		and this IP address may be assigned to a new node that had recently
	entered the network. This new node could pretend to be the DS and		entered the network. This new node could pretend to be the DS and
	send data traffic to the DR in conformance with the firewall policies		send data traffic to the DR in conformance with the firewall policies
	and cause service disruption.		and cause service disruption.
	SECURITY REQUIREMENT: Data origin authentication is needed to		SECURITY REQUIREMENT: Data origin authentication is needed to
	mitigate this threat. However, the described threat is applicable		mitigate this threat. However, the described threat is applicable
	skipping to change at page 17, line 27		skipping to change at page 20, line 27
	The adversary is able to inject its own data traffic in conformance		The adversary is able to inject its own data traffic in conformance
	with the firewall policies simultaneously along with the genuine DS.		with the firewall policies simultaneously along with the genuine DS.
	SECURITY REQUIREMENT: Since IP spoofing is a general limitation of		SECURITY REQUIREMENT: Since IP spoofing is a general limitation of
	non-cryptographic packet filters no security requirement needs to be		non-cryptographic packet filters no security requirement needs to be
	created for the NAT/FW NSLP. Techniques such as ingress filtering		created for the NAT/FW NSLP. Techniques such as ingress filtering
	(described below) and data origin authentication (such as provided		(described below) and data origin authentication (such as provided
	with IPsec based VPNs) can help mitigate this threat. This issue is,		with IPsec based VPNs) can help mitigate this threat. This issue is,
	however, outside the scope of this document.		however, outside the scope of this document.
	Ingress Filtering: Consider the scenario shown in Figure 12. In this		Ingress Filtering: Consider the scenario shown in Figure 14. In this
	scenario the DS is behind a router (R1) and a malicious node (M) is		scenario the DS is behind a router (R1) and a malicious node (M) is
	behind another router (R2). The DS communicates with the DR through		behind another router (R2). The DS communicates with the DR through
	a firewall (FW). The DS initiates NSIS signaling and installs		a firewall (FW). The DS initiates NSIS signaling and installs
	firewall policies at FW. But the malicious node is also able to send		firewall policies at FW. But the malicious node is also able to send
	data traffic using DS's source address. If R2 implements ingress		data traffic using DS's source address. If R2 implements ingress
	filtering, these spoofed packets will be blocked. But this ingress		filtering, these spoofed packets will be blocked. But this ingress
	filtering may not work in all scenarios. If both the DS and the		filtering may not work in all scenarios. If both the DS and the
	malicious node are behind the same router, then the ingress filter		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		will not be able to detect the spoofed packets as both the DS and the
	malicious node are in the same address range.		malicious node are in the same address range.
	skipping to change at page 18, line 32		skipping to change at page 21, line 32
	| | | |***| |*** |		| | | |***| |*** |
	| | +-------+ +---+---+ |		| | +-------+ +---+---+ |
	| | | |		| | | |
	| | | |		| | | |
	| +------------------+ |		| +------------------+ |
	+-----------------------------------+		+-----------------------------------+
	---->---- = genuine data traffic		---->---- = genuine data traffic
	********* = spoofed data traffic		********* = spoofed data traffic
	Figure 12: Ingress filtering		Figure 14: 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
	<========================
	Figure 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 DR is 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 Figure 13 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 14
	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 | |
	|--------->----------+-------->------------|
	| | |
	| | |
	| | |
	Figure 14: Connection Hijacking
	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		10. Eavesdropping and traffic analysis
	By collecting NSLP messages, an adversary is able to learn policy		By collecting NSLP messages, an adversary is able to learn policy
	rules for packet filters and knows which ports are open. It can use		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		this to inject its own data traffic due to the IP spoofing capability
	as already mentioned in Section 9.		as already mentioned in Section 9.
	An adversary could learn authorization tokens included in CREATE		An adversary could learn authorization tokens included in CREATE
	messages and use them to launch reply-attacks or to create a 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)		with its own address as source address. (cut-and-paste attack)
	As shown in Section 4.3 of [6] a solution of Section 7 might require		As shown in Section 4.3 of [6] a solution of Section 7 might require
	confidentiality protection of signaling messages		confidentiality protection of signaling messages
	SECURITY REQUIREMENT: The threat of eavesdropping itself does not		SECURITY REQUIREMENT: The threat of eavesdropping itself does not
	mandate the usage of confidentiality protection since an adversary		mandate the usage of confidentiality protection since an adversary
	can also eavesdrop on data traffic. In the context of a particular		can also eavesdrop on data traffic. In the context of a particular
	security solutions (e.g., authorization tokens) it might be necessary		security solutions (e.g., authorization tokens) it might be necessary
	to offer confidentiality protection. Confidentiality protection also		to offer confidentiality protection. Confidentiality protection also
	needs to be offered to the refresh period.		needs to be offered to the refresh period.
			11. Conclusions
			This memo describes security threads that are applicable to the NSIS
			NATFW NSLP and some related threads inherent to firewalls and NATs.
			Security requirements are given for the scenarios and some issues to
			be considered in NTLP design are raised.
			The most security threads shown here are related to missing
			authentication or authorization schemes between all NATFW nodes.
			Given a proper authentication and authorization scheme, many of these
			threads can be mitigated. The general problem is the missing
			identity of the nodes to what authorization and authentication could
			be bound. IP addresses are in general not suitable, since NATs are
			involved in any place to imagine and in mobility scenarios they are
			changed frequently. Other attacks, such as message eavesdropping,
			can be managed easily between adjacent NSIS nodes if the NTLP or NSLP
			supports encryption. The flooding, or denial of service, of NSIS
			nodes can be mitigated not only by authorization and authentication
			schemes, but also by extensions to NATFW NSLP, where NSIS receivers
			should be able to communicate upstream which type or from which node,
			via the flow routing information, signaling traffic is allowed to be
			forwarded to them.
	12. Security Considerations		12. Security Considerations
	The entire document highlights security threats that need to be		The entire document highlights security threats that need to be
	mitigated for the NATFW NSLP. It also addresses security issues		mitigated for the NATFW NSLP. It also addresses security issues
	related to packet filters. Security requirements have been derived		related to packet filters. Security requirements have been derived
	from the relevant threats.		from the relevant threats.
	13. Acknowledgments		13. Acknowledgments
	This document is the result of discussions with many individuals.		This document is the result of discussions with many individuals.
	skipping to change at page 21, line 35		skipping to change at page 23, line 15
	[2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",		[2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
	draft-ietf-nsis-threats-05 (work in progress), June 2004,		draft-ietf-nsis-threats-05 (work in progress), June 2004,
	<reference.I-D.ietf-nsis-threats.xml>.		<reference.I-D.ietf-nsis-threats.xml>.
	[3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet		[3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
	Messaging Protocol for Signaling", draft-draft-ietf-nsis-ntlp-02		Messaging Protocol for Signaling", draft-draft-ietf-nsis-ntlp-02
	(work in progress), May 2004,		(work in progress), May 2004,
	<reference.I-D.draft-ietf-nsis-ntlp.xml>.		<reference.I-D.draft-ietf-nsis-ntlp.xml>.
	[4] Brunner, M., "Requirements for Signaling Protocols",		[4] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
	draft-ietf-nsis-requirements (work in progress), April 2004,		April 2004, <reference.I-D.ietf-nsis-.requirements.xml>.
	<reference.I-D.ietf-nsis-.requirements.xml>.
	[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", March 1997.		Levels", March 1997.
	14.2 Informative References		14.2 Informative References
	[6] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and		[6] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and
	X. Fu, "Security Implications of the Session Identifier", June		X. Fu, "Security Implications of the Session Identifier", June
	2003, <reference.I-D.tschofenig-nsis-sid.xml>.		2003, <reference.I-D.tschofenig-nsis-sid.xml>.
	skipping to change at page 22, line 29		skipping to change at page 24, line 11
	EMail: alifessi@web.de		EMail: alifessi@web.de
	URI:		URI:
	Martin Stiemerling		Martin Stiemerling
	Network Laboratories, NEC Europe Ltd.		Network Laboratories, NEC Europe Ltd.
	Kurfuersten-Anlage 36		Kurfuersten-Anlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 (0) 6221 905 11 13		Phone: +49 (0) 6221 905 11 13
	EMail: stiemerling@ccrle.nec.de		EMail: stiemerling@netlab.nec.de
	URI:		URI:
	Srinath Thiruvengadam		Srinath Thiruvengadam
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	EMail: srinath@mytum.de		EMail: srinath@mytum.de
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/