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

From: Tim Hartrick <[email-masked]>
Date: Tue, 20 Jul 1999 10:41:05 -0700 (PDT)

Jinmei,

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

In the case of the jumbo payload option, yes, that is my position.  The
worst case is that the application adds a jumbo payload option which
results in an illegal datagram being sent to the destination.  The destination
will simply discard the broken datagram.
 
> 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.
>

Indeed, it is easy to imagine options which could be defined that could be
used in a DOS attack.  That would be a serious problem and we probably should
avoid defining such options if possible.  If we need such options then they
would need to be destination options which get placed after an AH header.
That is, they would need to be authenticated before they were processed.

The only ones I know of at this time which MIGHT have such a problem would
be the mobility options.  I have not read this spec in a long time so I can't
say with any degree of certainty that all these options are benign if added
to a datagram incorrectly.

Hopefully folks that have more experience with the IPv6 mobility spec and
its interactions with IPSec can give us the skinny on the security con-
siderations for the various mobility options.

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: Tue, 27 Jul 1999 12:29:57 +0900

I apologize for not responding for a while...

>>>>> On Tue, 20 Jul 1999 10:41:05 -0700 (PDT), 
>>>>> Tim Hartrick <[email-masked]> said:

> will simply discard the broken datagram.

OK.

> to a datagram incorrectly.

We've collected opinions of this issue from some implementors. Now let
me summarize the opinions.

For sending options:
  Tim: no restriction is necessary (at least currently).
  Craig: the current scheme is inherently flawed.
  Francis: (I'm not sure about his opinion, but he seems to think we
            need no restriction)
  jinmei: basically the same as Tim's, but would obey some restrictions
          if someone warries security.

For receiving options:
  Tim: no restriction is necessary.
  jinmei: ditto.

(Please correct the above if I misunderstood)

To the authors of the draft:
It seems to me that no one wants such a strict restriction described
in the draft. I believe the result is worth reconsidering the spec.

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