Re: IKE negotiation for ICMP message type selectors

[Charles Lynn <clynn@bbn.com>]

Folks,

> For example, we've had discussion on the list about using ICMP 
> message type fields in lieu of port fields, when ICMP was the payload.

I agree that the type and code fields need to be selectors.

The next question is whether there needs to be "sub-selectors" for the
fields a packet that, e.g., caused an error.  I think that this issue
is related to whether ICMP messages MUST/SHOULD/MAY be sent in the SA
of the packet that caused the error, or whether the ICMP should cause
its own SA to be created.  (If the answer is MUST in the SA of the
packet that caused the error, then the selectors are "implicit"; if
there MUST be a separate SA, then, I think, IKE would have to make
them explicit.  Do folks agree?)  If the answer is SHOULD/MAY, then
I think that the sub-selectors would be needed.

What do the folks who have said "agree" to ICMP type and code think?


itojun commented...
>  we will need to do this every time new protocol becomes available.
>  i guess we should make the concept of "selector" more generic.
>  (for KAME implementation i'm thinking of switching to BPF-based policy)

I agree that some extensible mechanism is needed.  Selectors form a tree
(or maybe lattice if one wants to simplify "reuse"). I do not think that
this is a problem that the current IPsec working group will have as a
work item, and not before IKEv2 advances.  Obvious issues are "complexity"
of the packet parsing/description language (of which BPF is an example),
and whether the concept or implementations introduce unacceptable risks.

Charlie