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

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?

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.

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

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

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

> Further comments on this are invited...

I am just reading the MIB first time, and I do have some questions and
comments.

There is a typo in the ipsecIkeSaEncKeyLength definition
(ipsecIkeSaEncLeyLength). I assume it is 0 for variable length ciphers
that are using default key length defined in the documents?

BTW, there IS always encryption for ISAKMP SA, if such exists, so it
might be better to change those "... or there is no encryption
specified" to "... or there is no ISAKMP SA active". There is also
same text for ipsecIkeSaHashAlg.

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

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.

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

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.

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.

I don't know how easy it is to find out ipsec sa decryption errors
either, but perhaps just checking the padding is enough.

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?

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

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.

I really don't like 3-second-encryption-algorithms to be added to
documents, but if they must be mentioned, I would think it is better
NOT to take the first available number for it, but take some random
number like 65322 instead, so we do not have conflicts so easily.

Should we add something about this to the doi and ike draft also
(about not taking the first one, but taking them in random order)? 

Same thing for ESP_DES40 (again the first available one, that
everybody is going to use anyway if they ever add private algorithms,
and not defined in the other documents).

It seems to be odd that group 5 is missing, even when it is much more
widely supported than DES40 :-)
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
References: