rfc2401bis and QoS selectors

[Lauri Tarkkala <ltarkkal@ssh.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 Tarkkala
SSH Communications Security Corp
http://www.ssh.com/