Re: Firewall "uniformity" issue

[Erik Nordmark <erik.nordmark@sun.com>]

Iljitsch van Beijnum wrote:

> This is in line with my message from two days ago.
>
> Another firewalling issue is whether we put the initial shim header  in 
> a packet that also has payload, or if we give it its own packet.  In the 
> former case if a firewall drops the packet we've also lost  data which 
> is never good. On the other hand having the shim in a data  packet is 
> more efficient.

In many cases we want to separate the shim setup from the data traffic, 
so that we can avoid doing anything in the shim for short-lived 
communication.
Thus e.g., a TCP SYN exchange will happen independently of the shim 
exchange.

With such separation, when the shim on the host says "I've sent more 
than N packets to this destination, let's try to setup shim state now", 
what are the tradeoffs in terms of combining the shim setup packet and 
some data packet into one?

Of course, the data packet might already be MTU size, so it makes sense 
to not try when the shim setup packet doesn't fit.
IPsec policies on the host shouldn't matter, because IPsec gets applied 
above the shim.

But there could be IPsec SGs along the path, which want to use 
protocol/port number selectors and protected some traffic, which would 
not "see" the data packet when it is hidden inside/after a shim header.
And then there is the firewall issue you bring up.

If we assume we always have deferred shim context establishment, then 
the timeliness of the shim setup isn't critical, hence it makes sense to 
avoid penalizing the data traffic (with firewall-related loss, or 
differently protected by a SG). With this assumption I think it makes 
sense to not try to put the two in the same packet.

   Erik