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

[Stephen Kent <kent@bbn.com>]

At 1:31 PM +0200 3/5/04, Markku Savela wrote:
>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

I assume an unstated part of this policy is that the S/D IP addresses 
are all the same, e.g.,  M and S and that the protocol is ANY or the 
same. also, only one port is cited above, so let's assume it is the 
destination port, since that is likely to be well known, whereas the 
source port is likely to be ANY. it's not clear why one would 
construct this policy, in practice, but it is legitimate in the 
abstract.

>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.

more precisely, all of the traffic between M and SG must be treated 
uniformly wrt ports, otherwise non-initial fragments cannot be 
assured the intended treatment. of course, one could also state that 
IF there were a total ordering on security, then affording 
non-initial fragments the most secure treatment would not "under 
protect" any traffic, although it might "over protect" it. so, the 
characterization above is not quite right.

>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).

but, as noted above, I could choose to map non-initial fragments to 
the ESP SA, if my concern were to not under protect any traffic.

>- 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.

this paragraph sounded OK until the last sentence, which then seems 
to be comparing the strategy to itself?

>- 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).

not clear that this is true.  there is a fragment reassembly overlap 
attack to worry about, but that could be addressed separately. if so, 
then it's not clear that allowing fragments through on an SA is bad, 
if they pass the non-port field selector checks, and if the initial 
fragment, when it arrives, passes all the selector checks.

>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.

see comment above.

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

each IPsec packet carries an SPI that maps it to an indicated SA, and 
the crypto checks will fail if it is mapped to the wrong SA. so the 
statement above is not correct.

>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).

see earlier comment.

>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?

see earlier comment.

>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.

I'm almost ready to send my analysis of the various issues, which 
hopefully will help clarify the arguments you have made above, as 
well as others. I agree that there is no magic bullet, but some 
details of your arguments here are not quite right.

Steve