Archive for Security

is a longer announce invalid or not found?

To: sidr wg list
Subject: [sidr] is a longer announce invalid or not found?
From: Randy Bush
Date: Fri, 30 Sep 2011 11:39:21 +0900

there has been a bit of confusion over whether announcement of a longer prefix than is covered by a roa is valid, invalid, or not found. so let me try to clarify the underlying decision process for valid, invalid, and not found so we are all on the same page. i believe this is as it is documented in pfx-validate.

---

if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no other roas for 10/...)

no announcement of 10.0.0.0/16 or any longer prefix thereof from any AS may be marked NOT FOUND, after all, a covering roa is there.

any announcement of any prefixes in that space, from /16 to /32, from an AS other than 42 are INVALID. this is the purpose of the exercise.

and, an announcement of 10.0.666.0/24 from AS 42 is INVALID, as it has a prefix length not specified by the roa. someone is trying to punch a hole, not allowed. this could be an origin forger trying to punch a /24 in my /16.

but if i publish a roa for 10.0.0.0/16-24 for AS 42, then an announcement for 10.0.666.0/24 from AS 42, would be marked VALID.

randy

Comments off

Do Not Complicate Routing Security with Voodoo Economics

[ http://archive.psg.com/110904.broadside.html ]

Do Not Complicate Routing Security with Voodoo Economics
a broadside

A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and Goldberg[1] drew a lot of ‘discussion’ from the floor. But that discussion missed significant problems with this work. I raise this because of fear that uncritical acceptance of this work will be used as the basis for others’ work, or worse, misguided public policy.
o The ISP economic and incentive model is overly naive to the point of being misleading,
o The security threat model is unrealistic and misguided, and
o The simulations are questionable.

Basic ISP economics are quite different from those described by the authors. Above the tail links to paying customers, the expenses of inter-provider traffic are often higher than the income, thanks to the telcos’ race to the bottom. In this counter-intuitive world, transit can often be cheaper than peering. I.e. history shows that in the rare cases where providers have been inclined to such games, they usually shed traffic not stole it, the opposite of what the paper presumes. The paper also completely ignores the rise of the content providers as described so well in SIGCOMM 2010 by Labovitz et alia[2]

It is not clear how to ‘fix’ the economic model, especially as[3] says you can not do so with rigor. Once one starts, e.g. the paper may lack Tier-N peering richness which is believed to be at the edges, we have bought into the game for which there is no clear end.

But this is irrelevant, what will motivate deployment of BGP security is not provider traffic-shifting. BGP security is, as its name indicates, about security, preventing data stealing (think banking transactions[4]), keeping miscreants from originating address space of others (think YouTube incident) or as attack/spam sources, etc.

The largest obstacle to deployment of BGP security is that the technology being deployed, RPKI-based origin validation and later BGPsec, are based on an X.509 certificate hierarchy, the RPKI. This radically changes the current inter-ISP web of trust model to one having ISPs’ routing at the mercy of the Regional Internet Registries (RIRs). Will the benefits of security – no more YouTube incidents, etc. – be perceived as worth having one’s routing at the whim of an non-operational administrative monopoly? Perhaps this is the real economic game here, and will cause a change in the relationship between the operators and the RIR cartel.

The paper’s simulations really should be shown not to rely on the popular but highly problematic[3] Gao-Rexford model of inter-provider relationships, that providers prefer customers over peers (in fact, a number of global Tier-1 providers have preferred peers for decades), and that relationships are valley free, which also has significant exceptions. Yet these invalid assumptions may underpin the simulation results.

Randy Bush
Dubrovnik, 2011.9.4

[1] P. Gill, M. Schapira, and S. Goldberg, Let the Market Drive Deployment: A Strategy for Transitioning to BGP Security, SIGCOMM 2011, August 2011.
http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p14.pdf

[2] [1] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and F. Jahanian, “Internet inter-domain traffic,” in SIGCOMM ’10: Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010.

[3] M. Roughan, W. Willinger, O. Maennel, D. Perouli, and R. Bush, 10 Lessons from 10 Years of Measuring and Modeling the Internet’s
Autonomous Systems
, IEEE Journal on Selected Areas in Communications, Vol. 29, No. 9, pp. 1-12, Oct. 2011.
https://archive.psg.com/111000.TenLessons.pdf

[4] A. Pilosov, T. Kapela. Stealing The Internet An Internet-Scale Man In The Middle Attack, Defcon 16, August, 2008.
http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf

Comments off

JSAC – “Configuration Management and Security”

A co-worker pointed out that I have been lax in keeping this site updated. So …

Bellovin, S.M.; Bush, R. Configuration Management and Security, IEEE Journal on Selected Areas in Communications, Volume 27, Issue 3, April 2009 Page(s):268 – 274

Comments off

Signing the IRR, a Contrary View

Robert Kisteleki proposed to use the RPKI to sign most of the IRR. I took the opposite view in the following rough proposal. Geoff Huston and I will be writing up my design in the next week.

Date: Mon, 03 Mar 2008 21:53:30 -0800
From: Randy Bush <randy@psg.com>
To: Robert Kisteleki <robert@ripe.net>
Cc: Resource Cert List <rescert@apnic.net>
Subject: Re: [Rescert] RPSL+RPKI proposals

robert,

i take a somewhat different view.

though i was hacking before ed codd, my mommy trained me to be
extremely wary when the same information is in two places.

but more important, i have a slightly different goal set.  i would ask
what we need to do in order to make the rpki helpful to isps in the
current task of configuring routing filters, but with more assurance of
correctness?

for this we do not need signed route: objects in the irr, as we have
roas and merely need to invert them, just as we do in the irr software,
to form the set of prefixes which each asn _may_ announce.

what we do not have in the rpki, which is in the irr, is the inter-asn
topology.  while josh and jrex would gather it from route-views or ris,
i am willing to stick one toe in the irr cesspool and sign the aut-num:,
probably in a fashion similar to the one you suggest.

but doing more is producing redundant data, transferring trust to a weak
sibling whose long-term survival is not required, and trying to make a
sow's ear into a silk purse when we are not in the silk purse business
anyway.

when we have s-bgp (or whatever), the irr will be completely IRRelevant
<tm>.  i see no need to try to touch it any more than we absolutely
needed to now.

randy

Comments off

FBI Report on Cisco Clones

Here is an interesting FBI report on Cisco clones which they consider to be dangerous.

Comments off

« Previous Page « Previous Page Next entries »