On Fri, 20 May 2005, Christopher Woodfield wrote:

implemented realistically at the single-peer level the paper mentions. Just don't ask me to run it on a GRP-B.

I think it'd be running on even your customer's 2500... and your 7500 and your 7200. :) hurray! :)

In message <Pine.LNX.4.61.0505212143090.1930@netcore.fi>, Pekka Savola writes:

On Sat, 21 May 2005, Randy Bush wrote:

...

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

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

On Sat, 21 May 2005, Pekka Savola wrote:

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 sent with BGP but that should be done slowly in the way that makes sure 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. -- William Leibzon Elan Networks william@elan.net

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? :-) 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. :-) :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone

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

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

In message <B6DE33ED-0C90-46A1-ACD9-329F10905B0B@muada.com>, Iljitsch van Beijn um writes:

On 23-mei-2005, at 17:39, Randy Bush wrote:

...

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.

Randy isn't talking about certificates, he's talking about how you tell if a path is legitimate. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

the certificates are carried ... in soBGP in a new BGP message.

btw, am i supposed to be cheered by yet another overloading of bgp? randy

...

...

the certificates are carried ... in soBGP in a new BGP message. btw, am i supposed to be cheered by yet another overloading of bgp? Well gee Randy, I think you would have been happy. Here we are carrying related data in the same place.

related, but not congruent. so it is just another transport, and one which provides no advantages, e.g. security, over any other transport for the same data. randy

...

...

the certificates are carried ... in soBGP in a new BGP message. btw, am i supposed to be cheered by yet another overloading of bgp? Since S-BGP overloads signatures into the current packet formats, destroys packing, and destroys peer groups, I'm not certain that you can make the claim that S-BGP has a "lower impact" on BGP than soBGP does.

then i guess i am very lucky not to have made such a claim. the point is that sbgp's changes, while more than one might prefer, are made so that congruent data, path attestation, can be carried in-band. i consider the trade-off worthwhile for the seriously improved security, which is the point of the exercise. randy

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.

This is specifically how soBGP is designed. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone

At 11:27 -0400 5/23/05, Larry J. Blunk wrote:

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).

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? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.

On Mon, 23 May 2005, Edward Lewis wrote:

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. -- William Leibzon Elan Networks william@elan.net

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 :) - Dan On 5/23/05 1:45 PM, "bmanning@vacation.karoshi.com" <bmanning@vacation.karoshi.com> wrote:

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

On Mon, May 23, 2005 at 08:15:15PM +0200, Jeroen Massar wrote:

On Mon, 2005-05-23 at 14:00 -0400, Daniel Golding wrote:

...

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 :) 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

ah... but my old hack did -NOT- have the circular dependency you point out (and not for the last time either...) and yes, thanks to the IETF for being on top of this. --bill

One correction: I shouldn't have said: "The RIRs are iffy". It should have been "The IRRs are iffy". A world of difference. I understand the limitations. However, no one is rushing to implement most of the things that folks in this thread are obsessing over: DNSSec, IPV6, sBGP, soBGP. A bizarre assertion was made that only a "few" are implementing SPF, which is demonstrably untrue. Its getting implemented because its easy, not because its complete. This obsession with perfection will (as usual) result in exactly no progress. Folks need to be willing to get 70% of the benefit for 10% of the effort. - Dan On 5/23/05 2:33 PM, "Edward Lewis" <Ed.Lewis@neustar.biz> wrote:

At 14:00 -0400 5/23/05, Daniel Golding wrote:

My reply is mostly tongue-in-cheek. I think it's always healthy to explore alternatives.

...

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.

I'll ignore that you said "(or use a TXT record)". ;)

Without DNSSEC, what does this buy? "Secure" information on a non-secure channel.

If, by "stealing addresses" you mean that the RIR records are changed, then changing the name servers is trivial - changing to servers that have the hijacker's preferred data (or none!).

...

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.

Who populates the DNS (well, the .arpa domain)? The RIRs do.

...

Ok, please start flaming now :)

Brave to make such a request on a Monday afternoon.

At 3:24 PM -0400 2005-05-23, Daniel Golding wrote:

A bizarre assertion was made that only a "few" are implementing SPF, which is demonstrably untrue.

It depends on whether you're talking about "few" relative to the number of mail systems in the world, or "few" relative to the number of users served by those mail systems. If you're talking about users, then all you have to do is implement SPF at a few large sites like AOL, where they don't support forwarding and therefore they don't care if they break forwarding, where they want to force everyone to use their outbound mail relay servers anyway, etc.... Do that, and you've got a "majority". If you're talking about mail systems, it's a whole different picture. Setting up TLSSMTP or SMTPAUTH is non-trivial, even for experienced admins. Indeed, many experienced admins may own their own domains, but not run their own machines. Even if the server side is capable of supporting TLSSMTP and/or SMTPAUTH, they may well be using clients which are not capable of doing so, or not capable of doing so interoperably with the server side. Much, much more difficult to get large numbers of installations. Penetration of SPF is pretty low, and it's likely to stay that way for the foreseeable future. The problems with SPF are pretty basic, and I don't see them being eliminated any time soon with a casual wave of your royal hand.

This obsession with perfection will (as usual) result in exactly no progress. Folks need to be willing to get 70% of the benefit for 10% of the effort.

And if twelve people told you that you'd have to implement twelve different incompatible systems, and each of them would give you a different 70% of the benefit for 10% of the effort (but only if they were the only solution implemented), what would you do? The IETF has taught us that multiple incompatible partial solutions is not a particularly desirable outcome. That way lies madness. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

At 04:00 AM 24/05/2005, Daniel Golding wrote:

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.

Or maybe, jut maybe, because we've never had the tools to deploy it. Lets face it, larger operators, and probably small operators, are not protocol or code developers by nature. Operational skills are strongly honed on process definition and subsequent adherence to process, as well as skills in box opening ( :-) ). However, I suspect that this circular argument of vendors claiming customers never demanded it and customers saying that vendors never supplied it is largely an irrelevancy, and to infer from it that the entire activity space is moribund is perhaps stretching this particular set of excuses relating to inactivity a bit too far. The issue is that we all really do not appear to appreciate the disturbing nature of the risks here, and consequently we really don't value measures that attempt to address these risks. Generating authentic and trustable routing information to inject into the inter-domain routing system is one of those things that have to fit into an ISP's cost and revenue equation, and its often the case that this is not any easy fit. I'd contend that any robust form of certificate infrastructure that is strongly rooted in a trust anchor is far far better than what we have now (oh, please not the ring of trust stuff - it really is not enough in this case!) http://www.potaroo.net/ispcol/2005-02/index.html is one of many enumerations of the risks involved here. The IETF work in routing protocol security (RPSEC) has been working in this area for some time now and their documents about risks do not make comforting reading. And then theres the mechanisms for inserting the validation elements into the inter-domain routing protocol. Again http://www.potaroo.net/ispcol/2005-03/route-sec-2-ispcol.html is one of a number of commentaries on the topic.

Why not do something simple?

Probably because you need to cross over a threshold from doing something just to make you feel better about yourself into an industry collectively deploying a technology that can provide all of us with reliable indications as to the validity of the information we are passing about, as well as the authority to allow you and I to pass it around. The essential difference as far as I can see today between soBGP and sBGP in this space is that, as a 2 liner: - sBGP allows the receiver to validate that the update indeed traversed the path described in the AS Path Update as part of the local acceptance of the update. - soBGP allows the receiver to determine that the AS Path describes a plausible traversal across the network, but cannot validate that the update itself traversed this path. In looking at this what I personally saw was a design tradeoff, where soBGP attempted to lighten the update load and the certification load by making one part of the BGP update message unprotected by a certificate set, while sBGP attempts to provide the receiver with sufficient information so as to allow the receiver to validate the entire update. Unfortunately I doubt whether we can ultimately afford the luxury of allowing each operator to select their favourite form of validation of routing information. It would be preferable, or at least useful, to have some guidance provided by a standards body as to what is a useful and reasonable security framework for securing inter-domain routing, together with a protocol specification for doing the same. Indeed I would've thought it was core business for a standards body to assist the industry in this manner. And, hopefully, it will happen soon in this case, rather than way too late. regards, Geoff

-- You must not rely on routing to secure routing.

I would like to point out that this goal is unnecesary. First, we need to understand that for ANY solution to be deployable, it must be incrementally deployable. We do not get an Internet-wide flag day for BGP. The Internet must continue to function, regardless of the percentage of NLRI that are actually authenticated. For the forseeable future, we will need to have a path selection policy that rejects any information that clearly fails authentication, continues to use unauthenticated prefixes, and prefers authenticated vs. unauthenticated. Second, validating a certificate must be doable even if the router is using unauthenticated prefixes to do so. Remember that the crypto properties of a certificate must make it unforgeable, and that routers must have at least one reference point in the web of trust. If the route to the root of that web is spoofed, then the crypto will not be able to validate any other certificates in the web, but this is NOT an authentication failure -- the related NLRI are just unauthenticated, not unuseable. Obviously, authenticating the root certificate NLRI are our top priority, but the system MUST continue to operate even without this. This is the only way to truly address the chicken and egg problem. I think that this also highlights the need for multiple, diversely routed certificate authorities. Tony

...

I suspect the right thing to do is to ask why soBGP and sBGP have failed? Or maybe, jut maybe, because we've never had the tools to deploy it.

actually, we had a small workshop with sbgp tools at the last eugene nanog. perhaps it's time for another? bill, can you host at he next nanog, as it is on your turf? but, of course, for real deployment, those tools, built for *bsd and linux, would limit initial deployment to those running pc-based routers. to go futher, we would need support from juniper and other vendors.

- sBGP allows the receiver to validate that the update indeed traversed the path described in the AS Path Update as part of the local acceptance of the update.

- soBGP allows the receiver to determine that the AS Path describes a plausible traversal across the network, but cannot validate that the update itself traversed this path.

further, the latter, because it relies on a separate data set for path validity, has serious and very kinky temporal sync problems. i receive a bgp announcement from a new peer, but the announcement was originated two weeks ago (shockers! a stable route); was the asserted path to my new peer valid when the announcement was originated two weeks ago? once your mind starts down such paranoid paths, the void opens before one's eyes. randy

i receive a bgp announcement from a new peer, but the announcement was originated two weeks ago (shockers! a stable route); was the asserted path to my new peer valid when the announcement was originated two weeks ago? once your mind starts down such paranoid paths, the void opens before one's eyes.

Which is EXACTLY why we need to remember that we are NOT trying to come up with the perfect solution. We have operational issues *TODAY* that we are trying to address. - We have people (admittedly accidentally) advertising prefixes that they do not own and thereby overloading BGP. See the talk at the latest NANOG. - We have people intentionally out there forging /24's as an attack. - We have OTHER people out there flooding the networks with their /24's so that they are less vulnerable to attack by forged /24's, and thereby exacerbating the BGP overload problem. Almost any of the popular proposals (and some of the really old ones) will address all of these issues. But only if they are deployed. We, as responsible operators/architects/vendors/coders need to pick a solution and field it. It may well be an interim solution, but we MUST act, and soon. We are already seeing the stress patterns, without reinforcement it is only a matter of time before we see wholesale fractures. Given that any solution will have an implementation and deployment delay, we dare not wait much longer. Tony

Let's look at Tony's points above. These solutions cannot deal with the last case, i.e., the "owner" of the prefix decides to advertise more specifics (and the ISPs pass that crap through). Then we're left with attacks where someone else advertises an equal route, or someone advertises a more specific.

One of the various policies available within the soBGP specs is the ability for the owner of an address block to state: "The longest prefix within this block will be /x." This means that if you own 10.1.0.0/16, you can say: "The longest prefix length within 10.1.0.0/16 will be a /17." Or you can say: "The longest prefix within 10.1.0.0/17 will be a /18, and the longest within 10.1.1.0/17 will be a /20." Now, if someone attempts to steal your traffic by advertising a longer prefix, anyone actually checking would toss their routes. Yes, you could advertise the same length, of course, but then, if the origin doesn't match, and/or the AS Path is bogus, they're toast, as well. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone

On Tue, 24 May 2005, Pete Templin wrote:

...

Let's take RIPE, RADB, etc. databases as an example. Apparently we can't count on the ISPs filtering out crap from their customers, because otherwise we'd never have had these attack. Also apparently, we can't count on the transit ISPs from weeding out the cruft that their ISPs spew in their direction and then to everyone else.

Two of Tony Li's points (accidentally advertising prefixes and forging prefixes as an attack) have nothing to do with ISPs filtering out crap from their customers. The talk at NANOG demonstrated that peering ISPs were vulnerable to the cruft from the offending ISP, not (just) transit ISPs.

I mentioned two cases; I should have listed this as well (peering between two ISPs) as well. It's exactly the scenario what the route registries are/were for.

...

So, what can you do? Everyone must process their incoming full Internet feed and filter out bogus advertisements. Prefix lists based on RIPE, RADB, etc. could block the more specific, but not an equal length prefix.

