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

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

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.

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

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.

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