Subject: [Mip6] bootstrap problem definition

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2004 12:20:33 +0200

Hello,

James Kempf and myself wrote an initial draft on the bootstrapping
problem in mobile ipv6. No solutions, just the problem. Comments
appreciated. Here's the abstract:

    This document discusses the creation of a security association
    between a mobile node and a home agent that is previously unknown to
    it.  This problem is called the bootstrapping problem.  The document
    discusses several different usage scenarios, as well as related
    issues involving informing the mobile node of changes in the home
    network topology and mobility management service.  Limitations of the
    base Mobile IPv6 protocol in dealing with the scenarios are outlined.

Unfortunately, we missed the I-D deadline (or I did) so you can
not find it from the directories. In the meantime you can access
it from:

   http://www.arkko.com/publications/mipv6/drafts/bootstrap.txt
   http://www.arkko.com/publications/mipv6/drafts/bootstrap.html

--Jari

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Tue, 17 Feb 2004 15:58:55 +0100

I have many comments about your bootstrap I-D:
 - first the problems in the abstract and in the introduction
   are not the same: in the abstract the home environment is dynamic
   and the mobile node does not know it enough. In the introduction
   the only problem of the mobile node is that it has lost the context,
   in particular the IPsec one (no security association of any type).
   Of course the problem you described, what I call "dynamic bootstrap",
   is even harder.
 - (1. intro) with IKEv1 the MN does not need to have a statically
   defined home address and the reason you gave is wrong: the home
   address is unknown during the phase 1. I agree that a static home
   address is easier because it makes authorization rules static, but
   this is not a requirement, just the case you have a chance to get
   implemented (:-).
 - dynamic home agent address discovery is a security nightmare: I agree
   we should not rely on it.
 - (2. MIPv6 conf) all MN-HA mobility signaling (not communications) are
   required to be protected by IPsec.
 - (3.1.1. Dyn H@ Assignment) dynamically assigned is not the opposite
   of statically configurated. And there are known extensions (widely
   implemented but not standardized) of IKEv1 to support dynamically
   assigned "internal" addresses.
 - Home prefix change is not a valid issue because the home agent can
   infer the new home address from the old one.
 - Same for duplicate address collision because the authorization stuff
   can, when it occurs, accept any address which is not in use or
   authorized for another client.
 - I don't understand the "addressing privacy" issue: the home address
   can be a RFC 3041 one. This even makes dynamic authorization easy
   (first come first served)...
 - (3.1.2 Dyn HA@ assignment) this is only about manual keying, isn't it?
   (note that IMHO the manual keying is very incompatible with dynamic
   bootstrap, I'd like to focus on the IKE case)
 - (3.2.1 AAA) Even I agree that IKE should be clearly integrated with
   an AAA system your statement that it can work only with certificates
   is not true.
 - Interconnected PKIs are poor replacements for a real AAA infrastructure
   but they (can) work.
 - IMHO the main advantage of an AAA infrastructure is some security
   properties for the care-of address, perhaps this is the only way
   to get more than a return routability check (included in IKE which
   uses many messages in both ways :-).
 - NAI == USER-FQDN, the real issue is AAA and NAI are user oriented
   when IKEv1 is system oriented.
 - (3.2.2 Opp/Local discovery) The idea of using the DNS to get infos
   about the home was in a very old message of someone from Digital
   in this list (I can grep into my archive to find the reference).
 - (3.3.1 Dormant mode MN) IPv6 prefix change is a matter of weeks
   or months. IMHO the real issue is not with nodes in low power
   dormant mode, but with MNs which are used every X months (every
   IETF meetings for instance :-).
 - (4. scenarios) The first scenario (no pre-existing relationship)
   has a little chance to work with IKEv1 which requires strong
   mutual authentication and authorization.
 - the second one is interesting and should be shown to VPN server
   sellers. IMHO this can be a good extension to standard VPNs,
   and there is no home address assignment issue as VPN stuff in
   general includes an "internal" address management.
 - if I understand the third scenario, the idea is to use the local
   AAA system for access control to do some kind of "local mobility"?
 - I don't understand the fourth/last scenario: there is no way to
   "turn" security associations. And IMHO IPsec people will be very
   against any attempt to define this kind of things.
 - you should add a reference to AAA/MIPv6 requirement document
   (draft-le-aaa-mipv6-requirements-03.txt) which was resubmitted
   by Frank Le (our editor) as AAA gives all you'd like: care-of
   assignment, home agent assignment, home address assignment,
   security properties for all of them, including for the care-of,
   fast or very fast creation of the first IPsec SAs, etc.
   So the (to come) solution document about dynamic bootstrap should
   be only when an AAA infrastructure is not available/used (:-).

Regards

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Sat, 28 Feb 2004 14:26:47 +0200

Hi Francis and sorry to take so long to get back to your
comments. Thanks for the comments, they were very relevant.

>    are not the same: in the abstract the home environment is dynamic

Yes. This needs to be corrected.

>    Of course the problem you described, what I call "dynamic bootstrap",

Dynamic boostrap may be a good name for this.

>    this is not a requirement, just the case you have a chance to get

Ok.

>    we should not rely on it.

I agree that its a security problem, but its also possible that a future
protocol would be capable of providing home agent discovery without the
problems ;-)

