Subject: Re: [RPSEC] Draft Status....

From: [email-masked]
Date: Mon, 22 Jul 2002 10:32:56 -0400 (EDT)

>Completely agree.  We should be seeing slightly different models
>based on different variables (e.g. IGP vs. EGP).

HM.  Having looked at security solutions for both OSPF and BGP,
I'm not convinced that the threat model is very different for the
two.  Certainly the threat actions are not different and the
threat sources are not different, though you might give them
different names.  The threat consequences have different scope
but are the same in definition.

Also - there are lots of different ways to characterize protocols:
- by scope (IGP vs EGP)
- by algorithm (link state vs distance vector)
- by underlying layer (link layer (well, maybe not), network, transport)
- by communication media (ATM (rather not touch that), wired, wireless)
- by routed traffic (unicast vs multicast vs ..)

I'm not sure that we should try to come up with threat models for
each different type in each way of assigning types - too much work.

The holy grail would be a general threat model, with perhaps instantiations
to various protocol types. Or instantiations to a small set of specific
protocols as examples.

If the intent of the threat model and security requirements are to
advise protocol designers, then making them specific to particular
characteristics of the protocol risks a loss of completeness, so that
the protocol designer would have no model/requirements that fit the
protocol being designed.  (OTOH, something terribly general might be
difficult to fit to a specific protocol - that's the challenge of writing
a general description.)

>Sounds reasonable.  I would prefer to have the routing protocol
>groups very involved.  Unless we can come up with a security
>mechanism that is protocol independent. :)

Mechanism?  I thought that our charter specifically discounted any
idea that we would come up with a mechanism.  It says "it is also a
non-goal at this point to produce new or change the current security
mechanisms in the existing routing protocols".  Evaluation and
documentation of mechanisms is listed as "possible future work".

--Sandy

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

---

From: Brian Haberman <[email-masked]>
Date: Mon, 22 Jul 2002 10:50:43 -0400

Sandy,

> but are the same in definition.

I see your point.  I was trying to point out that there may be
different models based on variables and picked IGP/EGP as an
example.  As you point, it probably wasn't a good example.

> - by underlying layer (link layer (well, maybe not), network, transport)

No, I think we need to stay away from that one.

> - by communication media (ATM (rather not touch that), wired, wireless)

How much does this differ from the link layer characterization?

> - by routed traffic (unicast vs multicast vs ..)

Agreed.  This could be a key distinction.  But since PIM relies
on the unicast routing table, we may be talking different
problem spaces.  Of course DVMRP has its own route exchange
which could be protected (not sure if it is worth the effort
though).

From the MSEC charter it seems that they are not interested in the
protection of any routing protocols, rather the group membership.

> each different type in each way of assigning types - too much work.

We just need to look at the different protocols to see if the threat
model varies.

> documentation of mechanisms is listed as "possible future work".

I wasn't talking about RPSEC specifically with that statement.

Brian

---

From: Alex Zinin <[email-masked]>
Date: Mon, 22 Jul 2002 20:01:16 -0700

Brian,

I agree with Sandy here. Please see some comments below.

Monday, July 22, 2002, 7:50:43 AM, Brian Haberman wrote:
...

> No, I think we need to stay away from that one.

Why? We have IS-IS, OSPF, and BGP that use link layer, IP, and TCP
as their transport. Each type of transport has its own set of
vulnerabilities.

> which could be protected (not sure if it is worth the effort

I think we should be able to cover both multicast and unicast RPs
within the same model if we make sure that the analysis of the
DB maintenance and rtg/fwd state establishment components includes
the instances used in PIM.

> We just need to look at the different protocols to see if the threat

right, as well as make sure that the model we come up with is
descriptive enough to cover at least the existing RPs and those
under development.

Alex

---

From: Brian Haberman <[email-masked]>
Date: Tue, 23 Jul 2002 09:48:46 -0400

Alex,

> as their transport. Each type of transport has its own set of

I think it becomes an issue of layering.

     1. Is RPSEC addressing the threats to the routing protocols?
     2. Will it address threats to TCP or UDP or IP?
     3. Will it focus on threats to TCP, UDP, and IP that can affect
        the routing protocols?

How much is different between #2 and #3?  I don't know.  My point was
addressed to the link layer aspect.  Looking at my comment, I didn't
make that very clear.

> the instances used in PIM.

I guess I am more focused on the protection of routing protocol
messages on the wire.  That is an area where the reason for sending
the message differs greatly between PIM and a unicast routing
protocol.  PIM messages (such as the join) actually indicate where
a receiver is located, there isn't an equivalent in unicast routing.

> descriptive enough to cover at least the existing RPs and those

Agreed.

Brian

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 23 Jul 2002 10:42:19 -0400

>      3. Will it focus on threats to TCP, UDP, and IP that can affect

As I mentioned at an IDR session (Minneapolis?), what the protocol
(in this case BGP) cares about is having a transport layer.
Transport layer security is important to the security of the
protocol, and a document should be documented to say what protections
should be applied to the transport layer to secure the routing
information at the transport layer.  However, we shouldn't need
a "secure transport layer <foo> for <bar> routing protocol".

So, for example, document the vulnerabilities in a given transport
protocol and hwo to secure it.  Examples of this are IPSec and TCP+MD5.
It would then be proper to point out that since a given protocol
uses a given tranport, that it should be secured per the
vulnerabilities document.  If there are special considerations,
these should also be pointed out.

Hopefully what this means is we end up with a small handful of
"securing transport layer <foo>" documents.  We will then have
a document per protocol (and per-extension if necessary) that says
"use the following security documents with the following additional
considerations".

Securing the protocol above the transport layer is a separate issue.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Wed, 24 Jul 2002 17:42:09 -0700

Brian,

> addressed to the link layer aspect.  Looking at my comment, I didn't

I hope my other message to the list also clarified this more.

> a receiver is located, there isn't an equivalent in unicast routing.

So, in your example, the commonalities will be: both protocols have
a transport system, both maintain state that is used to calculate
some sort of forwarding state, the difference is in exact messages,
and exact conditions under which the state is created and removed.

Alex