Re: SAs that carry fragments Was: Re: Some IKEv2 issues

[Stephen Kent <kent@bbn.com>]

At 18:21 +0200 2/24/04, Markku Savela wrote:
>I'm still somewhat uneasy with this talk about doing IPSEC on
>fragments. Say we have a following setup:
>
>  H  <======> SG <-----> S
>
>    H is my host
>    SG is security gateway
>    S is some server behind the SG
>
>Normally my policy on H would express something like
>
>   Use tunneled IPSEC via SG using ESP (3des, sha1) for all
>   communication with server S.
>
>There are cases
>
>1. S replies with fragmented packets
>
>   1.1 SG reassembles the packet, applies IPSEC as required, and the
>     result gets fragmented again.

there has never been a requirement for an SG to do this, but it 
could, and the result would be indistinguishable from traffic from S 
that had not been fragmented.

>   1.2 SG does not reassemble packet, but applies IPSEC directly to the
>     fragments coming from S.

and, these IPsec protected packets MIGHT be fragmented later along the path

>
>2. S does not fragment packets, and sends them as whole.
>
>   2.1 SG applies IPSEC to packet and sends it out without
>     fragmentation (packet is still short enough to fit PMTU)

you didn't say for 1.1 above where the packet is fragmented. if the 
SG fragments it after applying IPsec, this is indistinguishable from 
later fragmentation between SH and H, so I assume this is why you 
didn't need to say which of these two cases occurred.

>
>   2.2 SG applies IPSEC, but the resulting packet needs to be
>     fragmented

really another example of 1.1

>
>---------
>
>The bothering thing is:
>
>The H must now be prepared to handle all combinations EQUALLY with
>the same dataflow
>
>   - full packets protected with IPSEC
>   - full IPSEC:ed packets fragmented
>   - fragments with IPSEC applied individually to them

but this has always been true.

>because host H cannot know what type of impelementation SG has
>(whether it reassembles packets from S before doing IPSEC or not).

I think this is irrelevant, for the reasons I cited above.

>If there are different SA's required for normal and fragment packets,
>the implementation must in worst case negotiate 4 SA's for each
>connection, to be prepared for all possible variants (fragment and
>non-fragment SA for each direction).

this is true, in the worst case, but the way you said it makes it 
sound even  worse, since there would already be 2 SA for each 
"connection."

>If the possibility of the fragments needs to noticed in the policy,
>all policies need to be duplicated: one for non-fragmented, and one
>for fragmented case.

I don't understand you reasoning here. if we were to specify an SA to 
carry non-initial fragments are to be carried on a separate SA 
between two IPsec peers, then that would add another SPD entry on a 
per-peer basis, but that is not the same as doubling the number of 
SPD entries.

>The fragments may not arrive in order. If the policy is dependent on
>specific ports, the recever must remember each applied SA on each
>fragment until the full packet is received and the policy can be
>checked.

not true for v4. this is just one possible implementation option. 
others have suggested that its OK to accept non-initial fragments 
over an SA so long as minimum offset checks are verified, to prevent 
overlapping reassmebly attacks.

>Some optimization is possible, like if two fragments belonging to the
>same packet are protected with different SA's, the whole packet is
>invalid, and receiver can stop processing the fragments of that
>packet. [Note: if fragments are protected with some different SA, then
>also the first fragment must use the same].

sorry, but I can't quite parse the sentences above.

>What if SA's expire between fragments? For example due to bytecount?
>Long fragmented packets eat up the replay window fast (I still use 32
>bits, need to upgrade I guess)?
>
>I would just forbid doing IPSEC on fragments, and require SG in above
>to do reassembly, if S fragmented the packet. The other option is to
>disallow port selectors with tunnel mode policies [and thus the policy
>could be checked on each fragment individually].

I think that the suggested solution to require reassembly by an SG is 
not viable, in general, e.g., because outbound fragments might arrive 
at two different SGs. In general, at the Ip layer, we discourage 
intermediate reassembly strategies because of this sort of potential 
problem.

Steve