Subject: [Stackevo] Stack Evolution at the IAB/IESG Retreat: Status and Next Steps

From: Brian Trammell <[email-masked]>
Date: Mon, 11 May 2015 14:23:05 +0200

Greetings, all,

At the IAB/IESG retreat last week in London, we discussed the current state and structure of the IP Stack Evolution Program, work that came out of the SEMI workshop which does not yet have an owner, as well as related new work to take on. Along with the recent discussion on scope and organization, it might be time to update our program description, as well.

First, a review of existing work happening within the program:

(1) Architectural discussion on SPUD: identifying the applications that would benefit from selective explicit middlebox communication in a transport encapsulation, determining the limitations on what can be productively exposed, defining a set of protocol requirements based on these applications and limitations. IMO only once we have a fairly solid set of requirements and agreement on an architecture within the program does it make sense to refer anything to a WG; in the meantime, the [email-masked] list will remain open for general discussion, and architecture work will happen within the program. On which, please have a look at draft-trammell-stackevo-newtea-01 and poke holes in it.

(2) Creation of a HOPS RG to coordinate research and measurement on Internet path transparency impairment caused by middleboxes. This is ongoing, and we hope to have a meeting in Prague. Once this RG is created, this discussion will move there. Mirja Kühlewind holds the pen on the proposed charter and first proto-RG meeting agenda at the moment.

(3) Completion of (currently expired) draft-iab-filtering-considerations, which went through community review in January 2014, inherited from the IP Evolution Program. Dave Thaler holds the pen on this; if you'd like to help, please coordinate with him.

(4) Completion of the SEMI workshop report. We'd like to get this done soon. Please have a look at draft-trammell-semi-report-00 and point out what's missing.

In addition, we have the following work items from SEMI which don't have an editor assigned yet:

(5) A document providing guidelines on middlebox design and deployment; from section 6.3 of draft-trammell-semi-report: "The workshop identified the potential to update [RFC3234] to provide guidelines on middlebox design, implementation, and deployment in order to reduce inadvertent or accidental impact on stack ossification in existing and new middlebox designs.  This document will be produced by the IAB IP Stack Evolution program, drawing in part on the work of the BEHAVE working group, and on experience with STUN, TURN, and ICE, all of which focus more specifically on network address translation."

(6) An IAB statement on transport protocol evolution. It's not clear what this do beyond blessing UDP as the way forward for new transport protocols, in effect acknowledging (1) that the network-transport layer boundary has been four bytes from where the RFCs say it is for some time and (2) that the kernel-userspace boundary isn't really useful for security in a world where everything is virtualized anyway.

At the retreat, we discussed a few issues which we may want to examine in more detail in the program:

(7) General guidelines/principles for designing new encapsulations. We discussed at SEMI the possibility of working on guidelines for UDP as a transport substrate, but this is largely covered by draft-ietf-tsvwg-rfc5405bis. Erik Nordmark raised the point at the retreat that there are a bunch of new encapsulations (e.g. BIER, NVO3) coming out of the routing area, and these may have some common architectural principles with each other as well as with with new transport encapsulations. I'd nominate Erik Nordmark to lead following up on this, since he brought it up. :)

(8) Related to this, there appears to be some architecture and coordination work to do on new stacks, or rather, pointing out well-known principles of good engineering thereon, especially for IoT applications. Are there common principles which can/should be applied to the design of these stacks to make sure we don't have piles of gratuitously incompatible protocols?

(9) General guidelines for protocol transition. If the program is to define an architecture for evolving the transport layer, this will need to have the right incentives for deployment for new applications, as well as for transition from existing transports (where this is useful -- mainly in cases where TCP or HTTP have been pressed into service for less-than-appropriate applications). If there are guidelines for transition to be generalized from this, this would make a new document.

We briefly mentioned (in the joint session with the IESG), but did not discuss, one further piece of work:

