Re: Traffic selectors, fragments, ICMP messages and security policy problems

[Markku Savela <msa@burp.tkv.asdf.org>]

I've been thinking about this a bit more, and my conclusion is:

If
	you want to apply IPSEC on fragments,
and
	you want to use port selectors
then
	There is no way out of it: then at least one of the IPSEC
	implementations MUST buffer ALL fragments before it can
	release any packets to the stacks fragment assembly.

Consider mobile node M communicating with server S behing the security
gateway SG. Assume S fragments some data going towards M, and assume
there is a port specific policy:

  PORT=A, send in clear
  PORT=B, use ESP
  PORT=C, use AH

 M <==== IPSEC ====> SG <---> S

First SG: It has been said it is not acceptable to require SG to do
packet assembly before the IPSEC. If so, then NONE of the selectors
affecting the M <-> SG traffic can have port selectors.

If you have port selectors, you cannot let the packets through until
you see the first fragment. (You don't know whether port is A or
B).

- one argument against SG doing the assembly has been: not all
  fragments may arrive to the same SG. Only one of the SG's sees the
  first fragment. => The other can never do the correct thing and
  fragments are dropped after some timeout or until buffer space runs
  out. Communication fails randomly, exactly the same way as if SG's
  were required to assemble packets.

- because there is no ordering requirements for fragments, the SG must
  be prepared to buffer all fragments. It might as well do packet
  assembly. (Linux sends the first fragment as last!)

Second M: When receiving fragments protected with ESP from SG, the
IPSEC MUST buffer and hold all fragments until it receives the first
fragment. Only then it can check whether the port was A (if port is
not A, the packet must be dropped, even if the ESP transformation
succeeded).

After receiving the first fragment, IPSEC can release the buffered
fragments to the fragment assebly of the IP stack. However, it needs
to remember the port state to be able to check any remaining
fragments. How long it needs to keep this state? Might be just easier
to do the assembly in IPSEC, to be sure.

IPSEC on M must also hold all clear fragments in similar way, until it
knows what IPSEC was to be applied.

Additional consideration: the fragments will have SRC=S, DST=M. IPSEC
must buffer those too, until it knows the port. It cannot let them
through, because someone could send fake fragments to poison the
stacks fragment assembly (and place some attack data into supposedly
secured communication using port B or C).

So, if SG allows IPSEC on fragments, then IPSEC on M needs to be
prepared to buffer full packet. It has to implement same safeguards
against dos attacks as the standard fragment assembly. An attacker may
find some holes by forcing IPSEC to forget some state, and then
sending some tailored fake fragments?

I guess, supporting port selectors and IPSEC on fragments is possible,
but it's lot of work and requires almost full replication of the
fragment assemble within IPSEC. It might be hard to make the thing
actually secure against attacks.

Conclusion: Do not allow port selectors and IPSEC on fragments at same
time. Then, the buffering requirements disappear and it is possible to
check security of each packet and fragment alone.