< draft-tschofenig-mip6-ice-00.txt		draft-tschofenig-mip6-ice-01.txt >
	MIP6 H. Tschofenig		MIP6 H. Tschofenig
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Standards Track G. Bajko		Intended status: Standards Track G. Bajko
	Expires: December 29, 2007 Nokia		Expires: January 10, 2008 Nokia
	June 27, 2007		July 9, 2007
	Mobile IP Interactive Connectivity Establishment (M-ICE)		Mobile IP Interactive Connectivity Establishment (M-ICE)
	draft-tschofenig-mip6-ice-00.txt		draft-tschofenig-mip6-ice-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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		The list of current Internet-Drafts can be accessed at
	http://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 December 29, 2007.		This Internet-Draft will expire on January 10, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes how the Interactive Connectivity		This document describes how the Interactive Connectivity
	Establishment (ICE) methodology can be used for Mobile IP to		Establishment (ICE) methodology can be used for Mobile IP to
	determine whether end-to-end communication is possible. ICE makes		determine whether end-to-end communication is possible. ICE makes
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 8		4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 8
	5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 8		5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 8
	6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 9		6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 9
	7. Performing Connectivity Checks . . . . . . . . . . . . . . . . 9		7. Performing Connectivity Checks . . . . . . . . . . . . . . . . 9
	8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 9		8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 9
	9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 9		9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 9
	10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11. Attribute Encoding . . . . . . . . . . . . . . . . . . . . . . 10		11. Attribute Encoding . . . . . . . . . . . . . . . . . . . . . . 10
	12. Demultiplexing MIP and STUN messages . . . . . . . . . . . . . 12		12. Demultiplexing MIP and STUN messages . . . . . . . . . . . . . 12
	13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 16		14. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	14.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 16		14.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 13
	14.2. Attacks on Address Gathering . . . . . . . . . . . . . . . 18		14.2. Attacks on Address Gathering . . . . . . . . . . . . . . . 16
	14.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 19		14.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 17
	14.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 19		14.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 17
	14.4.1. MIP Amplification Attack . . . . . . . . . . . . . . 19		14.4.1. MIP Amplification Attack . . . . . . . . . . . . . . 17
	14.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 20		14.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 18
	15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20		15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 18
	15.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 21		15.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 18
	15.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 21		15.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 19
	15.3. Brittleness Introduced by M-ICE . . . . . . . . . . . . . 22		15.3. Brittleness Introduced by M-ICE . . . . . . . . . . . . . 19
	15.4. Requirements for a Long Term Solution . . . . . . . . . . 23		15.4. Requirements for a Long Term Solution . . . . . . . . . . 20
	15.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 23		15.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 21
	16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23		16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
	17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
	18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	18.1. Normative References . . . . . . . . . . . . . . . . . . . 24		18.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	18.2. Informative References . . . . . . . . . . . . . . . . . . 24		18.2. Informative References . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . . . 27		Intellectual Property and Copyright Statements . . . . . . . . . . 24
	1. Introduction		1. Introduction
	In a typical Mobile IP deployment, there are two endpoints, mobile		In a typical Mobile IP deployment, there are two endpoints, mobile
	node and correspondent nodes, which want to communicate. They are		node and correspondent nodes, which want to communicate. They are
	able to communicate indirectly via a combination of Mobile IP		able to communicate indirectly via a combination of Mobile IP
	signaling and reverse tunneling. A couple of different extensions		signaling and reverse tunneling. A couple of different extensions
	are available for Mobile IP that allow multiple care-of addresses,		are available for Mobile IP that allow multiple care-of addresses,
	IPv4/IPv6 interworking and different routes to be used through the		IPv4/IPv6 interworking and different routes to be used through the
	network.		network.
	skipping to change at page 13, line 32 ¶		skipping to change at page 13, line 32 ¶
	When the value in that place equals the value of the STUN Magic		When the value in that place equals the value of the STUN Magic
	Cookie, the presence of the STUN FINGERPRINT attribute tells		Cookie, the presence of the STUN FINGERPRINT attribute tells
	unambigously whether this is a STUN message or not.		unambigously whether this is a STUN message or not.
	A future version will also discuss the demultiplexing when UDP		A future version will also discuss the demultiplexing when UDP
	encapsulation is not used.		encapsulation is not used.
	13. Example		13. Example
	The subsequent example shows a minimal message. For editorial		[Editor's Note: An example will be provided in the next version of
	reasons middleboxes, such as NATs and firewalls along the path		the document.]
	between L and R are not depicted.
	L STUN R
	_______|_______ | |
	| (1) gather | | |
	| candidates | | |
	--------------- | |
	| (2) HoTI | |
	|---------------------------->|
	| (3) CoTI (candidates) |
	|---------------------------->|
	| | |
	| | ______|________
	| | | (4) gather |
	| | | candidates |
	| | ---------------
	|(5) HoT | |
	|<----------------------------|
	| (6) CoT (Candidates) |
	|<----------------------------|
	|(7) Bind Req | |
	|S=$L-CoA-1 | |
	|D=$R-CoA | |
	|USE-CAND | |
	|---------------------------->|
	|(8) Bind Res | |
	|S=$R-CoA | |
	|D=$L-CoA-1 | |
	|<----------------------------|
	|data flows | |
	| | |
	|(9) Bind Req | |
	|S=$R-CoA | |
	|D=$L-CoA-1 | |
	|<----------------------------|
	| | |
	| | |
	|(10) Bind Res | |
	|S=$L-CoA-1 | |
	|D=$R-CoA | |
	|---------------------------->|
	| | |data flows
	Figure 5: Example Message Flow
	Lets assume two agents, L and R, where L is a mobile nodes with one
	CoA and one HoA, and R is a node. L starts with gathering its host
	(CoA) and server relayed (HoA) candidates. Agent L sets a type
	preference of 126 for the host candidate and 100 for the server
	relayed. The local preference is 65535. Based on this, the priority
	for the host candidate is 2130706178 and for the server relayed
	candidate is 1694498562. It chooses its host candidate as the
	default candidate and encodes the candidates into the MIP signalling
	messages.
	The candidate is received at agent R. Agent R will also start
	gathering its own candidates, but it only has one host candidate.
	Type and local preferences are assigned by R in the same way as L,
	and the priority for the candidate will have the same value as L's
	host candidate. R also chooses its host candidate as the default
	candidate and encodes the candidates into the MIP signalling
	messages.
	Since neither side indicated that they are lite, the agent which
	initiated the signalling that began ICE processing (agent L) becomes
	the controlling agent.
	Agents L and R both pair up the candidates. They both have two pairs
	with the pair priorities 4.57566E+18 and 3.63891E+18, respectively.
	Agent R begins its connectivity check for the first pair (between the
	two host candidates). Since R is the controlled agent for this
	session, the check omits the USE-CANDIDATE attribute.
	When agent L gets the answer, it performs a connectivity check. It
	implements the aggressive nomination algorithm, and thus includes a
	USE-CANDIDATE attribute in this check. Since the check succeeds,
	agent L creates a new pair and is added to the valid list. In
	addition, it is marked as selected since the Binding Request
	contained the USE-CANDIDATE attribute. Since there is a selected
	candidate in the Valid list for the one component of this media
	stream, ICE processing for this stream moves into the Completed
	state. Agent L can now send media if it so chooses.
	If agent R is behind a firewall, then the Binding Request from agent
	L will be dropped. The ICE draft recommends that agents send STUN
	request for the candidate pairs every 20ms. Thus, for instance if
	the first Binding Request will be dropped, then next one will
	succeed, as agent R also sends a Binding Request using the same 5
	tuple selectors and open the pinhole in the firewall.
	Upon receipt of the STUN Binding Request from agent L, agent R will
	generate its triggered check, from its host candidate to agent L's
	host candidate. This check will succeed. Consequently, agent R
	constructs a new candidate pair using the host address from the
	response as the local candidate and the destination of the request
	L-CoA-1 as the remote candidate. This pair is added to the Valid
	list for that media stream. Since the check was generated in the
	reverse direction of a check that contained the USE-CANDIDATE
	attribute, the candidate pair is marked as selected. Consequently,
	processing for this stream moves into the Completed state, and agent
	R can also send media.
	14. Security Considerations		14. Security Considerations
	There are several types of attacks possible in an M-ICE system. This		There are several types of attacks possible in an M-ICE system. This
	section considers these attacks and their countermeasures.		section considers these attacks and their countermeasures.
	14.1. Attacks on Connectivity Checks		14.1. Attacks on Connectivity Checks
	An attacker might attempt to disrupt the STUN connectivity checks.		An attacker might attempt to disrupt the STUN connectivity checks.
	Ultimately, all of these attacks fool an agent into thinking		Ultimately, all of these attacks fool an agent into thinking
	skipping to change at page 24, line 49 ¶		skipping to change at page 22, line 33 ¶
	Pair Exploration Protocol for IPv6 Multihoming",		Pair Exploration Protocol for IPv6 Multihoming",
	draft-ietf-shim6-failure-detection-08 (work in progress),		draft-ietf-shim6-failure-detection-08 (work in progress),
	June 2007.		June 2007.
	[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,		[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
	"STUN - Simple Traversal of User Datagram Protocol (UDP)		"STUN - Simple Traversal of User Datagram Protocol (UDP)
	Through Network Address Translators (NATs)", RFC 3489,		Through Network Address Translators (NATs)", RFC 3489,
	March 2003.		March 2003.
	[I-D.ietf-behave-rfc3489bis]		[I-D.ietf-behave-rfc3489bis]
	Rosenberg, J., "Session Traversal Utilities for (NAT)		Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D.
	(STUN)", draft-ietf-behave-rfc3489bis-06 (work in		Wing, "Session Traversal Utilities for (NAT) (STUN)",
	progress), March 2007.		draft-ietf-behave-rfc3489bis-07 (work in progress),
			July 2007.
	[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral		[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
	Self-Address Fixing (UNSAF) Across Network Address		Self-Address Fixing (UNSAF) Across Network Address
	Translation", RFC 3424, November 2002.		Translation", RFC 3424, November 2002.
	[I-D.wing-behave-nat-control-stun-usage]		[I-D.wing-behave-nat-control-stun-usage]
	Wing, D. and J. Rosenberg, "Discovering, Querying, and		Wing, D. and J. Rosenberg, "Discovering, Querying, and
	Controlling Firewalls and NATs using STUN",		Controlling Firewalls and NATs using STUN",
	draft-wing-behave-nat-control-stun-usage-02 (work in		draft-wing-behave-nat-control-stun-usage-02 (work in
	progress), June 2007.		progress), June 2007.
End of changes. 6 change blocks.
	131 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/