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

[Mark Duffy <mduffy@quarrytech.com>]

At 01:54 AM 3/19/2004 +0200, Tero Kivinen wrote:
>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.

not necessarily the same SA, see below ("Yes, SG has...")


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

it could do another policy lookup for non-initial fragments.  That depends 
on how we (2401bis) end up deciding that fragments are to be handled.


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

I believe 2401 prohibited red-side fragmentation.  But the prohibition was 
a bit vacuous in the sense that from further downstream, red-side 
fragmentation by a SG is indistinguishable from fragmentation of the 
plaintext packets upstream of the SG.  2401bis serves to legitimize the 
practice.

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

I disagree.  Red side frag by the sender helps if the receiver checks the 
subsequent fragments on their own individual merits (with opaque port 
selectors).  And it even helps if the receiver will "reassemble" the 
fragments so it can determine the port selectors to use for non-initial 
fragments -- because as you yourself pointed out earlier in this thread for 
in-order fragments the receiver would only need to save the (src addr, dest 
addr, ident, SPI), not buffer nor actually reassemble the fragments.

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

That's great when it works, but often it doesn't e.g. ICMPs are dropped by 
firewalls, hosts don't do it right, etc.  Also AFAIK if the originator of 
the datagrams does not set the DF bit, the network is obliged to fragment, 
not discard and send icmp dest unreachable.


Tero, we've gotten a bit sidetracked today but I think we are basically 
coming from different positions on the fundamental question of whether a SG 
that wants to support fragments must either disallow port selectors or do 
reassembly, or is there a 3rd option to give the non-initial fragments 
different protection than the initial one.  I'd like to wait and see 
Steve's memo on this which it sounds like we will see soon.

--Mark