< draft-thubert-nemo-reverse-routing-header-02.txt		draft-thubert-nemo-reverse-routing-header-03.txt >
	Network Working Group P. Thubert		Network Working Group P. Thubert
	Internet-Draft M. Molteni		Internet-Draft M. Molteni
	Expires: December 24, 2003 Cisco Systems		Expires: April 12, 2004 Cisco Systems
	June 25, 2003		October 13, 2003
	IPv6 Reverse Routing Header and its application to Mobile Networks		IPv6 Reverse Routing Header and its application to Mobile Networks
	draft-thubert-nemo-reverse-routing-header-02		draft-thubert-nemo-reverse-routing-header-03
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	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 http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 24, 2003.		This Internet-Draft will expire on April 12, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	Already existing proposals enable Mobile Networks by extending Mobile		Already existing proposals enable Mobile Networks by extending Mobile
	IP to support Mobile Routers. In order to enable nested Mobile		IP to support Mobile Routers. In order to enable nested Mobile
	Networks, some involve the overhead of nested tunnels between the		Networks, some involve the overhead of nested tunnels between the
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	8. Home Agent Operation . . . . . . . . . . . . . . . . . . . 24		8. Home Agent Operation . . . . . . . . . . . . . . . . . . . 24
	9. Mobile Router Operation . . . . . . . . . . . . . . . . . 26		9. Mobile Router Operation . . . . . . . . . . . . . . . . . 26
	9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . 26		9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . 26
	9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . 27		9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . 27
	9.3 Processing of RHH for Outbound Packets . . . . . . . . . . 27		9.3 Processing of RHH for Outbound Packets . . . . . . . . . . 27
	9.4 Processing of Tree Information Option . . . . . . . . . . 28		9.4 Processing of Tree Information Option . . . . . . . . . . 28
	9.5 Processing of the extended Routing Header Type 2 . . . . . 28		9.5 Processing of the extended Routing Header Type 2 . . . . . 28
	9.6 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 30		9.6 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 30
	10. Mobile Host Operation . . . . . . . . . . . . . . . . . . 30		10. Mobile Host Operation . . . . . . . . . . . . . . . . . . 30
	11. Security Considerations . . . . . . . . . . . . . . . . . 30		11. Security Considerations . . . . . . . . . . . . . . . . . 30
	11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . . 31		11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . . 30
	11.1.1 Routing Header type 2 . . . . . . . . . . . . . . . . . . 31		11.1.1 Routing Header type 2 . . . . . . . . . . . . . . . . . . 31
	11.1.2 Routing Header type 4 . . . . . . . . . . . . . . . . . . 31		11.1.2 Routing Header type 4 . . . . . . . . . . . . . . . . . . 31
	11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . . 32		11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . . 32
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 33
	References . . . . . . . . . . . . . . . . . . . . . . . . 33		References . . . . . . . . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35
	A. Optimizations . . . . . . . . . . . . . . . . . . . . . . 35		A. Optimizations . . . . . . . . . . . . . . . . . . . . . . 36
	A.1 Path Optimization with RRH . . . . . . . . . . . . . . . . 35		A.1 Path Optimization with RRH . . . . . . . . . . . . . . . . 36
	A.2 Packet Size Optimization . . . . . . . . . . . . . . . . . 36		A.2 Packet Size Optimization . . . . . . . . . . . . . . . . . 37
	A.2.1 Routing Header Type 3 (Home Address option replacement) . 37		A.2.1 Routing Header Type 3 (Home Address option replacement) . 38
	B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . 39		B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . 40
	B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . 39		B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . 40
	B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . 40		B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . 41
	C. Changes from Previous Version of the Draft . . . . . . . . 41		C. Changes from Previous Version of the Draft . . . . . . . . 42
	Intellectual Property and Copyright Statements . . . . . . 42		Intellectual Property and Copyright Statements . . . . . . 43
	1. Introduction		1. Introduction
	This document assumes the reader is familiar with the Mobile Networks		This document assumes the reader is familiar with the Mobile Networks
	terminology defined in [2] and with Mobile IPv6 defined in [1].		terminology defined in [2] and with Mobile IPv6 defined in [1].
	Generally a Mobile Network may be either simple (a network with one		Generally a Mobile Network may be either simple (a network with one
	mobile router) or nested, single or multi-homed. This proposal starts		mobile router) or nested, single or multi-homed. This proposal starts
	from the assumption that nested Mobile Networks will be the norm, and		from the assumption that nested Mobile Networks will be the norm, and
	so presents a solution that avoids the tunnel within tunnel overhead		so presents a solution that avoids the tunnel within tunnel overhead
	skipping to change at page 30, line 45 ¶		skipping to change at page 30, line 45 ¶
	The inner packet is the plain IPv6 packet from the MH Home Address to		The inner packet is the plain IPv6 packet from the MH Home Address to
	the CN.		the CN.
	11. Security Considerations		11. Security Considerations
	This section is not complete; further work is needed to analyse and		This section is not complete; further work is needed to analyse and
	solve the security problems of record and source route.		solve the security problems of record and source route.
	Compared to MIPv6, the main security problem seems to be the fact		Compared to MIPv6, the main security problem seems to be the fact
	that the RRH can be modified in transit by an in-axis attacker. It		that the RRH can be modified in transit by an attacker on the path.
	has to be noted that an in-axis attacker (for example any MR in the		It has to be noted that such an attacker (for example any MR in the
	Mobile Network) can perform more effective attacks than modifying the		Mobile Network) can perform more effective attacks than modifying the
	RRH.		RRH.
	Selecting the tree to attach to is a security critical operation
	outside of the scope of this draft.
	11.1 IPsec Processing		11.1 IPsec Processing
	The IPsec [7] AH [8] and ESP [9] can be used in tunnel mode to		The IPsec [7] AH [8] and ESP [9] can be used in tunnel mode to
	provide different security services to the tunnel between a MR and		provide different security services to the tunnel between a MR and
	its HA. ESP tunnel mode SHOULD be used to provide confidentiality and		its HA. ESP tunnel mode SHOULD be used to provide confidentiality and
	authentication to the inner packet. AH tunnel mode MUST be used to		authentication to the inner packet. AH tunnel mode MUST be used to
	provide authentication of the outer IP header fields, especially the		provide authentication of the outer IP header fields, especially the
	Routing Headers.		Routing Headers.
	11.1.1 Routing Header type 2		11.1.1 Routing Header type 2
	Due to the possible usage of Doors [5] to enable IPv4 traversal, the		Due to the possible usage of Doors [5] to enable IPv4 traversal, the
	skipping to change at page 32, line 19 ¶		skipping to change at page 32, line 19 ¶
	multi hop option like RH type 0, care must be applied to avoid the		multi hop option like RH type 0, care must be applied to avoid the
	spoofing attack that can be performed with the IPv4 source route		spoofing attack that can be performed with the IPv4 source route
	option. This is why IPv6 [10] takes special care in responding to		option. This is why IPv6 [10] takes special care in responding to
	packets carrying Routing Headers.		packets carrying Routing Headers.
	AH authenticates the MR Home Address identity and the RRH sequence		AH authenticates the MR Home Address identity and the RRH sequence
	number. The RRH sequence number is to be used to check the freshness		number. The RRH sequence number is to be used to check the freshness
	of the RRH; anti-replay protection can be obtained if the receiver		of the RRH; anti-replay protection can be obtained if the receiver
	enables the anti-replay service of AH [8].		enables the anti-replay service of AH [8].
	As a consequence, the only kind of successful attack seems to require		In particular, if IPSec is being used, the content is protected and
	to be able to modify the packet in flight.		can not be read or modified, so there is no point in redirecting the
			traffic just to screen it.
	If one of the RRH entry is faked either to an address outside the		Say a MR in a nested structure modifies the RRH in order to bomb a
	tree or to an address that doesn't match the tree topology (not		target outside of the tree. If that MR forwards the packet with
	belonging to one of the Mobile Network prefixes at that level) then		itself as source address, the MR above it will make sure that the
	the reply packet containing a RH type 2 built out of the previous RRH		response packets come back to the attacker first, since that source
	will be dropped by the first MR that processes that entry, as		is prepended to the RRH. If it forges the source address, then the
	described in Section 9.		ingress filtering at the MR above it should detect the irregularity
			and drop the packet. Same if the attacker is actually TLMR. The
			conclusion is that ingress filtering is recommended at MR and AR.
	It is still an issue how to validate that the source of the outer		Say that an attacker in the infrastructure and on the path of the
	packet is the actual TLMR as opposed to a forged IP address put by an		MRHA tunnel modifies the RRH in order to redirect the response
	on-axis attacker outside the Mobile Network.		packets and bomb a target. Considering the position of the attacker -
			a compromised access or core router - there's a lot more it could do
			to send perturbations to the traffic, like changing source and
			destinations of packets on the fly or eventually polute the routing
			protocols.
			Say a MR in a nested structure modifies the RH 2 in order to attack a
			target outside of the tree. The RH type 2 forwarding rules make sure
			that the packet can only go down a tree. So unless the attacker is
			TLMR, the packet will not be forwarded. In any case, the attacker
			will be bombed first.
			Say that an attacker on the path of the MRHA tunnel modifies the RRH
			in order to black out the MR. The result could actually be
			accomplished by changing any bit in the packet since the IPSec
			signature would fail, or scrambling the radio waves in the case of
			wireless.
			Selecting the tree to attach to is a security critical operation
			outside of the scope of this draft. Note that the MR should not
			select a path based on trust but rather on measured service. If a
			better bandwidth is obtained via an untrusted access using IPSec,
			isn't it better than a good willing low bandwidth trusted access?
	12. Acknowledgements		12. Acknowledgements
	The authors wish to thank David Auerbach, Fred Baker, Dana Blair,		The authors wish to thank David Auerbach, Fred Baker, Dana Blair,
	Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur,		Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur,
	Kent Leung, Massimo Lucchina, Vincent Ribiere, Dan Shell and Patrick		Kent Leung, Massimo Lucchina, Vincent Ribiere, Dan Shell and Patrick
	Wetterwald -last but not least :)-.		Wetterwald -last but not least :)-.
	References		References
	[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in		[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
	IPv6", draft-ietf-mobileip-ipv6-21 (work in progress), March		IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
	2003.		2003.
	[2] Lach, H. and T. Ernst, "Network Mobility Support Terminology",		[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	draft-ietf-nemo-terminology-00 (work in progress), May 2003.		draft-ietf-nemo-terminology-00 (work in progress), May 2003.
	[3] Kniveton, T., "Mobile Router Tunneling Protocol",		[3] Kniveton, T., "Mobile Router Tunneling Protocol",
	draft-kniveton-mobrtr-03 (work in progress), November 2002.		draft-kniveton-mobrtr-03 (work in progress), November 2002.
	[4] Deering, S. and B. Zill, "Redundant Address Deletion when		[4] Deering, S. and B. Zill, "Redundant Address Deletion when
	Encapsulating IPv6 in IPv6",		Encapsulating IPv6 in IPv6",
	draft-deering-ipv6-encap-addr-deletion-00 (work in progress),		draft-deering-ipv6-encap-addr-deletion-00 (work in progress),
	November 2001.		November 2001.
	[5] Thubert, P., Molteni, M. and P. Wetterwald, "IPv4 traversal for		[5] Thubert, P., Molteni, M. and P. Wetterwald, "IPv4 traversal for
	MIPv6 based Mobile Routers",		MIPv6 based Mobile Routers",
	draft-thubert-nemo-ipv4-traversal-00 (work in progress), March		draft-thubert-nemo-ipv4-traversal-01 (work in progress), May
	2003.		2003.
	[6] Postel, J., "Internet Protocol", STD 5, RFC 791, September		[6] Postel, J., "Internet Protocol", STD 5, RFC 791, September
	1981.		1981.
	[7] Kent, S. and R. Atkinson, "Security Architecture for the		[7] Kent, S. and R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.
	[8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,		[8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
	November 1998.		November 1998.
	skipping to change at page 41, line 7 ¶		skipping to change at page 42, line 7 ¶
	then a new source route header is needed to enforce that path on MR1.		then a new source route header is needed to enforce that path on MR1.
	The other way around, MR5 may leave the decision up to MR1. If MR1		The other way around, MR5 may leave the decision up to MR1. If MR1
	uses the same attachment router for a given flow or at least a given		uses the same attachment router for a given flow or at least a given
	destination, then the destination receives consistent RRHs.		destination, then the destination receives consistent RRHs.
	Otherwise, the BCE cache will flap, but as both paths are valid, the		Otherwise, the BCE cache will flap, but as both paths are valid, the
	traffic still makes it through.		traffic still makes it through.
	Appendix C. Changes from Previous Version of the Draft		Appendix C. Changes from Previous Version of the Draft
			From -02 to -03
			reworded the security part to remove an ambiguity that let the
			reader think that RRH is unsafe.
	From -01 to -02		From -01 to -02
	Made optional the usage of ICMP warning "RRH too small" (Section		Made optional the usage of ICMP warning "RRH too small" (Section
	5).		5).
	Changed the IPsec processing for Routing Header type 2 (Section		Changed the IPsec processing for Routing Header type 2 (Section
	11.1).		11.1).
	From -00 to -01		From -00 to -01
End of changes. 15 change blocks.
	38 lines changed or deleted		64 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/