Subject: RE: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 6 Aug 2003 13:34:20 -0400

Hi,
please provide feedback ASAP so we can incorportae in the next vrsion of the
draft, that should be comming in the next two weeks.

abbie

> -----Original Message-----
> From: Jean-Jacques Puig [mailto:[email-masked]] 
> Sent: Wednesday, August 06, 2003 10:22 AM
> To: Routing Protocols Security Working Group
> Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming
> 
> 
> Hi !
> 
> 	('made a cut and paste from 'Threats Draft Issues: 
> Where we Stand?'
> 	so that to keep separate threads on specific issues)
> 
> On Sun, Jul 13, 2003 at 09:57:39PM -0400, Russ White wrote:
> > 
> > Did we come to some concensus on whether or not underclaiming is a 
> > legitimate threat? I know there was a lengthy discussion on 
> this, but 
> > I don't recall any sort of final concensus around the question.
> 
> On Fri, Jul 25, 2003 at 10:40:57PM -0400, Russ White wrote:
> > 
> > We've had some discussion over some of the issues on the 
> threats draft 
> > I had recorded from various places; below is a summary of 
> what I have 
> > so far. We need to get this cleaned up and finished up, so 
> we can move 
> > on to other work in the near future.
> >
> > ...
> > 
> > Issue 3: Issue 3: Section 4.5, Is underclaiming a threat to routing 
> > systems?
> > 
> > Status: I seem to remember Sandy and some others arguing against 
> > underclaiming being a threat, while I and others argue for 
> it being a 
> > threat. The reasoning on one side appears to be that you 
> can't force a 
> > router to advertise anything (?), while on the other side 
> the claim is 
> > that this doesn't matter, forcinf information can still cause 
> > misrouting to occur, and thus it's a threat. It seems we need some 
> > closure on this one.
> 
> After a second reading of the ML mails, WG minutes and drafts 
> on this topic, current positions are the following (please 
> correct me if I'm
> wrong):
> 
> For considering underclaiming as a valid attack: Yi, Birger, 
> Russ, Jean-Jacques  (and possibly Tony ?).
> 
> Against considering underclaiming as a valid attack: Sandy, 
> Radia, Curtis (and possibly Stephen ?).
> 
> Current input regarding this issue is mainly 
> draft-beard-rpsec-routing-threats-01, though further elements 
> were mentioned on the mailing list.
> 
> Discussion:
> 
> 	From RFC 2828: A threat (action ?) can be either 
> "intentional" or
> 	"accidental".
> 	According to this, if underclaiming is not a valid 
> attack, it may
> 	still be an accidental threat action, and as such, can be
> 	documented in the threats document (according to 
> current approach of
> 	threats definition sect 3.1).
> 
> 	There have been input that this attack was against an individual
> 	network element ? Does anyone want to develop on this ? 
> 	
> 	I think the router may not be affected by it's own 
> underclaiming,
> 	but so is the network it should have advertised; thus a possible
> 	target of the attack is a network.
> 
> 	Is it an attack against the routing system ? The routing db is
> 	affected by underclaiming. If farther on the paths routers make
> 	*legitimate* underclaiming of the prefix, only a part of the
> 	routing db may be affected. Most consequences already 
> listed in the
> 	draft may happen. *Incorrect* distributed routing db 
> is, IMHO, the
> 	manifestation of that a threat action against routing occured.
> 
> 	How can a routing protocol be protected against such an 
> attack ? The
> 	same way such a protocol can check authority for prefix
> 	advertisement through an appropriate distributed db (e.g.
> 	http://www.isi.edu/~bmanning/inet98.html ). Such a db 
> may announce
> 	policies related to routing, and systems REQUIRED (by 
> agreement) to
> 	advertise a prefix. This may not be sufficient for 
> forcing the path,
> 	yet it allows detection of an incorrect behavior by non 
> subverted
> 	devices. Besides, threats are not defined by the existence of a
> 	solution to them. Sometimes, when robustness cannot be achieved,
> 	detection can and is of great interest to limit the consequence
> 	zone. 
> 
> 	Is it too early for a consensus on this ?
> 
> 	Comments are welcome !
> 
> -- 
> Jean-Jacques Puig
> 
> [homepage] http://www-lor.int-evry.fr/~puig/
> 
> _______________________________________________
> RPSEC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rpsec
>

---

From: Russ White <[email-masked]>
Date: Mon, 11 Aug 2003 09:46:22 -0400 (Eastern Daylight Time)

I'm still of the belief that it is a valid threat, though it's hard to
define, and impossible to defend against.

:-)

Russ

