first comments on draft-ietf-ipsec-mib-02.txt (no ifIndex/ifEntry)
John Shriver <jas@shiva.com> Thu, 12 November 1998 22:14 UTC
Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA25143 for ipsec-outgoing; Thu, 12 Nov 1998 17:14:09 -0500 (EST)
Date: Thu, 12 Nov 1998 17:33:06 -0500
Message-Id: <199811122233.RAA21729@brill.shiva.com>
From: John Shriver <jas@shiva.com>
To: ipsec@tis.com
Subject: first comments on draft-ietf-ipsec-mib-02.txt (no ifIndex/ifEntry)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
My first comment applies to section 4.1 of the document, which states: It should be noted that the MIBs here are not extensions of the Tunnel MIB [IPTun] or the Interface Group MIB [IGMIB]. That approach was rejected for a number of reasons, including: [...] o The virtual tunnels created by IPSec SAs are independent of other logical interfaces. This document takes the point of view that IPSec sits on top of IP. This perspective is used since IPSec adds additional protocol headers before the IP header. In this case, it may be conceptually viewed as a layer 4 protocol from the IP layer point of view. As such, the handling of IPSec secured packets by IP is independent of how IP is routed over the physical or logical layer 2 interfaces. That particular mapping is part of the purpose of the Tunnel MIB, and thus has no direct relationship on the IPSec virtual tunnels. This point is not true. Both RFC 1354 and RFC 2096 are not implementable if there is not an ifTable entry (ifEntry), and ifIndex value, for each "VPN" tunnel. The reason is that the variables (RFC 1354): ipForwardIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The ifIndex value which identifies the local interface through which the next hop of this route should be reached." DEFVAL { 0 } ::= { ipForwardEntry 5 } and (RFC 2096): ipCidrRouteIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex value which identifies the local interface through which the next hop of this route should be reached." DEFVAL { 0 } ::= { ipCidrRouteEntry 5 } have pointers to "interfaces" (real or virtual) indicated by ifIndex values. I certainly expect that we expect to run OSPF or RIPv2 over "VPN" tunnel interfaces. From the point of view of those protocols, and the IP forwarder, the tunnels are very much interfaces. (Yes, they are recursively on top of IP. But they are still virtual interfaces.) The same thing applies to L2TP, which is why I wanted that MIB oriented by ifIndex. Since [IPtun] is indexed by ifIndex, the fact that there may be many tunnels with the same IP addresses as endpoints will not cause "despair" to that MIB. I suppose another alternative is to have a table with values of InterfaceIndex syntax, but with values not found in ifTable. But, that would be rather ugly, and probably would be shot down as illegal from RFC 2233's point of view. It's really not conformant to the DESCRIPTION of InterfaceIndex. Yet another alternative would be to change the stynax of ipCidrRouteIfIndex from Integer32 to InterfaceIndexOrZero, and redefine it appropriately. But I think that would not be a legal modification to an exisint OBJECT-TYPE. Instead, it probably would have to be deprecated and replaced with a new one, which would stall that MIB's path along the Standards Track. (Thus: unlikely!)
- first comments on draft-ietf-ipsec-mib-02.txt (no… John Shriver