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

From: Gerardo Giaretta <[email-masked]>
Date: Wed, 26 Oct 2005 16:19:28 +0200

>  In your previous mail you wrote:
> 
>    > 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.
>    
> => 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).
>

Agree. This is why I have been proposing EAP approach in the past.
 
>    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.
>    
> => 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...
>

Integrated scenario: MSA==ASA and this is the most common case for any
mobile operator. 

--Gerardo

> Regards
> 
> [email-masked]
> 

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: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 26 Oct 2005 19:12:30 -0400

If DHCPv6 is the most used way to discover DNS server address, it is
very unlikely that the DHCPv6 server won't return DNS server address
option.

In the worst case, the AR/NAS can relay DNS requests from the MN to the
local DNS server and vice-versa. We have already implemented this in our
product since there is no IPv6CP option for DNS.

-Kuntal

> -----Original Message-----
> From: [email-masked] [mailto:Francis.Dupont@enst-
> bretagne.fr]
> Sent: Wednesday, October 26, 2005 5:51 PM
> To: Chowdhury, Kuntal
> Cc: COMBES Jean-Michel RD-MAPS-ISS; [email-masked]
> Subject: Re: [Mip6] General comments/questions on MIPv6 bootstrapping
> 
>    In real world the MN may have other ways to get the local DNS
server
>    info e.g. PPP (this was also discussed in DT)
> 
> => where is the DNS stuff in IPv6CP?
> 
>    or pre-configuration.
> 
> => pre-configuration in a roaming environment?
> 
>    The MN won't be in "deep trouble" if it has other ways to acquire
local
> DNS
>    address, after all.
> 
> => LLMNR? I believe more in manual configuration (written on the
> blackboard:
> the WEP key is XXX, the DNS server is YY::YY, :-).
> 
> Believe me or not, the lightweight DHCPv6 service *is* the service
which
> will distribute local DNS server(s) address(es).
> 
> Regards
> 

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