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

[Stephen Kent <kent@bbn.com>]

At 3:40 PM +0200 3/14/04, Markku Savela wrote:
>Before going into details, just to restate my view of how dealing with
>fragments should be stated in the RFC:
>
>1. The IPSEC that is applied to all fragments must be exactly the same
>    that would be applied to the same packet when fully assembled.

I agree that this would be ideal, but it would not be awful, from a 
communication security perspective, if we applied "better" protection 
to fragments. Yes, I realize that the protection suites might be a 
lattice vs. totally ordered, in principle, but in practice I think 
this is not like to be true.

>2. Implementaion can limit support for IPSEC on fragments to policies
>    that don't use port selectors.

We are in complete agreement on this point.

>Above simple and clear, and does not lead to very convoluted
>additional specifications.
>
>>  From: Stephen Kent <kent@bbn.com>
>
>>  >>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.
>
>We are supposed to define RFC. There is no room for hand wawing. For
>interoperability, you would need write RFC that exactly spells out the
>ordering rules, so that each implementation ends up picking the same
>one.

Well, since fragment reassembly will not always be possible at an 
intermediate point, and that was your proposal, I don't think it is 
"hand waving" to suggest an artificially imposed total ordering vs. 
assuming that all fragments will arrive at a specific SG.

>
>>  >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.
>
>This is not acceptable for security. Whatever you choose 60, 128 or
>more, it still leaves the hole open. And, eventually, if the payback
>is large enough, someone will invent a way to utilize it.

What hole? if I choose 128 bytes that I know definitively that no 
non-initial fragment can overwrite port fields, because the max IP 
header length is bounded and well short of this size.

Steve