---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Wednesday, November 18, 1998 6:41 PM
> To: Tim Jenkins
> Cc: John Shriver; ipsec@tis.com
> Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only?
>
>
> Tim Jenkins writes:
> > My mandate was to *quickly* produce a usable MIB. The speed
> issue requires
> > some simplification. Further, I have only made a few
> simplifications:
> > 3) Only 1 phase SA between 2 peers at a time.
>
> I don't like this. There can easily be two phase 1 SAs between 2 peers
> at a time in case we have simultaneous startup or rekeying going on.
> Both ends just start phase I negotiation at the same time, we create
> two phase I SAs and both of them are valid and there is know defined
> way to select which one of them to leave, and which one to delete. If
> we just randomly delete one of them and the other end does the same we
> end up without SA at all 50 % of the time.
>
> This issue has been discuessed earlier in the list, but I don't think
> it have been resolved. As far as I can say any of the drafts doesn't
> disallow that, or say what you should do to resolve the thing, so it
> is going to happen.
>
> In any case if we end up having (or just want to support them)
> multiple ISAKMP SAs how are we going to represent them in the MIB?
You describe a problem that is not the MIB's problem: how to deal with
multiple phase 1 SAs. It's only the MIB's problem if we must support
multiple phase 1 SAs.
Can anyone tell me why we need to support multiple phase 1 SAs?
Obviously, there will be transient times when there are multiple
SAs during re-keying of a phase 1 SA. However, I don't see a need
for this condition to persist.
My impression of the needs for negotiating a second phase 1 SA:
1) A new phase 2 SA needs to be established under the protection of
a phase 1 SA that requires more protection than an existing phase 1
SA with the same peer.
2) Pending expiration of the existing phase 1 SA.
In both cases, the old SA can be deleted once the new one is up.
Additionally, since I made the assumption of a single SA, I could
put the phase 1 virtual tunnel stats/characteristics in the same
table as the phase 1 SA stats/characteristics.
>
> Also for mobile user case it would be nice not to tie ISAKMP SA to
> ip-addresses but to tie them to cookies. Now the MIB uses the
> ip-address and port numbers to identify the ISAKMP SA.
Yes, because it's supposed to be a virtual tunnel ID, not an SA ID.
In reality, the tunnel ID is the authenticated phase 1 ID. Should
the index for this table be changed to the phase 1 ID?
>
> For mobile users case it would be usefull to reuse old ISAKMP SA to
> IPsec gateway even if the ip-addresses of the mobile user has already
> changed. Currently only thing that requires destination address to
> remain constant between two phase II negotiations is the cookie
> generation algorithm (and that is quite easy to change, and it is
> implementation issue).
I recall that dealing with mobile IP was to be done later. Since
the mandate of *this* MIB was to get something out quickly that
was usable, I intentionally avoided these complications.
>
> Only cookies really distinguish the ISAKMP SA. I would change the
> ISAKMP SA table to be two layers just like the ipsec sa table, so that
> the first table is uniquely identified by the phase I identities
> (ipsecIkeTunnelTable), and the second table is uniquely
> identified by the
> ISAKMP SA cookies (ipsecIkeSaTable).
Yes, the cookies identify the SA, but not the phase 1 virtual tunnel.
If we insist on support for multiple phase 1 SAs, I would break out
the SA specific stuff from the IKE table like I did with the phase 2
SA specific stuff. In that case, you'd end up with four tables, not
three.
>
> > This would require the addition of an IP address added to every
> > 'ipsecSaEntry',
> > causing it to be duplicated, since it's already in the
> 'ipsecIkeSaTable'.
>
> Yes, I would think that would be wise anyways, if we consider this MIB
> to be used for other things that VPN also. For mobile user the ipsec
> address might change quite quickly and it might have multiple ipsec
> tunnels with different ip-address up at the same time (I am talking
> about mobile user with radio link connection, not necessary road
> warrior case).
Again, I wanted to leave mobile out for now. Wasn't someone supposed
to write something up about IPSec and Mobile IP? If they did, can someone
point me to it? (Thanks.)
>
> > Further comments on this are invited...
>
> I am just reading the MIB first time, and I do have some questions and
> comments.
>
... <snip>
>
> ipsecIkeSaDifHelFieldSize? How is this defined? What is the field size
> for MODP groups? Is this really needed? (I think the field size
> attribute in the ike is completely unused, because the field size can
> be seen from the polynomial anyways).
It was just an exercise in completeness. It comes from the Field Size class
described in Appendix A of [IKE]. I'm happy to remove it if no one objects,
if its use is either non-existent or unimportant.
>
> ipsecIkeSaPFS: If your policy doesn't mandate anything then I assume
> that you set this to TRUE as long as all SAs are created using PFS and
> set it to FALSE when you have first SA that is not using PFS?
>
> I don't really think this variable belongs here at all, because in the
> beginning you say that this document doesn't specify the policy, and
> this is clearly policy issue, there is nothing to prevent using one
> ISAKMP SA to create both PFS and non-PFS ipsec SAs.
Good points. It was intended to indicate that SAs created within this
phase 1 SA use PFS (as set by policy). A more appropriate place would
be with the SA itself then, if it's wanted at all. Comments?
>
> Why is the ipsecIkeSaTrafficLimit limited to Gauge32? Note that the
> current IKE draft doesn't limit the size of the life duration
> attribute (it may be variable length, although I assume all of the
> implementations will fail, if someone tries to send 64-bit number to
> them...).
It's actually an Integer (misprint in -02). Anyway, at 32 bits,
I figured 4,294,967,295 1024 byte blocks would be a reasonable upper
limit for expressing this.
>
> Why are the *Packets counters Counter32, instead of Counter64? We may
> end up using more than 2^32 packets also... It takes for 100 MB
> ethernet with small packets only less than an half a day to do it.
>
That's fine. And what will it be over the Internet? Even over a T3
with normal traffic, it's still likely more than a day.
I really don't want to proliferate 64-bit values unless
they're really needed. There are still many users of SNMPv1 that
can't support 64-bit values, so I don't want to make the translation
any more different than necessary.
> ipsecIkeSaDecryptErrors: How you defined such? Normally that might be
> guessed from the INVALID-PAYLOAD-TYPE, DOI-NOT-SUPPORTED,
> PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX error codes or something else.
> I think it might be quite hard to categorize errors to be decryption
> errors. At least there should be list of errors that are considered
> decryption errors.
>
> ipsecIkeSaHashErrors: I assume this doesn't contain the
> AUTHENTICATION-FAILED error codes that are generated when phase I
> authentication hash failes, only to the INVALID-HASH-INFORMATION that
> are generated if the hash lenght is invalid etc. The
> draft-ietf-ipsec-isakmp-10.txt says you should send
> AUTHENTICATION-FAILED error code if the hash comparision fails.
>
> I assume this should really be ipsecIkeSaAuthErrors if you want to
> calculate authentication errors.
>
These are SA processing errors, just like in IPSec. In other words,
the decryption of the payload of an encrypted ISAKMP packet lead
to a bad length or whatever. The hash calculation for the authentication
of the *packet* failed.
These count packet errors in the control stream (the IKE virtual tunnel)
as performed by the phase 1 SA. They are not protocol or negotiation
errors.
... <snip>
>
> ipsecTunnelLocalAddressOrStart, ipsecTunnelLocalAddressMaskOrEnd:
> where is the type of these fields given? How does the reader know if
> they should treat this range, subnet, or just one ip address?
If the maskOrEnd is a mask, it's a mask and the AddressOrStart is the
subnet. A 32-bit mask means the AddressOrStart is an address. Otherwise,
it's a range.
>
> "ipsecIkeSaEncAlg - Encryption Algorithm" defines DES40-CBC 65001,
> which is not defined by the DOI (and should not be defined by the DOI,
> because is it from the private range).
As I stated in the appendix, they are not part of the MIB. They
are reproduced for information only.
The values for DES40 come from a Cisco document, and were used at
the last interoperability workshop by both Microsoft and TimeStep.
>
> Also because the MIB doesn't provide the vendor id information (I
> think it should!) there is no way to know whose private number space
> we are using if there are any numbers from the private number space.
The DES40 values are not private number space; they are in co-operating
implementations number space.
>
...<snip further comments about DES40>
> It seems to be odd that group 5 is missing, even when it is much more
> widely supported than DES40 :-)
At release time of -02 of the MIB, there was a document for DES40. I
had not seen the Group 5 document at that time. Maybe I should put in
groups 6, 7, 8, 9, 10 etc. now? :-)