Skip to main content
  • QUIC working group looks to bring more security to Internet traffic

    Lucas Pardue serves as co-chair of the IETF QUIC Working Group, which focuses on a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol. The IETF blog recently asked Pardue about the QUIC standards project.

    • Grant GrossIETF Blog Reporter
    14 Jun 2021
  • Q&A with our new Director of Development

    Lee-Berkeley Shaw joins the IETF Administration LLC today as Director of Development. She will focus on designing and delivering the strategy to achieve the IETF’s goals for financial sustainability, with a focus on growing the IETF Endowment. We asked her questions about her plans for the IETF and her background.

    • Grant GrossIETF Blog Reporter
    7 Jun 2021
  • A new era in Internet transport

    The IETF’s Transport and Services (TSV) area is developing several potentially transformative technologies while it continues to maintain many of the foundational protocols of the Internet.

    • Martin DukeTransport Area Director
    • Zaheduzzaman SarkerTransport Area Director
    • Magnus Westerlund
    3 Jun 2021
  • Innovative New Technology for Sending Data Over the Internet Published as Open Standard

    Already broadly deployed and used, QUIC provides lower delay, improved security, and more robust delivery of data.

      3 Jun 2021
    • QUIC in the Internet industry

      QUIC, a new Internet transport technology that improves web application performance, security and privacy, was reviewed, redesigned and improved in the IETF, incorporating a broad range of input from across the industry.

        3 Jun 2021

      Filter by topic and date

      Filter by topic and date

      What does “Internet Access” mean?

      • Ted HardieIAB Chair

      12 Jun 2017

      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.

      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.


      Share this page