[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ran's emails



> From: Ran Atkinson <rja@bodhi.nrl.navy.mil>
>   Examples include "blocks of SPIs" which I'm not terribly keen on.
> I do think it is sensible to grab several keys out of a single
> D-H exponentiation if possible and cache a few of the keys for later
> use by those two parties.  This permits me to take advantage of
> locality in which systems my system is talking with if I want to,
> but I am not sure any spec change is really needed to make this work.
>
Fascinating.....

You expect the keys to change, and not change the SPIs?

You expect to "cache a few of the keys", without telling your peer how
many are assigned, and how and when they are used?

You expect this magically to happen without changing the spec?

I think this is an excellent example of our differences.  I am a
_practical_ protocol designer.

You suggested a feature you wanted to see.  I wrote up a protocol
mechanism to implement your feature.

If nobody implements it, then it will be removed in the Draft Standard.


>   Similarly, while I think that it is overkill for ISAKMP to have
> _both_ attribute lists and attribute sets, I can probably live with
> either one of those two.  I do think we need more flexibility in
> negotiating SA attributes than I see in the most recent online
> Photuris draft, but there are also aspects of ISAKMP that I'm
> not comfortable with (I've sent email to them about those issues).
>
We don't need more flexibility, we need less.  A few simple features,
which everyone implements.  Otherwise, we have no interoperability.

And if you have suggestions for changes, mail them to the list, not to
the authors.  That goes for the rest of you, too.  Thanks.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2