Re: [Mip6] bootstrap problem definition

[Francis Dupont <[e-mail]>]

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

[e-mail]

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