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

Re: Bruce Schneier on IPsec



Phil,

I'm puzzled by your commnets re the applicability of IPsec to the
protection of e-mail.  E-mail has ALWAYS been a staged delivery
application and that's why S/MIME and OPGP are appropriate protocols for
securing it.  This is a not a new issue and IPsec has never been
promoted as a substitute for e-mail security protocols. Yes, one can use
IPsec for point-to-point protection of e-mail, but that is not a primary
goal for this protocol.

On a broader note, I think that we may be forgetting that encryption,
per se, is probably not the most important feature of IPsec. Most IPsec
users, certainly in the commercial sector, are more at risk from
intrusions than from just passive wiretapping. Some amount of the
complexity of IPsec arises because it embodies access controls, applied
at both sender and receiver.  One cannot remove these controls from
IPsec without degrading the security they provide.  The reason is that
only within IPsec does a receiver know the SA with which the traffic is
associated, and thus what access control checks are appropriate for the
traffic exiting the SA.  Thus, for example, removing these controls from
IPsec (which have a lot to do with the differences in processing for
tunnel vs. transport mode) and putting a packet filtering firewall
behind an IPsec device does not provide the same access control capability.

Another issue that has come up is the utility of authentication only
services, either AH or auth-only ESP.  These modes of operation are not
present solely because of export controls.  For example, one might use a
tunnel SA with ESP from a mobile user to a security gateway at a
corporate site, then employ and authentication-only transport SA, nested
inside the tunnel, to get to a host on the corporate LAN.  The latter
use would allow a suitably configured firewall to examine the port
fields of the inner packet, an ability many system security
administrators may still require. 

Steve


References: