Subject: RE: [Mip6] draft-dupont-mip6-dhaadharmful-00.txt

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 24 Oct 2005 19:13:16 +0200

> > > >    Both ideas have appeal to me.  Both could be 
> supported by some
> > > >    argumentation.
> > > > 
> > > > => this is why we should have this discussion.
> > > 
> > > I agree that DNS-based DHAAD can be more secure, but one 
> > advantage of 
> > > anycast-based DHAAD I can see is that load balancing is better 
> > > supported since load conditions can be considered faster 
> (probably 
> > > cannot be distributed fast enough in DNS).
> > >
> > 
> > As pointed out in draft-ietf-mip6-bootstrapping-split-01, 
> > DNS-based HA discovery may be used only to achieve 
> > coarse-grained load balancing by dynamically updating the SRV 
> > RR priorities.
> 
> If you want to update the DNS servers frequently, DNSSEC cannot be
> usable:
> - for each update you will have to sign the zone
> - for each update you will have to transfer the signed zone to the
> secondary servers
> ...
> 

This is why the draft says that it can be used only for a coarse-grained
load balancing. We are not saying that DNS-based scheme can be used as
an efficient load balancing solution.

--Gerardo

> So forget DNSSEC in such a case: result, no more security.
> 
> >  On the other hand, DHAAD cannot be used to 
> > load balance using different HAs in different subnet.
> > I still think that achieving a good load balancing solution 
> > during HA discovery/assignment is very difficult in split 
> > scenario. I tend to agree with Francis that in this scenario 
> > the load balancing issue may be solved by a HA switch solution.
> > 
> > In integrated scenario it is a little bit easier and also a 
> > per-MN load balancing can be achieved relying on the AAA 
> > infrastructure (see the integrated scenario draft based on 
> > DHCP). IMO, an even better per-MN load balancing support is 
> > achieved performing HA discovery during network access 
> > authentication (e.g. via EAP or PANA), but this was discarded 
> > by the DT because of well-known reasons.
> > 
> > --Gerardo
> 
> Best regards.
> 
> JMC.
> 
> France Telecom - R&D Division - MAPS/NSS   
> Jean-Michel COMBES, Internet/Intranet Security
> E-Mail: [email-masked]
> Phone: +33 (0)1 45 29 45 94
> Fax: +33 (0)1 45 29 65 19
> Mobile: +33 (0)6 07 29 30 16
> 
> > 
> >  
> > > > => IMHO HA assignement is far better but there is not yet a
> > > mechanism
> > > > providing it *and* applicable in the general case.
> > > 
> > > Security-wise yes. But which entity assigns the HA? And 
> how do you 
> > > discover this HA assignment entity? And what about the signaling 
> > > overhead then? And the signaling overhead can be pretty 
> > high, e.g., if 
> > > MN first needs to request DNS to discover assignment entity and 
> > > subsequently establishes SA with assignment entity, gets HA 
> > assigned 
> > > and finally establishes SA with this HA.
> > > 
> > > Wouldn't it be possible to integrate HA discovery and assignment 
> > > somehow in an IKEv2 exchange, similar as HoA assignment is 
> > integrated 
> > > in IKE exchange in the bootstrapping solution? E.g., the 
> first IKE 
> > > message
> > > (IKE_SA_INIT) sent by MN would have anycast address as 
> destination 
> > > address (reply and all other IKE messages use unicast addresses as
> > > source/destination) and the Configuration Payload in the 
> > IKE_AUTH may 
> > > contain an HA address for assignment to MN (only used if 
> > the HA that 
> > > received the anycast IKE_SA_INIT shall not be used, e.g., 
> > because this 
> > > HA is overloaded).
> > > 
> > > > 
> > > >    >  - is the DNS-based DHAAD mechanism better enough 
> to replace 
> > > > the ICMP-base
> > > >    >    one?
> > > 
> > > What about the alternative to change the transport 
> protocol, e.g., 
> > > UDP-based instead of ICMP-based anycast DHAAD?
> > > 
> > > > - AFIK, there is no way currently standardized to 
> securely update 
> > > > anycast routing except to manually insert host routes into
> > > the subnet
> > > > router handling the anycast address. So maintaining an
> > > anycast address
> > > > would require extra maintenance effort, manually inserting and
> > > deleting
> > > > the routes when HAs are added or deleted.
> > > 
> > > Interesting point, but isn't such a mechnism needed for 
> almost all 
> > > anycast-based protocols? I.e., isn't there a need for such a 
> > > standardized mechanism anyway?
> > > 
> > > Regards,
> > > 
> > > Kilian
> > > 
> > > 
> > > _______________________________________________
> > > 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
> > 
> 

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