soBGP deployment

Mailman List Mirror (Read Only)
1

something like it, for sure. but i vastly prefer the s-bgp
approach as it maps closely to bgp operational reality, and does
not rely on a published policy database, which we have seen fail
for over a decade, etc.

So, can someone point out the important operational differences
between the two?

From 10K feet view, the only major difference seems to be that sBGP

also wants to protect the BGP sessions w/ IPsec all in one solution.
(Personally, I don't care about that all that much, and I have some
doubts whether this is a good approach for deployability in mind.)

The IPsec piece is actually the least important part of the difference.

Maybe the important operational differences are only observable
from 1K feet view ?

Fundamentally, the answer to this question is this: how accurate do you
think the routing registries are?

Both do a good job preventing fraud at the putative point of origination
of the route announcement. This is obviously the most common form of
attack.

With SBGP, each node signs the BGP statements it's about to send out.
The accuracy of the security statement is thus linked to the
transmission process. With SO-BGP, the security against in-path
attacks (or cut-and-paste attacks; see below) relies on a secure
version of the routing registry. If an AS forgets to update its
routing registry to reflect new BGP adjacencies, paths containing them
will be dropped by SO-BGP listeners. If old adjacencies aren't
deleted, routes that shouldn't be accepted will be. In other words,
there's a lot less coupling between the transmission process and its
security properties. Look at it this way: do you think that (a) most
sites will publish their policies in the registry, and (b) they'll
remember to update them? As Randy has noted, we have a decade of
experience suggesting that neither is true.

Let me add a word about cut-and-paste attacks. A signed origin
statement asserts that some AS owns some prefix. That statement will
be readily available. A nefarious site could cut that statement from
some actual BGP session and prepend it to its own path announcement.
That would add a hop, but many ASs will still prefer it and route
towards the apparent owner through the nefarious site. The nefarious
site wouldn't forward such packets, of course; it would treat the
packets as its own.

    --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

2

With SBGP, each node signs the BGP statements it's about to send out.
The accuracy of the security statement is thus linked to the
transmission process. With SO-BGP, the security against in-path
attacks (or cut-and-paste attacks; see below) relies on a secure
version of the routing registry. If an AS forgets to update its
routing registry to reflect new BGP adjacencies, paths containing them
will be dropped by SO-BGP listeners. If old adjacencies aren't
deleted, routes that shouldn't be accepted will be. In other words,
there's a lot less coupling between the transmission process and its
security properties. Look at it this way: do you think that (a) most
sites will publish their policies in the registry, and (b) they'll
remember to update them? As Randy has noted, we have a decade of
experience suggesting that neither is true.

Yet, what is the (SBGP) alternative?

I don't think we have much success distributing this kind of certificates in similar scenario either. At least we _do_ have some (limited) experience and even success in recording the prefixes in routing databases, and adding a signature there would be easy.

There's nothing to say the functional equivalent of certificate could also not be passed in an option or some other means as well when needed. My assumption would be that being able to use public databases would be a protocol optimization.

Compare this to the situation when BGP filtering is done by automatically generating the prefix lists. How would enhancing that to include a signature (and/or certificate) make matters worse or inefficient? Is there any reason to believe using a different approach would fare any better?

Note that the original soBGP didn't require any updates when the peering relationships changed; based on a quick look, a later extension has probably changed this.

Let me add a word about cut-and-paste attacks. A signed origin
statement asserts that some AS owns some prefix. That statement will
be readily available. A nefarious site could cut that statement from
some actual BGP session and prepend it to its own path announcement.
That would add a hop, but many ASs will still prefer it and route
towards the apparent owner through the nefarious site. The nefarious
site wouldn't forward such packets, of course; it would treat the
packets as its own.

Note that there's no technical reason AFAICS not to tie the signed origin statements to the origin's AS number, i.e., if someone would want to hijack a prefix, it would need to spoof the AS number as well. Not sure if that helps a lot, of course.

But this is a good point -- I think a fundamental question that needs to be asked is whether a sufficient security could be gained by just the originator and the verifier doing the cryptographic operations, and not requring everyone in the middle also do them (adding signatures etc.). Personally I'd certainly hope so -- because the practical deployment issues with the on-the-path signing model seem prohibitive (too much 3rd party deployment required before the solution would be useful).

3

<SNIP>

Let me add a word about cut-and-paste attacks. A signed origin
statement asserts that some AS owns some prefix. That statement will
be readily available. A nefarious site could cut that statement from
some actual BGP session and prepend it to its own path announcement.
That would add a hop, but many ASs will still prefer it and route
towards the apparent owner through the nefarious site. The nefarious
site wouldn't forward such packets, of course; it would treat the
packets as its own.

At least in that case you can quite easily identify the culprit when one
find out who it is, as the AS the path is going over is really the
culprit announcing it. And as one can identify the culprit one can
easily exclude this culprit from ever doing any business with you again,
which is also a great thing for protection against spamruns, announcing
some prefix for a few moments, spamming and removing it again as they
will have to get a new ASN to do it from. ASNBL anyone? :slight_smile:
Of course one can also nicely blacklist the ASN's who allow those
hostile ASN's to be connected and so on.

IMHO s(o)BGP is a good step forward and I hope that it will get
deployed, the sooner the better.

Greets,
Jeroen

4

Yet, what is the (SBGP) alternative?

that the assertion of as-path is produced by the very bgp
sessions themselves. simple and congruent, relying on no
other data, and can vary in real-time.

I don't think we have much success distributing this kind of
certificates in similar scenario either.

this is not cert distribution. all secure bgp proposals have
the pki issue.

At least we _do_ have some (limited) experience and even success
in recording the prefixes in routing databases

rofl. the irr is a notorious disaster and has not improved in
time. and i have been a long-term supporter. it just has not
worked.

and this aside from the whole design issue of keeping the irr in
sync with reality, protecting it from attack, ... when someone
suggests keeping data in two places, this red flashing light goes
off and sirens start.

Note that the original soBGP didn't require any updates when the
peering relationships changed; based on a quick look, a later
extension has probably changed this.

one of the 29 hacks to sobgp to try to fix this and that (kinda
like w's social security program). this one was to address the
attested as-path problem, which s-bgp solves so elegantly.

But this is a good point -- I think a fundamental question that needs
to be asked is whether a sufficient security could be gained by just
the originator and the verifier doing the cryptographic operations,
and not requring everyone in the middle also do them (adding
signatures etc.).

you have to or a monkey in the middle can divert the traffic.

randy

5

With SBGP, each node signs the BGP statements it's about to send out. The accuracy of the security statement is thus linked to the transmission process. With SO-BGP, the security against in-path attacks (or cut-and-paste attacks; see below) relies on a secure version of the routing registry. If an AS forgets to update its routing registry to reflect new BGP adjacencies, paths containing them will be dropped by SO-BGP listeners. If old adjacencies aren't deleted, routes that shouldn't be accepted will be. In other words, there's a lot less coupling between the transmission process and its security properties. Look at it this way: do you think that (a) most sites will publish their policies in the registry, and (b) they'll remember to update them? As Randy has noted, we have a decade of experience suggesting that neither is true.

There is no "registry." Each AS distributes set of certificates carrying a list of who they're connected to. You can, as an option, list who you allow to transit, and who you don't allow to transit, and other policies (nothing longer than prefix length x within this address block, etc). But, there's nothing saying you _must_ send any sort of _policy_ out. It's even possible to build the certificates so you can "hide" peering relationships you don't want to be known about by anyone other than the specific peers involved (by building multiple certificates of specific types, and filtering who you send them to).

As for updating the information--each AS originates it's own piece, just like they do routes today. If they keep their routes up to date, there's no reason not to update your peering information in a certificate you're originating. It's not as if you have to make a phone call to the local RR, and have them update their database, etc....

Let me add a word about cut-and-paste attacks. A signed origin
statement asserts that some AS owns some prefix. That statement will
be readily available. A nefarious site could cut that statement from
some actual BGP session and prepend it to its own path announcement.
That would add a hop, but many ASs will still prefer it and route
towards the apparent owner through the nefarious site. The nefarious
site wouldn't forward such packets, of course; it would treat the
packets as its own.

Huh? :slight_smile: Since soBGP doesn't put anything in the existing BGP packets at all, there's nothing to "cut and paste" from one packet to another (?). You can "make up" paths, I suppose, but you'd have to make one up that:

-- already exists
-- has one end anchored at the receiving AS
-- has the other end anchored at the originating AS

That's a pretty narrow range of "made up paths." When you start factoring in aggregation of routing information, you quickly realize there are much larger holes in aggregation than the "hole" of replacing one path that exists with another path that exists.

As for deploying this on a 2500--well, that's never been envisioned. The entire architecture has always been envisioned as running either on _or_ off box, where you could do the crypto part once on an "soBGP server," and then let the routers on the edges ask this "server" about the routes they receive. This is explicitely called out as the most likely deployment possibility in the current architecture draft, and also in evvery presentation we've ever given on it.

Of course, you can always do it on box, as well, given the box in question has the resources available. It's also possible, with the current architecture, to spread the certificate processing (the crypto part) across all the edges of an autonomous system. I don't know how well thought that part is, at this point, but we've always intended to allow that sort of thing to be done, as long as we can figure out how to do it and not break anything. :slight_smile:

:slight_smile:

Russ

6

Note that the original soBGP didn't require any updates when the
peering relationships changed; based on a quick look, a later
extension has probably changed this.

one of the 29 hacks to sobgp to try to fix this and that (kinda like w's social security program). this one was to address the attested as-path problem, which s-bgp solves so elegantly.

*sigh*

There were no "hacks" to "solve" this "problem."

The certificates can be issued as the originating AS wants to. If they believe losing all connectivity to a peering AS (all possible peering points) is worth issuing a certificate for, they can. There's no requirement to do, since it depends on local policy (this might be a short outage, and the security risk of leaving the connection in place in the certificates might be very low--it's a situation by situation thing). There is no concept of a "peering point" within soBGP, just the whether or not two AS' are actually connected. There's no way to tell, from soBGP, how many times, or in how many places, two AS' are connected (unlike S-BGP).

IMHO, there aren't going to be many cases where Sprint, for instance, loses every possible peering point with UUNET. I could be wrong, but it seems just beyond this side of improbable, to me.

:slight_smile:

Russ

7

There's nothing to say the functional equivalent of certificate could also not be passed in an option or some other means as well when needed. My assumption would be that being able to use public databases would be a protocol optimization.

I think people here are missing fundamental issue. It is not with how in particular signed data is passed (although that is important and certainly
SBGP is doing it in more secure way then soBGP ) but with who can vouch
for the signed data, i.e. its the distribution of authoritive data.

It should be understood that its not only that you need to lookup policy for ASN and see if it can announce ip block but it should be possible to
verify that ip block owner gave that ASN permission to announce the block,
The way it should work is that ASN gives ip block owner its cert, ip block
owner signs it with its private key and the new signed cert is given back to ASN. Now ASN can give this cert to anybody else and they can verify
(assuming access to public key of ip block owner is available) that
ASN has right to announce the block.

For peer relationships it works in similar way, when ASN1 wants ASN2 to
announce its routes, it asks ASN2 to give it its public cert, then ASN1
signs the cert and gives it back to ASN2.

Now here is worst part, ip block owner can not be trusted just because
they gave you certificate that says 192.168.0.0/24. IP block owner's certificate itself should be signed by known trusted party that can vouch for that block owner, i.e. whoever gave the ip block, i.e. RIR or another RIR that allocated the block.

So to get this all in place and working we need to develop a complete
root->enduser public key distribution infrastructure working all the way from RIR to the LIR to ISP and from one ISP to another and I don't see
it happening. Right now RIRs only recently started offering X.509 certs for updating whois (and ARIN, for example specifically said their cert is to be used only when talking to ARIN and is not intended for anything else) so the next step is try to to test if same cert can be used for
signing data related to routing policies and if it works then we should
begin to be worried on how best to distribute the end-resulting signature.

Regarding distribution, I think routing registry is fine for initial
deployment (as long as root certificate is signed by known trusted authority,
which is one of the RIRs) as that can be done faster and it is less intrusive
on BGP infrastructure. Ones we have some success with routing registries
and signed data, then we can work further start moving with signed data
those who do not support it do not suffer, so basically a new parameter would be required for peering setup for both sites when they want to
talk "S-BGP" and it would be necessary for all routers in the middle to
support it for end-end to work.

Let me add a word about cut-and-paste attacks. A signed origin
statement asserts that some AS owns some prefix. That statement will
be readily available. A nefarious site could cut that statement from
some actual BGP session and prepend it to its own path announcement.
That would add a hop, but many ASs will still prefer it and route
towards the apparent owner through the nefarious site. The nefarious
site wouldn't forward such packets, of course; it would treat the
packets as its own.

Note that there's no technical reason AFAICS not to tie the signed origin statements to the origin's AS number, i.e., if someone would want to hijack a prefix, it would need to spoof the AS number as well. Not sure if that helps a lot, of course.

As I described that above, it would not help with "man in the middle" if
that middle ASN adds an appropriate origin ASN in its announcement and the path itself is not signed.

But this is a good point -- I think a fundamental question that needs to be asked is whether a sufficient security could be gained by just the originator and the verifier doing the cryptographic operations, and not requring everyone in the middle also do them (adding signatures etc.). Personally I'd certainly hope so -- because the practical deployment issues with the on-the-path signing model seem prohibitive (too much 3rd party deployment required before the solution would be useful).

A full solution is of course having each "middle-ASN" further sign the
prefix it is transmitting, but I can only see that happening and working properly if SBGP id deployed slowly for each router and that would take
long time.

Quick way out that is using certificates that allow to verify peering relationship (but not necessarily actual route announcement). But that does require going through each "ASN1 ASN2" pair in routing table and trying to check if its correct - would require specially designated equipment to sort out all these relationships and cache cryptographic or verification information.

8

There's a very simple reason why registries have not been
kept up to date over the past decade -- many operators do
not use them for generating their policy configurations. Given
this situation, it's difficult to draw any conclusions
from the last decade. If you look back to the NSFNet days
(prior to a decade ago) and the PRDB (Policy Routing Database),
you might very well draw a different conclusion. The PRDB was
kept up to date because a database entry was required to
transit the NSFNet.

   This is not to imply that registries should play anything
more than an interim role. Nonetheless, there would seem
to be opportunities to improve current operational practices
until more secure solutions are deployed.

-Larry Blunk
  Merit

9

If you look back to the NSFNet days (prior to a decade ago) and
the PRDB (Policy Routing Database), you might very well draw a
different conclusion.

indeed, one of utter disaster. it would take days or weeks
before one could route a prefix.

randy

10

I suspect this was due to the fact that template submissions
were not fully automated at the time and required human
review (disclaimer: I worked for the MichNet side of Merit
back then and was not intimately familiar with PRDB
operations).

-Larry

11

my weak memory, it was due to a number of factors, some in the
database update workflow, some in the uneven usage workflow,
e.g. ans updating once, or was it twice, a week.

but this just underscores the difference here

  o with sbgp, the assertion of the validity of asn A announcing
    prefix P to asn B is congruent with the bgp signaling itself,
    A merely signs the assertion in the bgp announcement.

  o with sobgp, the assertion is in an external database with
    issues such as
    - data correctness & completeness
    - data consistency
    - update frequency
    - granularity (bgp is per-prefix, and this is used by real
      folk to do traffic eng etc). consider the mess of keeping
      this up to date and correct in a super irr.
    - etc

its the old simplicity vs complexity game yet again

randy

12

  o with sbgp, the assertion of the validity of asn A announcing
    prefix P to asn B is congruent with the bgp signaling itself,
    A merely signs the assertion in the bgp announcement.

  o with sobgp, the assertion is in an external database with
    issues such as

This is nonsense. Did you even read the soBGP drafts?

In S-BGP the certificates are carried in path attributes, in soBGP in a new BGP message. Other than that, they do not differ in this regard.

And unless the implementations are stupid, it should be simple enough to use a web of trust rather than a fixed trust hierarchy, so the RRs don't (necessarily) come into play.

its the old simplicity vs complexity game yet again

Do I hear you say that S-BGP is less complex than soBGP??

13

but this just underscores the difference here

its the old simplicity vs complexity game yet again

Why should the IETF be making the tradeoff decision
here rather than the operators?

It seems to me that a more workable solution in today's
Internet, is to decouple the definition of the information
exchanged by network operators from the protocol used
to exchange the information. It should be possible
to design a system in such a way that a network operator
can choose whether or not to do this job directly on
their BGP-speaking routers or whether to offload it
onto some type of route-registry database system.
In fact, it should be possible for a single AS to
vary which model it follows because in larger networks
there is less homogeneity, i.e. some BGP routers are
far more mission critical and carry higher traffic
levels than others.

Rather than looking for something that is 100%
overloaded on the BGP-speaking routers, why not
give network operators the tools to make their own
80-20 decisions about where this network management
function should be handled?

--Michael Dillon

14

It could have been the tools. (I can't argue, I wasn't there.)

Here's another thought. Much like the comparison of SSH and DNSSEC in this reply of mine from last March:
     http://www.merit.edu/mail.archives/nanog/2005-03/msg00694.html

I.e., the "mythical core" needs work. This time it's the address organizations and routing elements.

Yet another thought. Skimming through this thread, and only being slightly aware of sBGP and soBGP in past years, some concepts remind me of work under DARPA's Active Nets research done in the late 90's. (http://www.darpa.mil/ato/programs/activenetworks/actnet.htm)

Some things I learned then:

1) Keep the security ancillary data nearby. You might need it when the source of the data is unreachable (perhaps because of an incident like a flood).

2) Appending signatures is dicey. It has to be all public key and there's never a guarantee that the latest signer hasn't stripped out previous entries. (That could make a longer path seem shorter in order to redirect traffic.)

