Subject: RE: [mobile-ip] Security question for HMIPv6

From: Soliman Hesham <[email-masked]>
Date: Tue, 17 Jun 2003 19:28:53 -0400

Hi James,

 > > 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.
 > >
 > 
 > 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?

=> The use of stateful address autoconfiguration is only
relevant for the on-link CoA and would not interfere
with HMIPv6. What would happen is that the MN would get
an LCoA through DHCP, then after receiving the MAP option
in the RA it would form RCoA and proceed with the SA setup.

 > 
 > 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?

=> It depends on whether you believe this needs to be a special
service or not. For instance, when you connect to a cellular
network today mobility support is assumed, otherwise it's not
a cellular network. So I would say that if you havew access, you
should have mobility management. However, this does not preclude
the model that you suggest. You can always distinguish between
the users based on their CAs for example. This can be part of 
the IKE policy checks. In manual SAs are used (not a common 
case I suppose) you can easily distinguish the users when
manually configuring an SA. 

 > 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.

=> See above.

 > 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.

=> Correct. But there is a difference between the HoA and
the RCoA in this context. The HoA is assumed to be fixed
for reachability. Therefore you want to make sure that 
certain addresses are reserved for certain MNs. In the RCoA
case, the address is merely a CoA, it does not need to be 
fixed. So there is no need to associate certain MNs to
certain addresses. There is no reachability requirement
here, any address will do for the MN. 

Thanks, 
Hesham

---

From: "James Kempf" <[email-masked]>
Date: Wed, 18 Jun 2003 10:34:02 -0700

> in the RA it would form RCoA and proceed with the SA setup.

Might it also be possible for a MN to receive its RCoA through DHCP?
It would, of course, require defining a new DHCP option to deliver the
RCoA.

> manually configuring an SA.

I suppose that's the question. From an operator standpoint, I could
see having it be a separate service or not. Roamers might not use it,
for example, depending on the business agreement with the local
operator.

Regarding distingushing between users based on certificates, the
difficulty here is that a standard PKI cert is not sufficient to
establish authorization. That would require an authorization cert (RFC
3281). These are not widely used currently.

Another possibility is to use IKEv2 in which an EAP exchange can be
used within the IKE Phase 1 exchange to establish authorization. But
there is still the issue of what to use as the identity.  It would
probably have to be the MN's FQDN, since the MN is fabricating the
RCoA or obtaining it in some other fashion independently from the MAP.

> here, any address will do for the MN.

I think as long as there is some verifiable identity that could be
used to anchor the SA, this would work.

I'm not sure whether these issues really need to be fully worked out
in the draft, since it will be going to experimental. From a
deployment standpoint, it will probably be a while before operators
are ready to bite the PKI bullet anyway.

            jak