Prefix lists aren't the (whole) solution. The solution must check the {prefix, origin AS} correlation, and may check a subset of {prefix, origin AS, AS path, peer AS policy, (intermediate AS policy(ies)}.

Prefix lists as generated from the registries are built based on AS numbers, so there is already a degree of correlation between the prefix and the AS. Currently you just can't disambiguate between "your peer who is authorized to route 8.0.0.0/8 sent it to you, but it was originated by an unauthorized party inside that peer's network" and "your peer sent a correct 8.0.0.0/8 prefix". Such disambiguation may be useful, but it goes (IMHO) beyond the basic requirements. I'm not sure whether AS9121 would have been prevented or mitigated with prefix filters. I guess that depends on what AS9121's upstreams (in the path towards the affected networks) are allowed (by the routing registry) to advertise.

...

So, I guess I must ask -- if prefix lists haven't been deployed, why would this be?

Probably NVRAM constraints or ability to decipher the RIR tools to make a functional policy implementation. But see above, as prefix lists would NOT have solved the AS9121 problem, as was pointed out.

And managing the certificates, processing them, ...., would be significantly easier? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Which is EXACTLY why we need to remember that we are NOT trying to come up with the perfect solution. We have operational issues *TODAY* that we are trying to address.

wrong. as deployment will be expensive and long, we will have one chance to deploy. so need a serious solution set for what we have to consider to be a very serious attack model. plan for attacks against the routing system as smart, well-researched, constant, ... as the best we see against ssh, htt, ... today. randy

On 23.05 22:13, Tony Li wrote:

... We, as responsible operators/architects/vendors/coders need to pick a solution and field it. It may well be an interim solution, but we MUST act, and soon. We are already seeing the stress patterns, without reinforcement it is only a matter of time before we see wholesale fractures. Given that any solution will have an implementation and deployment delay, we dare not wait much longer.

From discussions with large operators during NANOG week it is clear to me that at this point most will simply not deploy anything that dynamically interacts with their inter-domain routing (BGP). All are comforatble with deploying something that works via the current mechanism of periodically built configurations. In fact most said to wait for something that would take some of the heuristics out of that process. We will not get any deployment unless either that attitude changes or we engineer taking it into account. I prefer the latter.

To me the first stage of any deployment becomes obvious then: Map the fucntionality of s*BGP into tools to build routing configurations from signed information distributed by whatever means. This will make rapid deployment possible with a high comfort level for operators which is key! It would bring immediate benefits and help us build and understand the databases that are necessary. In parallel we can develop more dynamic ways of distributing the information and interacting with BGP. If the design and trust model of s*BGP is indeed well conceived this will be attractive enough for operators to see deployment. Note that I am not advocating routing registries. I agree with those that consider them a failure although I have been a long time supporter. The idea is to start building the (signed) meta-information and using it as additional input to the configuration generation already done by operators. Ideally this would quickly obsolete from routing registries and many heuristics. Can such a first step of an incremental deployment be designed for any of s*BGP? Daniel

On Wed, 2005-05-25 at 16:24 -0700, Tony Li wrote:

For example, an operator can begin by enabling authentication on a BGP speaker that is wholly outside of the traffic path. Instability of this one speaker would have no effect on production traffic. Authentication alarms generated by this speaker could be set up to do nothing more than send a syslog message to operations personnel who would need to intervene manually to actually change production BGP path selection. For testing authentication, a host behind this speaker could monitor reachability.

In short, you mean setting up, eg a Quagga box behind the existing core infra that one has, feeding it a full feed, which matches the current best paths one has in it's RIB and verifying the paths. This is somewhat similar how the detection of GRH (*1) works already for IPv6 tables, that is it nightly fetches the route6 objects from various registries(*1) and checks if a AS is registered to be allowed to announce a certain prefix, if not it marks it in the looking glass as being a bad route which is supposed to be routed from the registered AS. Now, if BGP would have some signature over the the path, one could verify this in the same method and have the exact thing happening above. GRH sends out mailings every day, though one could of course implement the above in realtime. If one would mirror the full table, one could even analyze the alternative paths to see if those are valid. What you mention, does indeed not break current operations and would be quite transparent. Greets, Jeroen *1 = http://www.sixxs.net/tools/grh/ *2 = http://www.sixxs.net/tools/grh/how/

tony, all, On Wed, May 25, 2005 at 04:24:07PM -0700, Tony Li wrote:

Fundamentally, there is a serious scalability issue with doing everything at configuration generation time. Since one cannot predict with certainty what AS paths will be seen for which prefix, one would have to authenticate each and every possible path and then encode the authenticated paths in the configuration.

but you don't really have to do this to solve a big chunk of the problem. wouldn't it be a good start to simply be able to authenticate originations? and by originations, i don't just mean the single AS, but i the set of length-2 paths that form the existing originations for a prefix. the list of all prefixes seen in the global table combined with all origination patterns seen for the past 6 months or so is realively easy to produce. the scalability problem, as i understand it (not at all an expert here) is that routers won't currently handle such a list with regexps very well. apparently, ciscos will not allow filtering advertisements on a combination of prefix + as-path regexp at all and junipers will, but the perception is that they will not scale to a list of 300-500K (which is the union of routes in global tables without any consolidation). if you could consolidate all equally originated prefixes under their covering supernets and still adequately filter, that number would be *much* smaller, obviously. t. -- _____________________________________________________________________ todd underwood director of operations & security renesys - interdomain intelligence todd@renesys.com www.renesys.com

On Thu, 26 May 2005, Todd Underwood wrote: > the scalability problem, as i understand it (not at all an expert > here) is that routers won't currently handle such a list with regexps > very well. apparently, ciscos will not allow filtering advertisements > on a combination of prefix + as-path regexp at all and junipers will, > but the perception is that they will not scale to a list of 300-500K > (which is the union of routes in global tables without any > consolidation). if you could consolidate all equally originated > prefixes under their covering supernets and still adequately filter, > that number would be *much* smaller, obviously. Or if you could do it based on atoms rather than prefixes. But atoms have been looking like a trickier concept than I first thought, as we've started to look at them. -Bill

Steve,

I know all the issues up there are real, since I've occasionally heard about them happening. I understand the devastating consequences of somebody finding a sufficiently well connected unfiltered BGP session and using it to announce some important prefixes. I fully agree that it should be fixed.

And yet, in the nine or so years I've been working on network infrastructure stuff, spoofed BGP announcements have never been a major cause of problems for me.

That's what we can say so far. Do you really want to wait until we have a major problem? The time to replace the cockpit doors was PRIOR to 9/11.

Therefore, when somebody tells me they're going to make the Internet more reliable by adding more things that need to be done right to make a BGP announcement work, I get a bit apprehensive. When they further tell me it's going to get centralized, such that I'd no longer be dealing with multiple peers or upstreams maintaining multiple sets of filters that can be expected to not all break at the same time, I get even more nervous.

I hope any solution that finally gets settled on for this is done with the recognition that the goal is to reduce outages overall, rather than trading one outage cause for another.

Once again, I ask you to look a bit harder at the details before passing judgement. Incremental deployment of any authentication scheme can and must be done so that there are three classes of BGP paths: authenticated paths (highest preference) unauthenticated paths (next, still used) authentication failures (recorded, dropped, alarms triggered) If one does NOTHING, then your prefixes remain unauthenticated and used. Thus, there is no additional work to making a BGP announcement work. The additional work is only to make the announcement _secure_. Further, we will need to use multiple certificate authorities (for redundancy alone), with various certificates flying around from differing places along the AS path. So there's nothing about these schemes that is centralized from an operational sense. If your concern is that address space allocation is hierarchical, rooted in one of the RIR's, then this is not a new issue. Tony

steve, tony, all, just catching up. trying to ignore the TOS fest but the soBGP thread actually is interesting. On Wed, May 25, 2005 at 03:51:25PM -0700, Tony Li wrote:

...

And yet, in the nine or so years I've been working on network infrastructure stuff, spoofed BGP announcements have never been a major cause of problems for me.

That's what we can say so far. Do you really want to wait until we have a major problem?

i want to agree with tony here. i find steve's attitude troubling and unfortunately common. i hear about hijackings that cause *major* problems on a regular basis (several times per month) and i hear a lot of frustration from major *edge* ASes about the inability to do much about it. in the past two years i've presented at least one, very interesting, high-profile hijacking at some public event (NOTA peering forum, S&D peering forum, LINX members meeting, nanog, etc) every 3 months or so, and i'm not spending *any* time looking for them. i also hear a lot of nonchalance on the part of transit and SP ASes about the problem. and i can understand that. because the current tools don't give you many options and the current customers want *cheap* and not *good*. depressing but true. i also hear steve's point about not making things work *less* well. if we've learned anything from the md5 debacle it is that it is easy to create a new vulnerability or attack vector while preventing a non-problem. so it's prudent to be cautious. but i would suggest that doing anything that could *delay* a *new* announcement on a *new* path is completely acceptable. it's already happening now for edge ASes. you get new space. you contact your providers and peers and tell them to accept it. they do the same thing. and after a little while (usually more than a day but less than a week) the advertisements reach some plausible imitation of the "global" table and you call it good enough. so why not seriously consider options that don't impact existing routes on existing paths, but make it more difficult to get a new prefix working on a never-before-seen origination path pattern? like steve, i haven't yet formed an opnion on soBGP or sBGP (other than the fact that they've obviously been around for a while and obviously aren't being implemented by anyone yet). so my comments are more general. t. -- _____________________________________________________________________ todd underwood director of operations & security renesys - interdomain intelligence todd@renesys.com www.renesys.com

The thing we should keep in mind is that the problem set is really very limited.

and if we just stick our heads in the sand, it will stay so? have we learned nothing about internet threat models in the last decade? there are very smart and nasty people out there, and there is a very high payoff for them to do bad things to the net. leave a hole, and they will find a way to profit using it. randy

On Thu, 26 May 2005, Tony Li wrote:

You're not going to like this.

The simplest way to stop the hijacking is going to end up looking a LOT like one of the s*BGP proposals. Here's why:

The threat model includes:

- Forged origin ASs - Unauthorized advertisements from authenticatable sources - Unauthorized longer prefixes - Forged AS paths and AS path segments - Replay attacks on any of the above

The solution, no matter how simple, is constrained:

- No single point of failure/single point of attack - Must demonstrate that the AS path is authentic (i.e., not forged)

If you cannot authenticate the entire AS path, then all you know is that someone out there wants you to send traffic to them. Any unauthenticated portions of the AS path could easily be forgeries and cover up AS path hackery.

- Must demonstrate that the origin is authorized to advertise a prefix

Even if the AS path is authenticated, it doesn't mean that I have a right to advertise that space.

- Must be reasonably secure, and thus will involve some amount of crypto

Thus, from what I can see, the SIMPLEST solution will have:

- A distributed means of getting authorization information. Since address space can be delegated in a hierarchical fashion, this mechanism must be able represent that hierarchy, down to the origin AS level. - A distributed means of getting certificate information to authenticate each step on the AS path.

The biggest simplification that I can see is to remove any expectation for real-time or near-real-time authentication and authorization, as well as the need for real-time access to the above two distributed databases. If, for example, the several gigabytes (?) of information could be stored locally on all systems before authentication began, that could eliminate some of the requirements for distribution. However, this would require a different mechanism to distribute the information, effectively turning the solution from a secure "pull" model to a secure "push" model. In my (alleged) mind, the hard part about the secure "pull" model was the word 'secure', not the word 'pull', so that doesn't sound too promising.

Thus, I'm not seeing anything that seems like it is an order of magnitude less complex than s*BGP.

A big +1 from me for EVERYTHING Tony just said. If you want security that can prevent hijacking (and not just act after the fact), then you need to authenticate AS path from the the origin to destination and including authorization of right to announce the ip block itself. And I also don't see any way to avoid hierarchy certificate distribution with root at RIRs. What is possible is that RIRs would only be involved in providing certificate and actual distribution of this information would be done by routing registries (to avoid having RIR directly involved in maintaining routing infrastructure and keep separation of policy & allocations from operations). As far as downloading entire data for authorization - you can cache it, but ultimately you can not rely on it being distributed by protocol which itself depends on routing infrastructure, so it must be possible to pass information as part of BGP from peer-peer. -- William Leibzon Elan Networks william@elan.net

so... randy poked, some private nudging (and you know who you are!) leads me to make this plea... if a couple of transit providers and perhaps an end site or two, who would like to participate in a quasi-persistant trial run of a non-real-time hack to be able to "spray" the prefixes they inject into the routing system with their origin AS and public key "scent" ... and provide haqs^^^ooks to allow random third parties to check the same, please send me private email and i think we can cobble something together in a fairly short period. we might even be able to have several months/weeks/days of emperical data to review analysis before the next conflab. takers? --bill

On Fri, 27 May 2005, Randy Bush wrote:

i'll play, but only have the three year old sbgp toolkit. is there a later one from steve kent?

randy

