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

more on ipsec-mib-02 - Phase 1 tunnels

I've had a chance to digest the implications of the IKE Phase 1
tunnels part of ipsec-mib-02.  I'll try and structure this message
into parts.

DOI values and TEXTUAL-CONVENTIONS
----------------------------------

The first thing is how the various DOI variables are brought into the
MIB.  I think we should follow the example of using textual
conventions, defining them in a seperate document.  This was first
done for IANAifType-MIB, which is maintained by the IANA.

So, there should be an IPSEC-ISAKMP-DOI-TC MIB.  It would define
Textual Conventions for each of the DOI enumerations used by an IPSec
MIB.  This document would be revised with each revision of the DOI.
But, by being in a seperate document, the changes to it would not
reset the standards track progress of IPSEC-MIB (or IPSEC-IPV4-MIB and
IPSEC-IPV6-MIB).

For example (apologies for the long-winded name):

IANAipSecIsakmpDoiIkeSaAuthMethod ::= TEXTUAL-CONVENTION
	STATUS	current
	DESCRIPTION
		"These are the values of IKE Phase 1 Authentication
		method defined by the current IPSec DOI."
	SYNTAX	INTEGER {
			preSharedKey(1),
			dssSignatures(2),
			rsaSignatures(3),
			encryptionWithRsa(4),
			revisedEncryptionWithRsa(5)
		}

This has the enormous advantage to the network management user that
they see something intelligble as the value of ipsecIkeSaAuthMethod,
rather than a random integer.  Yet, we avoid the interlocking
revisions tendril.

Presumably the IPSEC-DOI-TC should be administered by the IANA, who
also administers these DOI values.  This eliminates the whole RFC
process issue.

Missing Local Address/Port in Phase 1 SA Table
----------------------------------------------

The Phase 1 SA table needs the local IP address and UDP port for the
Phase 1 SA.  How else can one possibly correlate these table entries
between the IPSec devices at each end of this SA?  There's no
guaruntee that the IPSec device has only one IP address.  Also, in
cases where IKE collisions have occured (without resolution), this
will be the only way to diagnose the situation.

So, add ipsecIkeSaLocalIPAddress and ipsecIkeSaLocalPortNumber.

Oh, both the port numbers should be described as UDP port numbers,
right?

Indexing of Phase 1 SA Table
----------------------------

Once we have the tuple that identifies an IKE Phase 1 SA
(ipsecIkeSaLocalIpAddress, ipsecIkeSaLocalPortNumber,
ipSecIkeSaPeerIpAddress, and ipsecIkeSaPeerPortNumber), we have the
true key to an IPSec IKE Phase 1 SA.  Thus, I'd propose that those
four variables form the INDEX.  (Well, at least for IPv4.  That
problem again!)

This is no more complicated an index than tcpConnTable.

Mapping Out Port 500
--------------------

I think it's gratuitous complexity to replace port 500 with 0.

What should be done is to have a DEFVAL of 500, if only to express
that, since it's really meaningless on a read-only variable.

Normal Versus Agressive Mode
----------------------------

There should be a variable in ipsecIkeSaTable that reflects whether
the phase 1 negotiation was done in normal versus aggressive mode.

More States
-----------

I think that ipsecIkeSaStatus needs another enumeration,
initializing(4).  There is a period during which the Phase 1 SA isn't
fully formed yet.

We can't add detailed states, since they are different for
everyipsecIkeSaAuthMethod, and they aren't named in IKE anyways.

Who Initiated
-------------

We need a variable ipsecIkeSeRole, with syntax INTEGER { intiator(1),
responder(2) }.  Otherwise how does one know which Cookie is which?

Human-Reable Names for Phase 1 SA's
-----------------------------------

I'd suggest that we follow the lead of RFC 2233 and predecessors, and
define a variable similar to ifAlias.  This is a string that can be
set by the manager to assign a human-readable name to thie Phase 1 SA.

UNITS
-----

A lot of variables need UNITS added.  For instance,
ipsedIkeSaIpsecInboundTraffic should say UNITS "bytes".  More
importantly, ipsecIkeSaTrafficLimit should say UNITS "Kbytes".  (Big
K, which is conventionally 1024.)

Similarly, ipsecIkeSaTimeLimit should say UNITS "seconds".  (I also
think it's syntax should probably be INTEGER(0..4294967295).  It
doesn't have Gauge behavior.)