Subject: Re: [RPSEC] Re: Potential Requirements New Thread

From: [email-masked]
Date: Wed, 13 Nov 2002 08:07:34 -0500 (EST)

>-- The ability to verify the path the update has taken.

This is important in BGP, since it's part of the protocol info used
in making decisions.  But do you think it is important in all routing
protocols?

In OSPF, for example, the flooding technique could conceivably make
the same LSA reach you through lots of different paths and the path
matters very little (not at all, except perhaps for timing issues?)
in how the protocol or even subsequent forwarding behaves.

In wireless protocols, sometimes the path matters quite a bit in
the protocol (e.g., DSR records the path) and in others it doesn't.

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

---

From: Russ White <[email-masked]>
Date: Wed, 13 Nov 2002 08:38:47 -0500 (EST)

> This is important in BGP, since it's part of the protocol
> info used in making decisions.  But do you think it is
> important in all routing protocols?
> 
> In OSPF, for example, the flooding technique could
> conceivably make the same LSA reach you through lots of
> different paths and the path matters very little (not at all,
> except perhaps for timing issues?) in how the protocol or
> even subsequent forwarding behaves.
> 
> In wireless protocols, sometimes the path matters quite a bit
> in the protocol (e.g., DSR records the path) and in others it
> doesn't.

Agreed.... I'm actually wondering how much of a difference
knowing the path in BGP makes. The path of the update doesn't
necessarily dictate the path of the packet following a given
route, so it doesn't secure the path. And the path is used in the
decision process only as a way to prevent loops (being a first
level tie breaker is only incidental, really).

The only part of the path that really seems to matter is:

-- Knowing the origin 
-- Knowing that the origin actually originated this prefix

The only time the entire path seems really useful is if you are
certain the packets will be taking that same path, and since IP
is a hop by hop protocol, I don't know that you can tie the two
together.

:-)

Russ

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Nov 2002 15:00:36 +0100 (CET)

> is a hop by hop protocol, I don't know that you can tie the two

So look at the part of the path that is relevant to you: the next hop.
That means you need a mechanism to correlate the origin with the next
hop. But then, maybe the next hop itself is valid, but the router there
made a mistake. So you'll end up validating the whole path anyway.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Nov 2002 11:51:57 -0500

>is a hop by hop protocol, I don't know that you can tie the two

I strongly disagree. If we only know the origin AS is authorized to 
advertise a prefix, then there are myriad ways for an AS that is not 
authorized to advertise a path for the prefix to hijack the route, 
e.g., merely by claiming that yes, eventually, this unauthorized AS 
promises to route the data to the correct origin. The fundamental 
requirement for making BGP routing UPDATEs secure is simple and 
directly derived from BGP semantics:

	for each prefix, you need to know that every AS along the 
path is authorized to advertise the prefix by the preceding AS, and 
that the origin AS was authorized to advertise the prefix by the owner

Any deviation from this basic model will result in vulnerabilities 
that can be exploited to cause black holes, etc.

I have not studied the soBGP documents in detail, but my impression 
is that the soBGP proposal would fail to protect against these sorts 
of attacks. (In part the confusion stems from the fact that the soBGP 
documents seem to be less than clear about exactly what will be 
protected other than the origin AS info.)

Steve