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

[Tero Kivinen <kivinen@iki.fi>]

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 repeat, that fragmentation is not in question here.

> And PMTU discovery does not work perfectly.

I read one of those articles
(http://www.caida.org/outreach/papers/2002/Frag/) found from the
http://www.caida.org/, and it said the fragmentation is about 0.2-0.8
% of the packets and around 0.6%-1.6% of bytes in the core network.

89% of the fragmented packets arrived in order and ware complete. 7.8%
arrived in the reverse order, and 1.6% had some out of order
fragments. That leaves 1.6% of fragmented packets in state which could
not be reassembled (and which might be missing the first fragment).

They also assumed 15 seconds for reassembly timeout, I used 64 seconds
in my previous calculations, thus my calculations ware 4 times too
big. 

There was also very little TCP fragmentation (1.6% of bytes in
fragmented packets, meaning around 0.03% of total traffic), most of
the fragments was because UDP (72% of fragmented bytes), ICMP (12% of
fragmented bytes) etc.

Those numbers will be different when checking the traffic inside the
VPN, but I do not think the number of fragments are going to change
that much, unless you run NFS over UDP over the VPN.

Those numbers can be used to calculate the good sizes for the
reassembly queues etc, so that it works fine under normal load.

> I agree with your statement here in a general sense and indeed that is how 
> many things work.  But here there are several options on the table that 
> would allow the protocol to be *more* resistant to attack, such that 
> legitimate fragments do not suffer as a result of such an attack.  (The 
> options I mean are the approaches that do not call for an IPsec 
> implementation to "reassemble" fragmented packets.)

Yes, if we drop all fragments, then legitimate fragments does not even
notice if there is attack going on or not :-)

Note, that if there is any attacks using fragments, then that attack
is coming from the inside of the VPN, thus you might have other
problems in that case too.

> I can accept an approach where a SG can do either port-selectors or 
> fragments.

I agree that. We shouldn't make the fragmentation processing with port
selectors MUST, you can simply not support port-selectors or not
support fragments, but if you implement then both, I think we want it
to have identical security properties than normal traffic. 

> However, I would prefer to do both, without reassembly.  This 
> could be accomplished by several means that have been discussed on this 
> list including having a separate SA for fragments, or allowing non-initial 
> fragments to be sent under a different policy entry than other packets 
> (e.g. one with port selectors of "opaque".)

I.e. you propose using different policy for parts of the traffic. I
consider that a security hole. 
-- 
kivinen@safenet-inc.com