[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipsp-config-policy-model Questions
At 13:08 18/07/2001 -0700, Michael Baer wrote:
Hi, I've been involved in trying to create a SNMP MIB that is based
off of the ipsp-config-policy-model and have come up with some
questions/comments regarding the current model.
For PreconfiguredSAAction's several extra values seem to be needed
beyond what is currently in the model:
A AH key value. The AH key length.
A AH IV value and the IV length.
ESP key value(s) (auth and encrypt) and the key lengths.
ESP IV values and the IV lengths.
The key values are in the external class SharedSecret as explained the
section about PreconfiguredSAAction.
The key length can be derived from the length of the value of the SharedSecret.
I'll update the I-D regarding the TWO keys needed for ESP (auth & encrypt),
thanks for spotting this mistake. Another addition is about the number of
key rounds ;-)
My understanding of the IV is that the IV is per packet (either explicit or
implicit) and hence is not part of the SA itself.
For SATransform, sub-class ESPTransform has values for the number of
key rounds with an indication this may be useful in future ESP
algorithms. Would this hold true for future AH algorithms as well? (in
which case the AHTransform class should have a key rounds value)
I didn't find any relevant information by doing a quick browse through the
IPSec RFC. But, assuming that the HMAC is using a cipher mechanism, the
number of rounds should be part of the AHTransform. I'm just uneasy to
change the I-D right now (deadline is in 2 days)...
And would the key rounds value be necessary for both future
authentication and encryption algorithms within ESP (in which case two
key rounds values may be necessary for the ESPTransform class)
In a given set of SATransforms within a negotiated SA Action, there
could be as many as 3 different values for maxLifetimeSeconds and
maxLifetimeKilobytes (one set from each of a AHTransform,
ESPTransform, and IPcomp Transform) for an SA. I would assume that the
minimum of the 3 value from each of these would be the value to use,
but this should probably be explicitly stated somewhere in the model
(maybe in the SATransform class or the IPsecProposal class?).
AFAIK, there will be 3 SA pairs: 1 SA pair for ESP, 1 SA pair for AH and 1
SA pair for IPcomp. Each of those SA will get its own MaxLifetimeSeconds
property inherited from SATransform.
In the SAStaticAction Class a similar problem exists. Including the
value from SAStaticAction, the value from the sub-class
PreconfiguredSAAction and the values from possibly 3 different
SATransform objects, 4 different values of maxLifetimeSeconds and
maxLifetimeKilobytes can exist for an SA. Should the
PreconfiguredSAAction's object lifetime values override the
SATransforms lifetime values or should the minimum of the 4 possible
values be used? or possibly a different method? I see advantages to
either method above, but one should probably be stated in the model.
Thanks for your comments