Re: ESP_NULL redefined

WH> Robert> As far as I can tell, cerberus is only using these defines in
WH> Robert> local structures, as identifiers. They are not used for
WH> Robert> anything that goes over the wire. This makes sense, as the
WH> Robert> values do not match the ISAKMP ESP transform values.
WH> 
WH> Right.  The questions are:
WH> 
WH> 1) are the values ever passed between cerberus and plutoplus?

Yes. Plutoplus uses the IKE versions, and calls a conversion routine to set the cerberus versions in the sadb entry passed to cerberus. In it's own code, plutoplus always uses the IKE versions.

WH> 2) were the values chosen arbitrarily or is there some math somewhere
WH>    that requires them at those values (in one package or another)?
WH>    Unlikely, but possible.

Errr... no idea. It looks to me like cerberus only uses them to look up the algorithm structure based on the sadb field. I *think* it'd be safe to switch.

WH> 3) think there are plutoplus files that are accidentally getting the
WH>    wrong definition due to include order, etc.  That'd be the real
WH>    bad.

Not any more. Nobody includes the cerberus ipsec header anymore.

WH> these all boil down to:
WH> 
WH> 4) would we break anything by redefining them to be the same.
WH> 
WH> I'd suggest we try that since it can only cause problems if they're not.
WH> 
WH> Robert> So, I'd like to update cerberus to use the same values as pp,
WH> Robert> to eliminate possible confusion. Any objections?
WH> 
WH> Nope, as long as everything still works.

The only wrinkle (you knew there had to be a wrinkle, right?), is that cerberus has one non-IKE-std algorithm (ESP_RIJNDAEL_CBC). But I think we can just tack that on to the end of the list of plutoplus non-IKE-std algorithms.


-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5