Subject: Re: [RPSEC] Re: Threats Draft Issue 6: Section 4.7 Overload

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Mon, 28 Jul 2003 14:14:56 -0400 (EDT)

Someone poked me to comment, and I haven't
been following this thread. But it seems, unless I'm
misunderstanding the thread based on some samples I've read just
now, that my thesis is an existence proof that changes in
the routing protocol *can* be a defense against DOS and
resource starvation. So the statement:

>> Unless the mechanisms used in these attacks
> > are capable of being dealt with by changes to the protocol, such
> > attacks are outside the scope of this document."

seems as though DOS and resource starvation should be in scope.

And also, it seems as though if someone can cause resource starvation
and prevent packets from being delivered, who cares if the routing
protocol is creating correct forwarding tables?

Radia

	From: Russ White <[email-masked]>

	So, could we build concensus around the text that Jeff proposed below? 
Or
	does someone object to this, would like to change it, etc?
	
	:-)
	
	Russ
	
	On Mon, 28 Jul 2003, Russ White wrote:
	
	>
	> This sounds fine to me....
	>
	> :-)
	>
	> Russ
	>
	> On Mon, 28 Jul 2003, Jeffrey Haas wrote:
	>
	> > On Mon, Jul 28, 2003 at 10:11:37AM -0400, Russ White wrote:
	> > > I think Jeff has argued for mentioning it, but not going into 
great detail.
	> >
	> > Basically:
	> > "Denial of service and resource starvation are two attacks against
	> > a routing system.  Unless the mechanisms used in these attacks
	> > are capable of being dealt with by changes to the protocol, such
	> > attacks are outside the scope of this document."
	> >
	> > --
	> > Jeff Haas
	> > NextHop Technologies
	> >
	>
	> __________________________________
	> [email-masked] CCIE <>< Grace Alone
	>
	>
	
	__________________________________
	[email-masked] CCIE <>< Grace Alone

	_______________________________________________
	RPSEC mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/rpsec

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Jean-Jacques Puig <[email-masked]>
Date: Tue, 29 Jul 2003 10:41:01 +0200

Hi !
	A short comment inline.

> seems as though DOS and resource starvation should be in scope.

Or that, in the end, the statement suffers from a bad formulation: may
be a threats document should not make assumptions about what changes in
a protocol are capable to deal with or not, and stand to threats
description according to the scope.

> protocol is creating correct forwarding tables?

Then it makes sense to consider that overloading is a more general
threat than a threat against the routing protocol.

General threats agains forwarding/routing devices are certainly indirect
threats against routing protocols if such a device runs such protocols,
but are also indirect threats against resource reservation protocols,
management protocols or whatever runs on the device. Thus a standalone
doc would provide reference for specific contexts and prevent redundant
work.

--
Jean-Jacques Puig

[homepage] http://www-lor.int-evry.fr/~puig/

---

From: Russ White <[email-masked]>
Date: Thu, 31 Jul 2003 07:08:05 -0400 (EDT)

> Someone poked me to comment, and I haven't been following this thread.
> But it seems, unless I'm misunderstanding the thread based on some
> samples I've read just now, that my thesis is an existence proof that
> changes in the routing protocol *can* be a defense against DOS and

Okay--so, if changing the routing protocol can actually prevent DOS attacks
against the devices running the routing protocol (not against the network,
per se, but against the routers), then we should include it as in scope.
But, it might be useful to have some draft that discusses how this is
possible.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Thu, 31 Jul 2003 07:10:06 -0400 (EDT)

> Or that, in the end, the statement suffers from a bad formulation: may be
> a threats document should not make assumptions about what changes in a
> protocol are capable to deal with or not, and stand to threats

But you have to make such assumptions, or all threats docs end up covering
everything, right? Then there would only be one threat doc in the world,
just a really big one... :-)

> doc would provide reference for specific contexts and prevent redundant

Yes, so should it be in or out of scope for this doc, and should the wg
take on such a doc, since it isn't "rp specific," although it does impact
the operation of rp's?

:-)

Russ

---

From: Jean-Jacques Puig <[email-masked]>
Date: Thu, 31 Jul 2003 14:41:24 +0200

> just a really big one... :-)

I meant that foreseeing solutions to a problem should not influence
the statement of the problem itself. Saying:

''Unless the mechanisms used in these attacks are capable of being dealt
with by changes to the protocol, such attacks are outside the scope of
this document.''

may result in rejecting a pb because we are currently unaware of a
solution through changes to the protocol. It seems that we have a
(bad) natural propensity for evaluating pbs in terms of solutions.

It is sometimes (rarely) possible to proove that no solution can solve
a specific pb; nevertheless, this does not imply that the pb should not
be stated clearly: monitoring occurences of the pb may provide a place
for forensic analysis and legal (prosecutions) 'post-solutions'.

> take on such a doc, since it isn't "rp specific," although it does impact

If no-one is interested in having a general threats document, then these
threats having consequences on rp operations, they should be mentionned
in the rp threats doc. If we set for a general threats document, then
the rp threats doc should mention that general threats have already
been presented in the general threats doc. This may be considered as a
modularity issue.

Of course the WG can take on such a doc. And so can ANY WG effort
focusing on a threat analysis possibly including such threats. The
question is: which will do it first ? I think we can: current draft
provides already some content (this was the whole issue of this thread
wasn't it ?).			

-- 
Jean-Jacques Puig