[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary of transport mode use in overlay nets
FWIW - the ID is now on-line at the usual places.
Ricky Charlet wrote:
>
> Joe Touch wrote:
> >
> > Use of IPSEC Transport Mode for Virtual Networks
...
> > --
>
> 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 )
The terminology below is a little swapped from what I'm familiar with;
in our ID (and in the IPsec arch doc), inbound = into the host/gateway,
outbound = leaving.
> 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 -
when we send a packet on an outbound ...
1. we don't use IPsec for IPIP encapsulation. We use 'conventional'
tunnels, e.g., gif on FreeBSD + KAME
2. as a result of (1), we don't do any policy DB search on the outgoing
packet itself; first, we IPIP encapsulate, THEN the packet goes
back through IP packet processing. This time, it matches the policy
DB,
and IPSEC occurs.
That's the main point - we do IPIP encapsulation based on routing
rules,
and AFTER THAT do IPSEC on the resulting encapsulated packet.
> 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.
Inbound -
a packet arrives. here there are two options:
A. the receiver can use a tunnel-mode SA
in which case, all the security of tunnel-mode SA receiver processing
is available, including checks of the header of the inner packet. This
has been tested in FreeBSD 3.4 with KAME IPSEC. We're not sure if other
stacks behave identically, but we can find nothing in the tunnel-mode
spec that indicates they should do otherwise.
B. the receiver can use a transport-mode SA, followed by IPIP
decapsulation as a separate step
far as we can determine, the IPSEC Arch document indicates that
packets, once de-transport-IPSEC'd, are supposed to carry a tag
indicated "yes, this packet has already been through this site's IPSEC,
and here is the SA that worked". The IPIP decapsulation can potentially
check this during decapsulation. I.e., the idea behind retaining the SA
with the packet is so subsequent processing can check the SA and do
additional processing if needed. While we're not sure how/if/whether
this is implemented, or how to activate it if so, it seems moot since we
can already use (A).
We hope this helps clarify things...
Joe (and Lars)
References: