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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 26 Oct 2005 18:37:11 -0400

Please see inline...

> -----Original Message-----
> From: [email-masked] [mailto:Francis.Dupont@enst-
> bretagne.fr]
> Sent: Wednesday, October 26, 2005 4:34 PM
> To: Chowdhury, Kuntal
> Cc: COMBES Jean-Michel RD-MAPS-ISS; [email-masked]
> Subject: Re: [Mip6] General comments/questions on MIPv6 bootstrapping
> 
>  In your previous mail you wrote:
> 
>    >  - 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.
> 
> => 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.

[KC>] No, this document is not the "only" one for the integrated
scenario. The draft is _a_ solution for the intergraded scenario using
DHCPv6. We are just trying to use an IETF defined protocol for
configuration management. The weaknesses with DHCPv6 should be discussed
in DHC WG.

> 
>    >  - 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."
> 
> => my concern is this is not enough and it seems it is shared...

[KC>] I have not seen any other comments besides yours. May be I missed
the postings from others. 

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

[KC>] Unlike RRAO, OPTION_MIP6-RELAY-Option does not carry RADIUS
attributes. It carries home agent IPv6 address or the home agent FQDN.
This one works for both RADIUS and Diameter. Hence, it is more generic
than RRAO. Also, it does not require the DHCPv6 server to parse RADIUS
attributes which is a disadvantage of RRAO, IMHO. 

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

[KC>] Well, I think you are contradicting yourself here. You like the
idea of reducing dependencies on other drafts...but you want to add
another (actually two, because we need an RRAO equivalent for Diameter)
dependency!

You may find a use of the RRAO, but that does not mean that everyone has
to find similar use of it as well. The defined attributes in RRAO are
simply not of any use for the integrated scenario solution. Besides, it
adds unnecessary dependencies.

>    [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.
> 
> => but today the document doesn't propose a secure solution in the
> general case...
> 

[KC>] I think it does provide adequate guidance to secure the MN-DHCP
communication via L2 or DHCPv6 security.

>    [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.
> 
> => I have to confess I don't like at all this shyness.
>

[KC>] We are discussing a draft which is an output of the DT. Regardless
of what you like to hear, as a member of the DT, I am going to state
exactly what the DT has decided.
 
>    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 (:-)?
>
 
[KC>] In the integrated scenario, bootstrapping of MIP6 info can happen
at the time of access auth since ASA == MSA. The DT has chosen DHCPv6
for conveying the home agent info to the MN and use AAA in the backend.
We had the option of defining a completely new set of procedures for HoA
and IPsec SA parts of the bootstrapping problem space, but we chose to
reuse procedures between split and integrated solutions. Not sure, why
you think it was a not-so-good decision?

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

[KC>] no comments.
 
> Regards
> 
> [email-masked]

"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: Thu, 27 Oct 2005 01:22:12 +0200

scenario.

=> what/where is the other one? I can see only the "probleme statement",
the "split" and the "integrated with DHCP" documents.

   The draft is _a_ solution for the intergraded scenario using
   DHCPv6. We are just trying to use an IETF defined protocol for
   configuration management.

=> yes, I saw the comment "EAP is not about configuration".
BTW I repeat from time to time to one of my colleagues that
RADIUS has no configuration application...

   The weaknesses with DHCPv6 should be discussed in DHC WG.
   
=> this is not the way real things are done...

   
=> I remember some comments about the operational constraints implied
by the choice of DHCPv6.

   [KC>] Unlike RRAO, OPTION_MIP6-RELAY-Option does not carry RADIUS
   attributes. It carries home agent IPv6 address or the home agent FQDN.
   This one works for both RADIUS and Diameter.

=> so your argument is with RRAO we have to translate Diameter AVPs to
RADIUS attributes. With OPTION_MIP6-RELAY-Option we have to translate
Diameter AVPs or RADIUS attributes to DHCPv6 options. Where is the win?

   Hence, it is more generic than RRAO.

=> it is fully a matter of taste. For me it is less generic.

   Also, it does not require the DHCPv6 server to parse RADIUS
   attributes which is a disadvantage of RRAO, IMHO. 

=> it is 10 lines of code (RADIUS attributes are in a very simple
TLV format). I am afraid the code to translate AAA stuff in the relay
is both longer and at a worse place.
   
   > RADIUS (Delegated-IPv6-Prefix). This is very similar to what
   
   [KC>] Well, I think you are contradicting yourself here.

=> no, I simply don't consider inclusion as a fair way to reduce
dependencies.

   You like the
   
=> Diameter is deployed nowhere so we don't need an RDAO (it is a shame
Diameter is not used but it is a fact). My suggession is more to
translate Diameter AVPs into RADIUS attributes than to specify an RDAO.

   You may find a use of the RRAO,

=> this use is more than suggested in the RRAO draft.

   but that does not mean that everyone has
   to find similar use of it as well. The defined attributes in RRAO are
   simply not of any use for the integrated scenario solution.

=> the RRAO draft lists only attributes which are already defined
(i.e., in the IANA table). Note I use the Delegated-IPv6-Prefix
which is in a more recent draft and not in the list.

   Besides, it adds unnecessary dependencies.

=> because you believe to define stuff which is in the scope
of another WG is a good idea? We'll see.

   
=> when the current DHCPv6 security is known to not work in the
context (according to the document itself ! :-).

   > => I have to confess I don't like at all this shyness.
   
   [KC>] We are discussing a draft which is an output of the DT.

=> yes, there are traces of a DT process (:-).

   Regardless of what you like to hear, as a member of the DT, I am
   going to state exactly what the DT has decided.
    
=> so we should dissolve the DT ASAP and give back your liberty?

=> because I can see the result...
   
Regards