[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: IPSec Monitoring MIB works for IPv4 only?
> Wait, you lost me. Say that between 2 SGWs I have 3 tunnel-mode
> (protocol) SAs. Up until now, I would say I have 3 tunnels. If I had 2
> GRE tunnels in addition to these, I would say I have 5
> tunnels. If (for
> some reason) I also had a L2TP tunnel, then I would say I have 6
> tunnels. How many tunnels would you say I have? If your
> answer is not 6,
> please explain your reasoning.
The terminology is certainly confusing. Some would say that anytime there is
encapsulation (IP in IP, whether it be 4-in-4, 6-in-6, 4-in-6, 6-in-4) there
is a tunnel. Others would reserve the term tunnel for those situations where
encapsulation is used to create a virtual interface, and that interface
enjoys the same privileges as real physical interfaces (assign addresses to
it, routable, etc).
> into another issue which I think Markku has touched on, that
> being that
> the SAs in the kernel are really independent of ISAKMP, IKE, SKIP, or
> whatever you used to negotiate them. Hence, for an ipsec
> monitoring mib,
> maybe the definitions should also be independent of the SA/Key mgmt
> subsystems.
Yes!
> What I have been trying to express is that the mib should support any
> legal SA bundle as defined in the architecture document. My comments
> regarding rigid ordering, e.g. [AH][ESP][IPPCP], were based mostly on
> the fact that the architecture doc does not forbid other
> orderings, but
> rather does not mandate support for more than a few likely ones. This
> doesn't mean others are illegal, only that support for them is not
> required. So long as they are not illegal, it is somewhat
> probable that
> some other orderings will occur, in which case the mib would
> be broken.
> This bothers me (a little).
It bothers me a lot.
Rich