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

Re: IPSEC tunnels for LAN-to-LAN interop issue



I don't know if I made myself clearer on this subject earlier.

If you _insist_ on using OSPF and/or RIP, you _can_ do the right thing with a
tunneling interface.  There is a price.

That price is that your tunneling interface will have to play an active role
in enforcing IPsec policy.  Let's first consider a transport-mode IPsec
implementation that enforces policy on a combination of "socket state" and
systemwide policy.

An inbound IP processing path would look like:

	* Get packet.
	* Process IPsec headers, remove IPsec headers, annotate packet with
	  IPsec protection applied to this packet.
	* When ready to deliver to destination upper-layer (e.g. TCP),
	  inspect annoatated packet against upper-layer's socket state and/or
	  systemwide policy.  Drop packet if it fails, or allow packet to
	  pass if it succeeds.

An outbound IP processing path would look like:

	* Get packet from upper-layer.
	* Annotate packet with what socket state and systemwide policy
	  require for this packet.
	* Select route, etc.
	* Based on annotations, apply IPsec.
	* Fragment packet.
	* Transmit packet.

Now a tunnel that doesn't apply full tunnel mode selectors (which has been
called Transport Mode IP-in-IP in this thread) can use the above
infrastructure with out any change.

What isn't obvious in the above is that TCP may not have full "socket state"
for detached or closing connections.  In that situation, the inbound
processing path now looks like (WITH CHANGES IN CAPS):

	* Get packet.
	* Process IPsec headers, remove IPsec headers, annotate packet with
	  IPsec protection applied to this packet.
	* When ready to deliver to destination upper-layer (e.g. TCP),
	  inspect annoatated packet against upper-layer's socket state and/or
	  systemwide policy.  Drop packet if it fails, or allow packet to
	  pass if it succeeds OR IF THE UPPER LAYER NEEDS TO FURTHER CHECK
	  THE ANNOTATIONS.

The outbound processing path now looks like (WITH CHANGES IN ALL CAPS):

	* Get packet from upper-layer.  THE PACKET MAY ALREADY BE ANNOTATED.
	* IF NOT ALREADY ANNOTATED, annotate packet with what socket state
	  and systemwide policy require for this packet.
	* Select route, etc.
	* Based on annotations, apply IPsec.
	* Fragment packet.
	* Transmit packet.

So with those required-for-TCP changes in place, why not allow the IP-in-IP
upper-layer to pre-annotate outbound packets based on inside packet
information, and why not also allow the IP-in-IP upper-layer to enforce
inbound policy based on further information.  TCP already has to do it for
detached connections, so why not your tunnel "driver"?

It's not rocket science, folks.  It's labor-intensive (how much so depends on
your implementation), and your SPD gets distributed, but it's not tough.

Hope this helps,
Dan


References: