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

Re: Summary of transport mode use in overlay nets

Joe Touch wrote:
> 
>             Use of IPSEC Transport Mode for Virtual Networks
> 
> Abstract
> 
>    This document addresses the use of IPSEC to secure the virtual links
>    of an overlay network. It addresses how IPSEC tunnel mode can
>    conflict with dynamic routing in an overlay, due to the dependence of
>    both the security association (SA) and the IP tunnel encapsulation
>    header on the header of the incoming packet. An alternative is
>    proposed, where IP tunnel encapsulation occurs as a separate initial
>    step, followed by IPSEC transport mode on the result. The tunnel
>    header is determined by the source header, and the SA is determined
>    by the tunnel header. The result is consistent with dynamic routing
>    in the overlay. This document discusses this alternative, and its
>    impact on IPSEC.
> 
> --



Howdy,
	I'm not sure I understand your suggested flow of processing. So let me
try and phrase it in my words and you tell me what bits I've got wrong.
( This is not sarcasim, but is honest confusion resolution )



Inbound Processing:
	When you recieve a packet on an inbound interface, you do a policy DB
search for matching selectors. When you find a tunnel mode selector, you
apply the outter IP headers to the packet but do NOT yet apply any
security services to the packet. Instead, you do another policy DB
search for selectors which match this new outer header. Then finding a
transport mode selector, you apply those security services to the
packet. (implementors may search for efficiencies as long as they
achieve the above result)

Outbound Processing:
	A packet arrives out of a transport mode SA. You de-security service
the thing and do a policy lookup to find that, yes this matches your
transport policy. Now you have to have some type of indicator (which I
dont get yet) to let you know that you still have to decapsulate this
packet. After decapsulation, you do another policy lookup to see that
the inner packet matches a policy of yours, but you seem to have no SPI
to match it against now.

	Any clarifications would be appreciated.

-- 
  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903
Follow-Ups: References: