Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)

It is widely recognized that the Internet transport layer has become ossified, where further evolution has become hard or even impossible. This is a direct consequence of the ubiquitous deployment of middleboxes that hamper the deployment of new transports, aggravated further by the limited flexibility of the application programming interface (API) typically presented to applications. To tackle this problem, a wide range of solutions have been proposed in the literature, each aiming to address a particular aspect. Yet, no single proposal has emerged that is able to enable evolution of the transport layer. In this paper, after an overview of the main issues and reasons for transportlayer ossification, we survey proposed solutions and discuss their potential and limitations. The survey is divided into five parts, each covering a set of point solutions for a different facet of the problem space: 1) designing middlebox-proof transports; 2) signaling for facilitating middlebox traversal; 3) enhancing the API between the applications and the transport layer; 4) discovering and exploiting end-to-end capabilities; and 5) enabling user-space protocol stacks. Based on this analysis, we then identify further development needs toward an overall solution. We argue that the development of a comprehensive transport layer framework, able to facilitate the integration and cooperation of specialized solutions in an application-independent and flexible way, is a necessary step toward making the Internet transport architecture truly evolvable. To this end, we identify the requirements for such a framework and provide insights for its development.

show abstract

“…Techniques for TCP hole punching are presented in [18] and [96]. The IETF has defined a TURN relay for TCP [97] and DTLS [98].…”

Section: A Implicit Middlebox Controlmentioning

confidence: 99%

De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives

Παπαστεργίου

Fairhurst

Ros

et al. 2017

IEEE Commun. Surv. Tutorials

View full text Add to dashboard Cite

show abstract

“…This document describes a security mechanism, details of which are mentioned in Sections 4.1 and 4.2 of [RFC7350]. Consent requires 96 bits transaction ID defined in Section 6 of [RFC5389] to be uniformly and randomly chosen from the interval 0 .. 2**96-1, and be cryptographically strong.…”

Section: Security Considerationsmentioning

confidence: 99%

Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness

Reddy¹,

Wing²,

Thomson³

et al. 2015

View full text Add to dashboard Cite

show abstract

“…An attacker may remove the THIRD-PARTY-AUTHORIZATION STUN attribute from the error message forcing the client to pick first-party authentication; this attack may be mitigated by opting for TLS [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC6347] as a transport protocol for STUN, as defined in [RFC5389]and [RFC7350].…”

Section: Security Considerationsmentioning

confidence: 99%