Re: rfc2401bis and QoS selectors

[Stephen Kent <kent@bbn.com>]

>The recent -11 ikev2 draft introduced the notion of using
>non-negoiated selectors for packets (e.g. the TOS bits). The
>rfc2401bis draft does not currently contain wording to this
>effect. In face of the inevitable I would like to remind the list
>of the problems that will follow if IKEv1 would be used to
>negotiate these kinds of multiple tunnels (for differing traffic)
>with equivalent IKEv1 negotiated selectors.
>
>Recall things about IKEv1:
>- There is no mechanism for stating that a quick-mode negotiation
>   is to rekey an SA-pair.
>- Delete notifications are not mandatory.
>- Delete notifications are not reliable.
>
>This means that implementations must resort to heuristics in managing
>the SAD, especially wrt. rekeys. The trivial solution of "keep all
>SA's alive untill they expire or you receive an initial contact
>or delete notifications" is unfortunately not acceptable in
>circumstances where one must scale to large amounts of SA-pairs
>in embedded devices with limited resources for SA-pair state
>(if the above shortcomings are in effect).
>
>IF the architecture document will be updated with the
>QoS-selectors AND the rfc2401bis is not limited to IKEv2
>THEN I would hope that in the 2401bis the QoS selectors be
>limited to either static key management and dynamic key mgmt
>mechanisms, which provide at least reliable and mandatory delete
>notifications and mandatory rekey notifications (e.g. IKEv2).
>
>Lauri

Lauri,

2401bis has a number of features that depend on IKEv2 support, and I 
see this as another example of such a feature. So, I will make sure 
that we note that 2401bis assumes use of IKEv2 capabilities, or 
equivalent capabilities if a different key and SA management protocol 
is employed.

Steve