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

[Tero Kivinen <kivinen@iki.fi>]

Mark Duffy writes:
> . SG receives large (e.g. 1500 B) plaintext packet.
> . SG policy says encrypt.

And at that point SG policy also says, that use this SA for the
traffic I assume?

> . Path MTU from SG to remote SG is known to be 1500 B.
> . SG does "red-side" fragmentation (of plaintext pkt) to avoid need to 
> reassemble at remote SG
> . SG encrypts each fragment.

using the SA selected earlier, which means that each fragment will be
sent inside the same SA as I proposed.

Do you propose that SG should do second policy lookup at that point,
to find out how to send the fragments?

> . Yes, SG has the complete packet and *could* use the port selectors to 
> find the policy to use for all fragments.  But since the receiver (assuming 
> it does not do the pseudo-reassemble) will evaluate the SPD for non-initial 
> fragments with opaque ports, the sender should do so too.  That way the 
> sender and receiver are treating the non-initial fragments the same.  I 
> believe this is the behavior RFC 2401 calls for in sect. 4.4.2.

Wasn't the red-side fragmentation forbidden in the RFC2401? I think it
was added only in rfc2401bis, or do I remember incorrectly? At least
we have issue 88 that seems to change the rfc2401bis so that it allows
red-side fragmentation.

Actually red-side fragmentation seems to be only usefull if the
responder does not care about checking the non-first fragments. If the
responder still wants to verify that all fragments match the policy,
then red-side fragmentation does not help. 

> My point here is still that the percentage of packets at the receiving SG 
> that are fragments may be substantial, since the fragmentation is a direct 
> result of the IPsec overhead.

The better option would be implement proper path MTU discovery in the
SG, i.e. send packet too big with suitable smaller mtu to the sender. 
-- 
kivinen@safenet-inc.com