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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 26 Oct 2005 14:42:26 -0400

Francis,

I am just trying to catch up with this thread. Please see my comments
inline...

-Kuntal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Francis Dupont
> Sent: Wednesday, October 26, 2005 7:47 AM
> To: COMBES Jean-Michel RD-MAPS-ISS
> Cc: [email-masked]
> Subject: Re: [Mip6] 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.

[KC>] Not sure why the solution should be split into separate
components. For the split scenario draft we talk about all the
components in one place. Why should we do it differently for this one?
Moreover, no one in the DT favored producing many drafts for a solution.

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

[KC>] Not entirely true. We have statements in the draft on this line
e.g. "Also, the mechanism defined in this document requires the NAS to
support Mobile IPv6 specific AAA attributes and a collocated DHCP relay
agent."

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

[KC>] It is required because the RRAO draft does not contain an option
to carry home agent address. Moreover, as stated earlier, reducing
dependencies on other drafts was an object in the DT.

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

[KC>] I see your point. I would let the other DT members (who
contributed to the security considerations section) comment for this
one.
> 
>  - 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.
> 

[KC>] In some deployments, lower layer security can be relied on for
DHCP interaction. This is mentioned in the draft. Moreover, SDOs are
working on general bootstrapping applications that might take care of
the inter domain roaming issue. 

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

[KC>] The AAA can be used to bootstrap other parameters such as HoA,
however the DT decided to restrict the use of AAA for HA bootstrapping
only. The idea was to have as much common procedures between the split
and the integrated solutions as possible. I don't understand why IKEv2
based HoA bootstrapping will be weaker than the same with AAA.

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

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 23:34:07 +0200

=> but if the document shall be the only one for the integrated
scenario (and it seems it is the case), the weakness of the DHCP
part will impact the whole solution.

   
=> my concern is this is not enough and it seems it is shared...

   [KC>] It is required because the RRAO draft does not contain an option
   to carry home agent address.

=> as the RRAO carries RADIUS attributes do you mean there is no
RADIUS attribute for home agent address (obviously not :-).

   Moreover, as stated earlier, reducing
   dependencies on other drafts was an object in the DT.
   
=> reducing the amount of similar drafts (and code I have to
write to support them) seems a good goal too.
The idea of the RRAO is to insert some AAA attribute from the NAS part
to messages to the DHCPv6 server using a colocated DHCPv6 relay.
I use it to connect the authentication (User-Name) on the NAS to
the DHCPv6 config (keyed by DUIDs) and to assign prefixes from
RADIUS (Delegated-IPv6-Prefix). This is very similar to what
the document proposes.

=> but today the document doesn't propose a secure solution in the
general case...

   only.

=> I have to confess I don't like at all this shyness.

   The idea was to have as much common procedures between the split
   and the integrated solutions as possible.

=> nice goal but it seems the result is at the opposite (procedures
are enough different to get concerns about this point, cf Jean-Michel's
original message, and the provided functionalities are minimal, i.e.,
some potentials of the different procedures have not been exploited).
A DT effect (:-)?

   I don't understand why IKEv2
   based HoA bootstrapping will be weaker than the same with AAA.
   
=> AAA bootstrapping has the potential to be stronger because it can
provide authentication of the CoA using a trusted third party.
   
Regards