[e2e] Offpath BoF at Montreal IETF

[Paul Francis]

Gang,

The offpath BoF, titled "Path-decoupled Signaling for Data", as been approved
for the next IETF.  The proposed topic for the BoF is copied below, and is
also available at http://www.cs.cornell.edu/people/francis/offpath/.

This message is being sent (separately) to the nsis, behave, p2psip,
e2e-interest, and ietf mailing lists.

The purpose of this message is to solicite feedback about the topics and
agenda for the BoF.  Note that the immediate goal of the BoF is to create an
IRTF research group.  

A BoF mailing list has been created (see below).

Thanks,

PF


---------------------------------------------------------------------

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 Chair:  TBD

  

BoF Initiators: 
Paul Francis and Saikat Guha (both of Cornell University) <francis,
saikat>@cs.cornell.edu

 

General Discussion: off-path-bof at ietf.org To Subscribe:
off-path-bof-request at 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, though other outcomes will of course be
considered.

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/