[EME] New IRTF RG chartered: End-Middle-End Research Group

[Aaron Falk <[e-mail]>]

A new IRTF research group, End-Middle-End (EME) Research Group, has  
been created with the appended charter.

The full RG charter is at
   http://www.irtf.org/eme
The RG web page/wiki is at:
   http://www1.tools.ietf.org/group/irtf/trac/wiki/EME
Subscribe to the mailing list:
   https://www1.ietf.org/mailman/listinfo/eme.

Aaron Falk
IRTF Chair

(Note that the membership of the [e-mail] mailing list  
has been moved to [e-mail].  The archives should be moved soon as  
well.)

====================================================

   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 and other middle
   boxes, which expect to understand the semantics behind any given
   port number (for instance to block or differentially handle a flow).
   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 exacerbated 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 packets 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 has no 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-Middle-End Research Group (EME) 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 experimental 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 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 and 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.


_______________________________________________
EME mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/eme