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

[Tero Kivinen <kivinen@iki.fi>]

Mark Duffy writes:
> >In your case you propably wouldn't have resources to encrypt all
> >non-first fragments, thus creating SA for non-first fragments isn't
> >a solution for you?
> 
> Not so.  I do not see encrypting all fragments as a problem at all.  I see 

I was thinking like the environment like syslog and NFS (both using
UDP), where almost all fragmented packets are NFS, and also causing
most of the traffic, but the sensetive packets are syslog, which might
also get fragmented in some cases. 

> mandating that security gateways buffer fragments until such time as they 
> can associate them with the initial fragment as a problem (for high 
> speed/capacity implementations).

The firewalls etc are already doing that on high-speed/capacity
implementations, so it is not impossible. The actual processing power
needed for the processing is low (one hash-table lookup per fragment
per fragmented packet). For non-fragmented packets it does not cause
any performance penalty.

For most of the fragmented packets do come in order, thus the extra
storage requirements can also kept quite low.

> Creating a separate SA for non-initial 
> fragments is acceptable to me, but I believe the wg has rejected this.

Yes.

> Like almost everything, this is a compromise between cost, performance, and 
> protection.  IMO the status quo from 2401 is ok for fragment 
> processing.

I think 2401 is silent about the issue, meaning that there will be
non-interoperable implementations, and I do not think that is
acceptable.

> AFAIK there have not been widespread complaints about it, 
> although others on this list would know much better than I.

I think the port selectors with tunnel mode are not used that much
that people would have noticed. 
-- 
kivinen@safenet-inc.com