[OFF-PATH-BOF] Proposed IRTF agenda

["Paul Francis" <[e-mail]>]

Below is the proposed IRTF agenda:

Note that Mark Handley authored an earlier version, and hasn't had a chance
to comment on this one (which was tweaked as a result of comments from
Aaron).

Comments appreciated.

PF





Draft Charter for the End-Middles-End Research Group (EMMERG)
=========================================================

Charter Authors: Mark Handley, Paul Francis
Proposed RG Chairs: Allison Mankin, Paul Francis

Mail List (subject to change once irtf group created):
General Discussion: [e-mail]
To Subscribe:  [e-mail]
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/off-path-bof/index.html

Web site (subject to change once irtf group created):
http://www.cs.cornell.edu/people/francis/offpath/


Proposed Charter:

In the original Internet end-to-end architecture, a transport connection
linked a pair of hosts and was bound to a globally unique IP address and
locally meaningful transport port at each end host.  This architecture has
been progressively eroded, most notably by the use of NATs, which modify
addresses, and firewalls, which expect to understand the semantics behind any
given port number.  As a result, end hosts are often not able to connect even
when security policies would otherwise allow such connections.   This problem
will only be exascerbated with the emerging need for IPv4-IPv6 translation.
Beyond this, other changes in the way the Internet is used has stressed the
original unique address/port model of transport connections.  For instance,
the need for robustness has resulted in a rise in multi-homing, which has led
to scaling issues in BGP.  The use of multiple addresses at hosts is known to
alleviate this problem, but the architecture provides no good way to manage
multiple addresses, either at connection establishment or when the active
address has to be changed.  Mobility across access networks similarly results
in the need to cope with changing IP addresses during a connection.  In
addition, DoS attacks are increasingly a concern.  There is a need for hosts
to be able to control which other hosts can send packet to it, and to
exercise that control deep in the network (i.e. near the attacker).

The common roots of this seemingly diverse set of problems are the following:

1.  The IP address is no longer globally unique, is no longer intact
end-to-end, and is no longer stable over even short time periods.
2.  The transport port number have clear semantics outside of the end-host
that opened the socket.
3.  End hosts are often not explicitly aware of middle boxes, especially
middle boxes far away from them, and therefore cannot control them much less
be aware of what they are doing.

Beyond the specific problems mentioned above, this erosion of the original
E2E Internet mechanisms broadly results in greater application-level
complexity (to cope with the erosion), network fragility and lack of
robustness, poor security, and difficulty in debugging the resulting
problems.

While this group is not the first to identify these problems, we do recognize
that there may be a single architectural enhancement that solves them all.
Namely, a higher-level DNS-based naming scheme (i.e. URIs) coupled with
signaling protocols used to initiate and modify transport-level connections
such as TCP, UDP, SCTP or DCCP flows.  Such a protocol could provide a way
for end-to-end communication to explicitly address middleboxes, so that their
behavior can be understood, monitored and controlled.  Such a protocol might
also be used to move connections between IP addresses, as with mobility and
multihoming, and to shut down unwanted communication, as with DoS attacks.  

The goal of the End-Middles-End Research Group (EMMERG) is to evaluate the
feasibility and desirability of such an architectural change to the Internet.
The aim is first to investigate possible designs for a strawman protocol that
can perform these tasks (the so-called "ideal" design) without being overly
constrained by overlapping work happening in the IETF and elsewhere.  Should
one or more designs appear viable, then issues such as related work and
incremental deployment should be considered.  Should this work still appear
viable, then the IESG will be consulted with regards to whether and how this
would should be brought into the IETF for standardization.

There are many questions that need to be answered along the way.  These
issues include precisely which architectural problems should be tackled and
which should not, the degree to which such signaling should be on-path vs
off-path, the balance between flexibility vs simplicity and efficiency.
There are clear concerns about such a track that need to be evaluated.
Candidate protocols should avoid falling into the virtual circuit trap, where
routers lose the ability to remedy failures locally, and avoid building a
mechanism that encourages the construction of walled gardens to the detriment
of the Internet as a whole.

Work Items
----------

 1. Applicability Statement.  This document would investigate possible
   architectural issues that resemble those described above, where
   there is a need to signal between end-systems and entities
   logically in the middle of the network, or where connections need
   to be bound between more than two IP addresses.

 2. Design Choices Document.  This document would describe the design choices
   available, so as on-path vs off-path options, signal encoding, and
   naming and addressing issues, both for end-systems and middleboxes.

 3. Strawman Protocol Design.

 4. A series of documents describing how the strawman protocol might be
   used to address specific architectural issues.

 5. Incremental deployment plan.  A document describing the obstacles
   that would be faced deploying the strawman protocol, and how these
   issues might be addressed.

 6. One or more reference implementations of the strawman protocol.

It is envisaged that the first three will be worked on simultaneously,
with (4) through (6) following later as the strawman protocol solidifies.



Membership

    The RG operates in an open fashion (meetings & mailing list). In some
cases, closed "design teams" may be used to accomplish work items that would
significantly benefit from a smaller group of people, or work items that
cannot be accomplished in an open group (e.g., due to data sharing issues).
The status of any closed activities the RG undertakes shall be reported to
the entire RG periodically. 



Meetings

    Meetings will be held as needed, but certainly no more than two or three
a year, hopefully less.

_______________________________________________
OFF-PATH-BOF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/off-path-bof