[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On transport-level policy enforcement (was Re: RFC 2401...)
I've been watching the transport vs. tunnel debate silently. For the record,
I'm in (almost?) full agreement with Joe Touch that "tunnel mode" can be
better implemented (and should be treated) as a special case of transport
mode. I'll now try and explain how I arrived here through experiences of two
(NRL and Solaris) IPsec implementations.
To allow for the best policy matching speed, you really shouldn't check
against the global SPD for each packet. What you should do is cache the
relevant SPD rules in the per-session state. When you select the appropriate
session(s) for a datagram, you compare the inbound IPsec processing on the
packet against what the rule is for this session. On outbound data, you use
the originating session state to guide the outbound packet through the
appropriate IPsec processing.
In Solaris, the SPD rule is cached in the "IP client" state, which
corresponds to an open socket or TLI/XTI descriptor. In BSD, this is in the
inpcb state, or perhaps socket state. (Any KAME folks want to clue me in on
the current practice?) When you change the global SPD, you must update the
per-socket caches _if_ you aren't following a latching policy. (Latching is
an implementation decision that keeps TCP retransmission bookkeeping from
exploding out-of-control. My very old IPsec API has reasoning for this, as
does C. Metz's not-quite-as-old API draft.)
Sometimes a transport layer still has to process per-session state even after
the session is gone. TCP connections in FIN_WAIT_* state are a fine example
of this. Because of this, TCP has to be able to ask the IPsec SPD about a
packet, or cache SPD rules itself.
Since TCP is doing this anyway... and if we consider tunneling to be just
another upper-layer protocol, perhaps our tunneling "session" can always ask
the SPD for rules? Or perhaps it can do what is currently defined in 2401 as
"tunnel mode processing" with respect to security checking. This way, we
keep the complexity (acknowleged by many as the enemy of security) out of the
common IP path and in the tunnel-specific code.
Leaving out breaking NAT (or NAT being broken), transport mode is better for
end-to-end encryption of packets because of MTU and redundant (Do the headers
match? If not, how do I handle the differences?) packet checking issues.
Francis and Itojun have made these arguments already. It also allows a
cleaner separation of policy and mechanism - AH and ESP are the mechanisms of
IPsec, not IP in IP. I believe this is Joe's point.
My own implementation experiences lean toward transport mode as the preferred
way of doing business, because I enforce policy further away from IPsec
header processing than perhaps others do.
Dan
Follow-Ups: