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

Re: ipsec vs. firewalls





I guess another solution is through policy definitions.  A security policy
definition that says you can use ESP through the firewall to the outside world
should be accompanied by an entry that allows the firewall to let the packets
through.  Since the firewall is doing essentially an unnatural act of looking
at bits it ought not to (TCP header), the policy definition relieves the
firewall of its guilt.  It does sound like the policy based networking solution
involves a lot of configuration, though.  I suppose it is part of the tighter
security or **control** the network administrator can enforce.

What do people think about providing this level of configuration as well as
this level of control to the network administrator, as opposed to "figuring out
security policy on the fly?"

Vach Kompella
IBM Corp.
Network Security Product Development
kompella@us.ibm.com
Ph.: (919) 254-7281
Fax: (919) 254-4239





owner-ipsec@ex.tis.com on 05/07/98 02:30:00 AM
Please respond to owner-ipsec@ex.tis.com
To: ipsec@tis.com
cc:
Subject: ipsec vs. firewalls


I came up with a disturbing conflict between ubiquitous IPSEC and
common firewall policies.  I'm not certain how to resolve it,
either.

A common firewall policy permits most outgoing calls.  (The
requirement to authenticate such calls, say via AH from the inside
host to the firewall, wouldn't affect what comes next.)  Suppose,
though, that the inside host wants to use ESP for end-to-end
encryption to the destination.  How will the firewall inspect the
return packet?

To implement that firewall policy, the return packet *must* be a
reply to the outbound packet -- say, the SYN+ACK in response to
the SYN.  But if it's encrypted, there's no way to tell; it could
be a probe from the outside host to some vulnerable ports on the
inside client machine.

There are a number of possible solutions; each has its limitations.

The most obvious, of course, is to prohibit end-to-end encryption,
and require that all packets be decrypted at the firewall.  Apart
from the obvious security risks, this complicates the topology
discovery process.

Another pretty good solution is per-connection keying.  But that
only works if the firewall *knows* that the inside machines will
indeed enforce that, and drop packets to different ports than are
bound to the SPI.

A third solution is to use some sort of auxiliary header with
cleartext port numbers, similar to that suggested by Greg Minshall.
Again, the firewall would have to *know* that hosts would drop
packets where the outer and inner port numbers didn't match.
Furthermore, in both this case and the previous one, all the firewall
knows is the packet direction; SYN, ACK, and FIN bits are still
invisible.  (Well, we could expose more of the TCP header.)  This
reduces the ability of a dynamic firewall to handle TCP to its
ability to handle UDP.

Fourth, we could restrict end-to-end encryption to trusted outside
hosts, and in particular to machines that comprise the VPN.
Obviously, this works against general use of encryption.

Finally, I suspect that some people will regard anything that
cripples firewalls as a feature.  With all due respect, I tend
to differ...

I'm not suggesting any changes to anything at this point.  I do
suggest that IPSEC vendors -- including IPSEC implementations that
will live on firewalls -- work towards per-connection keying.