if you have the stuff from the 02 workshop: http://www.ir.bbn.com/projects/s-bgp/021030.OregonWorkshopNotes.html I think that's the last open release but see: http://www.ir.bbn.com/projects/s-bgp/src/S-BGP-1.0.html

Todd,

...

- Forged AS paths and AS path segments

ditto, provided that you have long enough AS path segments in your list of valid prefixes. if you have a long enough memory of routes and a fast enough system, it's trivial to produce weighted lists of the likelihood of a given prefix-path pair being valid.

What you're suggesting here is simply a pre-computation of a portion of the acceptable paths. It has a significant disadvantage in that it is not capable of authenticating all of the possible authenticatable paths. We certainly see some bizarre (but valid!) paths in the core at various times, especially during flappage. How do you propose to deal with them with your system? Do you propose to reject them? If so, you are now violating the earlier mandate of not damaging current connectivity. If you do not reject them, then how do you reject the Bad Guy's routes?

...

- Replay attacks on any of the above

unclear on the relevance of this but i'd like to see more.

Very simply, any BGP advertisement (or portion of an advertisement) can always be re-injected into BGP sometime later by the Bad Guy, anywhere they have access into the BGP mesh. The Bad Guy can even replay certificates and such.

...

- Must demonstrate that the AS path is authentic (i.e., not forged)

If you cannot authenticate the entire AS path, then all you know is that someone out there wants you to send traffic to them. Any unauthenticated portions of the AS path could easily be forgeries and cover up AS path hackery.

sure. we see this from time to time in our data. and as i mentioned above, there's no reason you can't decomposed your path regexps into several segements so as to constrain the valid paths. there are far fewer paths through the internet than most people think.

Through the Tier 1 core, yes, to be sure. However, the paths that the core sees through the remainder of the net can get VERY interesting.

...

- Must demonstrate that the origin is authorized to advertise a prefix

Even if the AS path is authenticated, it doesn't mean that I have a right to advertise that space.

it would be good to do this, but we don't do anything like this now and i disagree that a future solution would be required to do this.

Great. What is your prefix please? I'd like to steal your address space. Without this, anyone who is a legit member of the BGP mesh can steal ANYONE's space. And what's worst about this is that this is the failure mode that most of the accidents fall into. AS 7007 anyone?

...

- Must be reasonably secure, and thus will involve some amount of crypto

sure. signed prefix-filter list distributed from a trusted source.

That would violate the earlier requirement that we not have a single point of failure. Any single trusted source can be DoS'ed off of the net effectively forever. BTW, if we go down this path, how do we expect to get people to participate. As noted before, the IRR's have not been an overwhelming success. How do we get everyone to register their topology with the trusted source? If UUnet decides not to register, is everyone going to start dropping paths through them?

let several organizations calculate and distribute them. an inverse-bogons.

That gives only a list of the currently routable prefixes. It does nothing to tie those prefixes to their correct origins or real paths to get to those origins.

...

- A distributed means of getting authorization information. Since address space can be delegated in a hierarchical fashion, this mechanism must be able represent that hierarchy, down to the origin AS level. - A distributed means of getting certificate information to authenticate each step on the AS path.

<snip the rest>

see, here's where you've added potentially unnecessary complexity.

Tell me what requirements we can relax. So far, I don't see it. As you may or may not know, I'm usually the first in line when it comes to pragmatic solutions.

i think that the sbgp and sobgp proposals are great. they're just like IPv6: full of well-meaning, complicated engineering that doesn't offer great migration paths and doesn't address a burning need among network operators. as such, they're not getting much traction, not surprisingly.

if tony is right that only the full solution will work, and that no heuristic that dramatically reduces the problem space will work, then we are probably stuck with no solution for the time being.

