Re: [Mip6] bootstrap problem definition

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

   >  - 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 ;-)
   
=> IMHO this future protocol will at least take a long time to appear...

   >  - (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.
   
=> the draft is clearly about IKEv1 only.

   Once more you have to have policy entries in place.

=> in fact this argument is not true: many IKE implementations support
dynamic policy entries which are built according the negociated
traffic selectors and authorization, or, perhaps even more common,
according the assigned "internal" address of the mobile initiator.
   
   >  - (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)
   
=> Ok but I don't understand the parenthesis.

   - AAA integration in IKEv1 is generally non-existent or at least
     non-standardized.
   
=> I strongly disagree: all IKEv1 implementations for VPN are integrated
with a AAA system. Don't believe that the market didn't require this!

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

=> I can look at our local IPsec VPN server. There is a RADIUS interface
but I don't know what it uses (this is a Cisco, it should be proprietary
extensions :-).
   
   >  - (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!
   
=> perhaps there is something older but I got:

> Date:    Mon, 10 Apr 2000 09:15:28 -0400
> To:      [e-mail]
> From:    "Powell, Ken" <[e-mail]>
> Subject: [MOBILE-IP] Mobile IPv6 questions
>...
> Message-ID:  <[e-mail]>

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

=> OE (Opportunistic Encryption) uses DNSSEC to solve this problem.

   But I agree its in
   general unworkable with the combination of MIPv6 and IKE, for
   reasons that we stated in the draft.
   
Thanks

[e-mail]

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