Re: IKEv2 selectors for IPsec?

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

IPv6 uses header chaining for extensions, IPv4 protocols are named
"next header types". Filtering is used for QoS classification,
firewall and IPsec. Standard filtering is done on the 5-tuple,
i.e., source and destination addresses, "upper layer/transport"
protocol, source and destination ports.
This raises a lot of issues:
 - what is a "upper layer/transport" protocol?
 - protocol specific selectors (in place of ports)?
 - how to get the tuple for packets in transit?

In IPv6, next header types are divided into 3 classes:
 - final protocols, i.e., protocols which don't include
   a next header field and are always at the end of the
   extension header chain. Note this is the default, i.e.,
   an unknown protocol is considered as final.
   Examples are UDP, TCP, OSPF, no-next-header (59),
   mobility header, etc.

 - extension header protocols which are always in a middle
   of the extension header chain and which have a next header
   field which gives the type of the following header.
   Predefined extension header protocols are hop-by-hop options
   header (0!), destination options header, routing header, fragment
   header, AH, ESP and IPCOMP.

 - encapsulation protocols which are at the end of the extension
   header chain but with a payload which is an IP packet.
   Examples are 4 (IPv4 over IP), 41 (IPv6 over IP), GRE,
   94, etc.

Some protocols like ICMP can carry an IP packet in some cases
(ICMP errors, ICMP redirect) but usually they are considered
as final for simple filtering, i.e., by everything at the
exception of some firewalls.
All final and considered as final protocols are "upper layer/transport"
protocols.

The second issue, protocol specific selectors, has to be solved per
protocols. Current transport protocols use ports. ICMP, IGMP, ICMPv6
can use the type/code pair which fits perfectly. The mobility header
of Mobile IPv6 can use the message type (consider this as an official
request).

Fragmentation, ESP or IPCOMP can hide the 5-tuple, to be more accurate:
 - the "upper layer/transport" header can be in another fragment than
   the first one, for instance this sequence is legal:
   1: <IPv6 header>, <fragment header for 0-7>, <empty destionation option>
   2: <IPv6 header>, <fragment header for 7-*>, <TCP header>, <payload>
   For an intermediate node, there are only three kinds of fragments,
   first, last and intermediate.
 - even if ESP can use the null cipher, an intermediate node has no
   way to know this, so the only visible thing in ESP is the SPI.
We have to distinguish between intermediate nodes, which are not supposed
to perform reassembly or to be able to look inside ESP payloads, and
end-nodes (original source or final destination), which have access to
the whole clear packet. Of course, an intermediate node which is
collocated with a firewall can get a part or all of end-node properties.

So when an extension header protocol is transparent (fragment, ESP
and IPCOMP for end-nodes, all others in any context) it should *not*
be considered as an "upper layer/transport" protocol just because
there is always another one in packets, and filtering over more than
one protocol is not simple. So AH and an extension header version of
the mobile header should not be considered as valid "upper layer /
transport" protocols.

The last case is encapsulation, including the hidden encapsulation
used by mobile IPv6 with the home address option and the routing
header of type 2 (cf. draft-deering-ipv6-encap-addr-deletion-00.txt).
Again the context, i.e., intermediate node or end node, is very important:
usually an encapsulation protocol is considered as final but in an
end node it can be associated with a virtual interface and filtering
can be applied to the outer header or to the inner header. For instance
in Mobile IPv6 the mobility entities work with inner headers, i.e.,
home addresses, and not with outer headers, i.e., care-of addresses.

Regards

Francis.Dupont@enst-bretagne.fr