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

From: "Senthilkumar Ayyasamy" <[email-masked]>
Date: Mon, 22 Jul 2002 23:02:20 -0500

>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.
  I accept your point that all the above listed protocols have their own 
list of vulnerabilities. As russ mentioned in one of his previous mails, we 
can have many documents relating to threat models for different routing 
protocol/routing types. I think there are some documents already on table( 
but mostly solution space which is not the goal of this working group but 
may provide some pointers.)

    But my concern is requirement document should be generic enough to cover 
all issues be it mobility, unicast/anycast/multicast, routing algo. It 
should provide input to respective routing protocol WG for further work.

I have some queries:

1. Is there a need for separate security mechanism for routing and 
forwaring? Are their any tradeoffs ?

2. whether we need to have end to end security mechanism or between  peers?
-senthil

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

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

---

From: Alex Zinin <[email-masked]>
Date: Tue, 23 Jul 2002 00:53:45 -0700

Senthil,

> protocol/routing types.

I guess my point was that even though we have many, they do not have
to be in different models, they are just specific instances of
the transport subsystem.

> I think there are some documents already on table( 

We have the first approximation from Sandy and Dennis.
Russ mentioned on the list something else might be coming.

> should provide input to respective routing protocol WG for further work.

I agree, it should be generic. Note however, that even in a generic
document you can still have practically useful classification, which
is the case with transport, as well as, I believe, any other
subsystem. I'm really looking forward to seeing the second document
Russ mentioned, to see if I am convinced that we need more than
one model ;)

> forwaring? Are their any tradeoffs ?

I'm not really sure what you mean by security for forwarding.
Could you explain, please?

> 2. whether we need to have end to end security mechanism or between  peers?

Answering questions like this is one of the reasons we have this WG--we
need the community to agree on where the line between acceptable complexity
and acceptable security should be drawn. The requirements document is
supposed to answer these questions.

Alex

---

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

Alex,

> Could you explain, please?

I made mention of this in another reply, but I will spell it out here
in more detail.  With PIM, some of the message exchanges on the wire
occur to indicate that there is a host interested in a particular
group.  The message exchange identifies a receiver and causes
the creation of forwarding state in the routers.  In unicast, the
message exchanges do not identify receivers.  So, Senthil's question
is whether or not the differences between those types of messages
are great enough that there is actually a different threat model
for routing and forwarding.

Brian

---

From: Alex Zinin <[email-masked]>
Date: Wed, 24 Jul 2002 18:25:35 -0700

Brian,

  Quite interesting interpretation, I would say...

  Let me give you my perspective on this.

  First, routing vs forwarding. Let's not re-invent the wheel
  and stick with the currently accepted definitions, i.e.,
  in an overly simplified way, "routing" calculates the state
  that routers need for data packet forwarding, while "forwarding"
  is the actual process of relaying packets from one interface
  to another using the state calculated by routing.

  Regarding multicast state creation--it can be triggered either
  by the mechanisms within the multicast _routing_ protocols
  (employing router-to-router communication), such as PIM, or by
  the mechanisms within the _network_ protocols (employing host-to-
  router communication), such as IGMP. Network protocols are
  explicitly excluded from the charter of this WG, while routing
  protocols are explicitly included. The reason for this is that
  indeed the trust and security models for network protocols are
  quite different from those in the routing ones. For those who're
  interested in this topic, please tune in to SEND.

  Hope this helps.

-- 
Alex