Subject: Re: IKEv2 selectors for IPsec?

From: Francis Dupont <[email-masked]>
Date: Tue, 01 Jul 2003 11:43:34 +0200

In your previous mail you wrote:

   What do folks think of making the IPsec (AH/ESP) protocol and SPI an
   IKEv2 selector?
   
=> I object for AH because it is an extension header.
I agree about ESP when the node is not the source or the destination,
i.e., ESP packets are "in transit"., cf. the "intermediate security
gateways" in the original message.
The SPI is the natural selector for (AH and) ESP.

   Its use gets into the area of dynamically created policy, e.g., when
   an end-to-end SA has to traverse intermediate security gateways. The
   question might be more appropriate for the IP Security Policy WG (is
   there any progress there or have folks lost interest?).

=> in this context ESP in a selector makes sense.

   A catch-22
   might be that AH is not currently treated as an "upper layer protocol",
   so the processing model might need to be extended a bit.
   
=> AH is *not* an upper layer protocol so this is at least very
problematic.

   That in turn leads to the question of whether folks see any advantage
   to having IPv6 extension headers -- fragmentation header, routing header,
   jumbogram, destination options (and maybe Option Type), be selectors.

=> I'll send a message to clarify these issues before we fall into
a two year discussion like the piggy-backing for Mobile IPv6 (on exactly
this issue BTW) one.

   One might argue that they are useful for filtering (access control) but
   not not useful as items that would select a policy action -- i.e., IPsec
   should use them but there is no need for IKEv2 negotiation.
   
=> IMHO we should *not* ask IPsec to perform the same kind of complex
things than a firewall. More in another message.

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Tue, 01 Jul 2003 16:41:06 +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