Information Page for
the offpath BoF:
Path-decoupled
Signaling for Data (offpath)
To be held at the 66th (
BoF Chairs: Aaron Falk,
BoF Initiators:
Paul Francis and Saikat Guha
(both of
<francis, saikat>@cs.cornell.edu
General Discussion:
off-path-bof@ietf.org
To Subscribe: off-path-bof-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/off-path-bof/index.html
This page at: http://www.cs.cornell.edu/people/francis/offpath
Purpose of BoF:
Gauge interest in creating an
IRTF research group on this topic.
Synopsis:
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:
http://nutss.gforge.cis.cornell.edu/
last updated June 6, 2006