IMHO - the inherent problem is that a router is trying to work inside the plane of activity (meaning it can only talk to it's nearest neighbors), but it takes the view point of something with ubiquitous knowledge to know if every thing is cool. How can you do this without a trusted third party involved somewhere, in a way that is not obtrusive (whether at registration time or at run time)?

Dijkstra's shortest path algorithms (an example IGP) work "in the plane" because it manages to mimic the ubiquitous view. You aren't afraid that someone is "not playing my the rules." When you are working with security (algorithms), you don't have that safety belt.

And a final thought...

Security ought to not make the system being protected brittle. Like the example of routing changes being held up until the paperwork went through - maybe an improvement in tools will enable this. But think of the long term impact - who will be paying to keep the tools and system up to date?

15

Security ought to not make the system being protected brittle. Like
the example of routing changes being held up until the paperwork went
through - maybe an improvement in tools will enable this.

It should be possible for a network operator to make
their own policy decisions on this. Some may choose to
accept uncertified routes in certain address ranges
because this makes their network less brittle. Others
may consider the brittleness to be a feature because
it tends to highlight deficiencies with the 3rd
party tools, databases, systems, which should be fixed.
Consider the phone number translation databases used
for number portability. If they are not updated when
a telephone moves to another location, then the service
is disrupted. If PSTN operators can find a way to
share and synchronize a number portability database,
then why can't network operators do something similar?

--Michael Dillon

16

1) Keep the security ancillary data nearby. You might need it when the source of the data is unreachable (perhaps because of an incident like a flood).

That is why in my view soBGP is something that can only be deployed as an after-filter (i.e. ones full BGP mesh is in for decisions about if the routing data is to be passed along to other peers or to IGP).

2) Appending signatures is dicey. It has to be all public key and there's never a guarantee that the latest signer hasn't stripped out previous entries. (That could make a longer path seem shorter in order to redirect traffic.)

IMHO - the inherent problem is that a router is trying to work inside the plane of activity (meaning it can only talk to it's nearest neighbors), but it takes the view point of something with ubiquitous knowledge to know if every thing is cool. How can you do this without a trusted third party involved somewhere, in a way that is not obtrusive (whether at registration time or at run time)?

You do need "trusted third party" to act as PKI root signer. We're lucky
because unlike other places, we do have hierarchy with ip addresses and
ASNs and NIR is the "root" organization.

17

for the old-timers.... this is not quite sBGP or soBGP, but does
have many of the desirable traits.... for the new kids on the block,
if ISPs want to do this, its something they can do themselves, w/o
centralized coordination, on an incremental basis.

http://www.isoc.org/inet98/proceedings/6h/6h_3.htm

--bill

18

Don't confuse cryptography with security.

You need one trusted third party to arrange for the cryptography to scale (work). You need a different third party to help authenticate (secure) the routing data.

IMHO, you don't necessarily want these two third parties to be the same.

19

I suspect the right thing to do is to ask why soBGP and sBGP have failed?

And yes, they've failed. Just like DNSSec, we aren't seeing even limited
adoption. Why? Too complex, too many moving parts, too much reliance on iffy
third parties and requires mass adoption.

I suggest that the community finds something that gives us most of what we
want, is simple to understand, and can be implemented in a piece-wise
fashion. Look at SPF - not perfect, but certainly useful. It is simple, easy
to implement, and IS being implemented.

One of the Internetworking community's biggest problems is a fixation on the
perfect solution. Its natural - we're engineers, after all. We want an
elegant 100% solution to our ills. This often leads to something that never
gets implemented in real life.

Why not do something simple? The in-addr.arpa reverse delegation tree is
pretty accurate. We use it for lots of different things. Why not just give
IP address blocks a new RR (or use a TXT record) to identify ASN? This
solves the biggest problem we have right now, which is stealing of address
blocks. It requires little processor overhead, and only a few additional DNS
lookups. Its reasonably foolproof.

Why create reliance on more databases? The RIRs are iffy. We rely on DNS
right now. Why not keep relying on it? This solution doesn't solve all of
our problems, but it does help, its easy, and people will implement it.

Ok, please start flaming now :slight_smile:

- Dan

20

I suspect the right thing to do is to ask why soBGP and sBGP have failed?

And yes, they've failed. Just like DNSSec, we aren't seeing even limited
adoption. Why? Too complex, too many moving parts, too much reliance on iffy
third parties and requires mass adoption.

I suggest that the community finds something that gives us most of what we
want, is simple to understand, and can be implemented in a piece-wise
fashion. Look at SPF - not perfect, but certainly useful. It is simple, easy
to implement, and IS being implemented.

<sidetrack>

SPF gets implemented by a few. I won't implement it simply because it
will break my mailsetup because the mechanism format does not allow
optional mechanisms to be defined eg, if I would use in DNS:
"v=spf1 ip6:2001:db8::/48 -all"
Any host which implements SPF checks but does not know how to do ip6
checks, even though the message went 100% through an IPv6 only path will
drop the mail in the trashcan, even though the mail is 100% legit.
But this is a non-issue of course as everybody uses IPv6 only... just
like nobody uses DNSSec and other cool toys.

</sidetrack>

<SNIP>

Why not do something simple? The in-addr.arpa reverse delegation tree is
pretty accurate. We use it for lots of different things. Why not just give
IP address blocks a new RR (or use a TXT record) to identify ASN? This
solves the biggest problem we have right now, which is stealing of address
blocks. It requires little processor overhead, and only a few additional DNS
lookups. Its reasonably foolproof.

<sarcastic smiling comment> But you are the fool here </sa....>

So your router boots and receives a prefix and then you are going to
check using the just received prefix if it is legit to be sent from that
ASN, remember that it was just faked :slight_smile: Or do it before you get it and
thus don't have a route...

L3 on L3 dependencies don't work unfortunately.

I am really glad the IETF has a lot of people who catch above things
quite easily because of expertise and experience.

Btw "pretty accurate" is not good enough unfortunately...

Greets,
Jeroen