Re: 2nd try

[Stephen Kent <kent@bbn.com>]

At 6:06 PM +0200 3/23/04, Markku Savela wrote:
>Somewhat related to the "2nd try" text. I'm somewhat curious how
>implementations plan to handle this fragmentation issue:
>
>  (1) IPSEC must verify the policy of packets before they are given to
>  the reassembly, and

I don't think this is true if one chooses to support reassembly, or 
partial reassembly in IPsec. That process requires maintaining state 
on a per SA basis, and thus might be expected to be performed as part 
of SA- processing.

>  (2) IPSEC must ALSO verify the policy for the complete the packet
>  after it has been reassembled. This is the normal case where IPSEC is
>  applied to complete packet and the result fragmented (IPSEC can be
>  done only after reassembly).

this sounds like reassembly on the ciphertext/unprotected side of an 
IPsec receiver, a very different case from what we have been 
discussing.

>
>
>            TCP/IP
>    ------> Fragment  ---->
>      (1)   Assembly   (2)
>     IPSEC            IPSEC
>     Policy           Policy
>     Check            Check
>
>"2nd try" text relates to (1) IPSEC. How does the (2) IPSEC know that
>a complete packet coming out of fragment assembly is has been checked
>or not? (The packet looks like plain unprotected packet, which by all
>normal rules should be dropped, if policy required it to be
>protected).
>
>To work, IPSEC must be able to associate some additional information
>with the packet in the assembly?

this seems to assume a particular implementation approach, and is 
analogous to the issue we have discussed previously, i.e., performing 
firewall checks outside of the IPsec context requires access to SA 
info that would not normally be available at that point.

Steve