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

[Brian Trammell <[e-mail]>]

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)

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:[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
>> 
>> 
>> 
>