CSRIC Tackles E911 Location Accuracy, BGP Security Extensions, DNSSEC Support
When the next disaster strikes, the best practices recommended by the FCC’s Communications Security, Reliability and Interoperability Council will ensure the American public has access to a reliable public safety network, Commissioner Ajit Pai told CSRIC Thursday. CSRIC approved several reports designed to improve Internet security and 911 reliability and location accuracy. Zachary Katz, chief of staff for Chairman Julius Genachowski, praised the working group that he said “moves the ball in very meaningful ways,” with 92 percent of ISPs having adopted its recommendations. Public Safety Bureau Chief David Turetsky called the CSRIC results “nothing short of spectacular."
Sign up for a free preview to unlock the rest of this article
If your job depends on informed compliance, you need International Trade Today. Delivered every business day and available any time online, only International Trade Today helps you stay current on the increasingly complex international trade regulatory environment.
"Significantly more work needs to be done” on addressing the challenge of indoor location accuracy for 911 callers, said Steve Wisely, co-chair of the E-911 location accuracy working group. The group analyzed Wi-Fi based location, metropolitan beacon, RF fingerprinting and other technologies. Subsequent test beds should have trials to evaluate future technologies, he said. The group performed testing in the San Francisco Bay Area because it had “a representative sampling of the different morphologies” that needed to be tested, said co-chair Richard Craig.
There was “no major surprise” in the results, Craig said, as the technologies performed “about as they expected them to perform” given the challenges associated with monitoring RF technologies indoors. “We can’t think about indoor accuracy in 911 performance the same way we think about outdoor accuracy,” Craig said. Even traditionally good performance in an outdoor environment won’t meet the “unmitigated expectations of some folks in the industry,” he said. In a dense urban environment, a few feet of accuracy can mean “now you're in a different building."
The working group for Secure Border Gateway Protocol (BGP) Development recommended a framework for incremental adoption of security extensions to the protocol, which is used to make basic routing decisions on the Internet. It’s critically important, said co-chair Andy Ogielski, because “if you break the routing, everything else breaks down too.” The fundamental problem is how to distinguish legitimate routes from “bogus routes,” he said. “We cannot route securely until we really know who is authorized to route what and when.” The “sky is not falling,” he said, “however the incidents we see are fairly unsettling from time to time. In short, they are too common for comfort."
The working group recommended improved mechanisms for keeping databases with Internet number resource ownership and routing policies, which could be done using cryptographic technologies such as public key infrastructure. There should be a cautious, staged deployment of resource public key infrastructure (RPKI) origin validation in order to provide a “good ground truth” about who is authorized to route when and where, Ogielski said. But RPKI “has its own problems,” such as opening new attack surfaces and means of abuse, he said. There should be improved BGP security metrics and measurements, with tracked participation in the RPKI system to measure if it works, he said.
ISP support for Domain Name System Security Extensions (DNSSEC) is necessary, even in a future in which end points perform all validation, the DNSSEC implementation practices group found. They must at a minimum be able to recognize DNSSEC related traffic and let it pass for the smooth functioning of an end-to-end DNSSEC secured system, the report said. Many resolvers are DNSSEC-aware -- “that’s good news,” said working group chair Steve Crocker. But controversy continues over whether DNSSEC aggravates distributed denial-of-service (DDoS) problems, he said: The problem is that name servers can give back longer results with DNSSEC than they would have without, and those play a role in amplified DDoS attacks.
The claim that DNSSEC is causing the problem is “a little bit controversial in its own right in that amplified DDoS attacks existed before DNSSEC,” Crocker said. The “more subtle question” is not whether they enable the attacks, but whether they make them harder to counter, he said. There’s no “simple answer one way or another,” he said, and currently there’s confrontation between two different goals: eliminating DDoS attacks, and protecting the DNS system.
The 911 prioritization working group, tasked with making sure 911 calls could reach public safety in the event of disasters, recommended that currently the FCC do nothing in regards to prioritization of calls. There are possibilities moving forward, but it might not be smart to prioritize the networks, said co-chair Jeanna Green. “Until we have something that the public safety answering points can do when 80 percent of them only have an average of two call takers, prioritizing the networks to get more calls on them when they're not all going to be answered -- or maybe answered slowly, or maybe put in a queue -- I think there are some other issues to deal with before we set priorities to the network,” she said.
Eventually, though, 911 prioritization is conceivable on LTE networks, she said, because that network architecture could give 911 calls a higher priority packet access than non-emergency calls. But it would require enhancements to both the network and the handsets, as legacy handsets can’t take advantage of the prioritization feature on the networks, she said. And emergency preparedness personnel already have their own priority services, she said: “How do you prioritize consumer calls into those existing environments?”