Well, if most folks feel like you do, yes, I guess we WILL have to wait for our version of 9/11 too. ;-(

transit providers *still* don't see value in authenticating prefixes because they don't feel the pain of the hijacks. and the people who do feel that pain *still* haven't decided that preventing hijacking by means of authenticating routes is something they're willing to pay extra for. so, like everything else on the $5/mb/s gige-port internet, we get what we pay for and the lowest common denominator is more or less required to stay in business (for now).

In fact, I know for certain that this is not true. Some transit providers are actually concentious folks who (between caring for their infant son ;-) actually help out their customers by backtracking hijacks. I submit, rather, that the transit providers have not yet seen the right alignment of a unified, effective solution that comes at a sane cost, that is implementable and deployable in a rational way. This suggests that our work item is really: - reach consensus on the technical solution - implement - provide clear understanding of operational requirements and deployment plans If I'm missing something, I'd dearly love a clue. Tony

On Mon, May 23, 2005 at 02:00:12PM -0400, Daniel Golding wrote:

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.

But it's worth noting here that there's a good reason for that: It's *miserable* to replace a fundamental protocol with insufficiently forward-thinking design decisions, too. Viz: IPv6. So the real question is: where's the happy medium? Cheers, -- jr 'first person who says "NBC" is fired' a -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me

...

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.

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.

One of, perhaps, the most confusing aspects of soBGP is that there are four certificates. Why not just do one certificate? Because of this specific separation.... 1. We need someone to verify X's key is really X's key. We believe SP's won't, necessarily, want to be in this business. 2. We need someone to verify X is allowed to advertise Y. We believe RR' and SP's will probably be in this business, whether or not they like it. 3. We need some way for a local AS to express various things that don't need to be signed by some third party, connectivity and policy, specifically. We want different chains of trust--one person to say "this is X's key," another to say: "this is X's address space." :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone

* Steven M. Bellovin:

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

I don't think it's important how accurate they are *now*, but how accurate they will be when some "secure" BGP version makes them (or, more precisely, the route registration process) the weakest link in the chain. The fact that careful checking on the ISP side protects other ISPs only (and your own business interests just in a very indirect fashion) makes me believe that securing BGP will be *very* hard.

On 21-mei-2005, at 20:25, Randy Bush wrote:

...

If you are an operator, would you deploy soBGP or something like it? If not, why not.

[skip to the bottom for my reaction to Randy's post] I think it would be a very good idea to start experimenting with this as soon as there are decent implementations. The operational problem that soBGP will hopefully solve for me is peering with lots of relatively small peers, some of whom may be clue- challenged with regard to inter-domain routing. (AS number consumption seems to be higher than BGP book consumption...) It's not the really small networks that are the biggest problem, BTW. It's the ones that have a few BGP customers but not enough to really know how to filter them properly that are the most dangerous. The trouble is that today, I basically have three choices: 1. Generate filters from a routing registry. Here in RIPE country, we have a pretty good routing registry, because it's also the RIR database. Still, many people don't register their stuff, or don't register it correctly. And the tools necessary to generate configurations are _very_ hard to use. Also, if something goes wrong, my filters are zapped with unpredictable results. So basically I'd have to work very hard to get something that doesn't work properly and will kill my network if it fails. 2. Maintain filters manually. That won't scale, so the fact that peers usually don't inform you when they have new announcements etc doesn't even matter. 3. Use max-prefix and push a virgin into the volcano once in a while. The nice thing about something like soBGP is that it makes it possible to work together to solve this problem rather than everyone having to do it on their own. For instance, if I know that networks X and Y have very high standards and when they say something is ok, it is, I could accept certificates signed by X or Y. This only requires the bare minimum of clue from the origin AS: they need to include the signed certificate, not much more. When something goes wrong, the worst thing that can happen when (for instance) Y screws up, is that I lose some peering routes, or I potentially allow some routes that shouldn't be allowed. The former case isn't all that bad: I still have all the routes for which I don't depend on Y. The latter case could be problematic, but it would be hard for an attacker to abuse this situation as she still has to corrupt the source or neighbor ASes in question. I'm not saying this will solve all our problems, but I think there is a lot of potential here, and we need some operational experience to guide further development.

something like it, for sure. but i vastly prefer the s-bgp approach as it maps closely to bgp operational reality,

S-BGP signs every update. This is problematic in several ways. A receiver needs to check all AS hops in each AS path (that would be ~500k for a full BGP table), which means you are pretty much forced to have a crypto accelerator on board. Also, no more peer group update optimization, so when you have a lot of peers you're going to burn much more CPU time for every update. Last but not least: because S-BGP signs updates, a secret key must be present inside the router, making physical security much more important.

and does not rely on a published policy database, which we have seen fail for over a decade, etc.

soBGP and S-BGP aren't different in this regard, AFAIK. I don't think either needs a "published policy database" but obviously they need some trust anchors and access to policy information in some way.

we should learn from the decade-long problems with the deployment issues in dnssec, and map routing security as closely as possible to operational protocol and reality.

If you give people an incentive to use a technology, you'll see the use of that technology increase over the situation prior to the incentive. :-) (See MD5 last year.)