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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Stackevo [mailto:[e-mail]] On Behalf Of Brian
> Trammell
> Sent: Wednesday, May 13, 2015 2:52 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [e-mail]
> Subject: Re: [Stackevo] Stack Evolution at the IAB/IESG Retreat: Status and
> Next Steps
> 
> hi Tiru,
> 
> > On 11 May 2015, at 14:54, Tirumaleswar Reddy (tireddy)
> <[e-mail]> 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).

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

> 
> Thanks again, cheers,
> 
> Brian
> 
> > Thanks and Regards,
> > -Tiru
> >
> >> -----Original Message-----
> >> From: Stackevo [mailto:[e-mail]] On Behalf Of Brian
> >> Trammell
> >> Sent: Monday, May 11, 2015 5:53 PM
> >> To: [e-mail]
> >> 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.
> >>
> >> 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 [e-mail] 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
> >>
> >>
> >>
> >