I'm a student in college learning about networking and, specifically, BGP.
Does anyone have any statistics on the use of S-BGP or soBGP in the wild?
I've read a few papers / RFCs on the subject (from Cisco and the like), but
I haven't been able to find any information about actual usage.
Additionally, do people scan BGP speakers in the same sense that
researchers perform scans of the Internet (e.g. zmap)?
I'm a student in college learning about networking and, specifically, BGP.
Does anyone have any statistics on the use of S-BGP or soBGP in the wild?
Take a look at rPKI.
Additionally, do people scan BGP speakers in the same sense that
researchers perform scans of the Internet (e.g. zmap)?
Everything on the Internet is scanned (or, at least attempts to scan everything on the Internet are made), constantly.
If network operators have configured their BGP speakers properly, with BCPs such as iACLs and GTSM, then they can't be touched by anything except configured peers.
TCP/179 scanning of BGP speakers which haven't implemented the BCPs isn't generally going to return much in the way of useful results beyond identifying the BGP speakers themselves, as the scanners aren't configured as peers (it may be possible to fingerprint some BGP speakers via scanning a la nmap or zmap or masscan, perhaps someone else can comment on this). That being said, attackers will scan routers that they're interested in DDoSing or subverting; implementing the relevant BCPs is strongly recommended.
Networks which haven't implemented the BCPs sometimes find their BGP peering sessions disrupted via DDoS attacks against the routers themselves; SYN-floods and the like against TCP/179 are sometimes used to disrupt BGP sessions in such scenarios, for example. Aggressive scanning per the above against BGP speakers which haven't implemented the BCPs could result in inadvertent disruption of BGP sessions.
Having seen few hundreds BGP peerings with internal clients as well as with
uplink providers cannot
recall anyone ever even trying to use such features. And given that both
were created back in late 90s early 2000s we can safely assume these
technologies (S-BGP/soBGP) will stay just that - blue-sky academic research
(but who can tell the future on the other hand ...)
In real life people use - bgp ttl security, md5 passwords, control plane
protection of 179 port, inbound/outbound routes filters. So far this has
been enough.
In real life people use - bgp ttl security, md5 passwords, control plane
protection of 179 port, inbound/outbound routes filters. So far this has
been enough.
These mechanisms do little or nothing to protect against unauthorized
origination of routing information. There are plenty of examples which
say it has *not* been enough, see for instance the Pakistan Telecom -
Youtube incident in 2008.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
mis-origination and related problems are all policy problems rather than
technical transport issues. Policy implies human input at some stage along
the chain, so probably the only way we'll ever see the end of unintended
prefix leaks is to completely eliminate human input in all aspects of
routing policy management.
Nick
I see a distinction between policy and authorization.
Policy is something the ISP decides for themselves - "I make my own routing policy as to what is my best path".
BGP was created to make it possible for operators to have that policy decision.
Authorization is something else.
Prefix holders want to say "I authorize the origination of this prefix". Operators can decide to enforce that authorization in their policy or not, but at least the prefix holder gets to make the determination of what is authorized. (See IRR route objects, RPKI ROAs)
There are those who call route leaks an authorization problem. [[[I think.]]]] They want to be able to say "I authorize my neighbor to propagate this announcement with the following constraints (no peers, no transit, customers only, etc)." [[[I think.]]] Again, operators could decide to enforce that authorization in their policy or not, but those wanting to stop route leaks want to make the determination of what is authorized.
Policy is local.
Authorization is global. (And so it relies on global access to a statement of the authorization, aye, there's the rub.)
--Sandy
I don't think anyone uses S-BGB or soBGP in the wild--except on Internet2 (debatable whether I2 is in the wild). Mostly just labs and classrooms...?
We get zmap/nmap/xmap scans on our BGP speakers constantly. However, most people do a tight lockdown on anything internet-exposed, limiting useful information for most speakers to whatever their prime function is (routing, gathering, reflecting, etc.)
--Patrick Darden
Let me disagree - Pakistan Youtube was possible only because their uplink
provider did NOT implement inbound route filters . As always the weakest
link is human factor - and no super-duper newest technology is ever to help
here .
As regards to S-bgp/soBGP from technical point of view , wait for the day
when the vulnerability gets published (SSL-heartbleed style) that
invalidates all this PKI stuff ...
Yuri
Authorization is global. (And so it relies on global access to a
statement of
the authorization, aye, there's the rub.)
The real rub is -- What are you authorizing? Or perhaps -- what can you
actually authorize in BGP, or any other routing protocol? This is the
question that (as of yet) hasn't even been asked, from what I can see.
Russ
Let me disagree - Pakistan Youtube was possible only because their uplink
provider did NOT implement inbound route filters . As always the weakest
link is human factor - and no super-duper newest technology is ever to help
here .
One problem with route filters is that the protection relies on the place closest to the problem to detect the leak.
Further on in the network, not as effective.
As regards to S-bgp/soBGP from technical point of view , wait for the day
when the vulnerability gets published (SSL-heartbleed style) that
invalidates all this PKI stuff …
Or the IRRs on which the route filters are built. (No need for publication of a vulnerability. See recent msgs about already known problems with IRRs.)
--Sandy
Let me disagree - Pakistan Youtube was possible only because their uplink
provider did NOT implement inbound route filters . As always the weakest
link is human factor - and no super-duper newest technology is ever to help
here .
Agreed, the uplink absolutely should have implemented prefix filtering.
However, if the Youtube prefixes had been protected with RPKI, ISPs far
away could have verified the announcements themselves - and would have
found that the Pakistan Telecom originated prefixes were invalid (and
would presumably have found the original Youtube prefixes to be valid).
As least that's how I understand RPKI.
I want *both* prefix filtering and a system like RPKI.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Am I the only guy wondering how many boxes out there are *still*
vulnerable to forged RST packets?
That's covered by ' . . . and the like . . . '
;>