Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Fri, 15 Nov 2002 14:59:22 -0500 (EST)

Actually, I think that forwarding of data counts as "part of the routing
algorithm", since if we are concerned about a Byzantine failure of a router,
malicious behavior in forwarding can mess things up. For instance,
misforwarding packets and resetting the hop count. Or flooding the
network by generating bogus data. These sorts of things are
not solved by end-to-end encryption/integrity protection of data flows.

So I would have answered Yannis the opposite way on his first question...
that protection of forwarding *should* be a legitimate requirement.
What would NOT be a legitimate requirement is trying to keep routers
from snooping on the data...that would be
handled end-to-end. Modifying cryptographically protected data, although 
detectable end-to-end
would be something we should worry about, I think, because it is the
same as misrouting the data.
It's equivalent, more or less, to having the router drop the data. This
becomes especially annoying (to you) if a router behaves perfectly
well on the calculation of the forwarding tables, and behaves perfectly
well on forwarding everyone else's data, but mangles *your* data.

This even happens sometimes, where some link just doesn't like the
particular sequence of bits in your packet. So the link quality is great...
for everyone else, but for your packet, it never gets through. And
if the router has been maliciously programmed to discriminate against
you...

Firewalls of course do this on purpose...discriminating against some
packets based on whatever the firewall administrator configured.

So to summarize...our goal isn't to have routers calculate wonderful
forwarding tables, but rather to get the data to its destination. :-)

Radia

	From: Russ White <[email-masked]>

	This working group really only covers the secuiryt of routing,
	not forwarding traffic. I think for forwarding traffic, the
	general concensus is to encrypt the data flows, through something
	like IPsec.
	
	Byzantine robustness for routing would be a valid requirement.
	
	:-)
	
	Russ
	
	On Thu, 14 Nov 2002, Ioannis C. Avramopoulos wrote:
	
	>  Dear Security Researchers,
	> 
	>  is the protection of data packet forwarding a 
	>  legitimate requirement within this working group?
	> 
	>  Does the term "routing protocol" refer only to the
	>  acquisition of topological information and the 
	>  building of forwarding tables? Or it includes
	>  the data plane as well? Are the terms "routing
	>  protocol" and "routing system" defined somewhere
	>  and if not should they be?
	> 
	>  Are "Byzantine Robustness" and "Byzantine
	>  Detection", as defined in Radia Perlman's thesis,
	>  legitimate requirements?
	> 
	>  Regards
	>  Yannis
	> 
	> _______________________________________________
	> RPSEC mailing list
	> [email-masked]
	> https://www1.ietf.org/mailman/listinfo/rpsec
	> 
	
	__________________________________
	[email-masked] CCIE <>< Grace Alone

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

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

---

From: Tony Tauber <[email-masked]>
Date: Fri, 15 Nov 2002 15:25:04 -0500 (EST)

> forwarding tables, but rather to get the data to its destination.

I agree and suspect that this kind of distinction dissolves when
considering threats.  The threat isn't really to the protocols but to
the service that the network provides by using those protocols.
In this case, advertising reachability and not delivering on that
promise is clearly one of the threats we're already considering.

My intutition is that keeping our eyes on the pragmatic ball will
help greatly in steering through inevitable semantic distractions.

Tony

---

From: Russ White <[email-masked]>
Date: Fri, 15 Nov 2002 15:35:17 -0500 (EST)

> I agree and suspect that this kind of distinction dissolves
> when considering threats.  The threat isn't really to the
> protocols but to the service that the network provides by
> using those protocols. In this case, advertising reachability
> and not delivering on that promise is clearly one of the
> threats we're already considering.

The problem is that routing is a hop by hop affair.... Just
because you've secured the generation of a routing table doesn't
mean you've secured the forwarding of the packet. If we are to go
further than being able to verify/validate the routing
information, and into validating the forwarding information, and
forwarding behaviour, of each device in a network, the problem
becomes much more complex, and, I would argue, outside the pervue
of the routing group at all, most likely.

You would then be delaing with how to secure the devices
themselves against having false routing information manually
installed on them, for instance, and how to prevent the
forwarding table from being attacked through icmp redirects,
etc. This, then, would take us into the territory of passwords on
devices, etc.

Do we really want to go there?

:-)

Russ