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

Re: Firewall "uniformity" issue



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