[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: first comments on draft-ietf-ipsec-mib-02.txt (no ifIndex/ifEntry)
OK, this rash of responses (glad to see the MIB finally merit
discussion!) opens some interesting issues.
First, I realize that I oversimplified. A Tunnel mode SA could be a
virtual interface in the ifTable. On the other hand, a transport mode
SA is not going to be an interface in the ifTable.
However, if there is a bi-directional tunnel-mode SA, there's no
reason that OSPF can't run across it. From OSPF's point of view, it's
a point-to-point link (between the SA endpoint) running un-numbered
(no IP addresses). Of course the OSPF packets will have to have
source IP addresses, these will be the router ID of the router on each
end. (The router ID has to be an address from inside the security
cloud.)
But, we have to consider the whole point of the Security Policy
Database. If the two "security gateways" have only one SA tunnel
between them, that carries all classes of traffic for all networks on
each side of those SG's, then that tunnel is an interface subject to
conventional routing via OSPF.
But, what happens when there are different tunnels, possibly with
different encryption transforms for different classes of traffic,
between the two SG's? IP routes don't get that specific, they are
only by IP address, but now the route is specific down to the protocol
and port level. Do you group these several SA's into a single virtual
interface from the point of view of routing? That's one approach, but
one too implementation-specific to codify in a MIB.
Perhaps we need to do the replacement for RFC 2096, which instead of
having CIDR routes, has routes indexed by all the possible keys of the
Security Policy Database.
Meanwhile, the issue of RFC 2096 is, of course, independent from OSPF,
it also has to export static routes.
As for running GRE over a tunnel mode SA, that's essentially blasting
a hole through the whole point of the Security Policy Database. Once
it allows IP protocol 47 (GRE) through, the SPD is rendered
ineffective.
So, back to the MIBs. Here's my conclusions related to this batch of
issues.
1. The IPsec MIB should allow a SA to be an interface, with an ifIndex
value, and an ifEntry in the ifTable. But we can't require this by
any means. So, it should be data in a table, with syntax
InterfaceNumberOrZero.
2. We could have a simple table that sparesely augments ifTable (or
more particularly, augments tunnelIfTable) for those SA tunnels that
are interfaces. It probably doesn't need any data other than a
pointer to the right entry or entries in the SA table. It would be
optional, only if tunnels are ever represented as interfaces.
3. We need to have a MIB that exports the "routes" to the granularity
of the Security Policy Database. (One might be wise to put this in a
MIB view accessible only from the inside of the VPN, but that's not a
MIB design issue.) If a MIB is to be useful in troubleshooting
problems, it has to allow you to determine the path of a packet,
including which tunnel it will go through.
References: