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

[Aaron Falk <falk at ISI.EDU>]

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

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

  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.


_______________________________________________
IRTF-Announce mailing list
IRTF-Announce at irtf.org
https://www1.ietf.org/mailman/listinfo/irtf-announce