Subject: Re: how to prohibit an application from sending a jumbo payload opt

From: Tim Hartrick <[email-masked]>
Date: Mon, 19 Jul 1999 12:28:17 -0700 (PDT)

Itojun,

> 
> >I am not convinced that there is any need to forbid the user from sending
> >or receiving the jumbo payload option.  The worst that the user can do is
> >send illegal options out on the wire which will be discarded by the receiver.
> >If an application receives the jumbo payload option I don't see what damage
> >can be done with the information.  Searching for the option so that it can
> >be removed looks like a bunch of work for no reason at all.  This is more or
> >less how IP options have worked forever.
> 
> 	Some of the extension headers are okay to be modified/seen from the
> 	userland, some are not.  AH, ESP, and mobility options are apparently
> 	not to be touched from advaned API.  I believe jumbogram falls into
> 	the category. (it needs to be used together with other code, like
> 	TCP/UDP.  userland can not do much about it)
> 

I am not arguing that user applications should add things like the various
mobility options to their packet.  Clearly, applications shouldn't do this.
I am arguing that if we allow applications to build completely arbitrary
options headers these applications can only harm themselves by adding jumbo
payload or mobility options to their datagrams.  If these busted applications
can't harm the host system or other systems then there is no upside to making
the kernel more complicated to protect the system from nonexistent threat.

Is there some damage an application can do to its host system or other systems
by being able to create arbitrary hop-by-hop or destination options headers
and receive all the contents of hop-by-hop or destination options headers?

Obviously, AH and ESP are in a very different category entirely.  These are
extension headers that should never be passed in from or passed out to user
space.  The current advanced API rightly forbids this by simply not allowing
raw packet headers to be passed to and from the kernel.  I was not suggesting
that this change.  We were discussing hop-by-hop and destination options
headers.

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