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

"Hancock, Robert" <robert.hancock@roke.co.uk> Wed, 30 August 2006 13:44 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIQMq-0003m2-Rn; Wed, 30 Aug 2006 09:44:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIQMp-0003lx-SI for off-path-bof@ietf.org; Wed, 30 Aug 2006 09:44:31 -0400
Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIQMo-000878-2Z for off-path-bof@ietf.org; Wed, 30 Aug 2006 09:44:31 -0400
Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7UDi5VV003076; Wed, 30 Aug 2006 14:44:05 +0100
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 14:44:06 +0100
Message-ID: <A632AD91CF90F24A87C42F6B96ADE5C50157A8B6@rsys005a.comm.ad.roke.co.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OFF-PATH-BOF] Proposed IRTF agenda
Thread-Index: AcamorURyjc1zgYSReSo/Qa5N3UqMAJXg/+AA/I+y9ADGe+lMA==
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "Paul Francis" <francis@cs.cornell.edu>, <off-path-bof@ietf.org>
X-MailScanner-roke-co-uk: Found to be clean
X-MailScanner-roke-co-uk-SpamCheck:
X-MailScanner-From: robert.hancock@roke.co.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990
Cc:
X-BeenThere: off-path-bof@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "BOF: Path-decoupled Signaling for Data" <off-path-bof.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/off-path-bof>, <mailto:off-path-bof-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/off-path-bof>
List-Post: <mailto:off-path-bof@ietf.org>
List-Help: <mailto:off-path-bof-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/off-path-bof>, <mailto:off-path-bof-request@ietf.org?subject=subscribe>
Errors-To: off-path-bof-bounces@ietf.org

Paul,

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 URIs].
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.

cheers,

Robert h.

> -----Original Message-----
> From: Paul Francis [mailto:francis@cs.cornell.edu] 
> Sent: 14 August 2006 18:53
> To: off-path-bof@ietf.org
> 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: off-path-bof@ietf.org
> To Subscribe:  off-path-bof-request@ietf.org
> 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
> OFF-PATH-BOF@ietf.org
> https://www1.ietf.org/mailman/listinfo/off-path-bof
> 

_______________________________________________
OFF-PATH-BOF mailing list
OFF-PATH-BOF@ietf.org
https://www1.ietf.org/mailman/listinfo/off-path-bof