[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New IPSec Monitoring MIB draft
Tim Jenkins writes:
> A typo shows in the URL. Use the line above it to change it to
> The URL is <ftp://206.191.59.148/draft-ietf-ipsec-monitor-mib-00.txt>.
Some comments about the draft:
There doesn't seem to be any way to identify what ISAKMP SA (phase 1)
was used to create IPSec SA (phase 2). There is no index from the
IpsecProtSuiteEntry to the IpsecIkeSaEntry. I think there should be a
way to find the Phase 1 SA based on the Phase 2 SA, so users can find
for example the certificate and the identities used to create that
IPSec SA.
> -- protection suite selectors
> ipsecProtSuiteLocalId OCTET STRING,
> ipsecProtSuiteLocalIdType Unsigned32,
> ipsecProtSuiteRemoteId OCTET STRING,
> ipsecProtSuiteRemoteIdType Unsigned32,
> ipsecProtSuiteProtocol Integer32,
I think the ISAKMP doesn't restrict the protocol to be same in both
local and remote id, but it really doesn't make sence to have them
different.
> -- creation mechanism
> ipsecProtSuiteDifHelGroupDesc Integer32,
> ipsecProtSuiteDifHelGroupType Integer32,
> ipsecProtSuitePFS TruthValue,
Do we really need the PFS flag? If we have
ipsecProtSuiteDifHelGroupDesc that is different from zero then we have
PFS, otherwise we do not have it. I would leave it out completely,
because it is just duplication of the data.
> -- expiration limits
> ipsecProtSuiteCreationTime DateAndTime,
> ipsecProtSuiteTimeLimit OCTET STRING, -- sec., 0 if none
> ipsecProtSuiteTrafficLimit OCTET STRING, -- 0 if none
> ipsecProtSuiteInTrafficCount OCTET STRING,
> ipsecProtSuiteOutTrafficCount OCTET STRING,
Why octet string. I know that those can be variable length, but I
think Counter64 or similar is enough for them.
> ipsecProtSuiteTimeLimit OBJECT-TYPE
> SYNTAX OCTET STRING (SIZE (4..255))
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The maximum lifetime in seconds of the protection suite,
> or 0 if there is no time constraint on its expiration."
> ::= { ipsecProtSuiteEntry 27 }
Are they ascii representation of the number or just binary value of
the number (I assume binary)? If they are binary values then the
minimum size should be 2, because if those lifetimes are expressed as
basic encoding then their length is 2 bytes.
> ipsecProtSuiteEspEncKeyLength Unsigned32,
...
> ipsecProtSuiteEspEncKeyLength OBJECT-TYPE
> SYNTAX Unsigned32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The length of the encryption key in bits used for the
> algorithm specified in the 'ipsecTunnelEspEncAlg' object,
> or 0 if the key length is implicit in the specified
> algorithm or there is no encryption specified."
> ::= { ipsecProtSuiteEntry 22 }
The key length must be basic encoded, so its maximum value is 65535.
> -- security algorithm information
> ipsecIkeSaEncAlg INTEGER,
> ipsecIkeSaEncKeyLength Integer32,
> ipsecIkeSaHashAlg Integer32,
> ipsecIkeSaDifHelGroupDesc Integer32,
> ipsecIkeSaDifHelGroupType Integer32,
> ipsecIkeSaDifHelFieldSize Integer32,
> ipsecIkeSaPRF Integer32,
Why ipsecIkeSaEncAlg is INTEGER and rest are Integer32?
> ipsecIkeSaEncKeyLength OBJECT-TYPE
> SYNTAX Integer32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The length of the encryption key in bits used for
> algorithm specified in the ipsecIkeSaEncAlg object or 0
> if the key length is implicit in the specified
> algorithm."
> ::= { ipsecIkeSaEntry 18 }
Here is a same thing that maximum value of the key length is 65535, so
SYNTAX Integer32 (0..65535) should be used.
Is there any reason why ipsecProtSuiteEspEncKeyLength was Unsigned32
and ipsecIkeSaEncKeyLength is Integer32?
> ipsecIkeSaDifHelFieldSize OBJECT-TYPE
> SYNTAX Integer32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The field size, in bits, of the Diffie-Hellman group
> used to generate the key-pair, or 0 if unknown."
> ::= { ipsecIkeSaEntry 22 }
This have also maximum value of 65535, because of basic encoding of
the value in the IKE.
> ipsecIkeSaPFS OBJECT-TYPE
> SYNTAX TruthValue
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "A value that indicates that perfect forward secrecy is
> used for all IPSec SAs created by this IKE SA."
> ::= { ipsecIkeSaEntry 24 }
This is a policy information, that cannot be found from anywhere in
the packets in the wire. If this MIB tries to remove all policy
information it should remove this one too.
> ipsecIkeSaTimeLimit OBJECT-TYPE
> SYNTAX OCTET STRING
> UNITS "seconds"
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The maximum lifetime in seconds of the SA, or 0 if there
> is no time constraint on its expiration."
> ::= { ipsecIkeSaEntry 26 }
>
> ipsecIkeSaTrafficLimit OBJECT-TYPE
> SYNTAX OCTET STRING
> UNITS "Kbytes"
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The maximum traffic in 1024-byte blocks that the SA is
> allowed to carry, or 0 if there is no traffic constraint
> on its expiration."
> ::= { ipsecIkeSaEntry 27 }
Is this again ascii number or binary, and why this doesn't have size
constraints while the ipsec versions have?
> ipsecIkeSaEncAlg - Encryption Algorithm
> DES40-CBC 65001
> ipsecTunnelEspEncAlg
> ESP_DES40 249
Again. Do we need the Appendix A at all?
Anyways it looks quite good now...
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
References: