Subject: RE: [Mip6] General comments/questions on MIPv6 bootstrapping

From: Gerardo Giaretta <[email-masked]>
Date: Wed, 26 Oct 2005 15:56:51 +0200

Hi Francis,

just one comment below. I'll let the editor of the draft to answer more
detailed comments. 

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

I believe that AAA is also the most pratcial way to perform HA
assignment.

I think modifying 802.1X is tricky. An extension to PANA may be easier.
Another approach is the usage of EAP between MN and AAA for HA
assignment. This has also the advantage that it does not imply
extensions to network access and this is good for deployment. The issue
with this approach is the applicability statement of EAP.

--Gerardo

>  - 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
> 
> [email-masked]
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 16:14:42 +0200

=> yes, AAA is very fine:
 - more capability (it can assign all addresses)
 - more efficient (if it is used for piggybacking other things in it)
 - more secure (cf my concern).

=> Julien has just done the same comment. IMHO the security improvment
is the key, i.e., operators won't be happy if we can solve a security
issue (protect against fake CoA) but don't.
BTW I'd like to know the real world probability to be in the
integrated scenario for MIPv6 and for NEMO...
   
Regards