Tag Archives: IAB

What does “Internet Access” mean?

On the joint day of the the recent IESG and IAB retreats, the group discussed a number of topics related to network operator activities for encrypted flows. As part of that conversation, the group looked at RFC 4084, which tackled the question what “Internet Access” means. A dozen years on, that subject probably deserves a new look, and several of the folks at the retreat agreed to draft a new version for community review.

As one of those volunteers, I’d like to dive into RFC 4084 a bit and explore what may have changed since it was published. After walking through the need to avoid pejorative terms, the RFC sets out the following types of connectivity: web connectivity; client connectivity only with no public address; client connectivity only with a public address; firewalled Internet connectivity; and full Internet connectivity.

For those who have bought enterprise connectivity recently, it’s obvious that several common categories are missing: dark fiber, lit service connectivity to a home office, managed MPLS tunnels, and so on. More importantly, though, the RFC doesn’t really touch on cellular wireless connectivity at all, which is now one of the most common ways people connect to the Internet. That means that it doesn’t touch on topics like data caps, roaming for data services, zero rating, or data compression proxies. For cellular connectivity, those can be the key to understanding the trade-offs in connectivity, privacy, and costs for a particular service offering.

Beyond that proliferation in available offerings, there has been another major change, in the ubiquity of filtering. RFC 4084 describes filtering at the ISP level in section 3 and notes “the effort to control or limit objectionable network traffic has led to additional restrictions on the behavior and capabilities of internet services”. RFC 7754 has since provided a much more detailed description of blocking and filtering, and it highlights restricting objectionable content as a category beyond blocking objectionable traffic. That blocking may be a requirement imposed by state regulators. In those jurisdictions, what RFC 4084 described as “full Internet connectivity” has disappeared, because service providers are required to prevent their customers from reaching specific Internet resources, services, or destinations. Even where blocks are not in place, regulatory increases in the amount of Internet tracking data retained and the length of time it is kept have become common. These may contribute to self-censorship in the use of some content. Put simply, firewalled Internet connectivity has become the default offering required of service providers within those territories.

Lastly, the document describes Internet connectivity in terms that apply to the services which would be consumed by a human user and, though some social networking or streaming services are not included, it is generally useful in that regard. As we move into an era in which devices talk to other devices, we also need to examine what a service provides for traffic among devices or between devices and back-end services. Is the implication of a web-only service that the Internet of Things is not supported, or is the implication that it must be reached by a web-based gateway or proxy? The difference between those two is a serious topic of contemplation now, and the architecture of a number of services will depend on it.

In many cases, the architecture of the Internet has developed in the course of a commercial dialog between network operators’ offerings and consumers’ use. Many efforts to make cellular systems walled gardens failed, for example, because the users simply weren’t willing to use them that way and wanted the broader connectivity of the Internet. As we look at this new tension among users’ desires for confidential communication, network operators’ management practices, and regulatory frameworks, a common vocabulary for the services available to the user may help us understand what architectures we can build. If you’d like to contribute to the early discussion, architecture-discuss@iab.org is one place to start.

Ted Hardie

Coordinating Incident Response at Internet Scale (CARIS)

Kathleen Moriarty, Security Area Director

Coordinating incident response at Internet scale as a concept sounds fabulous, but can we achieve it? What will it take?

For those working in incident response and information sharing efforts, we know there is much to be done. While there is lots of good work progressing this area of information security, there are still very few resources skilled in forensics and mitigating threats. The CARIS workshop will bring together the diverse sets of experts to collaborate and better scale their efforts.

Last year, I wrote a blog series on the problems in the space with some ideas on how we might be able to progress in a way that helps not only the large organizations with resources to participate, but also smaller organizations with no resources.  The smaller organizations are part of the supply chain, hence the motivation to assist them. You can find more information in the blog series: Driving Towards More Effective Sharing Models.

One of the key takeaways, is the need for coordination among those driving efforts to progress this space including those running attack type mitigation efforts (APWG, ACDC, etc.), operators at service providers, regional CSIRTs, security professionals at large organizations, researchers, and vendors. Coordination requires getting these folks into the same room to see how we might collectively advance this space and have a greater impact with the few resources dedicated to these activities. The Internet Architecture Board (IAB) and the Internet Society (ISOC) CARIS workshop is set to take place on June 19th on the last day of the FIRST conference in Berlin.

CARIS will be run as a workshop to allow for active participation of attendees with a requirement to submit a research paper or fill in a template on your organizations sharing and mitigation efforts. All research papers accepted will be published on the IAB CARIS site and the template information will be shared out with participants via ISOC. The template will provide information needed for organizations to participate in each other’s efforts, potentially reducing duplication of effort and improve scaling of resources. This increased coordination of threat information may help with automation through the involvement of vendors.  Additionally, the increased coordination could assist with the ability to directly address threats where they can be mitigated or stopped by service providers, CSIRTS, or threat specific working groups.

One goal of this coordination is to more efficiently address threats for all, rather than limiting activity to sharing by organizations with adequate resources. This requires coordination among those with resources. The database of sharing efforts has the potential to increase collaborative efforts by involving communities such as the service providers and vendors who might be able to more quickly address such threats. Bringing this diverse crowd into a full day workshop could be a catalyst to enable future collaboration between organizations. We look forward to your submission and collaboration! The call for papers is open until April 3, 2015.