[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKE negotiation for ICMP message type selectors

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

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.


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
|>>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

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