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

Re: ICMP messages and per-port selectors



At 10:07 +0100 2/26/04, Jean-Jacques Puig wrote:

	<SNIP>
>
>  > We're not guaranteed
>>  that the 64-bytes we get with an IPv4 ICMP message will have porty
>>  fields, for example, so it is not always as easy as reversing the
>>  addresses and ports to match against an extant SA.
>
>Can you give an example of these 64 BITS not carrying the adequate
>information for upper layer selectors check ? Note that non-initial
>fragments are not allowed in ICMP errors, and that the original data
>should be *at least* 64 bits (as for rfc1122).

I was thinking about the added IPsec header, and ICMP messages 
returned via an intermediate gateway (not over an SA). in those cases 
we will not have access to the protocol or the port fields.  but for 
an ICMP arriving via an SA, we should get the necessary info.

the issue here is one of relative performance impacts for ICMP 
traffic sent or received via an SA. if we don't have a separate SA 
for such traffic, then I'm not sure we need to add selectors for ICMP 
type/code values, but we do find ourselves having to afford special 
treatment for ICMP traffic both on transmission and reception, if we 
don't segregate this traffic.

we have to look at tghe ICMP payload, retrieve addresses and ports 
and flip them, and use these values plus the protocol to locate the 
right SA for outbound traffic. if we have an ICMP SA, then we don't 
have to do that work. we have to do the same sort of work if one of 
these packets arrives via a non-ICMP SA, to see if the ICMP payload 
is right for the SA via which it was received. If we have an 
ICMP-specific SA, then the first pass checks are not special, and the 
slow path processing takes place after these checks are completed. 
So, it would seem that use of a dedicated ICMP SA makes transmission 
easier, but reception processing is complex in both cases. it may be 
very implementation specific as to whether its easier on steady state 
processing to segregate the ICMP traffic on its own SA, vs. having 
every SA be prepared to forward such traffic to an ICMP process.

Michael suggested it was a toss up because one would have to hand off 
packets that failed inbound SA checks for auditing. 2401 does says 
that this is an auditable event, and suggests minimum data for an 
audit log. I have a question for implementors: do you audit inbound 
packets packets that are discarded due to SA check failures, and if 
so is the audit log entry one that captures packet data (vs. just 
adding 1 to the "received bad packet via this SA" counter?

Steve