[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



At 10:43 PM 3/18/2004 +0200, Tero Kivinen wrote:
>Mark Duffy writes:
> > At 11:44 AM 3/18/2004 +0200, Tero Kivinen wrote:
> > > > I believe the 1% number is very low for IPsec packets, due to the
> > > frequency
> > > > of adding ESP to 1500 byte cleartext packets and then transmitting 
> the ESP
> > > > packets over ethernet.
> > >
> > >That fragmentation happens after IPsec, thus it not concern here. We
> > >are now talking about the packets arriving to the SGW which are
> > >already fragmented at that point. If PMTU etc works perfectly there
> > >should not ever be any TCP packets that are fragmented, and most of
> > >the UDP traffic is for small packets, with only exception of the NFS
> > >etc.
> >
> > That fragmentation can happen before IPsec, and is highly likely to in
> > high-speed implementations.
>
>I do not think ESP inside ESP it that common case, even in high-speed
>implementations. If the fragmentation is because of the ESP header
>being added, then it happens INSIDE SGW, thus the SGW will have the
>complete packet to base the policy decisions on. Actually SGW has
>already done the policy decision because it knows it is going to apply
>ESP on the packet.

I was not talking about ESP in ESP.  I was talking about this:

. SG receives large (e.g. 1500 B) plaintext packet.
. SG policy says encrypt.
. 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.

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

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.

--Mark