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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 30 Aug 2006 14:44:06 +0100

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:[email-masked]] 
> Sent: 14 August 2006 18:53
> To: [email-masked]
> 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: [email-masked]
> To Subscribe:  [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/off-path-bof
> 

_______________________________________________
OFF-PATH-BOF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/off-path-bof

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 30 Aug 2006 19:54:09 -0400

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:  

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. 

PF

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]] 
Sent: Wednesday, August 30, 2006 9:44 AM
To: Paul Francis; [email-masked]
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.

> 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
> 
> 
> 
> 
> 
> Charter Authors: Mark Handley, Paul Francis Proposed RG Chairs: 
> Allison Mankin, Paul Francis
> 
> General Discussion: [email-masked] To Subscribe:  
> [email-masked] In Body: (un)subscribe
> 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
> 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 
> The common roots of this seemingly diverse set of problems are the 
> following:
> 
> 2.  The transport port number have clear semantics outside of the 
> end-host that opened the socket.
> 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.
> 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
> ----------
> 
>  2. Design Choices Document.  This document would describe the design 
> choices
>  4. A series of documents describing how the strawman protocol might 
> be
>     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.
>