Subject: ICMP protocol filtering

From: David Lehmann <[email-masked]>
Date: Fri, 29 Mar 2002 11:00:26 -0500

Y'all,

RFC 2292bis, section 3.2 describes ICMPv6 type filtering.
Would it be useful to have protocol (Next header) filtering
on an ICMP socket?

e.g. I am developing SCTP and would only like to receive ICMP
_error_ messages for SCTP.  i.e. I would like only packets in which
the offending IPv6 packet has a Next Header field == IPPROTO_SCTP
in the IPv6 header.

-David

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 29 Mar 2002 12:38:20 -0500

David

A possible problem with this would be intervening
extension headers even though the transport was
SCTP.  Would you want to filter on those headers
as well?

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		IPv6 Project Lead
Compaq Computer Corp.		
110 Spit Brook Rd ZK03-3/T07	Tel: (603) 884-1079
Nashua, NH 03062		Fax: (435) 514-6884
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 30 Mar 2002 02:40:31 +0900

>>>>> On Fri, 29 Mar 2002 11:00:26 -0500, 
>>>>> David Lehmann <[email-masked]> said:

> the offending IPv6 packet has a Next Header field == IPPROTO_SCTP

This example seems too specific to incorporate the extension into the
document at this late stage.  Also, I don't get why the next header is
so special.  If we added this, then other implementors would want
filtering based on inner flowlabel, inner hop limit, inner source or
destination addresses, inner extension headers...

So...sorry, but I don't think we can add the feature to rfc2292bis.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Fri, 29 Mar 2002 19:58:18 +0200

> > the offending IPv6 packet has a Next Header field == IPPROTO_SCTP

Isn't there already last error or something, that you could query from
the SCTP socket. That error would be the last ICMP error specific to
that socket.

Or, there is no such feature in sockets? It would be a sensible
feature for the stack to route ICMP errors that are specific to a
socket to the specific socket.

---

From: David Lehmann <[email-masked]>
Date: Fri, 29 Mar 2002 13:02:58 -0500

> SCTP.  Would you want to filter on those headers

Yes, I can see that simply checking the Next Header
on the IPv6 header is not enough.  If ICMP could filter
on a particular header, then the packet would pass
through the filter if any of the headers had the
specified header ID.

-- 

David Lehmann                          Ulticom, Inc.
AOL IM: davidULCM                      1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA

---

From: David Lehmann <[email-masked]>
Date: Fri, 29 Mar 2002 13:21:53 -0500

JINMEI Tatuya wrote:

> document at this late stage.  

The lateness of this proposal was pointed out to me by Erik,
but thought I could give a shot nonetheless.

> Also, I don't get why the next header is
> so special.  

The reason is that if I am implementing a particular protocol
(e.g. SCTP), I don't want to be bothered by errors generated
for every other protocol on the node.  I would only want errors
for my particular protocol.

> If we added this, then other implementors would want

If they are generally useful, so be it.  However, I don't know how
great the dangers are of those additional requests.

--

---

From: David Lehmann <[email-masked]>
Date: Fri, 29 Mar 2002 13:40:53 -0500

> socket to the specific socket.

I agree that it is a sensible feature to get ICMP errors that are
specific to a socket.  In the raw socket case, the socket is based on a
protocol.  This is why a protocol filter would be useful.

However, I am NOT suggesting to use the same socket which
implements the protocol to be used also for ICMP error messages.
(This would be too complicated.) I am suggesting that we can
expand the filtering capabilities of an ICMPv6 socket to
filter on 'protocol' as well.

--

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 30 Mar 2002 04:09:55 +0900

>>>>> On Fri, 29 Mar 2002 13:21:53 -0500, 

> but thought I could give a shot nonetheless.

Yes, anyone can basically raise their own requests at any time, but
whether the requests are accepted or not depends on the timing...IMO,
just saying "this could be useful" cannot be a reason to adopt the
request at this stage, and, honestly, I don't see much benefit of
the idea comparing to the status of the document.  (But, of course, I
may be wrong or be biased, so I'll hear from others' opinions for a
while.)

> for my particular protocol.

If you're implementing SCTP itself in the user space, I would point
out that this API is not intended to aid implementing a transport
layer protocol in the user space (at least in my understanding.)  If
you want to let an SCTP application accept ICMPv6 error messages, I'd
say it's a so special case (even though this is the "advanced" API).

Secondly, one of the reasons why ICMPv6-type based filtering was
introduced was because we can see many ICMPv6 messages even in normal
operation, because ND and MLD are both using ICMPv6 messages.  Error
messages, however, are basically exceptions.  Thus, I don't see much
validity for the motivation to filter ICMPv6 error messages.

> great the dangers are of those additional requests.

My point is that the request of filtering on the next header is as
special as others, at least for me.  But, again, I may be wrong, and
will hear from others.

At this moment I sill do not think we can add the feature to the
document.

					JINMEI, Tatuya

---

From: David Lehmann <[email-masked]>
Date: Fri, 29 Mar 2002 15:14:15 -0500

> may be wrong or be biased, so I'll hear from others' opinions for a

I agree that my sole opinion is not enough to adopt a change.

> say it's a so special case (even though this is the "advanced" API).

Actually, I am implementing it in both the kernel and user space.
In either location, the concept is still the same. In the kernel
(Solaris), I simply link the socket under the SCTP driver, in which
case I still only want ICMP error packets which are SCTP related.

-- 

David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA