Subject: Re: [Stackevo] StackEvo meeting in Seoul

From: Brian Trammell <[email-masked]>
Date: Thu, 1 Dec 2016 15:26:38 +0100

Hi, all,

And now as draft minutes, below.

Cheers,

Brian

The IAB Stack Evolution Program met on Wednesday 16 November at the IETF 97 meeting in Seoul.

Ted Hardie will continue editing draft-hardie-path-signals within the scope of the program as a standalone draft (from the PLUS effort) for consideration as an IAB stream document.

The program discussed whether there was any work for the program to reduce of the attack surface the Internet architecture presents to distributed denial of service attacks. Ted Hardie posited that there appear to be two potential questions with respect to stack evolution: (1) Whatever happened to source quench? We lost it, it was abusable. Now we wish we had it. Now we have to take the traffic all the way to the endpoint. Can we rebuild this idea without the same level of abuse?  (2) The architecture is predicated on smart endpoints/dumb network, but with IoT, the endpoints are getting dumber. Can we design a system that required a proof of "I am this tall (capable)" before getting on the Internet, shorter (less-capable) devices are required to go through a gateway. Can we do this in a DHCP/network attachment world that isn't a dystopian nightmare? Dave Thaler pointed out that source quench is not only spoofable, but there is no guarantee it will be honored. A different question is whether "less-tall" devices in this analogy should have IP in them at all. This is a hard problem; discussion will continue within the program.

The program discussed ways to get better interaction between the mobile access network and IETF worlds. The program is open to finding people to speak about specific work at e.g. GSMA meetings in order to get feedback on IETF protocols outside an IETF meeting.

> On 21 Nov 2016, at 10:25, Brian Trammell <[email-masked]> wrote:
> 
> Greetings, all,
> 
> Attached, my transcript notes from the Stack Evolution meeting. Please send additions and corrections; I'd like to turn these into minutes to post on the program page.
> 
> Cheers,
> 
> Brian
> 
> 
>> On 25 Oct 2016, at 20:27, Brian Trammell <[email-masked]> wrote:
>> 
>> Greetings, all,
>> 
>> I've booked a lunch meeting for the Stack Evolution program on Wednesday 16 November.  I'd propose the following points of
>> 
>> (1) Further program involvement in the PLUS effort? (and proponents' plans)
> 
> Writing out the pro/con arguments for PLUS (in terms of attack surface and benefits) would be a useful
> 
> Brian will draft an on-the-wire protocol specification, discussion to continue on the [email-masked] list, once it exists.
> 
> draft-hardie-path-signals will be continued as a program document for consideration for adoption on the IAB stream.
> 
>> (2) Transport and network layer work to reduce DDoS susceptibility (in keeping with the emerging plenary theme)
> 
> Aaron: as attacks get larger and more vulnerable targets, you're going to see an emerging layer 9 control loop. Liability (limited with uncertified devices) to provide an incentive to pay attention to device hygiene. Kind of a ramble, don't know if there's a stack evolution angle here. Educating and informing sources of this regulation to keep them from destroying the
> 
> Ted: Two stack evolution questions here. #1: Whatever happened to source quench? We lost it, it was abusable. Now we wish we had it. Now we have to take the traffic all the way to the endpoint. Feeding back toward the network is lost. Can we rebuild this idea without the same level of abuse? Spoofable source quench is a huge attack vector. Can't throw crypto at it, key management daunting. #2: The endpoints are getting dumber. Can we design a system that required a proof of "I am this tall (capable)" before getting on the Internet, dumber devices are required to go through a gateway. Can we do this in a DHCP/network attachment world that isn't a dystopian nightmare?
> 
> Suresh: How do you implement this? BGP is coarse.
> 
> Lee: We have BGP flowspec now, we have certain ports. Layer 4. We can't filter at layer 7. What I think you said, Ted, is catenets good.
> 
> Ted: Network remains unified, you just have a partition at the edge.
> 
> Lee: Not a translator, policy enforcement device. Home gateways would be a good place to do this, but we don't trust them.
> 
> Dave: On source quench, it's probably a dead end. Not just that they're spoofable, they might also be dishonored. Once you have a botnet that is owned, they might not be playing nice. On being this tall: NEA, separated network for devices "not this tall". At ISOC lunch yesterday, this was exactly the question I brought up to prep panel speakers (note this problem is not IoT specific): if you have devices constrained in various ways, maybe not developed by networking experts. They're refrigerator companies. Classic question on the smart object arch plenary: "Should I put IP into a device or not?" No IP, not reachable, means not attackable. LWIG tried to make the limit of how small you can put IP into lower, this is consistent with IETF
> 
> Michael: What about authenticated traffic shapers? Source quench doesn't come from the end-host, but from in-network monitoring.
> 
> Ted: Typically, failed "not tall enough" in 802.1x you still attach but you are limited in what you can do (rump network; link local only, no Internet routability). Hook this up with something like MUD, we assume you don't need to talk to Internet. Problem with shaping problem, no place in an architecture that's "between" due to CDN architecture.
> 
>> (3) Handles and the ITU-T (on the IoT security theme as well): anything to do here?
> 
> Nothing to do for the program here.
> 
>> (4) Action item review re: NSG IGP and heading off bad 5G ideas w/ 3GPP (I don't think anything ended up happening here)
> 
> Brief update: Natasha, Suresh, Gonzalo, and Bjorn. Outcome: nobody has any idea what 5G is going to be yet. Need to go and participate in 3GPP to influence that. 3GPP would appreciate more love from the IETF. Natasha will work to help lower the barriers.
> 
> Natasha: Make a list of IETF things that might have an interaction with 3GPP. 5g-in-ip, etc.
> 
> Suresh: Would it be useful to have an IESG/IAB person to come to an GSMA meeting to talk about what the IETF does? So GSMA can share concerns without fear of backlash.
> 
> Natasha: Ian Swett came to talk about QUIC, that helped. Brian has volunteered.
> 
> Aaron: This is a community that doesn't speak our language, wireless. has always been so. Very different ways of thinking about architecture and tradeoffs. If 5G doesn't have an architecture, that's better than it looked before. Try to understand what they want to achieve, so they can avoid sins of commission. Small group  of people try to get in sync, common understanding of each other. Kevin Smith seems like he'd be a great person to start with. Pair him up with someone here. MaRNEW had a problem because the room was too big. We need to get to the point where people can send each other emails.
> 
> Mirja: We started with NSG documents. You talked with 3GPP, and they said they don't care.
> 
> Suresh: No, they don't care.
> 
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo