Subject: Re: 2292bis comment

From: Tim Hartrick <[email-masked]>
Date: Tue, 23 Nov 1999 18:03:45 -0800 (PST)

Itojun,

> 
> 	If we put validation in the kernel before throwing packets to the
> 	userland, we will not be able to implement certain class of userland
> 	applications.
> 	example: a userland application that monitors and prints invalid
> 	ICMPv6 packets (maybe academic example...).
>

You will be able to implement them.  You just can't do it using an AF_INET6,
SOCK_RAW, IPPROTO_ICMPV6 socket.  This type of application can always be
written using a link layer packet filter facility.
 
There is a certain class of applications which should be written using
link layer packet filters.  Any application that is looking for packets which
would otherwise be discarded by the layer above the link layer is in that
class in my opinion.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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: Richard Draves <[email-masked]>
Date: Wed, 24 Nov 1999 09:23:56 -0800

> 	ICMPv6 packets (maybe academic example...).

I have not been following this discussion too closely (since we don't
implement the advanced API), but a general thought - most applications will
want "cooked" packets. A few applications (testing and the like) want "raw"
packets, but they can have a different interface.

Rich

---

From: Tim Hartrick <[email-masked]>
Date: Wed, 24 Nov 1999 16:05:56 -0800 (PST)

Erik,

> 
> > 	In general it seems to me that if the kernel knows a message is in-
> > valid it shouldn't waste the application's time by passing it out to user
> > space.
> 
> Sure, but that doesn't provide any help for portable applications
> since they don't know what different kernel implementations will consider
> invalid.
>

Yes.  The applications may have to do what amounts to duplicate checking.
As Francis said, double checking is better than none.

> But for extensibility I don't think the kernel should be dropping unknown
> ICMP types - an application might want to use new types.
> In most cases those types will be informational but for extensibility
> I don't see any harm in passing up unknown error types (suject to the 
> ICMP6_FILTER stuff).
>

Sure.  Any stack that did that would be fubar, but I guess we need to say
that explicitly and not leave it to chance.

> Thus what we can say in the 2292bis is something like:
> 	The protocol stack will verify the ICMPv6 checksum and discard
> 	any packets with invalid checksums.
> 
> 	An implementation might perform additional validity checks
> 	on the ICMP message content and discard malformed packets.
> 	However, a portable application must not assume that such 
> 	validity checks have been performed.
> 
> 	The protocol stack should not automatically discard packets if
> 	the ICMP type is unknown to the stack. For extensibility reasons
> 	received ICMP packets with any type (informational or error) 
> 	must be passed to the applications (subject to ICMP6_FILTER filtering
> 	on the type value and the checksum verification).
>

Sounds find to me.

Tim Hartrick
Mentat Inc.