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

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

Jinmei,

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

Sure raw sockets have traditionally been privileged.  I was not suggesting
that this change.   Note however that that prohibition probably doesn't have 
anything to do with prohibiting the sending of broken options.  If one wants
to send datagrams with busted options (IPv4 or IPv6) you can simply open a UDP
socket and have at it.  I believe that prohibition exists because raw sockets
allow for the sending of datagrams from arbitrary protocols like IPPROTO_TCP,
IPPROTO_UDP and IPPROTO_OSPF.  Clearly, this facility can be used to cause
significant problems for the host system and other systems on the network.

The damage that can be done with bpf is obvious.
 
> 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.
>

100% agree.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 21 Jul 1999 02:28:30 +0900

>>>>> On Mon, 19 Jul 1999 12:45:03 -0700 (PDT), 
>>>>> Tim Hartrick <[email-masked]> said:

> significant problems for the host system and other systems on the network.

Okay, so your position is that we don't need any restriction
(including the spec discribed in the 2292bis draft) on sending a jumbo
payload option or even on sending a whole hop-by-hop opt header,
right?

IMO, it depends on how we regard allowing a user to freely send a
hop-by-hop option. I basically agree with you, but someone may warry
that a busted option annoys the receiver's system and sometimes cause
a DoS attack. I'd like to know others' opinion, especially the
authors' one.

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