Re: General comments/questions on MIPv6 bootstrapping

This is a review of draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt:

 - in fact the document can (should?) be split into 2 parts:
   the AAA stuff and the DHCP stuff. IMHO the important part
   is the AAA one because it comes directly from the "integrated"
   scenario, DHCP is used only to transmit the AAA results to
   the MN. One can use in some cases the access control protocol,
   for instance if it is 802.1X.

 - DHCPv6 has some constraints which are not explained in
   the document (cf my previous messages)

 - I don't know if the OPTION_MIP6-RELAY-Option is necessary, i.e.,
   why not use the RADIUS-RELAY-Option (aka RRAO) ?
   (cf. draft-ietf-dhc-v6-relay-radius-01.txt)

 - Security Considerations reference RFC which are not for DHCPv6,
   i.e., the right reference is RFC 3315.

 - DHCPv6 security doesn't work well in multi-domain environments
   so in the mobility context. Quoting RFC 3118:

   The "delayed authentication" protocol does not attempt to address
   situations where a client may roam from one administrative domain to
   another, i.e., interdomain roaming.  This protocol is focused on
   solving the intradomain problem where the out-of-band exchange of a
   shared secret is feasible.

   and:

      Delayed authentication requires a shared secret key for each
      client on each DHCP server with which that client may wish to use
      the DHCP protocol.  Each secret key has a unique identifier that
      can be used by a receiver to determine which secret was used to
      generate the MAC in the DHCP message.  Therefore, delayed
      authentication may not scale well in an architecture in which a
      DHCP client connects to multiple administrative domains.

 - IMHO this paragraph is not sound:

   The communication between the DHCP client and the DHCP server for the
   exchange of home agent information is security sensitive and requires
   authentication, integrity and replay protection.  Either lower-layer
   security (such as link layer security established as part of the
   network access authentication protocol run) or DHCP security
   [RFC3118] can be used.  The latter approach is only applicable in
   non-roaming environments due to the limited applicability of the DHCP
   security mechanisms.  An adversary that is able to modify home agent
   information can force the mobile node to use a different home agent
   than intended by the MSA.  However, this type of attack can be
   detected by the security mechanism between the mobile node and the
   home agent.


 - to finish the document presents the less aggressive scheme to use
   AAA in MIPv6 bootstrapping, i.e., it only assigns the HA. I have
   a concern about this because AAA is the only practical way to
   attach security properties (i.e., a proof it is not fake) to
   the care-of address so to improve the MIPv6 security.
   Unfortunately the document does nothing for this...

Regards

Francis.Dupont@xxxxxxxxxxxxxxxx