Re: IKEv2 selectors for IPsec?

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

 In your previous mail you wrote:

   What do folks think of making the IPsec (AH/ESP) protocol and SPI an
   IKEv2 selector?
   
=> I object for AH because it is an extension header.
I agree about ESP when the node is not the source or the destination,
i.e., ESP packets are "in transit"., cf. the "intermediate security
gateways" in the original message.
The SPI is the natural selector for (AH and) ESP.

   Its use gets into the area of dynamically created policy, e.g., when
   an end-to-end SA has to traverse intermediate security gateways. The
   question might be more appropriate for the IP Security Policy WG (is
   there any progress there or have folks lost interest?).

=> in this context ESP in a selector makes sense.

   A catch-22
   might be that AH is not currently treated as an "upper layer protocol",
   so the processing model might need to be extended a bit.
   
=> AH is *not* an upper layer protocol so this is at least very
problematic.

   That in turn leads to the question of whether folks see any advantage
   to having IPv6 extension headers -- fragmentation header, routing header,
   jumbogram, destination options (and maybe Option Type), be selectors.

=> I'll send a message to clarify these issues before we fall into
a two year discussion like the piggy-backing for Mobile IPv6 (on exactly
this issue BTW) one.

   One might argue that they are useful for filtering (access control) but
   not not useful as items that would select a policy action -- i.e., IPsec
   should use them but there is no need for IKEv2 negotiation.
   
=> IMHO we should *not* ask IPsec to perform the same kind of complex
things than a firewall. More in another message.

Thanks

Francis.Dupont@enst-bretagne.fr