Subject: RE: [mobile-ip] Draft 15

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 4 Oct 2001 16:35:50 +1000

> OK, let me explain more about this,,,
> As you wrote in your mail, our implementation can handle the SA only for
> BU and BA 
> which I call MIP6 SA. I modified the IPsec.
> I assigned new protocol number for MIP6 binding messages. This number is
> not used as
> the normal protocol number and it is just magic number for IPsec
> selectors. 
> The MIP6 protocol number indicates that the SA is established for MIP6 BU
> and BA.
> 
	=> OK. so it's not really draft -13 but I guess you're showing
	one way of fixing the problem.
>  
> > 	=> Well on a BW-rich link (like ethernet :) ) you can do things 
> > 	to speed up the movement detection It certainly should 
> > 	take less than 1 sec. 
> > 	Of course on more BW constrained links, you need other
> > 	optimisations like the Fast Handoffs draft.
> 
> I agree with you. I guess handling layer 2 information in MIP6 layer is
> also requisite for
> the movement detection. We plan to support one of the fast handoffs draft
> in near future
> 
	=> Handling layer 2 is important to get better BW utilisation.
	Of course if BW is not important, other methods are possible
	on the IP layer.

	Hesham

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Oct 2001 12:55:08 +0300

Hi,

I have a question on -15/-14 authentication suboption
and its handling of the 'address ownership' problem.

As a background, we of course assume that something
like BAKE can establish somehow that a particular
peer really is allowed to specify what to do with
its address. In BAKE for instance, keying material
from messages sent over different paths are combined
to establish a form of trust. My question is not about
this phase, however.

As a result of BAKE or whatever we are left with an
SA that is identified by the 'destination ip address
and SPI', and contains a shared secret with the peer.

My question relates to how we can prevent a MN from
establishing a legitimate SA with a CN, and then
misusing this SA to send a BU for _another_ MN.
Given rules in -14/-15, it seems that both sides
calculate the MAC based on the contents of the
BU packet. So, what if the sender lied about the
Home Address, but used its own SPI; hence fooling
the CN to use the wrong SA? The destination ip
address of course is the CN for both.

It seems that the rules presented so far are not
sufficient to prevent this from happening. Or have
I missed something, some text hiding somewhere perhaps?

As a possible solution, I propose that the Home
Address of the MN is stored in the SA during
BAKE/whatever, and that each reception of a BU
message not only checks the MAC but also verifies
that the given Home Address is the same one as
that in the SA. (This is similar to what selectors
do in an IPsec SA to ensure that the right kind
of packet was received from the tunnel.) Alternatively,
the text in -15 4.6. under the Binding Cache entry or
in 8.2. should be clarified that the implementations MUST
*check* that only the given BSA was used. This may be
implied from 4.6 but I'd rather have this said explicitly.

Also, it might clarify things a bit if the conceptual
data structure of an SA was described in more detail,
what the components are. Btw, do we have the algorithms
specified anywhere regarding what the suboption must
support?

Jari