[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: