[saag] IPsec spec problems

[Tero Kivinen <kivinen at iki.fi>]

Pekka Savola writes:
> I actually read RFC 4301 for the first time on a plane (for the 
> record, I had not read any IPsec RFCs previously).  The situation was 
> much worse than I thought.  One could say that the IPsec spec is not 
> optimized for control plane protection with all of its crazy talk 
> about protected/unprotected interfaces, non-native implementations, 
> etc.

The architecture document describes all possible ways you could use
IPsec in various different places. For the control plane prorection
you should concentrate on the host-to-host case, i.e. transport mode
cases.

Router protecting traffic originating to/from itself is considered as
host in that case not as security gateway. I.e. see section 4.1 where
it says

    o Where traffic is destined for a security gateway, e.g., Simple
      Network Management Protocol (SNMP) commands, the security gateway
      is acting as a host and transport mode is allowed.  In this case,
      the SA terminates at a host (management) function within a
      security gateway and thus merits different treatment.

> My perception is that IPsec spec tries to address too many problems 
> (minimal firewall policing through SPDs; control traffic protection; 
> VPN protection), and the result is too complex that it isn't useful 
> for anything except VPNs, and even that's pretty complicated due to 
> all the baggage.

If you only implement control plane protection, i.e. host to host
IPsec with transport mode, there is things you do not have to
implement. If you want to combine both control plane protection (host
to host IPsec) and security gateway features (i.e. VPN usage) then you
need to implement more of the architecture described in the rfc4301.

> I was also boggled by the notion that an IPsec implementation at a 
> router would have to inspect ALL packets it forwards (whether IPsec or 
> not) against SPD.  That means IPsec would need to be implemented on 
> all the linecards even if all you wanted is to protect the control 
> plane.
> 
> Saner alternative: whether to look for SPDs for particular packet 
> should be keyed off from the routing table entries. That way IPsec is 
> only consulted when it needs to be consulted.

There is no reason why the SPD cannot be combined with the routing
table as you described above. The SAD/SPD etc are used to describe how
the system looks from the outside. The internal implementation can be
completely different provided that to the outsider it can offer
similar properties than the model described in the architecture
document.

I.e. it is completely ok to implement the SPD DISCARD rules in IP
firewall module, which supports required actions, i.e. has at least
the mandatory selectors and allows you to drop packets based on that.
Same thing with BYPASS. There are some complications as the SPD is
ordered but those can be taken care of for example by using
decorrelation.

Important thing about the RFC4301 is:

   The model described below is nominal; implementations need not
   match details of this model as presented, but the external behavior
   of implementations MUST correspond to the externally observable
   characteristics of this model in order to be compliant.
-- 
kivinen at safenet-inc.com