Subject: Re: [Stackevo] StackEvo meeting in Seoul

From: Brian Trammell <[email-masked]>
Date: Wed, 16 Nov 2016 09:36:53 +0900

hi Suresh,

We'll be meeting in Park Studio (the IAB office) on the 5th floor.

Cheers,

Brian

> On 16 Nov 2016, at 09:35, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Brian,
>   Where is the location?
> 
> Cheers
> Suresh
> 
> On 10/25/2016 08:28 PM, Brian Trammell 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)
>> 
>> (2) Transport and network layer work to reduce DDoS susceptibility (in keeping with the emerging plenary theme)
>> 
>> (3) Handles and the ITU-T (on the IoT security theme as well): anything to do 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)
>> 
>> Other agenda points?
>> 
>> Thanks, cheers,
>> 
>> Brian (lazy program lead hat)
>> 
>>> On 25 Oct 2016, at 08:57, Brian Trammell <[email-masked]> wrote:
>>> 
>>> Hi Spencer,
>>> 
>>> I've blocked out Wednesday lunch. Agenda is in queue for this week.
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 25 Oct 2016, at 01:10, Spencer Dawkins at IETF <[email-masked]> wrote:
>>>> 
>>>> If StackEvo is meeting in Seoul, I'd like to block out calendar time for it soon :-) ...
>>>> 
>>>> Spencer
>>>> _______________________________________________
>>>> Stackevo mailing list
>>>> [email-masked]
>>>> https://www.iab.org/mailman/listinfo/stackevo
>> 
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 16 Nov 2016 00:40:23 +0000

Awesome dude. Will see you there.

Cheers
Suresh

-----Original Message-----
From: Brian Trammell [[email-masked]]
Received: Wednesday, 16 Nov 2016, 9:37AM
To: Suresh Krishnan [[email-masked]]
CC: Stackevo [[email-masked]]
Subject: Re: [Stackevo] StackEvo meeting in Seoul

hi Suresh,

Cheers,

Brian

---

From: Aaron Falk <[email-masked]>
Date: Wed, 16 Nov 2016 00:42:08 +0000

Will they be food or should we bring our own?
On Wed, Nov 16, 2016 at 09:40 Suresh Krishnan <[email-masked]>
wrote:

