[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: more on ipsec-mib-02 - Phase 1 tunnels
---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: John Shriver [mailto:jas@shiva.com]
> Sent: Wednesday, November 18, 1998 1:54 PM
> To: ipsec@tis.com
> Cc: Tim Jenkins
> Subject: 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
> ----------------------------------
>
<snipped stuff on a text convention doc>
>
> Presumably the IPSEC-DOI-TC should be administered by the IANA, who
> also administers these DOI values. This eliminates the whole RFC
> process issue.
This sounds good to me. How do we go about getting it done?
>
> 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.
Agreed, but not to the IKE tunnel table; I've created a specific IKE SA
table to allow for multiple phase 1 SAs between two peers.
>
> 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.
The actual tunnel identifier is more correctly the tuple of the
authenticated IDs at each end of the tunnel. This will also be added.
>
> 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.
Fine.
>
> Normal Versus Agressive Mode
> ----------------------------
> More States
> -----------
> Who Initiated
> -------------
>
The states will be increased in detail and added to the IKE SAs themselves.
>
> 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.
>
Given that the MIB is read-only, I'm not sure this is very useful. Do I
mis-understand how this alias is used?
<snip>
Follow-Ups: