[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New IPSec Monitoring MIB draft
---
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, January 27, 1999 1:11 PM
> To: Tim Jenkins
> Cc: 'ipsec@tis.com'
> Subject: 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.
Not directly. The reason for that is that phase 2 lifetimes are independent
of phase 1 lifetimes. If the phase 1 SA that created a particular phase 2 SA
expires before the phase 2 SA, where do you point the phase 2 SA?
The indirect way is to take the 'ipsecProtSuiteLocalAddress' and
'ipsecProtSuiteRemoteAddress' values from the protection suite entry of
interest, and do a search in the 'ipsecIkeSaTable' using the values
'ipsecIkeSaLocalIpAddress' and 'ipsecIkeSaPeerIpAddress', since that's where
the protection suite pairs (inbound and outbound) go to and come from.
Yes, it's ugly. That's why I had the concept of a phase 1 control channel in
the previous MIB document stream.
>
> > -- 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.
Interesting point. In this case though, the inbound and outbound protection
suites would then require separate entries, and it would the same as two
asymmetric uses of the table, as discussed in the document.
However, it makes me think that the definition of the source and destination
ports needs to be redone.
>
> > -- 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.
Yes, that sounds right.
>
> > -- 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.
The main reason was to make it the same as the attribute used. You make a
good point below about the size, though, if it is a basic attribute format.
>
> > ipsecProtSuiteTimeLimit OBJECT-TYPE
> > SYNTAX OCTET STRING (SIZE (4..255))
<snip>
> > ::= { 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.
>
<inconsistencies around key length and others discovered>
Good catches; I'll clean these up. I'll also add some DISPLAY-HINT clauses
to assist in presentation.
>
> > 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.
Okay. Consider it removed.
>
> > ipsecIkeSaEncAlg - Encryption Algorithm
> > DES40-CBC 65001
> > ipsecTunnelEspEncAlg
> > ESP_DES40 249
>
> Again. Do we need the Appendix A at all?
John Shriver has volunteered to write a MIB that will allow the display by
SNMP browsers of the meanings of all the integer values used. Its use will
make Appendix A unnecessary.
>
> Anyways it looks quite good now...
Thanks. At least it appears that we're discussing small things, rather than
the entire architecture.
> --
> kivinen@iki.fi Work : +358-9-4354 3218
> SSH Communications Security http://www.ssh.fi/
> SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
>
Follow-Ups: