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

From: Tim Hartrick <[email-masked]>
Date: Mon, 19 Jul 1999 11:53:08 -0700 (PDT)

Jinmei,

> 
> draft-ietf-ipngwg-2292bis-00 says that we should prohibit a userland
> application from including a jumbo payload option in a hop-by-hop
> options header when the application sends a packet:
> 
>    The Jumbo Payload option should not
>    be passed back to an application and an application should receive an
>    error if it attempts to set it.
>    (the second paragraph of section 7, page 30.) 
> 
> I agree that we need some kind of restriction on sending a packet with
> a hop-by-hop options header. However, IMO, the behavior described in
> the draft is too heavy for the kernel. The kernel has to parse all
> options in a hop-by-hop options header passed from an application in
> order to check whether or not a jumbo payload option is mistakenly
> included. (Note that an application can set a jumbo payload option in
> any position of a hop-by-hop options header using inet6_opt_xxx
> library functions.) Moreover, the check must be done for every packet
> when the application uses a raw/UDP socket.
> 
> I'd prefer the following approach:
> 
>   - simply prohibit an application from setting a hop-by-hop
>     options header(i.e. not special type of options) in a sending
>     packet unless the application has some privilege(e.g. the super
>     user privilege).
>   - if we need an application which may send a hop-by-hop options
>     header and can be used by a normal user, temporarily give the
>     privilege to the user(using, for example, setuid operation).
> 
> Erik Nordmark(@Sun, who is one of the authors of the draft) suggested
> me to ask other implementors' opinion. So I posted here. How do you
> think of this issue as implementors? I'd appreciate any comments.
> 

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.

I don't see any reason to make the sending of hop-by-hop or any options
privileged.

Tim Hartrick

--------------------------------------------------------------------
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: [email-masked]
Date: Tue, 20 Jul 1999 04:06:10 +0900

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

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 20 Jul 1999 04:26:50 +0900

>>>>> On Mon, 19 Jul 1999 11:53:08 -0700 (PDT), 
>>>>> Tim Hartrick <[email-masked]> said:

> I don't see any reason to make the sending of hop-by-hop or any options

Hmm...to tell the truth, I don't see any special reason,
either. However, there has been restriction on kind of options that
can affect the IP header or some other important fields of the
packet. For example, access to bpf is usually restricted to privileged
users. Even opening a raw socket is restricted. My suggestion is thus
based on such a conservative point of view.

For receiver side, I totally agree with you; there is no damage with a
receiving jumbo payload option. In fact, I asked Erik to remove the
unnecessary (at least for me) restriction from the draft.

In any case, the important point for me is to keep the kernel simple,
especially when we can do so.

					JINMEI, Tatuya
					Communication Platform Laboratory
					Corporate R&D Center, Toshiba
					[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: Francis Dupont <[email-masked]>
Date: Mon, 19 Jul 1999 21:52:33 +0200

In your previous mail you wrote:

   For example, access to bpf is usually restricted to privileged users.

=> this is for security reasons: it is too easy to grab passwords if
any user can read and with write you can abort TCP connections, ...
(only IPSEC can make this more safe)

   Even opening a raw socket is restricted.

=> in fact for many ICMPv6 packets it should be nice to have unrestricted
socket. Alain Durand works with a student on an ICMPv6 socket API without
special priviledges...

=> only AH and ESP have no usage for users (they need SAs, no the bits).
Let users build junk options...

=> there are already far too many things in kernels!

Regards

[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 20 Jul 1999 23:08:07 +0900

>>>>> On Mon, 19 Jul 1999 21:52:33 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

> (only IPSEC can make this more safe)

Right. The bpf example might not have been a good one...I meant that:

  if the restriction of sending jumbo opt described in the draft came
  from some security reasons, I'd follow the rule. But I don't like to
  make the kernel code too complex for that purpose. I'd rather
  prohibit sending the entire hop-by-hop header. If there is no
  security issue of sending a jumbo opt, we should of course eliminate
  any restrictions.

> Let users build junk options...

I'm sorry, but I missed your point...how do AH and ESP relate to
receiving a jumbo opt?

> => there are already far too many things in kernels!

Yes, but it doesn't mean we need no effort to make the kernel simpler.

					JINMEI, Tatuya