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

From: Soliman Hesham <[email-masked]>
Date: Tue, 17 Jun 2003 07:55:52 -0400

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

=> Not that I can think of. 

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

=> Probably, it makes no difference. For MIPv6 it was 
easier I suppose to just use ESP because it covers
all cases (BU + HOT/HOTI). In HMIPv6 either one
is fine.

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

=> Agreed. That's why the keywords are used as shown 
above. The implementation choice is also there
(i.e. forward packets while waiting for BAA).

Thanks, 
Hesham

---

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

James, one clarification below

 >  > 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 
                            ^^^^
=>                         I meant certificate not CA

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Wed, 18 Jun 2003 23:15:36 -0400

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

=> There is no fundamental reason that would make it impossible
but I don't know why one would want that. All it does is
delay things more for no benefit.

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

=> FQDN would work fine. In future people might want to 
add other identities, local NAI for instance might
be one. All of this is possible to add as nothing in
the spec restricts adding more options. But for we
can just deal with existing standards. I haven't
looked at RFC 3281, but there is no restriction
on the type of certificate that can be used with
IKE. 

 > 
 > > => 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.
 > >
 > 
 > I think as long as there is some verifiable identity that could be
 > used to anchor the SA, this would work.

=> Agreed.

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

=> Aside from the draft progress. The issues above are related
to the type of authorisation needed and the consequential
choice of certificate/identifier. These are essentially
business requirements and are best left for the specific
business case to decide. HMIPv6 itself does not care which
one of these cases are being used. 
As a side comment on the PKI issue. There need not be a 
Global PKI or anything like that. An operator can setup
their own CA in a few hours and they'll probably need
to anyway for other security reasons. So this will cover
the operator's own users. For roaming users, operators
already have roaming agreements and the inclusion of 
a CA PK into that agreement is all we need to allow
roaming users to use HMIPv6. I seriously doubt that
mobility will be an additional service for cellular
operators. It never has been and I can't see that
changing in future. Just imagine your reaction if an
operator tells you that you have to pay more to walk 
or drive during a phone call on a mobile phone!

The differentiating factor between operators will be 
services, cost ...etc IMO. 

Hesham

 >             jak