Subject: [RPSEC] Quesitons....

From: Russ White <[email-masked]>
Date: Thu, 9 May 2002 06:01:31 -0400 (EDT)

So, I messed up the address when I sent this, and it still got
delivered, somehow, but people seem to be having problems
responding, so I'm sending it again to the right address this
time.

:-)

Russ

-----

Okay, this list is too quiet. So BOO!

I think we need to get some discussion rolling here, and decide
how we are going to get some drafts up and going. So, to that
end, some questions:

-- There appear to be several seperate problems in securing
routing systems:

-- Knowing for certain the the device/as advertising a given
address actually should be advertising that address. For
instance, you are receiving an advertisement for 10/8 from AS
65000. Should as 6500 really be advertising this destination as
reachable?

-- Knowing for certain that a device/as advertising a given
address is who it claims to be. For instance, some device
claiming to be part of as 65000 is advertising 10/8. Is it really
part of that as?

The second aspect is represented in a couple of ways--a "man in
the middls" can grab your traffic (or misdirect it) by claiming
as 65000 is behind them, or by stating that they are as
65000. Either one seems to work equally as well.

Are these two seperate problems which need to be solved in two
seperate ways? Are they applicable to all protocols? How much of
a chunk of these two problems does securing the interrouter
communications within a given protocol solve any of these
problems?

Should we address these as seperate problems in seperate
documents, or should an entire system stand or fall as one unit?

On another topic, should we have two seperate sets of drafts for
requirements docs, one for interior protocols, and one for
exterior protocols? Should we form technical subgroups to work on
these?

:-)

Russ

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

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

---

From: Alex Zinin <[email-masked]>
Date: Thu, 9 May 2002 13:50:14 -0700

Folks

 Some draft thoughts on this discussion...

 Assuming that the WG will start with threat description
 (according to the milestones), why don't we try to identify
 common subsystems in all routing protocols, e.g.:

  o Transport subsystem            (mechanisms to send messages)
  o Neighbor state maintenance     (how we find/drop nbrs, adjacency/session process)
  o Database maintenance           (additional DBs used for topology and
                                    reachability info: LSDBs, RIBs, TIBs,etc.)
  o Routing state maintenance      (how the routing/forwarding state is setup/removed)
    ...
    
 --then describe different categories and subcategories in
 each subsystem and then go ahead with description of threats
 specific to each type of subsystem.

 To give an example, let's take the transport subsystem. A description
 of it would probably follow an outline like this:

    1. Transport Subsystem
    1.1 Degree of connectivity
        -Point-to-point transport
        -Point-to-multipoint transport
        -Broadcast/multicast transport
    1.2 Used layer
        -Link-layer transport
        -Network-layer transport
        -Transport-layer transport
    1.3 Provided service
        -Connectionless unreliable (link-layer, raw ip, udp)
        -Connection-oriented reliable (tcp,...)
        -other (???)

 I guess we could associate a set of threats with each bullet
 above.
 
 What I like in this approach is that it will allow us to give
 a good coverage in a structured manner without becoming too
 protocol-specific. We'll also be able to start with a skeleton
 document, and go into deeper details as we progress. We can
 later use the same model for the requirements document.

 Thoughts?
  
-- 
Alex

---

From: Tony Tauber <[email-masked]>
Date: Thu, 9 May 2002 17:11:10 -0400 (EDT)

>  common subsystems in all routing protocols, e.g.:

<snip>

>  later use the same model for the requirements document.

I quite like it.
It seems to me that when thinking about security it's often
matter of classifying a given situation and then knowing
what kinds of questions to ask about such a situation.

This way protocol designers, implementors and users can
ask "What about DoS?"  "What about authorization?", etc.

Tony

---

From: Russ White <[email-masked]>
Date: Thu, 9 May 2002 21:18:25 -0400 (EDT)

Agreed.... I would probably divide the routing system into
reachability and topology aspects, since this is where they seem
to naturally fall.

BTW--someone said that reachability was intrinsic to topology in
link state protocols, I think (?).... Actually, I think it's the
opposite. A link state protocol can clearly give you a topology
with no reachability (although it cannot give you reachability
with no topology). IS-IS in IP mode with no prefixes to
advertise.

A distance-vector protocol can't give you topology without
reachability, it seems to me.

:-)

Russ

---

From: Alex Zinin <[email-masked]>
Date: Fri, 10 May 2002 00:30:27 -0700

Russ,

> reachability and topology aspects, since this is where they seem

Hmmm... I have a different model in mind, I guess:
[Note the presence of the database subsystem.]

The way I see it is routing/forwarding state is information
you maintain to actually forward packets. Creation of
this state can be:
 - Destination-presence driven (current unicast system)
 - Data traffic driven (MANET: AODV, DSR)
 - Membership driven (multicast)
 - [other examples]

reachability and topological information is an example
of a database (or databases) used to create destination-presence
driven routing state.

> with no topology). IS-IS in IP mode with no prefixes to

You're right, of course. One could imagine OSPF routers
announcing no reachability info as well.

> reachability, it seems to me.

Not the ones we have at the moment.

One could imagine a routing protocol announcing _locations_
of the routers using the DV (BF) rules and then distributing
reachability info in a flooding-like fashion (no hop-by-hop
metric increment). Route calculation would then be similar
to external route calculation in link-state, but the SPT would
already be precomputed by BF without having to run Dijkstra.
Hope I'm not confusing much ;)

Alex

---

From: Russ White <[email-masked]>
Date: Fri, 10 May 2002 06:07:50 -0400 (EDT)

> Hmmm... I have a different model in mind, I guess: [Note the
> presence of the database subsystem.]
> 
> reachability and topological information is an example of a
> database (or databases) used to create destination-presence
> driven routing state.

Well, I was thinking in terms of what it is you're trying to
secure.... You can try to "secure" the topology information (in
some sense, though I'm not certain what that would be at the
moment?), and you can secure the destination information--can you
verify the source of this information, and is that source really
the right place to send traffic towards this destination?

But both of these fall into the current unicast structure--i'm
not certain you can divide the multicast domain in such a way,
nor MANET and such....

> Hope I'm not confusing much ;)

Actually, some time ago the concept of bgp just advertising what
as' different prefixes are attached to, then using some other
method of actually mapping out the as'. If a distance vector
system were used to map the as', then you would have such a
system. In fact, security in bgp today could be broken into these
pieces--is this as actually attached to the as that it claims to
be, and is the as which is sourcing this information actually
authorized to do so, and is the source really the as which claims
to be sourcing it?

Of course, the problem here is uncovering who is connected to
whom, which I'm not certain is palatable to most ISPs, since it
also reveals lots of interesting things, like who your customers
are, and who all you are peering with. With a little creativity,
you could use this information to map an isp's entire network, I
think.

And by tracking this sort of information on a historical scale,
you could uncover  business strategies, etc. I would not have a
hard time believing that this would be a security risk in and of
itself.

:-)

Russ