Subject: (IPng 7578) mobile-ipv6 and ipsec

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 02 Jun 1999 06:06:25 -0700

I may be confused, but if possible could someone please clarify.
	These question really related to processing order between IPsec and
	mobile-ipv6.  It is not very clear to me (please give me pointer if
	there are).

1. IPsec SAD to be used for mobile-ipv6
	mobile-ipv6 requires (MUST) IPsec in some places, like:
	1. packets with Binding update
		mobile node --> home agent
		mobile node --> corresponding node
	2. packets with Binding acknowledgement
		home agent --> mobile node
		correspondent node --> mobile node
	3. packets tunneled by home agent
		correspondent node --> home agent --> mobile node
						   ^this packet
	For each of those packets, should we use care-of address of mobile
	node, or home address of mobile node, for looking up SAD (security
	association database) for IPsec?

	It looks that (3) case should use care-of address for SAD lookup,
	as the packet will be like this:
		outer IPv6: src=home agent, dst=mobile node(care-of)
		inner IPv6: src=correspondent node, dst=mobile node(home)
		payload
	IPsec should protect outer IPv6 header and it should be transport-mode
	IPsec SAD between (home agent, care-of for mobile node).

	However, for (2) and (1), it is not very clear for me.
	For example, in case of (1), if mobile node transmits the following
	packet, both possibility is there.
		IPv6: src=mobile node(care-of) dst=corresponding node
		home addr option: mobile node(home)
		payload
	If we are to lookup (care-of for mobile node, corresponding node),
	IPsec can never get benefit from mobile-ipv6 (mobility is not
	transparent to IPsec).  IKE must be re-executed every time mobile
	node moves.
	If we are to lookup (home for mobile node, corresponding node),
	IPsec can benefit from mobile-ipv6 (mobility is transparent to IPsec).
	You run IKE just once (between corresponding node, and home address of
	mobile node) and use that even after moving to other subnet.

2. location of mobile-ipv6 destination options
	RFC2460 4.1 shows two places to attach destination headers.
		IP hbh dst1 rt frag ah esp dst2 payload
	Should I insert mobile-ipv6 options into dst1, or dst2? 

	I'm more convinced to insert to dst2, because:
	- mobile-ipv6 document suggests that ESP can be used for protecting
	  mobile-ipv6 destination options.  Only dst2 is covered by ESP.
	- mobile-ipv6 destination options are for use on final destination,
	  not intermediate hops.
	However, if we insert home address option to dst2, we can never
	look up SAD like (home for mobile node, corresponding node) because
	home address option itself can be encrypted.

itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Jun 1999 16:17:58 +0200

In your previous mail you wrote:

=> obviously "dst2" because the mobile host is the final destination,
not an intermediate router (hoem address option is clearly
a real end-to-end parameter as the source address).
I have reversed the two sections because this one has strong consequences.

=> this case is "dst2" header from the mobile.

=> this case is with a routing header "rt" to the mobile.

=> this last case is for the inner packet (the idea is to avoid forged
router advertisement from the home agent to the mobile node, cf 9.7 in I-D 7).

=> in case 1 the SA is in the from mobile way then a wildcard source SAD
entry will work (SA is supposed to be destination based then wildcard
source selector is legal, cf RFC 2401 4.4.2 second selector in the list).
 In case 2 we know the real destination (ie. the home address) and we can
use it. The case 3 is similar if we only deal with the inner packet
which has the home address as the destination. My proposal is to consider
routing to the mobile host as a wrapping which is near ignored by security.
 Both reasonning seems to be valid (or invalid :-) for not mobility bound
security too.

=> tunnel mode is attractive for mobility because it gives the routing stuff
without an extra overhead.

=> the I-D 7 says nothing about this or about what happens for bootstrap
in visit (for instance you need IKE with IPv6 transport...).
Implementations should help for that but unfortunately most of them have
no/not yet support for security today (like mine :-).

Regards

[email-masked]

PS: I have added a cc for an exception to my last statement.

---

From: [email-masked]
Date: Wed, 02 Jun 1999 23:42:18 +0900

>without an extra overhead.

	IPsec tunnel mode has very strict requirement in outer header
	generation (RFC2401 5.1.2.2).  Will mobile-ipv6 work happily
	with it?  You can insert no extension headers between outer IPv6
	and inner IPv6.

>in visit (for instance you need IKE with IPv6 transport...).

	we have IKE works on IPv6 UDP port 500 :-)

>no/not yet support for security today (like mine :-).

	We already have IPsec in code base and having hard time thinking how
	should we integrate mobile-ipv6 into it.  Maybe I should forget about
	security for a while... :-(

itojun

---

From: "Aaron Griggs" <[email-masked]>
Date: Wed, 2 Jun 1999 11:05:11 -0400

> mobile node) and use that even after moving to other subnet.

We haven't finished implementing this and I think a discussion would help.
My problem is from the SPD perspective, which are usually manually
configured.  On the correspondent node send side, the home address could be
used as the main lookup and IPSec performed for that packet.  Once the
care-of address is discovered (node is mobile), a second lookup is performed
to see if there is any other IPSec for the destination address.  An example
from the Correspondent Node's view:

    HomeAddr ----------- HomeSG --------- Internet ------------
CorrespondentNode

    MobileNode ---------- MobileSG -----|

The correspondent node's SPD may have the policy that says for traffic from
me to the home address do AH transport to HomeAddr.  A care-of address is
discovered and the second lookup says do ESP tunnel to MobileSG:
    IP(CN->MSG)_ESP_IP(CN->MN)_RH(HA)_AH_Data.

So in this case, everything works fine.

However what if the SPD entries for the HomeAddr was an SA bundle that says
do AH transport to HomeAddr and ESP tunnel to HomeSG:
    IP(CN->HSG)_ESP_IP(CN->HA)_AH_Data

When the node is mobile and a care-of address is cached, the ESP tunnel to
HomeSG is wrong because the packet is not sent to the home network.  One way
to handle this is to make sure the SPD doesn't have an SA bundle with HomeSG
but then you sacrifice not doing tunnel mode to the home security gateway.
Another is to recognize the IPSec tunnel is not to the end station
(HomeAddr) but to an intermediate gateway (HomeSG).  The IPSec send side
processing doesn't complete the bundle processing and does the second lookup
using the care-of address.

The verification of the proper IPSec (receive side processing) is also
affected since the normal SA bundle will cause the packet to be dropped.
So, IPSec has to know about the mobile node.  Basically, this is doable and
not too complicated but IPSec is definitely aware of the mobility.

> home address option itself can be encrypted.
I just read Francis response and the wildcarded source seems the best
solution.  Here is how our SP entry and corresponding SA entry would look on
the correspondent node:
SP:
    RemoteAddr     LocalAddr        OtherSelectors        IPSecProto
Direction
    HomeAddr        *                     *                             ESP
BIDIRECTION
SA:
    SPI        SADestAddr    IPSecProto    DestAddr        SourceAddr
Direction
    2000       HomeAddr      ESP              POLICY          POLICY
OUTBOUND
    2001       CorrAddr         ESP              POLICY          POLICY
INBOUND

SA entry with SPI 2001 is still found without knowing the actual home
address.  After the destination option is processed, the SP verification
passes since the remote address is the home address now.

Currently MSR, does the destination options for mobility before the IPSec.
It sounds like we need to probably change that.

Aaron