RE: [OFF-PATH-BOF] Proposed IRTF agenda

"Paul Francis" <> Wed, 30 August 2006 23:54 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GIZst-0002Mt-6m; Wed, 30 Aug 2006 19:54:15 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GIZsr-0002K1-Mf for; Wed, 30 Aug 2006 19:54:13 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GIZsq-00070f-58 for; Wed, 30 Aug 2006 19:54:13 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Aug 2006 19:54:11 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [OFF-PATH-BOF] Proposed IRTF agenda
Date: Wed, 30 Aug 2006 19:54:09 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [OFF-PATH-BOF] Proposed IRTF agenda
Thread-Index: AcamorURyjc1zgYSReSo/Qa5N3UqMAJXg/+AA/I+y9ADGe+lMAAW3ilA
From: "Paul Francis" <>
To: "Hancock, Robert" <>, <>
X-OriginalArrivalTime: 30 Aug 2006 23:54:11.0620 (UTC) FILETIME=[973A2E40:01C6CC8F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "BOF: Path-decoupled Signaling for Data" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Sorry for the delay on this answer...I've been on the road.

Here is my view.

I see two name-spaces, one IP addresses and the other DNS-rooted URIs

I see the two name-spaces as de-coupled, and the signaling path and data path
as different.

However, there is a relationship between the two, which is:  

Everywhere there is a "firewall" function in the datapath, there is a
corresponding "policy box" in the signaling path.  The policy box knows about
the firewall, and knows what information the firewall needs to allow flows to
path (lets call that "information" a "token").  The policy box can convey the
tokens to the end hosts during the signaling, and they in turn can convey
these tokens to the firewalls.  (The token may be nothing more than a nonce
and the IP address of the policy box, thus allowing the firewall to validate
the flow with the policy box.)  Likewise, the firewall knows about the policy
box so that it can help the end host discover the policy box. 


-----Original Message-----
From: Hancock, Robert [] 
Sent: Wednesday, August 30, 2006 9:44 AM
To: Paul Francis;
Subject: RE: [OFF-PATH-BOF] Proposed IRTF agenda


A few comments. (These occurred to me before the original bof, and even while
reading the nutss papers, but the subsequent discussions haven't made them
any clearer to me.)

It strikes me that the fundamental assumption behind emmerg is that there are
two namespaces in the world
- one based on IP addresses, within which data packets are routed
- one based on some other identifier, within which signalling packets are
routed [it may even be the case that this namespace is being assumed to be
Probably both of these namespaces have to be assumed to be structured, for
scalability reasons. That structuring will be related in some way to the way
the network itself is structured.

What I've never been able to work out is what are the assumed relationships
between the network structure as seen in IP address space and the network
structure as seen in URI-or-other-identifier space. Are these two structures
assumed to be the same? Can one be derived from the other? For example, is it
assumed that the data and signalling paths will coincide at some coarse
('domain') level? Or is the signalling going to select matching network
paths? Or can the signalling and data paths be totally uncorrelated?
In which case, how do the devices on the signalling path find out which data
path devices to control?

Is it the view that all of these are entirely open points which will be
clarified in developing the applicability statement?
Or are there already statements which can be made? They would seem to me to
correspond to a lot of variability in the problem space (which take it all
the way from "impossible" to "design the protocol now"), and I'm not really
clear on where emmerg is positioning itself on that spectrum.


Robert h.

> -----Original Message-----
> From: Paul Francis []
> Sent: 14 August 2006 18:53
> To:
> Subject: [OFF-PATH-BOF] Proposed IRTF agenda
> 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: To Subscribe:  
> In Body: (un)subscribe
> Archive:
> Web site (subject to change once irtf group created):
> 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

OFF-PATH-BOF mailing list