Re: Question re HIP dependency & some architectural considerations
marcelo bagnulo braun <[email protected]>
| Newsgroups | gmane.ietf.multi6 |
|---|---|
| Message-ID | <[email protected]> |
Hi Kurtis, El 27/07/2004, a las 4:46, Kurt Erik Lindqvist escribió: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2004-07-26, at 17.06, marcelo bagnulo braun wrote: > >> [Side Note: Also, i think that the AID should be used as IP address >> (i.e. locator) for the initial packets, since i believe it would allow >> to delay the security checks to the moment you need to start using an >> alternative address. >> I mean, initial packets just use the AID as the IP address contained >> in the received packet (no additional security checks are required) >> and then if you need to change locators, you start performing more >> complex. >> But this is one step ahead i guess and it doesn't really belong to >> this part of the reasoning] > > While you might not have to have the alternative locators verified with > the initials, having them pre-computed seems more optimal performance > wise, instead of waiting for failure detection to start the > verification process. Having to do that if the previously verified > locators fails at the time of attempted usage seems like something you > will hae to live with in any case. > Yes i see your point. The tradeoff that we have to consider is: imposing additional load when no failure occurs (i.e. verification of alternative locators and the crypto is before you know you need them) versus delaying the recovery the time required for the verification when the outage really occurs An observation: we can build a solution that supports both modes and leave it up to the user policy to decide which mode to use imho the common situation would be that no failure occurs, so i would argue that the default behavior should be performing the verification when needed. regards, marcelo > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQQXCEKarNKXTPFCVEQLqTgCeKyWAczHATMrTA8GKMCNG59prucEAoNY2 > nQ2fTQZ7ziCf7aNURWxNY1Rd > =F3Gn > -----END PGP SIGNATURE----- > >