(10) An IAB statement on the deployment of ECN (along the lines of 'yes please'). Probably this is a pointer to draft-tsvwg-ecn-benefits and related analysis of the risk of enabling ECN by default (see http://ecn.ethz.ch/ecn-pam15.pdf). We should discuss whether this is something the IAB would be interested in doing before putting much effort into it.

We should put some thought into which of these things we think we can get done during this year (rather, until Buenos Aires), and update the program's description at https://www.iab.org/activities/programs/ip-stack-evolution-program if it's not current anymore. Clearly (1), (2), and (4) are related to the original scope and are ongoing, (5) and (6) are related as well and were referred to us by the workshop (so we should get some names assigned to them, hint hint :). If you've got particular interest and cycles to work on these (or any of the following things), please shout.

Thanks, cheers,

Brian

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 May 2015 10:43:55 -0700

On 5/11/15 5:23 AM, Brian Trammell wrote:
> (7) General guidelines/principles for designing new encapsulations. We discussed at SEMI the possibility of working on guidelines for UDP as a transport substrate, but this is largely covered by draft-ietf-tsvwg-rfc5405bis. Erik Nordmark raised the point at the retreat that there are a bunch of new encapsulations (e.g. BIER, NVO3) coming out of the routing area, and these may have some common architectural principles with each other as well as with with new transport encapsulations. I'd nominate Erik Nordmark to lead following up on this, since he brought it up.
For those that haven't seen it, there is a design team report in 
draft-rtg-dt-encap-01 which was discussed in RTGWG and TSVWG in Dallas, 
and the plan is to make that a RTGWG document.

The use of UDP encapsulation (for NVO3 and potentially SFC and BIER) is 
quite different than the transport evolution using UDP as a substrate. 
For instance, in the former case the encapsulation and decaps are 
typically done in a router or (v)switch, and in the latter is end-to-end 
between the applications. However, there appears to be some common 
considerations as well. For example, OAM error reporting doesn't look 
that different than P2A signalling, and the RTG encaps are also likely 
to be affected by middleboxes (such as NVO3-aware firewalls).

I don't yet know what to do about these observations, but I'm open to 
suggestions. Is there is a way to cross-polinate ideas and what folks 
learn from SPUD/newtea and the RTG encaps that would be great.

> (8) Related to this, there appears to be some architecture and coordination work to do on new stacks, or rather, pointing out well-known principles of good engineering thereon, especially for IoT a…
I think #8 is quite orthogonal to #7. Ralph Droms and I are working on 
framing the concerns related to IoT and different deployment contexts 
vs. protocol fragmentation.

    Erik

---

From: Brian Trammell <[email-masked]>
Date: Wed, 13 May 2015 11:21:50 +0200

hi Tiru,

> On 11 May 2015, at 14:54, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 
> Hi Brain,
> 
> I am interested in taking up (5).

Cool, thanks!

> I have worked on STUN, TURN and ICE protocols; lead author of TURNbis, turn third party authorization for STUN/TURN drafts and contributed to various other WG documents related to these protocols. We had also submitted the following document https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_reddy.pdf for the SEMI workshop.

The thinking about "good middleboxes" and "bad middleboxes" and the line between them is well thought out in the case of NAT, so this is a very good starting place. But I think the document needs eventually to cover the entire spectrum of these things (and I'd be happy if we could get IAB consensus that certain kinds of middleboxes -- transparent traffic content modifiers that MITM crypto, for example --  are simply damaging to the architecture, full stop)

Let us know when you've got a starting point for comment and review.

Thanks again, cheers,

Brian

> Thanks and Regards,
> -Tiru
> 
>> -----Original Message-----
>> From: Stackevo [mailto:[email-masked]] On Behalf Of Brian
>> Trammell
>> Sent: Monday, May 11, 2015 5:53 PM
>> To: [email-masked]
>> Subject: [Stackevo] Stack Evolution at the IAB/IESG Retreat: Status and Next
>> Steps
>> 
>> Greetings, all,
>> 
>> At the IAB/IESG retreat last week in London, we discussed the current state
>> and structure of the IP Stack Evolution Program, work that came out of the
>> SEMI workshop which does not yet have an owner, as well as related new
>> work to take on. Along with the recent discussion on scope and organization,
>> it might be time to update our program description, as well.
>> 
>> (1) Architectural discussion on SPUD: identifying the applications that would
>> benefit from selective explicit middlebox communication in a transport
>> encapsulation, determining the limitations on what can be productively
>> exposed, defining a set of protocol requirements based on these applications
>> and limitations. IMO only once we have a fairly solid set of requirements and
>> agreement on an architecture within the program does it make sense to refer
>> anything to a WG; in the meantime, the [email-masked] list will remain open
>> for general discussion, and architecture work will happen within the
>> program. On which, please have a look at draft-trammell-stackevo-newtea-
>> 01 and poke holes in it.
>> 
>> (2) Creation of a HOPS RG to coordinate research and measurement on
>> Internet path transparency impairment caused by middleboxes. This is
>> ongoing, and we hope to have a meeting in Prague. Once this RG is created,
>> this discussion will move there. Mirja Kühlewind holds the pen on the
>> proposed charter and first proto-RG meeting agenda at the moment.
>> 
>> (3) Completion of (currently expired) draft-iab-filtering-considerations, which
>> went through community review in January 2014, inherited from the IP
>> Evolution Program. Dave Thaler holds the pen on this; if you'd like to help,
>> please coordinate with him.
>> 
>> (4) Completion of the SEMI workshop report. We'd like to get this done soon.
>> Please have a look at draft-trammell-semi-report-00 and point out what's
>> missing.
>> 
>> (5) A document providing guidelines on middlebox design and deployment;
>> from section 6.3 of draft-trammell-semi-report: "The workshop identified the
>> potential to update [RFC3234] to provide guidelines on middlebox design,
>> implementation, and deployment in order to reduce inadvertent or
>> accidental impact on stack ossification in existing and new middlebox
>> designs.  This document will be produced by the IAB IP Stack Evolution
>> program, drawing in part on the work of the BEHAVE working group, and on
>> experience with STUN, TURN, and ICE, all of which focus more specifically on
>> network address translation."
>> 
>> (6) An IAB statement on transport protocol evolution. It's not clear what this
>> do beyond blessing UDP as the way forward for new transport protocols, in
>> effect acknowledging (1) that the network-transport layer boundary has been
>> four bytes from where the RFCs say it is for some time and (2) that the
>> kernel-userspace boundary isn't really useful for security in a world where
>> everything is virtualized anyway.
>> 
>> (7) General guidelines/principles for designing new encapsulations. We
>> discussed at SEMI the possibility of working on guidelines for UDP as a
>> transport substrate, but this is largely covered by draft-ietf-tsvwg-rfc5405bis.
>> Erik Nordmark raised the point at the retreat that there are a bunch of new
>> encapsulations (e.g. BIER, NVO3) coming out of the routing area, and these
>> may have some common architectural principles with each other as well as
>> with with new transport encapsulations. I'd nominate Erik Nordmark to lead
>> following up on this, since he brought it up. :)
>> 
>> (8) Related to this, there appears to be some architecture and coordination
>> work to do on new stacks, or rather, pointing out well-known principles of
>> good engineering thereon, especially for IoT applications. Are there common
>> principles which can/should be applied to the design of these stacks to make
>> sure we don't have piles of gratuitously incompatible protocols?
>> 
>> (9) General guidelines for protocol transition. If the program is to define an
>> architecture for evolving the transport layer, this will need to have the right
>> incentives for deployment for new applications, as well as for transition from
>> existing transports (where this is useful -- mainly in cases where TCP or HTTP
>> have been pressed into service for less-than-appropriate applications). If
>> there are guidelines for transition to be generalized from this, this would
>> make a new document.
>> 
>> (10) An IAB statement on the deployment of ECN (along the lines of 'yes
>> please'). Probably this is a pointer to draft-tsvwg-ecn-benefits and related
>> analysis of the risk of enabling ECN by default (see http://ecn.ethz.ch/ecn-
>> pam15.pdf). We should discuss whether this is something the IAB would be
>> interested in doing before putting much effort into it.
>> 
>> 
>> We should put some thought into which of these things we think we can get
>> done during this year (rather, until Buenos Aires), and update the program's
>> description at https://www.iab.org/activities/programs/ip-stack-evolution-
>> program if it's not current anymore. Clearly (1), (2), and (4) are related to the
>> original scope and are ongoing, (5) and (6) are related as well and were
>> referred to us by the workshop (so we should get some names assigned to
>> them, hint hint :). If you've got particular interest and cycles to work on these
>> (or any of the following things), please shout.
>> 
>> Thanks, cheers,
>> 
>> Brian
>> 
>> 
>> 
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 14 May 2015 06:48:39 +0000

> Sent: Wednesday, May 13, 2015 2:52 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]
> Subject: Re: [Stackevo] Stack Evolution at the IAB/IESG Retreat: Status and
> Next Steps
> 
> hi Tiru,
> 
> > I have worked on STUN, TURN and ICE protocols; lead author of TURNbis,
> turn third party authorization for STUN/TURN drafts and contributed to
> various other WG documents related to these protocols. We had also
> submitted the following document https://www.iab.org/wp-content/IAB-
> uploads/2014/12/semi2015_reddy.pdf for the SEMI workshop.
> 
> The thinking about "good middleboxes" and "bad middleboxes" and the line
> between them is well thought out in the case of NAT, so this is a very good
> starting place. But I think the document needs eventually to cover the entire
> spectrum of these things (and I'd be happy if we could get IAB consensus that
> certain kinds of middleboxes -- transparent traffic content modifiers that
> MITM crypto, for example --  are simply damaging to the architecture, full
> stop).

Agreed, we should discuss transparent verses explicit proxies in the draft.

> Let us know when you've got a starting point for comment and review.

Sure, will inform when first cut of the doc ready.

Cheers,
-Tiru

> >> Subject: [Stackevo] Stack Evolution at the IAB/IESG Retreat: Status
> >> and Next Steps
> >>
> >> Greetings, all,
> >>
> >> At the IAB/IESG retreat last week in London, we discussed the current
> >> state and structure of the IP Stack Evolution Program, work that came
> >> out of the SEMI workshop which does not yet have an owner, as well as
> >> related new work to take on. Along with the recent discussion on
> >> scope and organization, it might be time to update our program
> description, as well.
> >>
> >> (1) Architectural discussion on SPUD: identifying the applications
> >> that would benefit from selective explicit middlebox communication in
> >> a transport encapsulation, determining the limitations on what can be
> >> productively exposed, defining a set of protocol requirements based
> >> on these applications and limitations. IMO only once we have a fairly
> >> solid set of requirements and agreement on an architecture within the
> >> program does it make sense to refer anything to a WG; in the
> >> meantime, the [email-masked] list will remain open for general
> >> discussion, and architecture work will happen within the program. On
> >> which, please have a look at draft-trammell-stackevo-newtea-
> >> 01 and poke holes in it.
> >>
> >> ongoing, and we hope to have a meeting in Prague. Once this RG is
> >> created, this discussion will move there. Mirja Kühlewind holds the
> >> pen on the proposed charter and first proto-RG meeting agenda at the
> moment.
> >>
> >> (3) Completion of (currently expired)
> >> draft-iab-filtering-considerations, which went through community
> >> review in January 2014, inherited from the IP Evolution Program. Dave
> >> Thaler holds the pen on this; if you'd like to help, please coordinate with
> him.
> >>
> >> Please have a look at draft-trammell-semi-report-00 and point out
> >> what's missing.
> >>
> >> (5) A document providing guidelines on middlebox design and
> >> deployment; from section 6.3 of draft-trammell-semi-report: "The
> >> workshop identified the potential to update [RFC3234] to provide
> >> guidelines on middlebox design, implementation, and deployment in
> >> order to reduce inadvertent or accidental impact on stack
> >> ossification in existing and new middlebox designs.  This document
> >> will be produced by the IAB IP Stack Evolution program, drawing in
> >> part on the work of the BEHAVE working group, and on experience with
> >> STUN, TURN, and ICE, all of which focus more specifically on network
> address translation."
> >>
> >> (6) An IAB statement on transport protocol evolution. It's not clear
> >> what this do beyond blessing UDP as the way forward for new transport
> >> protocols, in effect acknowledging (1) that the network-transport
> >> layer boundary has been four bytes from where the RFCs say it is for
> >> some time and (2) that the kernel-userspace boundary isn't really
> >> useful for security in a world where everything is virtualized anyway.
> >>
> >> (7) General guidelines/principles for designing new encapsulations.
> >> We discussed at SEMI the possibility of working on guidelines for UDP
> >> as a transport substrate, but this is largely covered by draft-ietf-tsvwg-
> rfc5405bis.
> >> Erik Nordmark raised the point at the retreat that there are a bunch
> >> of new encapsulations (e.g. BIER, NVO3) coming out of the routing
> >> area, and these may have some common architectural principles with
> >> each other as well as with with new transport encapsulations. I'd
> >> nominate Erik Nordmark to lead following up on this, since he brought
> >> it up. :)
> >>
> >> (8) Related to this, there appears to be some architecture and
> >> coordination work to do on new stacks, or rather, pointing out
> >> well-known principles of good engineering thereon, especially for IoT
> >> applications. Are there common principles which can/should be applied
> >> to the design of these stacks to make sure we don't have piles of
> gratuitously incompatible protocols?
> >>
> >> (9) General guidelines for protocol transition. If the program is to
> >> define an architecture for evolving the transport layer, this will
> >> need to have the right incentives for deployment for new
> >> applications, as well as for transition from existing transports
> >> (where this is useful -- mainly in cases where TCP or HTTP have been
> >> pressed into service for less-than-appropriate applications). If
> >> (10) An IAB statement on the deployment of ECN (along the lines of
> >> 'yes please'). Probably this is a pointer to draft-tsvwg-ecn-benefits
> >> and related analysis of the risk of enabling ECN by default (see
> >> http://ecn.ethz.ch/ecn- pam15.pdf). We should discuss whether this is
> >> something the IAB would be interested in doing before putting much effort
> into it.
> >>
> >>
> >> We should put some thought into which of these things we think we can
> >> get done during this year (rather, until Buenos Aires), and update
> >> the program's description at
> >> https://www.iab.org/activities/programs/ip-stack-evolution-
> >> program if it's not current anymore. Clearly (1), (2), and (4) are
> >> related to the original scope and are ongoing, (5) and (6) are
> >> related as well and were referred to us by the workshop (so we should
> >> get some names assigned to them, hint hint :). If you've got
> >> particular interest and cycles to work on these (or any of the following
> things), please shout.
> >>
> >> Thanks, cheers,
> >>
> >> Brian
> >>
> >>
> >>
> >