Subject: IKE negotiation for ICMP message type selectors

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Jun 2003 19:43:45 -0400

One last selector negotiation suggestion:

We ought to decide now if there are other fields we want to specify 
as selectors AND that need to be negotiated (unlike the DiffServ 
bits). For example, we've had discussion on the list about using ICMP 
message type fields in lieu of port fields, when ICMP was the payload.

What do people think, and why?

Steve

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 25 Jun 2003 20:59:40 -0400

> For example, we've had discussion on the list about using ICMP 

Long overdue.  

Particularly important for IKE and IPv6 (as, pending introduction of
some facility to secure Neighbor Discovery) you likely want ND traffic
in clear while other ICMPv6 traffic is protected.

					- Bill

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jun 2003 19:12:35 -0700

> in clear while other ICMPv6 traffic is protected.

agree.

infact Mobile IPv6 makes use of ICMP messages to convey 
to the mobile node changes in the set of IPv6 prefixes
advertised on the home link. we use ESP in transport mode
betwen the Home Agent and the mobile node for protecting
these messages. since IPsec does not look at the ICMP type, 
it ends up protecting all ICMP messages between the mobile 
node and the Home Agent.

and I believe ICMP can be used for lot more than just
error messages. a lot of protocols can make use of ICMP
for signaling. so, it would be great if IPsec looks at the
ICMP type field.

Vijay

---

From: [email-masked]
Date: Thu, 26 Jun 2003 11:53:13 +0900

>in clear while other ICMPv6 traffic is protected.

	we will need to do this every time new protocol becomes available.
	i guess we should make the concept of "selector" more generic.
	(for KAME implementation i'm thinking of switching to BPF-based policy)

itojun

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Jun 2003 08:35:39 +0300

> in clear while other ICMPv6 traffic is protected.

I agree.

--Jari

---

From: Charles Lynn <[email-masked]>
Date: Thu, 26 Jun 2003 10:18:10 -0400 (EDT)

Folks,

> message type fields in lieu of port fields, when ICMP was the payload.

I agree that the type and code fields need to be selectors.

The next question is whether there needs to be "sub-selectors" for the
fields a packet that, e.g., caused an error.  I think that this issue
is related to whether ICMP messages MUST/SHOULD/MAY be sent in the SA
of the packet that caused the error, or whether the ICMP should cause
its own SA to be created.  (If the answer is MUST in the SA of the
packet that caused the error, then the selectors are "implicit"; if
there MUST be a separate SA, then, I think, IKE would have to make
them explicit.  Do folks agree?)  If the answer is SHOULD/MAY, then
I think that the sub-selectors would be needed.

What do the folks who have said "agree" to ICMP type and code think?

itojun commented...
>  (for KAME implementation i'm thinking of switching to BPF-based policy)

I agree that some extensible mechanism is needed.  Selectors form a tree
(or maybe lattice if one wants to simplify "reuse"). I do not think that
this is a problem that the current IPsec working group will have as a
work item, and not before IKEv2 advances.  Obvious issues are "complexity"
of the packet parsing/description language (of which BPF is an example),
and whether the concept or implementations introduce unacceptable risks.

Charlie

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 26 Jun 2003 09:14:10 -0700

I agree. We need ports for tcp/udp, and (at minimum) type/code for icmp,
but we cannot always be sure that two 16/32-bit fields will suffice for
all future (or even current) protocols. One way would be to come up with
a general protocol sub-selector field which is implicitly defined by the
protocol in question, and make it large enough to hold what we expect to
be enough demuxing info for any forseeable protocol (sounds prone to
error).

Another way would be to specify explicit selector types for tcp/udp,
icmp, and whatever else comes up. If we only add icmp to the current
spec, then it would be nice to do so in an open-ended way so we can
easily add new protocol sub-selectors later.

Scott

[email-masked] wrote:
|>>For example, we've had discussion on the list about using ICMP
|>>message type fields in lieu of port fields, when ICMP was the
|>>payload.
|>>
|>>What do people think, and why?
|>
|>Long overdue.
|>
|>Particularly important for IKE and IPv6 (as, pending introduction of
|>some facility to secure Neighbor Discovery) you likely want ND traffic
|>in clear while other ICMPv6 traffic is protected.
|
|
| 	we will need to do this every time new protocol becomes available.
| 	i guess we should make the concept of "selector" more generic.
| 	(for KAME implementation i'm thinking of switching to BPF-based policy)
|
| itojun

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Jun 2003 18:55:56 +0200

=> far too complex. IMHO this is like trying to extend selectors
to encapsulated traffic: reasonable for a firewall *only*.

   
=> add me in the list (in case some people disagree :-)

   itojun commented...

=> OpenBSD has an unified filtering/classifying stuff which can (should!)
be used for QoS (aka ALTQ), IPsec and firewall.

Regards

[email-masked]

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Thu, 26 Jun 2003 11:40:33 -0700

Hi,
   Yes. ICMP message type as one of the selectors is very
    helpful. ICMP is not only used to find out the host liveness,
    but also for mobile agent discovery, registration etc. and
    admins would not want to secure all kinds of ICMP packets.

    In general, we seem to be finding the requirements that
    selectors space needs to be increased. ICMP message type
    is one and TOS bits for QoS.

    I feel that we should have some extensible mechanism such that
    when we add new selectors to the protocol (assigned numbers),
    protocol implementation need not change.
    Also, the end users can choose their own selector space that is 
    agreed upon between two SG administrators. For example, 
    there may be a requirement where different SA Bundles are required
    for different RPC program numbers. One way to achieve is to define
    selectors by offset into the protocol headers, length and mask.

Srini
Intoto Inc. 
Enabling Security Infrastructure
3160, De La Cruz Blvd #100
Santa Clara, CA 95054
www.intotoinc.com

---

From: [email-masked]
Date: Fri, 27 Jun 2003 07:38:41 +0900

>be used for QoS (aka ALTQ), IPsec and firewall.

	actually yesterday i changed my mind and working on PF-based policy
	lookup.  stay tuned (but i need to think about IKE-interaction more...
	hi, sakane-san!)

itojun