From off-path-bof-bounces@ietf.org Mon Aug 14 13:53:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCgcn-0003MS-7E; Mon, 14 Aug 2006 13:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCgcm-0003MN-FG for off-path-bof@ietf.org; Mon, 14 Aug 2006 13:53:16 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCgcl-0004qM-1o for off-path-bof@ietf.org; Mon, 14 Aug 2006 13:53:16 -0400 Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 13:53:14 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 14 Aug 2006 13:53:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IRTF agenda Thread-Index: AcamorURyjc1zgYSReSo/Qa5N3UqMAJXg/+AA/I+y9A= From: "Paul Francis" To: X-OriginalArrivalTime: 14 Aug 2006 17:53:14.0657 (UTC) FILETIME=[840FE110:01C6BFCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: Subject: [OFF-PATH-BOF] Proposed IRTF agenda X-BeenThere: off-path-bof@ietf.org 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: , Errors-To: off-path-bof-bounces@ietf.org 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) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D 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. =20 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.=20 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 From off-path-bof-bounces@ietf.org Wed Aug 30 09:44:41 2006 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: 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" To: "Paul Francis" , 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=20 is being assumed to be URIs]. Probably both of these namespaces have to be assumed to be=20 structured, for scalability reasons. That structuring will be=20 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=20 space. Are these two structures assumed to be the same? Can one be derived from the other? For example, is it assumed that the=20 data and signalling paths will coincide at some coarse ('domain') level? Or is the signalling going to select matching network=20 paths? Or can the signalling and data paths be totally uncorrelated? In which case, how do the devices on the signalling path find out=20 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]=20 > Sent: 14 August 2006 18:53 > To: off-path-bof@ietf.org > Subject: [OFF-PATH-BOF] Proposed IRTF agenda >=20 >=20 >=20 > Below is the proposed IRTF agenda: >=20 > Note that Mark Handley authored an earlier version, and=20 > hasn't had a chance > to comment on this one (which was tweaked as a result of comments from > Aaron). >=20 > Comments appreciated. >=20 > PF >=20 >=20 >=20 >=20 >=20 > Draft Charter for the End-Middles-End Research Group (EMMERG) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > Charter Authors: Mark Handley, Paul Francis > Proposed RG Chairs: Allison Mankin, Paul Francis >=20 > 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 >=20 > Web site (subject to change once irtf group created): > http://www.cs.cornell.edu/people/francis/offpath/ >=20 >=20 > Proposed Charter: >=20 > In the original Internet end-to-end architecture, a transport=20 > connection > linked a pair of hosts and was bound to a globally unique IP=20 > address and > locally meaningful transport port at each end host. This=20 > architecture has > been progressively eroded, most notably by the use of NATs,=20 > which modify > addresses, and firewalls, which expect to understand the=20 > semantics behind any > given port number. As a result, end hosts are often not able=20 > to connect even > when security policies would otherwise allow such=20 > connections. This problem > will only be exascerbated with the emerging need for=20 > IPv4-IPv6 translation. > Beyond this, other changes in the way the Internet is used=20 > has stressed the > original unique address/port model of transport connections. =20 > For instance, > the need for robustness has resulted in a rise in=20 > multi-homing, which has led > to scaling issues in BGP. The use of multiple addresses at=20 > hosts is known to > alleviate this problem, but the architecture provides no good=20 > way to manage > multiple addresses, either at connection establishment or=20 > when the active > address has to be changed. Mobility across access networks=20 > similarly results > in the need to cope with changing IP addresses during a=20 > connection. In > addition, DoS attacks are increasingly a concern. There is a=20 > 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). >=20 > The common roots of this seemingly diverse set of problems=20 > are the following: >=20 > 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=20 > the end-host > that opened the socket. > 3. End hosts are often not explicitly aware of middle boxes,=20 > especially > middle boxes far away from them, and therefore cannot control=20 > them much less > be aware of what they are doing. >=20 > Beyond the specific problems mentioned above, this erosion of=20 > 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. >=20 > While this group is not the first to identify these problems,=20 > we do recognize > that there may be a single architectural enhancement that=20 > solves them all. > Namely, a higher-level DNS-based naming scheme (i.e. URIs)=20 > coupled with > signaling protocols used to initiate and modify=20 > transport-level connections > such as TCP, UDP, SCTP or DCCP flows. Such a protocol could=20 > provide a way > for end-to-end communication to explicitly address=20 > middleboxes, so that their > behavior can be understood, monitored and controlled. Such a=20 > protocol might > also be used to move connections between IP addresses, as=20 > with mobility and > multihoming, and to shut down unwanted communication, as with=20 > DoS attacks. =20 >=20 > The goal of the End-Middles-End Research Group (EMMERG) is to=20 > evaluate the > feasibility and desirability of such an architectural change=20 > to the Internet. > The aim is first to investigate possible designs for a=20 > strawman protocol that > can perform these tasks (the so-called "ideal" design)=20 > without being overly > constrained by overlapping work happening in the IETF and=20 > elsewhere. Should > one or more designs appear viable, then issues such as=20 > related work and > incremental deployment should be considered. Should this=20 > work still appear > viable, then the IESG will be consulted with regards to=20 > whether and how this > would should be brought into the IETF for standardization. >=20 > There are many questions that need to be answered along the=20 > way. These > issues include precisely which architectural problems should=20 > be tackled and > which should not, the degree to which such signaling should=20 > be on-path vs > off-path, the balance between flexibility vs simplicity and=20 > efficiency. > There are clear concerns about such a track that need to be evaluated. > Candidate protocols should avoid falling into the virtual=20 > circuit trap, where > routers lose the ability to remedy failures locally, and=20 > avoid building a > mechanism that encourages the construction of walled gardens=20 > to the detriment > of the Internet as a whole. >=20 > Work Items > ---------- >=20 > 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. >=20 > 2. Design Choices Document. This document would describe=20 > 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. >=20 > 3. Strawman Protocol Design. >=20 > 4. A series of documents describing how the strawman=20 > protocol might be > used to address specific architectural issues. >=20 > 5. Incremental deployment plan. A document describing the obstacles > that would be faced deploying the strawman protocol, and how these > issues might be addressed. >=20 > 6. One or more reference implementations of the strawman protocol. >=20 > It is envisaged that the first three will be worked on simultaneously, > with (4) through (6) following later as the strawman protocol=20 > solidifies. >=20 >=20 >=20 > Membership >=20 > The RG operates in an open fashion (meetings & mailing=20 > list). In some > cases, closed "design teams" may be used to accomplish work=20 > items that would > significantly benefit from a smaller group of people, or work=20 > items that > cannot be accomplished in an open group (e.g., due to data=20 > sharing issues). > The status of any closed activities the RG undertakes shall=20 > be reported to > the entire RG periodically.=20 >=20 >=20 >=20 > Meetings >=20 > Meetings will be held as needed, but certainly no more=20 > than two or three > a year, hopefully less. >=20 > _______________________________________________ > OFF-PATH-BOF mailing list > OFF-PATH-BOF@ietf.org > https://www1.ietf.org/mailman/listinfo/off-path-bof >=20 _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof From off-path-bof-bounces@ietf.org Wed Aug 30 19:54:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIZst-0002Mt-6m; Wed, 30 Aug 2006 19:54:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIZsr-0002K1-Mf for off-path-bof@ietf.org; Wed, 30 Aug 2006 19:54:13 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIZsq-00070f-58 for off-path-bof@ietf.org; Wed, 30 Aug 2006 19:54:13 -0400 Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by exchfe1.cs.cornell.edu 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: X-MS-Has-Attach: X-MS-TNEF-Correlator: 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 Cc: X-BeenThere: off-path-bof@ietf.org 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: , Errors-To: off-path-bof-bounces@ietf.org =20 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 (probably). 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: =20 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.=20 PF -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 Sent: Wednesday, August 30, 2006 9:44 AM To: Paul Francis; off-path-bof@ietf.org Subject: RE: [OFF-PATH-BOF] Proposed IRTF agenda 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 >=20 >=20 >=20 > Below is the proposed IRTF agenda: >=20 > Note that Mark Handley authored an earlier version, and hasn't had a=20 > chance to comment on this one (which was tweaked as a result of=20 > comments from Aaron). >=20 > Comments appreciated. >=20 > PF >=20 >=20 >=20 >=20 >=20 > Draft Charter for the End-Middles-End Research Group (EMMERG)=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > Charter Authors: Mark Handley, Paul Francis Proposed RG Chairs:=20 > Allison Mankin, Paul Francis >=20 > Mail List (subject to change once irtf group created): > General Discussion: off-path-bof@ietf.org To Subscribe: =20 > off-path-bof-request@ietf.org In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/off-path-bof/index.html >=20 > Web site (subject to change once irtf group created): > http://www.cs.cornell.edu/people/francis/offpath/ >=20 >=20 > Proposed Charter: >=20 > In the original Internet end-to-end architecture, a transport=20 > connection linked a pair of hosts and was bound to a globally unique=20 > IP address and locally meaningful transport port at each end host. =20 > This architecture has been progressively eroded, most notably by the=20 > use of NATs, which modify addresses, and firewalls, which expect to=20 > understand the semantics behind any given port number. As a result,=20 > end hosts are often not able to connect even when security policies=20 > 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=20 > stressed the original unique address/port model of transport=20 > connections. > For instance, > the need for robustness has resulted in a rise in multi-homing, which=20 > has led to scaling issues in BGP. The use of multiple addresses at=20 > hosts is known to alleviate this problem, but the architecture=20 > provides no good way to manage multiple addresses, either at=20 > connection establishment or when the active address has to be changed. = =20 > Mobility across access networks similarly results in the need to cope=20 > with changing IP addresses during a connection. In addition, DoS=20 > attacks are increasingly a concern. There is a need for hosts to be=20 > able to control which other hosts can send packet to it, and to=20 > exercise that control deep in the network (i.e. near the attacker). >=20 > The common roots of this seemingly diverse set of problems are the=20 > following: >=20 > 1. The IP address is no longer globally unique, is no longer intact=20 > end-to-end, and is no longer stable over even short time periods. > 2. The transport port number have clear semantics outside of the=20 > end-host that opened the socket. > 3. End hosts are often not explicitly aware of middle boxes,=20 > especially middle boxes far away from them, and therefore cannot=20 > control them much less be aware of what they are doing. >=20 > Beyond the specific problems mentioned above, this erosion of the=20 > original E2E Internet mechanisms broadly results in greater=20 > application-level complexity (to cope with the erosion), network=20 > fragility and lack of robustness, poor security, and difficulty in=20 > debugging the resulting problems. >=20 > While this group is not the first to identify these problems, we do=20 > recognize that there may be a single architectural enhancement that=20 > solves them all. > Namely, a higher-level DNS-based naming scheme (i.e. URIs) coupled=20 > with signaling protocols used to initiate and modify transport-level=20 > connections such as TCP, UDP, SCTP or DCCP flows. Such a protocol=20 > could provide a way for end-to-end communication to explicitly address = > middleboxes, so that their behavior can be understood, monitored and=20 > controlled. Such a protocol might also be used to move connections=20 > between IP addresses, as with mobility and multihoming, and to shut=20 > down unwanted communication, as with DoS attacks. >=20 > The goal of the End-Middles-End Research Group (EMMERG) is to evaluate = > the feasibility and desirability of such an architectural change to=20 > the Internet. > The aim is first to investigate possible designs for a strawman=20 > protocol that can perform these tasks (the so-called "ideal" design)=20 > without being overly constrained by overlapping work happening in the=20 > IETF and elsewhere. Should one or more designs appear viable, then=20 > issues such as related work and incremental deployment should be=20 > considered. Should this work still appear viable, then the IESG will=20 > be consulted with regards to whether and how this would should be=20 > brought into the IETF for standardization. >=20 > There are many questions that need to be answered along the way. =20 > These issues include precisely which architectural problems should be=20 > tackled and which should not, the degree to which such signaling=20 > should be on-path vs off-path, the balance between flexibility vs=20 > 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=20 > trap, where routers lose the ability to remedy failures locally, and=20 > avoid building a mechanism that encourages the construction of walled=20 > gardens to the detriment of the Internet as a whole. >=20 > Work Items > ---------- >=20 > 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. >=20 > 2. Design Choices Document. This document would describe the design=20 > choices > available, so as on-path vs off-path options, signal encoding, and > naming and addressing issues, both for end-systems and middleboxes. >=20 > 3. Strawman Protocol Design. >=20 > 4. A series of documents describing how the strawman protocol might=20 > be > used to address specific architectural issues. >=20 > 5. Incremental deployment plan. A document describing the obstacles > that would be faced deploying the strawman protocol, and how these > issues might be addressed. >=20 > 6. One or more reference implementations of the strawman protocol. >=20 > It is envisaged that the first three will be worked on simultaneously, = > with (4) through (6) following later as the strawman protocol=20 > solidifies. >=20 >=20 >=20 > Membership >=20 > The RG operates in an open fashion (meetings & mailing list). In=20 > some cases, closed "design teams" may be used to accomplish work items = > that would significantly benefit from a smaller group of people, or=20 > work items that cannot be accomplished in an open group (e.g., due to=20 > data sharing issues). > The status of any closed activities the RG undertakes shall be=20 > reported to the entire RG periodically. >=20 >=20 >=20 > Meetings >=20 > Meetings will be held as needed, but certainly no more than two or = > three a year, hopefully less. >=20 > _______________________________________________ > OFF-PATH-BOF mailing list > OFF-PATH-BOF@ietf.org > https://www1.ietf.org/mailman/listinfo/off-path-bof >=20 _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof