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

From: "COMBES Jean-Michel RD-MAPS-ISS" <[email-masked]>
Date: Mon, 24 Oct 2005 19:08:51 +0200

Hi,  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Gerardo Giaretta
> Sent: Monday, October 24, 2005 6:51 PM
> To: Kilian Weniger; [email-masked]; 
> Alexandru Petrescu
> Cc: [email-masked]
> Subject: RE: [Mip6] draft-dupont-mip6-dhaadharmful-00.txt
> 
> Hi Kilian, all, 
> 
> > Hi Francis, Alex,
> > 
> > >    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
...

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
> 

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Oct 2005 14:09:53 +0200

In your previous mail you wrote:

=> this is not true: you can use dynamic updates and you can put
the critical RRs in a small zone in order to mitigate the main issue
of dynamic updates with DNSSEC (the private key must be online).

=> I disagree: the only real problem with DNSSEC is it is not yet
deployed.

Regards

[email-masked]