Subject: [mobile-ip] Security question for HMIPv6

From: Soliman Hesham <[email-masked]>
Date: Mon, 16 Jun 2003 23:19:19 -0400

Hi all, 

I was waiting to send this on the MIP6SHOP
list but the deadline is approaching fast. 
I'll summarise the security issue that we 
brought up in Atlanta and the suggestion for 
moving forward. 

The problem
-----------

HMIPv6 introduces the MAP which is basically
a local home agent. The current design of HMIPv6
assumes that the relationship between the MAP and
the MN is similar to the MN-HA relationship. That is, 
it is sufficient to setup an IPsec SA to protect the 
local binding updates between the MN and the MAP. 

The SA setup is relatively easier than in the MN-HA
case because the MN does not care which RCoA it receives
from the MAP. This is a significant difference from the
HA case since the MN expects a particular HoA. 

The current design assumes that the MN will pick an RCoA, 
setup the IPsec SA and from this point onwards, it uses
the SA to protect future bindings between the RCoA
and any LCoA. For further details see the draft. 

Now, the problem we brought up here is that, like the 
MN-HA relationship, there is no CoA (LCoA for HMIPv6)
test. Therefore, it is possible that the MN bomb
another address using the local BU. Although this is 
the same for the MN-HA relationship, it was seen as 
a potential issue for HMIPv6. So we will add an LCoA
test as shown below.

Basic requirements
-------------------

These are some basic requirements that led to the 
agreement in Atlanta:

1. HMIPv6 is about optimising handovers and minimising
signalling. Therefore, the solution should not add
a significant signalling burden. 
2. The solution should disallow the MN from bombing
another node on another link. 
3. The solution should reuse existing security mechanisms
whenever possible.

Solution
---------

The basic idea was to have a 3-way handshake between
the MN and the MAP to test the LCoA. The 3-way handshake
will ensure that the MN is located at the link that it 
claims to be on. Here is how it works:

     BU
MN------------> MAP
     BA+ seq no
MN<-----------  MAP
     BAA (BA+ (seq no +1)
MN------------> MAP

BU: Binding updated proted with AH/ESP
BA: Binding acknowledgement protected with AH/ESP
    In addition, the BA includes a sequence no.
BAA: The same message as the BA, with the seq no
     incremented by 1.  

This solution ensures that the MN has received the 
BA, which was sent to the claimed LCoA. Therefore, 
it ensures that the MN is located on the link that 
it claimed. 

This solution MUST be implemented and MAY be
used. The decision whether the MAP sends the BA
with a sequence no MUST be configurable in the MAP. 
Therefore, an operator that does not want to use
this solution could configure the MAP to send a normal
BA (without the seq no). This use of the keywords handles
the optimisation Vs strong security tradeoff.
MAP implementers may decide to continue forwarding the 
MN's packets while waiting for the BAA provided that
BAA_timeout has not expired. A default value for BAA_timeout
could be 2 seconds. 

Possible changes to this solution:
- Use a Nonce or a seq no? Both will work I think.
- MAY Vs SHOULD for using this mechanism? I think a
  'MUST implement' is necessary though and we should not
  change that. 

Comments?

Hesham

---

From: Greg Daley <[email-masked]>
Date: Tue, 17 Jun 2003 14:58:11 +1000

Hi Hesham,

My comments are way down below.

Soliman Hesham wrote:
[problem statement snipped]
>   'MUST implement' is necessary though and we should not

I'm not particularly fussed if either the sequence number
or the nonce is used (unless there's some reason to
prevent prediction of the BA+ packet).

One comment though.  Draft07 and your post both mention
AH/ESP (the draft says AH or ESP).  draft 22 of MIPv6
says BU/BAck SHOULD use ESP, which MUST be implemented.
Do you think there's value in bringing HMIPv6 requirements
into line with MIPv6?

Overall, the cost of performing this test is high
(50% more signalling!), but I can live with it so long
as the BAA is not on the criticial path for handover
signalling.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Jun 2003 11:33:19 -0700

Hesham,

> and any LCoA. For further details see the draft.

Aren't there still some issues here, though?

Suppose the ISP uses stateful address configuration. Then the MN would
need some way to obtain an address directly from the MAP's subnet, or?

Also, with stateless address autoconfiguration, how does the MAP know
that a particular MN showing up and claiming the right to localized
mobility management service actually has the right to such service?
Without that authorization, how can the MAP establish an IPsec SA for
the MN? The IKE Phase 1 exchange will occur via the LCoA, and within
that exchange, presumably the RCoA is used as the HoA would be for the
HA from draft-ietf-mobileip-mipv6-ha-ipsec-05.txt, to identify the MN.
I believe draft-ietf-mobileip-mipv6-ha-ipsec-05.txt mentions that this
requires the MN to have a fixed HoA, known to the HA, for this
purpose.

            jak