[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