Subject: [RPSEC] Threats Draft Issues: Where we Stand?

From: Russ White <[email-masked]>
Date: Fri, 25 Jul 2003 22:40:57 -0400 (Eastern Daylight Time)

Y'all:

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.

In other words: Please read the drafts and the issues, and comment on them,
so we can make certain we have some semblance of agreement on each of the
issues. I think Abbi has promised a revision in two weeks, if we can come
to agreement on each of these issues.

Is there anyone on list that thinks the draft, in general, is "not right,"
in some way? Are we all okay with with the format, etc, or the draft? I
remember there was some discussion on this, but I'm not certain any sort of
concensus was ever reached on this topic.

:-)

Russ

--

Current Issues and Status:

Issue 1: Use neighbors throughout to describe two adjacent routers running
the same protocol, etc. I think

Status: I think we have concensus on this.

Issue 2: Section 4.1, Is deliberate exposure a threat to a routing system?

Status: We have one comment that it is a threat, and no other comments that
I've seen. Do I take it that deliberate exposure is a threat to routing?

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.

Issue 4: Section 3.1, Splitting masquerading threats from unauthorized
threats.

Status: I don't think I've seen any concensus here (?). I take the silence
on the issue to mean that the compromise text I proposed is okay with
everyone, defining them seperately, but using the same term for the two
throughout.

Issue 5: Is the term blackhole used consistently throughout?

Status: The term only appears to used twice in the draft as it is right
now, and it appears to be used consistently. I take this as a concensus on
this item.

Issue 6: Section 4.7 Is overload a legitimate attack against a routing
protocol?

Status: Thus far, we have Jeff, Jean-Jacques, and I arguing against it
being a threat, and Alex A arguing it is a threat. What's the concensus on
this one? I'm inclined to all it not a threat based on the current
arguments.

Issue 7: Ownership as a term.... Is ownership the right term to use?

Status: I think we've reached concensus on this one, with "owner" being the
acceptable term, as long as it is defined at the beginnig of the doc.

Issue 8: In the abstract, there's an awkwardly worded sentence:

Status: I take the following as a concensus change:

> That's fine or just change "the network operations" to either "the
> network's operations" or "network operations".

This would work as well....

> ps. In your message about "Comments on Section1, Introduction" you
> proposed text starting with:
>
> "While its well known that bad, incomplete, or poor implementations of
> routing protocols may, in themselves, lead to routing problems or..."
>
> That "its" should be "it's".   I didn't bother then but we're on the
> grammatical side so I bring it up.  I like that stuff. -T

Issue 9: Use words rather than numbers for references.

Status: I assume we have concensus on this.

Issue 10: Section 3.1.2.1 Threat Consequence Zone

Status: I've seen no discussion on this issue--does everyone else
understand this section of the draft completely?

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

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

---

From: "Dijiang Huang" <[email-masked]>
Date: Fri, 25 Jul 2003 22:57:38 -0500

> this one? I'm inclined to all it not a threat based on the current

I think we should leave the overload to control plane. This based on several
facts. 1. The threat draft is not only for TCP/IP type based routing
protocols.
Some routing protocol may have separate channels to take only routing
traffic.
2. Even based on TCP/IP protocol stack and in-band routing, when the "data"
is
destine to the port used by routing process, the router will consider the
"data" is
routing data. Since I think the router will forward the "data" to the
routing
process. 3. Moreover, I am thinking good protocol design will help to
minimize
the effect of control plane based overloading. For example, a routing
protocol
is lack of authentication protection. The overloaded traffic might be
amplified
due to flooding. Thus, when you designing a routing protocol, you should be
cautious, how strong/complicated the authentication scheme is, and
what kind of routing scheme is used, such as flooding/selective flooding.
Although
you might not totally prevent the overload attack, you could decrease the
overloading
effect of overall routing domain.

Based on these facts, I think the overload should be there in the control
plane
level.

Dijiang