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

[Stephen Kent <kent@bbn.com>]

At 12:16 AM +0200 3/13/04, Markku Savela wrote:
>  > From: Stephen Kent <kent@bbn.com>
>>  At 1:31 PM +0200 3/5/04, Markku Savela wrote:
>
>>  >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.
>>
>>  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.
>
>>From a set of ESP and AH choices, how do you order them? Which ESP is
>better protection over another ESP? Is AH better than ESP without
>authentication?

didn't you note my comment above re IF you could totally order? 
Frankly, I think that in practise this is possible, even though it is 
not in principle.

>
>>  >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.
>
>Yes, but at least my current implementation rejects packets that are
>protected validly with ESP or AH, but policy calls for no protection
>(or if policy calls for different protection).

that's an interesting "feature." I can understand why you might 
choose to do that, e.g., for fault detection and isolation, but I'm 
not sure it is needed from a security perspective.

>
>>  >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.
>
>Yes, but it must hold clear packets, until it knows their ports. If it
>lets a non initial clear packets (no SPI, just plain data, it might be
>port=A), through to packet assembly, an attacker can create the
>following assembled packet:
>
>     ================== attack data from clear packets
>   **                   data from real ESP protected packet
>
>If the attack data comes before the ESP packet(s), only the still
>missing parts in the assembly are filled from the protected data (and
>this could be as little as the TCP header -- the first attack content
>can begin at the payload offset 8).
>

in the case of v4, it is possible for a receiver to perform a simple 
sanity check on offset values to reject this sort of attack. since 
the PMTU min for v4 is 576, and since the max header size is 60 
bytes, one could adopt a conservative value such as 128 for the 
offset in a non-initial fragment, and prevent reassembly attacks. 
this check can be applied to all non-initial fragments, whether they 
arrive via an SA or as bypass traffic.

Steve