>    required to be protected by IPsec.

Right. Thanks for catching this.

>    assigned "internal" addresses.

Ok. In IKEv2 this supposed to change, as there will be a standard.

>    infer the new home address from the old one.

True. But it still needs to do something, i.e., "infer".

>    authorized for another client.

Right, but once again there needs to be some behaviour in the home
agent to handle this.

>    (first come first served)...

It is easy, but once again both end points have to do something
(setup appropriate policy entries) and we also need to specify
somewhere that the home agent should do FCFS.

>    bootstrap, I'd like to focus on the IKE case)

That's a good constraint for the work, I agree.

But dynamic home agent assignment isn't necessarily solved by
just using IKE. Once more you have to have policy entries in
place. Maybe not a big deal, but it has to get done (and specified
so that we can rely on this to be the standard functionality).

>    an AAA system your statement that it can work only with certificates

Our text is too unclear here. I'm not even myself sure what this sentence
meant. But I think we can agree on the following:

- It would be desireable to integrate a MIPv6 home agent security
   system with AAA (on an optional basis; end-to-end security should
   still be possible)

- AAA integration in IKEv1 is generally non-existent or at least non-standardized.

- AAA integration in IKEv2 should work at least if EAP authentication
   is used. There's currently no "IKEv2 AAA" application defined, but
   I think RFC 3579 (RADIUS EAP) or draft-ietf-aaa-eap-04.txt (Diameter EAP)
   should work. One caveat: I'm not sure we have defined link layer or service
   type for IPsec gateways anywhere. But that's a small detail.

>  - Interconnected PKIs are poor replacements for a real AAA infrastructure

Yes.

>    uses many messages in both ways :-).

Perhaps, though I'd have to see the specific side-by-side comparisons
on required roundtrips and security properties. And this would only work
if the mobile and correspondent nodes were both under the same AAA or
at least roaming infrastructure; this may be quite an assumption.

But I agree that in theory at least AAA could be used to provide some
assurance of address validity.

In any case, we can mention this issue in the draft as one potential
advantage. I do think there are others, however, the main one being
that most users typically have some sort of a subscription within an
AAA system whereas most users don't yet have any MIPv6 SAs.

>    when IKEv1 is system oriented.

That's true. Another issue is availability of AAA applications and
protocols that fit the authentication model in IKE.

>    in this list (I can grep into my archive to find the reference).

Please do!

>    IETF meetings for instance :-).

I think I agree.

>    mutual authentication and authorization.

Well, there's always opportunistic IPsec. But I agree its in
general unworkable with the combination of MIPv6 and IKE, for
reasons that we stated in the draft.

>    general includes an "internal" address management.

Yes. There could be different styles of address management here,
as you point out the internal address might directly be the home
address too. I suspect this might not be the only case, though.

>    AAA system for access control to do some kind of "local mobility"?

No, you turn the relationship with the local AAA system into
something else which can then be used for semi-long-term global mobility.
Or at least for the duration that you are interested in the assigned
home address. This is very similar to scenario 2, except that the
existing SA comes from an access network, perhaps even access network
that you use temporarily.

>    against any attempt to define this kind of things.

"turn X into Y" = "generate a new Y based on X"

Can you list some security concerns in this operation?

>    be only when an AAA infrastructure is not available/used (:-).

Right. Thanks.

--Jari