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

first comments on draft-ietf-ipsec-mib-02.txt (no ifIndex/ifEntry)

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!)