Re: [Mip6] bootstrap problem definition

[Jari Arkko <[e-mail]>]

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

> 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

Yes. This needs to be corrected.

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

Dynamic boostrap may be a good name for this.

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

Ok.

>  - dynamic home agent address discovery is a security nightmare: I agree
>    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 ;-)

>  - (2. MIPv6 conf) all MN-HA mobility signaling (not communications) are
>    required to be protected by IPsec.

Right. Thanks for catching this.

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

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

>  - Home prefix change is not a valid issue because the home agent can
>    infer the new home address from the old one.

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

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

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

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

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.

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

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

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

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
>    but they (can) work.

Yes.

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

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.

>  - NAI == USER-FQDN, the real issue is AAA and NAI are user oriented
>    when IKEv1 is system oriented.

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

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

Please do!

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

I think I agree.

>  - (4. scenarios) The first scenario (no pre-existing relationship)
>    has a little chance to work with IKEv1 which requires strong
>    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.

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

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.

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

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.

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

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

Can you list some security concerns in this operation?

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

Right. Thanks.

--Jari




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