Re: IKE negotiation for ICMP message type selectors

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   > 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

=> far too complex. IMHO this is like trying to extend selectors
to encapsulated traffic: reasonable for a firewall *only*.

   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?
   
=> add me in the list (in case some people disagree :-)

   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.
   
=> OpenBSD has an unified filtering/classifying stuff which can (should!)
be used for QoS (aka ALTQ), IPsec and firewall.

Regards

Francis.Dupont@enst-bretagne.fr