Subject: Re: IKEv2 selectors for IPsec? (re-sent in ipsec-policy)

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Jul 2003 11:52:03 +0200

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

[email-masked]