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