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

[Mark Duffy <mduffy@quarrytech.com>]

At 11:36 AM 2/26/2004 +0200, Tero Kivinen wrote:
>Mark Duffy writes:
> > To respond more directly to your question, any situation that requires
> > per-port selector granularity at low speed/capacity may require the same
> > selector granularity at high speed/capacity if the data rate grows or if
> > IPsec is provided at a place in the network where traffic is more highly
> > aggregated.  If no one needs per port granularity, let's remove it from
> > 2401bis; if it is needed, then in some cases it will be needed with high
> > performance.
> >
> > One reason someone might want to encrypt only certain applications 
> would be
> > if IPsec implementations that do not run at wire rate are present in the
> > network and therefore encryption has to be rationed to the most
> > sensitive apps.
>
>Which means that you really would not like the case where the
>non-first fragments of that sensitive apps receive no protection at
>all are sent out in clear? Or all ICMP messages sent back quoting the
>packet are also sent in clear.

agreed

>If we ever are going to use tunnel mode IPsec with port selectors in
>the cases where different protocols gets different level of encryption
>we MUST put all the traffic associated with the flow (normal packets,
>first fragments, non-first fragments and ICMP messages) to SA having
>at least similar protection.

I'm not convinced that is a MUST.  One alternative is to leave this choice 
to the administrators.  I.e. if they want to protect the non-initial 
fragments, they do so via SPD rules that match them based on port selectors 
of "any" or "opaque".

>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 
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).  Creating a separate SA for non-initial 
fragments is acceptable to me, but I believe the wg has rejected this.

Like almost everything, this is a compromise between cost, performance, and 
protection.  IMO the status quo from 2401 is ok for fragment 
processing.  AFAIK there have not been widespread complaints about it, 
although others on this list would know much better than I.

Regards,
Mark