The routing security battles intensify(internetgovernance.org)
internetgovernance.org
The routing security battles intensify
http://www.internetgovernance.org/2013/01/09/the-routing-security-battles-intensify/
11 comments
I don't know. The security policy in BGP isn't all that agile and decentralized to begin with; it's mostly just a mess, isn't it? Different providers with different systems for truing up filters, many of which themselves rely on centralized databases? Can it get much worse than it already is?
Any resources for learning about BGP, preferably through the lens of security? I feel like it's something most people (myself included!) have no clue about.
Take a look at http://moo.cmcl.cs.cmu.edu/~dwendlan/routing/ (slow to load, but it does load) - he covers a good number of the security aspects around a distributed routing protocol like BGP.
Network engineers tend to be big fans of simplicity - enabling security options like md5 passwords was like pulling teeth until a few years ago . This is partially because it quickly becomes difficult to keep track of what password is used where, and the netengs like their excel files to be clean and simple.
Not sure what my thoughts are on this RPKI thing - taking days to sync the local cache doesn't sound right, altho I'm not fully through the paper, yet. Needing a full copy of the cache to guarantee security in a distributed routing protocol doesn't sound right. And if it is, Cisco's gonna make a small fortune selling memory upgrades...
A linux box and a BGP peer won't teach you BGP...it'll provide you with a nice start. This is one of those things that requires battle scars, like solid UNIX admin skills. You have to be running one or more BGP peers for a good period of time to get exposure to what can break and how it should be fixed. Going through CCIE labs will get you closer, but this is definitely one of those things where there's nothing like experience.
Network engineers tend to be big fans of simplicity - enabling security options like md5 passwords was like pulling teeth until a few years ago . This is partially because it quickly becomes difficult to keep track of what password is used where, and the netengs like their excel files to be clean and simple.
Not sure what my thoughts are on this RPKI thing - taking days to sync the local cache doesn't sound right, altho I'm not fully through the paper, yet. Needing a full copy of the cache to guarantee security in a distributed routing protocol doesn't sound right. And if it is, Cisco's gonna make a small fortune selling memory upgrades...
A linux box and a BGP peer won't teach you BGP...it'll provide you with a nice start. This is one of those things that requires battle scars, like solid UNIX admin skills. You have to be running one or more BGP peers for a good period of time to get exposure to what can break and how it should be fixed. Going through CCIE labs will get you closer, but this is definitely one of those things where there's nothing like experience.
A Linux box and an IPv6 tunnel provider that allows BGP peering. There's a tonne of software implementations (e.g. Zebra)
I agree, most providers want you to register with a RADb anyways before you advertise networks upstream don't they? Whether you register with a RADb and it issues a cert, or it creates a database entry, seems trivial. Heck, ARIN appears to already be running an RPKI for their customers. I haven't applied for an allocation in well over ten years, wonder if they require registering once you get one, or if it's optional.
"RPKI is being advocated by US government-funded contractors and US government agencies such as the US National Institute of Standards and Technology (NIST)."
Big, bad, NIST!
Also, nearly every company that knows anything about internet routing is a government contractor. Because, you know, they invented the internet under government contract.
Big, bad, NIST!
Also, nearly every company that knows anything about internet routing is a government contractor. Because, you know, they invented the internet under government contract.
And how is Verisign not also a government contractor?
Looks to me like Verisign isn't a fan of the scheme because it would take a few hours to propagate routing changes.
That makes it harder to run its DDoS prevention business. Not sure that's a good reason to oppose better routing security.
That makes it harder to run its DDoS prevention business. Not sure that's a good reason to oppose better routing security.
[deleted]
rough consensus, running code
This is too much talk, not enough code. Whoever wants PKI needs to put together a POC and release it into the wild.
This is too much talk, not enough code. Whoever wants PKI needs to put together a POC and release it into the wild.
Key quote: "If authoritarian governments were smarter and really did want to assert direct control over Internet operations, they would forget about the ITRs and push for passage and implementation of BGPSEC, and then make plans to assert legal control over the ROA certificates. Oddly, the only government that seems to be present in SIDR is the USG. Hmmm…"
Sounds a lot like actors within the US government want to maintain and extend their just-hidden-enough centralized control of internet information, just as the intelligence apparatus achieved for finance (via SWIFT and credit/debit card networks) and telecommunications (via global interception of conventional networks, and US-centric internet routing).
What I've always wondered is why China doesn't give fat pipes to Russia, East and Southeast Asia.
Sounds a lot like actors within the US government want to maintain and extend their just-hidden-enough centralized control of internet information, just as the intelligence apparatus achieved for finance (via SWIFT and credit/debit card networks) and telecommunications (via global interception of conventional networks, and US-centric internet routing).
What I've always wondered is why China doesn't give fat pipes to Russia, East and Southeast Asia.