Subject: [RPSEC] Interoperation between solutions

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Nov 2002 19:35:04 +0100 (CET)

We may end up in a situation where part of the internet uses S-BGP and
another part uses soBGP. We need something to make the two work
together. Proposed requirement:

	An interdomain routing protocol security solution must have
	provisions to allow the use of proxy validation servers between
	areas of the network where the solution is used, and other areas
	of the network where other solutions are in use. It must be
	possible to determine the real origin of the routing
	information that has passed the proxy server, but validation of
	this information must be based on the proxy server's credentials
	and a possible implicit or explicit indication of the security
	level of the original information, as determined and validated
	by the proxy server. Information passing a proxy server shall
	not be given a higher security level than that warranted by the
	proxy server's credentials, even if the proxy server indicates
	the original information has a higher security level. The
	security level of individual proxy servers must be configurable.

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Nov 2002 14:09:24 -0500

>	security level of individual proxy servers must be configurable.

I think this suggestion is getting way ahead of what this WG is supposed to do.
It has the flavor of "I know what the answer is and I want to make 
sure we craft requirements that accommodate my idea of the right 
answer."

This WG is supposed to develop security requirements for routing 
protocols.  We have had a lot of discussion of S-BGP as an example, 
but it's adoption and deployment is far from certain and ought not be 
the focus of most of our discussions. soBGP is very, very new. I know 
of no published papers analyzing it from any perspective: security, 
performance, etc., unlike S-BGP.  So unless you believe that the 
corporate affiliation of its authors automatically ensures its 
adoption (hardly an IETF way of doing business), it is even less 
certain to be adopted or deployed.

This sort of requirements gerrymandering is very inappropriate.

Steve

---

From: Tony Tauber <[email-masked]>
Date: Tue, 12 Nov 2002 14:31:48 -0500 (EST)

> I think this suggestion is getting way ahead of what this WG is

Complete agreement.

The S-BGP and so-BGP things may be timely and/or coincident with some
current themes in the community and world around us.  They also might
provide decent food for thought or discussion but are not the primary
mission of this WG whatsoever.

Let's focus on the threats drafts.

Tony

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 12 Nov 2002 14:49:04 -0500

... there are the distinctions between network element signaling (common
control) and forwarding and control seperation... 

i'm just a hobbist now, but the several times i worked on things that ran
routing algorithms, the distinctions seemed helpful.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Nov 2002 21:50:21 +0100 (CET)

> I think this suggestion is getting way ahead of what this WG is supposed to do.

Well, it's in the archive now to be scooped up whenever the time for it
to be relevant comes.

> the focus of most of our discussions. soBGP is very, very new.

So when Z-BGP and xyBGP are deployed we need something to make those
work together. And with the currently deployed BGP security measures.
The requirement is a valid one. I'll try not to make the mistake of
citing work in progress to show the relevance of a requirement again.

> I know of no published papers analyzing it from any perspective: security,
> performance, etc., unlike S-BGP.

The fact that S-BGP behavior is better documented doesn't mean the
behavior is better.  :-)

> So unless you believe that the

I believe soBGP has several very interesting properties which may help
it catch up with S-BGP in a relatively short time. On the other hand,
S-BGP couples the light touch of an elephant to the strength of one, so
I'm not about to underestimate it.

But the real solution is to abandon BGP as its architecture just isn't
suitable for all of this. Each route is treated as an individual entity.
This is an example of a poorly normalized database. Having a good
"database design" for a routing protocol makes securing it much easier
while at the same time minimizing convergence times. But here I go
talking about solutions again...

Iljitsch