> >> I've booked a lunch meeting for the Stack Evolution program on
> Wednesday 16 November.  I'd propose the following points of
> >>
> >> (4) Action item review re: NSG IGP and heading off bad 5G ideas w/ 3GPP
> (I don't think anything ended up happening here)
> >>
> >> Other agenda points?
> >>
> >> Thanks, cheers,
> >>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 16 Nov 2016 09:43:25 +0900

Yep, there will be food.

> On 16 Nov 2016, at 09:42, Aaron Falk <[email-masked]> wrote:
> 
> On Wed, Nov 16, 2016 at 09:40 Suresh Krishnan <[email-masked]> wrote:

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 16 Nov 2016 11:40:37 +0900

Regrets for this meeting due to a conflict.

    Erik

---

From: Natasha Rooney <[email-masked]>
Date: Wed, 16 Nov 2016 02:42:26 +0000

Shotgun on Erik’s share of the food.

Natasha

Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

On 16 Nov 2016, at 11:40, Erik Nordmark <[email-masked]<mailto:[email-masked]>> wrote:

   Erik

hi Suresh,

Cheers,

Brian

On 16 Nov 2016, at 09:35, Suresh Krishnan <[email-masked]><mailto:[email-masked]> wrote:

Hi Brian,
  Where is the location?

Cheers
Suresh

Greetings, all,

Other agenda points?

Thanks, cheers,

On 25 Oct 2016, at 08:57, Brian Trammell <[email-masked]><mailto:[email-masked]> wrote:

Hi Spencer,

Sent from my iPhone

On 25 Oct 2016, at 01:10, Spencer Dawkins at IETF <[email-masked]><mailto:[email-masked]> wrote:

Spencer
_______________________________________________
Stackevo mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/stackevo

_______________________________________________
Stackevo mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/stackevo

_______________________________________________
Stackevo mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/stackevo

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 21 Nov 2016 10:25:22 +0100

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,
> 

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.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Nov 2016 14:33:14 -0800

Howdy,

I don't think the he-said/she-said bits would be useful minutes under the
best of circumstances, and these would need a lot of filtering if we were
to publish them that way (Suresh probably didn't mean to say that 3GPP
didn't care about NSG on the record, for example).

I think for minutes, we should capture the three action items, note that we
talked about network affordances for DDOS and the risks thereof, report the
conclusion that the program did not believe it had any actions related to
the Digital object architecture, and also indicate that we are looking at
the 5g work and are willing to work with 3GPP as it develops.

If you need help drafting, I can probably do it when I get back from
Thanksgiving, but my main point is really "less is more" on this.

regards,

Ted

On Mon, Nov 21, 2016 at 1:25 AM, 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
>
>
> > I've booked a lunch meeting for the Stack Evolution program on Wednesday
> 16 November.  I'd propose the following points of
> >
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 28 Nov 2016 22:59:29 -0600

We didn't talk about this in Seoul, but I did want to let the program know
that Brian capably represented
https://datatracker.ietf.org/doc/draft-iab-protocol-transitions/ in TSVAREA
immediately following the program meeting, and we had a really good
discussion about transition considerations for transport protocols after
his presentation.

Brian and I had a (pleasant) exchange during that discussion about our need
to understand the impact of operational practices on protocol transitions
(my poster child being IPv6 folk showing up with a shiny new protocol that
didn't require NATs, except that by the time people started looking at IPv6
seriously, "do you have NATs? suggested answer = yes" had made its way into
audit guidelines, and people were much more eager to point to a NAT and
pass the audit, than to challenge the guidelines). We both thought that was
worth thinking about.

Do folks agree this is something to pursue?

Thanks,

Spencer

---

From: Brian Trammell <[email-masked]>
Date: Tue, 29 Nov 2016 12:55:25 +0100

> On 21 Nov 2016, at 23:33, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> I don't think the he-said/she-said bits would be useful minutes under the best of circumstances, and these would need a lot of filtering if we were to publish them that way (Suresh probably didn't mean to say that 3GPP didn't care about NSG on the record, for example).
> 
> I think for minutes, we should capture the three action items, note that we talked about network affordances for DDOS and the risks thereof, report the conclusion that the program did not believe it had any actions related to the Digital object architecture, and also indicate that we are looking at the 5g work and are willing to work with 3GPP as it develops.
> 
> If you need help drafting, I can probably do it when I get back from Thanksgiving, but my main point is really "less is more" on this.

Agreed. I'll try to get a first pass out on this this week.

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Wed, 30 Nov 2016 11:55:13 +0100

> On 29 Nov 2016, at 05:59, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> We didn't talk about this in Seoul, but I did want to let the program know that Brian capably represented https://datatracker.ietf.org/doc/draft-iab-protocol-transitions/ in TSVAREA immediately following the program meeting, and we had a really good discussion about transition considerations for transport protocols after his presentation.
> 
> Brian and I had a (pleasant) exchange during that discussion about our need to understand the impact of operational practices on protocol transitions (my poster child being IPv6 folk showing up with a shiny new protocol that didn't require NATs, except that by the time people started looking at IPv6 seriously, "do you have NATs? suggested answer = yes" had made its way into audit guidelines, and people were much more eager to point to a NAT and pass the audit, than to challenge the guidelines). We both thought that was worth thinking about.
> 

I'm (probably unsurprisingly) in the "yes" column here.

Much of the recent discussion I can recall about documentation for operational practices for IETF protocols within the IETF has been under the heading "what to do with useless but harmless documents?". I think, in light of transition planning when extending or replacing a protocol, these operational practices are part of the "installed base" to be transitioned away from, which makes them somewhat less "useless".

These don't always impose additional constraints on a transition plan; for example, if a specified protocol feature has never been implemented or deployed, then transition planning doesn't need to put too much effort in a way to transition away from it.

I'll note that MAPRG is one part of an attempt to get more data about protocols "as deployed". Some of what we've seen measured there reflects implementation choices (and faults), while some reflects operational choices (e.g., I'm pretty sure access-network-linked UDP blocking is intentional). Actually talking to operations people about their practices (or looking at the outputs of things like BCOP, if that's still a going concern) is another way to get this information...

Cheers,

Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 30 Nov 2016 21:31:14 -0600

Hi, Brian,

On Wed, Nov 30, 2016 at 4:55 AM, Brian Trammell <[email-masked]> wrote:

> > We didn't talk about this in Seoul, but I did want to let the program
> know that Brian capably represented https://datatracker.ietf.org/
> doc/draft-iab-protocol-transitions/ in TSVAREA immediately following the
> program meeting, and we had a really good discussion about transition
> considerations for transport protocols after his presentation.
> >
> > Brian and I had a (pleasant) exchange during that discussion about our
> need to understand the impact of operational practices on protocol
> transitions (my poster child being IPv6 folk showing up with a shiny new
> protocol that didn't require NATs, except that by the time people started
> looking at IPv6 seriously, "do you have NATs? suggested answer = yes" had
> made its way into audit guidelines, and people were much more eager to
> point to a NAT and pass the audit, than to challenge the guidelines). We
> both thought that was worth thinking about.
> >
> Much of the recent discussion I can recall about documentation for
> operational practices for IETF protocols within the IETF has been under the
> heading "what to do with useless but harmless documents?". I think, in
> light of transition planning when extending or replacing a protocol, these
> operational practices are part of the "installed base" to be transitioned
> away from, which makes them somewhat less "useless".
>
> These don't always impose additional constraints on a transition plan; for
> example, if a specified protocol feature has never been implemented or
> deployed, then transition planning doesn't need to put too much effort in a
> way to transition away from it.
>
> I'll note that MAPRG is one part of an attempt to get more data about
> protocols "as deployed". Some of what we've seen measured there reflects
> implementation choices (and faults), while some reflects operational
> choices (e.g., I'm pretty sure access-network-linked UDP blocking is
> intentional). Actually talking to operations people about their practices
> (or looking at the outputs of things like BCOP, if that's still a going
> concern) is another way to get this information...

That's an excellent point, and thank you for pointing out that there are
two (non-exclusive) ways to attack this problem.

Spencer