Re: IKEv2 selectors for IPsec?
Francis Dupont <Francis.Dupont@enst-bretagne.fr> Tue, 01 July 2003 17:18 UTC
Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07313 for <ipsec-archive@lists.ietf.org>; Tue, 1 Jul 2003 13:18:34 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21049 Tue, 1 Jul 2003 10:35:17 -0400 (EDT)
Message-Id: <200307011441.h61Ef6of090764@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Charles Lynn <clynn@bbn.com>
cc: ipsec@lists.tislabs.com, ipsec-policy@vpnc.org
Subject: Re: IKEv2 selectors for IPsec?
In-reply-to: Your message of Thu, 26 Jun 2003 10:38:06 EDT. <20030626143806.880D316484@wolfe.bbn.com>
Date: Tue, 01 Jul 2003 16:41:06 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
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
- IKEv2 selectors for IPsec? Charles Lynn
- Re: IKEv2 selectors for IPsec? Scott G. Kelly
- Re: IKEv2 selectors for IPsec? Francis Dupont
- Re: IKEv2 selectors for IPsec? Francis Dupont