Information Page for the offpath BoF:


Path-decoupled Signaling for Data (offpath)


To be held at the 66th (Montreal) IETF, under the auspices of the Transport Area (Lars Eggert), and coordinated with the IRTF (Aaron Falk).



BoF Chairs:  Aaron Falk, Paul Francis



BoF Initiators: 

Paul Francis and Saikat Guha (both of Cornell University)

<francis, saikat>



General Discussion:
To Subscribe:
In Body: (un)subscribe

This page at:



Purpose of BoF:

Gauge interest in creating an IRTF research group on this topic.





Path-decoupled (or off-path) signaling, in the form of SIP, has proven to be a very powerful mechanism for facilitating media connection establishment between hosts.  It provides friendly naming, discovery, user mobility, authentication, transport and application negotiation, and even NAT/FW traversal for UDP and, more recently, TCP.  Furthermore, it is network independent, working equally well for IPv4 and IPv6.  This set of features, however, would be attractive to all types of data sessions, not just media.  The purpose of this BoF is to gauge interest in the design of off-path signaling (probably but not necessarily using SIP) for establishing all kinds of non-public-server data sessions.  A positive outcome of this BoF would be the formation of an IRTF group.


We are particularly interested in models of off-path signaling that improve security beyond today's address/port/deep-inspection model.  The use of path-decoupled signaling gives both the middle and the ends the opportunity to assert policy and negotiate an acceptable session.  We would like to explore cases where the off-path signaling operates alone (i.e. NAT/FW traversal with legacy NAT/FW's), as well as where it operates in conjunction with subsequent path-coupled signaling (either in-band or out-of-band).  Considering that an application can always lie about what it is, we would also like to explore how to couple the signaling primitives with emerging OS security features (i.e. trusted computing platforms).  Beyond security, we would like to explore the use of off-path signaling for such features as user and host mobility, transport negotiation (i.e. TCP versus SCTP), anycast and multicast, billing, and time-delayed communications messaging). 


The ultimate goal here is that some or all of these features become part of the standard sockets API of typical OS's, and that infrastructure support for the signaling becomes ubiquitous (in the same sense that DNS is ubiquitous).  This would allow application developers, security vendors (middlebox and endhost), users, and network administrators to converge on a unified method of naming and connection establishment over the Internet.  (By contrast, naming and connection establishment through NATs and firewalls today is ad hoc and usually application specific, variously involving email, IM services, dynamic DNS services, manual configuration of ports, and so on.)


Of the IETF working groups, this BoF is most closely aligned with the nsis WG in the Transport Area, especially the NAT/FW NSLP.  The following gives an example of how an off-path signaling protocol would work in conjunction with the NAT/FW NSLP.   This is only an example…there are other approaches and variants on this example.


Say an application wishes to establish a TCP connection with a “peer”, where both peers are behind NAT/FW’s.  The initiating peer off-path signals a connection request.  The request contains the application name, user names, authentication information (Certs or Diameter), and information about the preferred transport (TCP, SSL, IPSec, etc.).  The off-path request is checked by the initiating endhost’s policy, and then flows through policy boxes representing the initiator’s and the recipient’s networks.  This gives both sides an opportunity to reject the request, or to request different transport or security characteristics, or to accept and pass on the request as-is.  Note that the policy boxes could both be far from either ends’ physical network, thus not revealing the IP addresses of either end until the connection is approved.  The policy boxes could also be widely replicated. 


Assuming the connection request is approved, the endhosts use the NAT/FW NSLP to obtain address and port mappings from their respective NAT boxes.  These are conveyed through the off-path signaling channel.  In addition, the policy boxes create secure tokens that firewalls can use to allow the approved connection.  These tokens are passed to the endhosts through off-path signaling, which then convey them on-path, either in-band or out-of-band (i.e. the NAT/FW NSLP), to traverse the firewall.



Supporting material:





last updated June 6, 2006