Re: IKE negotiation for ICMP message type selectors

["Scott G. Kelly" <scott@airespace.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

itojun@iijlab.net 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE++xvRMtIdhO0pgN4RAsmYAKDi9LGFkP2pRFj0PKILdc8WKudzYgCeLulZ
BTQFmovu2BOGX+Tm5WfwkHM=
=rLxa
-----END PGP SIGNATURE-----