Subject: ipsp-config-policy-model Questions

From: Michael Baer <[email-masked]>
Date: 18 Jul 2001 13:08:25 -0700

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.

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)

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?).

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.

-- 
Michael Baer
[email-masked]
NAI Labs

---

From: Eric Vyncke <[email-masked]>
Date: Thu, 19 Jul 2001 14:05:58 -0700

>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.

>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)...

>(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.

>either method above, but one should probably be stated in the model.

See above

Thanks for your comments

-eric

---

From: Michael Baer <[email-masked]>
Date: 19 Jul 2001 11:49:39 -0700

>>>>> "Eric" == Eric Vyncke <[email-masked]> writes:

    Eric> At 13:08 18/07/2001 -0700, Michael Baer wrote:
    >>
    >> 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?).

    Eric> AFAIK, there will be 3 SA pairs: 1 SA pair for ESP, 1 SA
    Eric> pair for AH and 1 SA pair for IPcomp. Each of those SA will
    Eric> get its own MaxLifetimeSeconds property inherited from
    Eric> SATransform.

I just made the Homer Simpson 'Doh' sound.

    >> In the SAStaticAction Class a similar problem exists. Including
    >> the value from SAStaticAction, the value from the sub-class
    >> SATransform objects, 4 different values of maxLifetimeSeconds
    >> and maxLifetimeKilobytes can exist for an SA. Should 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.

    Eric> See above

Thanks for your response. I see how I wasn't thinking straight about
the 3 possible SA'S in a negotiated action above (sigh), but I still
don't understand the maxLifetime values in a preconfiguredSAACtion. If
the Action has maxLifetime values and each SA Transform has
maxLifetime values, which value is used for a given SA? (the
SATransform's, the preconfiguredSAACtion's, or the minimum of the
two.)

-- 
Michael Baer
[email-masked]
NAI Labs

---

From: Eric Vyncke <[email-masked]>
Date: Fri, 20 Jul 2001 08:38:09 -0700

>SATransform's, the preconfiguredSAACtion's, or the minimum of the

I'm afraid that you got us ;-) thanks for spotting it.

I will have to add text in the I-D for this specific case and specifying 
that the smallest timers are used.

-eric