> > 	Is it too early for a consensus on this ?

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Eric Gray <[email-masked]>
Date: Tue, 12 Aug 2003 06:37:11 -0400

Russ,

    As I understand it, the premise is that 'underclaiming' is a problem if
it results from subversion of a router.  In this case, isn't the threat really
the subversion of the router?  Lots of things can be done with subverted
routers...

--
Eric Gray

---

From: Russ White <[email-masked]>
Date: Tue, 12 Aug 2003 06:57:14 -0400 (EDT)

Is that true? With RIP, at least, you can force underclaiming by just being
on the wire, and having direct control of the network hardware, I'd guess.
Just collide with anything that comes out looking like a RIP update, no?
That would cause your peers to think you couldn't reach anything.

Of course, the rest of the routing protocols have reliable delivery, so
this isn't theorectically possible.

On the other side of the issue, if we are going to state that any attack
which can only be accomplished through some other attack is really only the
"lower level" attack, then we should probably scrub about half of this doc
out, right?

Again, it comes down to where you draw the line, I think (?).

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Aug 2003 09:35:56 -0400

>That would cause your peers to think you couldn't reach anything.

The attack you describe is an active wiretapping problem. I think we 
need to maintain a clear separation here. I assumed that any 
reference to underclaiming was in the context of an authenticated, 
integrity-protected communication by a  legitimate router.

>"lower level" attack, then we should probably scrub about half of this doc

That would be my suggestion.  This document seems to be very sloppy 
in this regard. One wants a clear taxonomy of problems, and citing 
one problem which is the result of any number of other precursor 
attacks is just confusing.

Steve

---

From: Russ White <[email-masked]>
Date: Tue, 12 Aug 2003 09:43:52 -0400 (EDT)

> The attack you describe is an active wiretapping problem. I think we need
> to maintain a clear separation here. I assumed that any reference to
> underclaiming was in the context of an authenticated, integrity-protected
> communication by a legitimate router.

But then you're presupposing a solution to the threat, and saying it's not
a threat if there's a solution that people should be running, correct? In
that case, there are no threats, right? :-)

> That would be my suggestion.  This document seems to be very sloppy in
> this regard. One wants a clear taxonomy of problems, and citing one
> problem which is the result of any number of other precursor attacks is
> just confusing.

Okay, there seems to be some tension between the concept of providing a
"complete reference," and a "set of specific threats at the lowest level."
Is there any attack on a routing protocol that cannot be reduced to:

-- access to the physical media
-- access to the physical device

? It doesn't seem like it--they can all be reduced to one of these two.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Aug 2003 10:13:28 -0400

>that case, there are no threats, right? :-)

First, the term threat is being misused here, still, but I've given 
up on trying to fix that, after submitting my grief threat analysis 
note to the group some time ago.

A useful taxonomy distinguishes attacks at low levels, and includes 
discussion of how combinations of attacks, or different attack paths, 
can result in problems at higher levels, as a way of showig the 
reader how to put the pieces together.

>? It doesn't seem like it--they can all be reduced to one of these two.

This is not a useful basis for the discussion, especially when one 
thinks harder about the meaning of "access."

I do not mean to suggest that there is only one way to provide the 
taxonomy. But any approach should give the reader as sense of 
completeness, relative to the approach selected.

In this context one might discuss passive and active attacks against 
transmission media, attacks against routers, attacks against the 
computers used to manage the routers, and operational problems 
resulting from human actions. In the attacks against the routers or 
the management computers, one could distinguish attacks effected via 
communication paths from attacks that require physical access to the 
components.

One could also look at the problems from the traditional security 
discipline perspective: personnel, procedural, physical, 
communications and computer security.

You could adopt the approach we did for analyzing BGP security, i.e., 
consider correct operation to be the base definition, then examines 
the means by which correct operation can be subverted.

All of these are valid starting points, but whichever way this 
analysis is done, one has to avoid drifting into an ad hoc listing.

Steve

---

From: Russ White <[email-masked]>
Date: Tue, 12 Aug 2003 10:25:25 -0400 (EDT)

> All of these are valid starting points, but whichever way this analysis
> is done, one has to avoid drifting into an ad hoc listing.

Okay, if you could remake this draft, rather than giving us a general
feeling of what is wrong with it, how about taking one specific section,
and telling us what you would take out, vs what you would leave in, add,
etc (?).

I suppose my question to the list is: Would this be a useful excercise for
everyone to understand, so we could read through this in a "more standard"
way?

Russ

---

From: [email-masked]
Date: Tue, 12 Aug 2003 11:37:44 -0500 (CDT)

> I suppose my question to the list is: Would this be a useful excercise
> for everyone to understand, so we could read through this in a "more
> standard" way?
>
> Russ

Yes please. That would surely help us all.

Sanjay

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Aug 2003 12:56:11 -0400

>Yes please. That would surely help us all.

Sure, just send time & money :-)

Remember, BBN is a contract R&D company, not a vendor. We bill 
clients for our time. I am happy to spend some time trying to help 
here, but I have no current client who I can bill for an extended 
amount of work on this topic.  Since my last contribution to the 
efforts of this WG, a concrete example of how to perform a threat 
analysis for routing, seems to have gotten nowhere, it's very hard to 
justify the expenditure of more hours on rewriting parts of this 
document.

Steve

---

From: [email-masked]
Date: Wed, 13 Aug 2003 11:20:49 -0500 (CDT)

Looks like I added more fuel to the fire. I had missed a couple of earlier
mails and mistook the list Russ was talking, to a summary list one Jean
had a couple of days back. I have mailed Steve personally, and please
disregard my previous mail.

Sanjay

---

From: Eric Gray <[email-masked]>
Date: Wed, 13 Aug 2003 19:01:31 -0400

Russ,

    It comes down to what you were saying earlier - we have to draw a
line somewhere.  For example, we know that active wire tapping and
router subversion are problems, because - if they're allowed to happen,
a lot of other things can be done as well.

    Do we need to list all of those other things as separate threats? If we
head down that road, we end inevitably in a rat hole, so the answer
should be - no.

    I believe the answer is that we do not need to list these as separate
threats when it is well known that several effectively unanswerable
attacks are possible if a certain type of exposure is allowed to occur.
In such a case, it should be sufficient to state a few such attacks as
existence proof, possibly assert that others (perhaps many others)
exist and leave it at that. In these cases, the secondary risks are not
so much separate threats as validation of the initial exposure.

--
Eric

---

From: Russ White <[email-masked]>
Date: Wed, 13 Aug 2003 21:02:00 -0400 (Eastern Daylight Time)

> line somewhere.  For example, we know that active wire tapping and router
> subversion are problems, because - if they're allowed to happen, a lot of
> other things can be done as well.
>
>     Do we need to list all of those other things as separate threats? If
> we head down that road, we end inevitably in a rat hole, so the answer
> should be - no.
>
> existence proof, possibly assert that others (perhaps many others) exist
> and leave it at that. In these cases, the secondary risks are not so much
> separate threats as validation of the initial exposure.

Okay, which attacks within the current document would you say fall within
the bounds of one of these two attacks, and which do not?

:-)

Russ

---

From: Tony Tauber <[email-masked]>
Date: Thu, 14 Aug 2003 14:23:15 -0400 (EDT)

On Wed, 13 Aug 2003, Russ White wrote:

> >     It comes down to what you were saying earlier - we have to
> >     draw a line somewhere.  For example, we know that active wire
> >     tapping and router subversion are problems, because - if
> >     they're allowed to happen, a lot of other things can be done
> >     as well.
> >
> >     Do we need to list all of those other things as separate
> >     threats? If we head down that road, we end inevitably in a rat
> >     hole, so the answer should be - no.
> >
> >     I believe the answer is that we do not need to list these as
> >     separate threats when it is well known that several
> >     effectively unanswerable attacks are possible if a certain
> >     type of exposure is allowed to occur.  In such a case, it
> >     should be sufficient to state a few such attacks as existence
> >     proof, possibly assert that others (perhaps many others) exist
> >     and leave it at that. In these cases, the secondary risks are
> >     not so much separate threats as validation of the initial
> >     exposure.
>
> Okay, which attacks within the current document would you say fall
> within the bounds of one of these two attacks, and which do not?
>
> Russ

So, we've got these (from the table of contents):

4.  Generally Identifiable Routing Threats
4.1  Deliberate Exposure
4.2  Sniffing
4.3  Traffic Analysis
4.4  Spoofing
4.5  Falsification
4.5.1  Falsifications by Originators
4.5.2  Falsifications by Forwarders
4.6  Interference
4.7  Overload
4.8  Byzantine Failures
4.9  Discarding of Control Packets
4.10  Network Mapping Threats
4.11  DoS and DDoS Attacks

Seems like most of these can be effected by compromised routers.
A number (eg. sniffing, spoofing, interference, traffic analysis,
discarding) can also arise from compromised links.
Given that the signalling is in-band with user traffic, there's
another avenue which is spoofing, DoS, Overload by use of spoofing
routing packets.

Remember that the goal with this exercise is to derive a security
requirements document for routing protocols.
I think Steve Kent gave the insight that it's possible to apply
mechanisms to counteract the threat of subverted routers and links
(possibly operators, even.)

Tony

---

From: Alex Audu <[email-masked]>
Date: Fri, 15 Aug 2003 12:35:37 -0500

It may just be sufficient to document the symptoms of attacks on routing,
instead
of the different ways the attacks my be carried out. For example, active wire
tapping
my trigger the same effect or symptoms as another attack method say X. But all
we care about are the symptoms. For example, does it cause routing information
corruption, or processing resource starvation, or,..

Alex.

---

From: Russ White <[email-masked]>
Date: Fri, 15 Aug 2003 16:18:42 -0400 (Eastern Daylight Time)

> 4.11  DoS and DDoS Attacks

Yep, these seem like the right areas that would be implemented through
comprosing a router or link.

> Seems like most of these can be effected by compromised routers. A number
> (eg. sniffing, spoofing, interference, traffic analysis, discarding) can
> also arise from compromised links. Given that the signalling is in-band
> with user traffic, there's another avenue which is spoofing, DoS,
> Overload by use of spoofing routing packets.
>
> requirements document for routing protocols. I think Steve Kent gave the
> insight that it's possible to apply mechanisms to counteract the threat
> of subverted routers and links (possibly operators, even.)

So, we could _theoretically_ replace all of these sections with a single
section stating that a compromised router or link could cuase "bad things,"
that we don't need to specify what these "bad things" could be. In the
requirements doc this would be paralleled by a statement about protecting
routers and links from being compromised.

Thoughts?

:-)

Russ

---

From: Tony Tauber <[email-masked]>
Date: Fri, 15 Aug 2003 16:35:58 -0400 (EDT)

On Fri, 15 Aug 2003, Russ White wrote:

> Date: Fri, 15 Aug 2003 16:18:42 -0400 (Eastern Daylight Time)
> From: Russ White <[email-masked]>
> So, we could _theoretically_ replace all of these sections with a
> single section stating that a compromised router or link could cuase
> "bad things," that we don't need to specify what these "bad things"
> could be. In the requirements doc this would be paralleled by a
> statement about protecting routers and links from being compromised.
>
> Thoughts?

No.  Compromising a router or link does not comprise an attack on the
routing protocol.  Moreover, since one can't fix those things within a
routing protocol, we might as well pack up and go home.  The
mitigtions that can be implemented in routing protocols are to address
what can be put in so that the protocols can function even in the face
of these attacks (hopefully).

For instance, some cryptographic enhancements might mitigate some
attacks that can carried out through a compromised link (eg. spoofing,
sniffing) but not others (eg. discarding of control packets, traffic
analysis).

I believe that the so/s BGP enhancements are designed to mitigate,
among other things, compromised routers (ie. someone with control of a
router announcing a prefix they're not authorized to).

Does that sound right?

Tony

---

From: Jean-Jacques Puig <[email-masked]>
Date: Tue, 19 Aug 2003 18:18:34 +0200

Hi !

	(I have to split here in the tree because later in the thread it may
	be difficult to understand what I'm talking about)

> the subversion of the router?  Lots of things can be done with subverted

As states Russ later in the thread, the underclaiming may be done on the
wire; or a 'subverted link'.

I fear that in the following part of the discussion, threat sources and
threat attacks are mistaken. The current draft list subverted links and
devices as threat *sources*, whereas the question was whether
underclaiming is a valid threat *action* (attack). This approach to
threat definition may not be perfect, but it looks coherent here.
The subvertion of the router / the link is required, but is not
sufficient to provide a complete description and is not the real attack
against routing operations.

-- 
Jean-Jacques Puig

---

From: Russ White <[email-masked]>
Date: Wed, 20 Aug 2003 06:38:13 -0400 (Eastern Daylight Time)

> threat definition may not be perfect, but it looks coherent here. The
> subvertion of the router / the link is required, but is not sufficient to
> provide a complete description and is not the real attack against routing
> operations.

I think it's probably useful to maintain the distinction between threat
sources and threat actions (what I would consider just a threat, although I
suppose it's better to have some qualifier on the word). This way we can
state that a link can be subverted, and then what actions an attacker could
take based on that subversion, right?

Otherwise, most all attacks are going to come down to just a couple of
threat sources, and the draft will lose most of its usefulness in helping
people understand what sorts of attacks could take place. I'll agree, on
the other side, that we shouldn't try to catalogue every possible threat
action in the world, but some examples to set the reader's mind to thinking
are good, at least.

:-)

Russ