Subject: [Stackevo] Stackevo program telechat, 11 September 2017, 20:00 UTC

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 1 Sep 2017 14:51:41 +0200

Greetings, all,

We'll have a telechat a week from Monday, largely to follow up on and continue our discussions in Prague. Currently on the agenda, I have a few things following from that meeting:

(1) MaRNEW workshop report review: Spencer and Natasha to release a community-review ready version of this report.

(2) A statement based on draft-hardie-path-signals: should the core architectural insight here lead to an IAB statement, referring the messy work of enumerating these signals to a more appropriate venue like PAN(P)RG?

(3) Next steps on draft-trammell-whats-an-endpoint: based on discussion to date, it seems that this question might be muddled enough that no insights will fall out of it after all, but maybe the questions that it leads to are useful.

(4) Next steps on the broader encryption question: should we consider a workshop focusing on the impact of encryption network performance measurement and management in general?

Are there any other points we'd like to add to the agenda?

Thanks, cheers,

Brian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Sep 2017 10:01:38 +1000

This already looks like a full agenda, and I have a hard cutoff at the
hour, but I have another to add to the pile, time permitting.

Recent attempts to deploy new protocols has made the whole
ossification question come back up again.  I'd like to spend a little
time on this question and whether there is anything we can do about
it.  Obviously, deploying TFO and TLS 1.3 are just going to be
annoying and hard, but I'd be interested if anyone has insights into
what we might do differently in future.

I recently noticed that "greasing" (aka. "use it or lose it") isn't
really written down as a thing-that-you-might-do.  Maybe there's
something we can say about that.  I've a terrible draft that might
have some salvageable content.

On Fri, Sep 1, 2017 at 10:51 PM, Brian Trammell (IETF) <[email-masked]> wrote:
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 3 Sep 2017 19:40:34 -0500

Martin,

> hour, but I have another to add to the pile, time permitting.

Well, we COULD talk again before we land in Singapore ;-)

> what we might do differently in future.

I like the idea of collecting experience on deploying new protocols. I
think at least some of the impediments for those two aren't surprising(*),
but I don't know all of them, and identifying other protocols that we
thought should be deployable, seems worthwhile, too.

(*) DCCP didn't get significant use because it was a new transport protocol
with the same impediments that every other new transport protocol has.
Amazing, no? SCTP had a closely-tied application used by people who had
deep pockets at the time, and was deployed in closed networks, and got at
least some significant usage before there was a binding over UDP, but DCCP
was just ... DCCP.

> have some salvageable content.

If "greasing" does end up as a thing-that-QUIC-might-do, I hope "greasing"
gets written down before IESG Evaluation. Is StackEvo the right place for
that? Honest question.

Thanks,

Spencer

> > We'll have a telechat a week from Monday, largely to follow up on and
> continue our discussions in Prague. Currently on the agenda, I have a few
> things following from that meeting:
> >
> > (1) MaRNEW workshop report review: Spencer and Natasha to release a
> community-review ready version of this report.
> >
> > (2) A statement based on draft-hardie-path-signals: should the core
> architectural insight here lead to an IAB statement, referring the messy
> work of enumerating these signals to a more appropriate venue like PAN(P)RG?
> >
> > (3) Next steps on draft-trammell-whats-an-endpoint: based on discussion
> to date, it seems that this question might be muddled enough that no
> insights will fall out of it after all, but maybe the questions that it
> leads to are useful.
> >
> > (4) Next steps on the broader encryption question: should we consider a
> workshop focusing on the impact of encryption network performance
> measurement and management in general?
> >

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Sep 2017 11:24:58 +1000

> gets written down before IESG Evaluation. Is StackEvo the right place for

I think that it's the right place to start, or else I wouldn't have
asked for time :)

It might be that this is a topic that gains IETF consensus, but it
seems that it's the sort of thing that IAB stream documents often do:
provide advice on how to make a protocol design effective.  I honestly
don't mind where it ends up, but I do think that having a reference
with some properly moderated advice on what greasing can (and can't)
do is worth having.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 3 Sep 2017 20:54:04 -0500

Hi, Martin,

> with some properly moderated advice on what greasing can (and can't)

On this, we agree.

Spencer

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 4 Sep 2017 06:03:01 +0200

hi Martin,

Given that the the big initial question we asked with the initial charter for stackevo was "how do we evolve the stack, specifically at layer 4?", and that "maybe you should grease stuff", together with "encrypt everything the path doesn't need to see", is one of the few parts of that answer we know enough to agree on, that this definitely fits within the program

I'd actually put this on the agenda ahead of whats-an-endpoint, since I think it's more likely to lead to something useful in the short term.

A question: do we want this do be "greasing is good" (which I think would be a fine thing to say), or would we like to expand the scope slightly to "current observations on / guidelines for deossification" (which would perhaps bring in the not-detail-work from path-signals, specifically the "stop leaking stuff you don't mean to" bit)?

Cheers,

Brian

> On 4 Sep 2017, at 03:24, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Sep 2017 14:15:29 +1000

> A question: do we want this do be "greasing is good" (which I think would be a fine thing to say), or would we like to expand the scope slightly to "current observations on / guidelines for deossif…

I'm leaning towards having "use it or lose it" statement being a clear
standalone statement.  It's certainly part of the same clusterf^Wball
of string, but I think that we could make a decent pass without
drawing in all related context.

A major motivation for greasing is not the paths themselves, but other
endpoints.  For instance, the major Erlang implementation of TLS had
problems with new additions to certain extensions. So now you can't
deploy the additions at all without accepting the risk of exploding
those implementations.  And Langley's maxim definitely applies here.

The other reason I say that is that path signals isn't always
applicable in the way that is natural to conceive of the idea.  In
SIP, you (might) encrypt, but the box that you encrypt towards is
still an intermediary and that's an explicit part of the architecture.
HTTP is approximately the same[1].  You could say that there are paths
and then there are *paths*, but that starts to stretch my ability to
cover the idea properly.

[1] What's interesting is that HTTP header fields generally survive
far better than in SIP, the reasons for which are worth spending a
little time on.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 4 Sep 2017 06:24:19 +0200

> On 4 Sep 2017, at 06:15, Martin Thomson <[email-masked]> wrote:
> 

Ack. Sounds good to me.

Are we thinking of the program proposing an IAB statement, or publishing something short and sweet on the IAB stream? I think I'd lean toward the latter, simply for ease of reference in future RFCs that say that they grease [RFCxxxx] certain header fields.

> and then there are *paths*, but that starts to stretch my ability to

Point. (Some of this ball of string I'd like to try to move over to PANRG, but... i'm not sure which bits of it. ball of string and all.)

> far better than in SIP, the reasons for which are worth spending a

hm. I'm most decidedly not a SIP person: say more?

Cheers,

Brian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Sep 2017 14:27:49 +1000

> Are we thinking of the program proposing an IAB statement, or publishing something short and sweet on the IAB stream? I think I'd lean toward the latter, simply for ease of reference in future RFCs…

RFC, for the same reasons.  ++work for ++value.

> hm. I'm most decidedly not a SIP person: say more?

SIP B2BUAs are potentially more common than proxies.  One of the
things that distinguishes a B2BUA over a proxy is that it terminates
and reoriginates signaling.  That leads to a default-deny policy.  If
the B2BUA doesn't understand (and respect) a header field called
This-Call-Should-Be-Free, then it won't survive this transformation.

More details in RFC 7092.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 3 Sep 2017 23:54:53 -0500

Hi, Martin,

> This-Call-Should-Be-Free, then it won't survive this transformation.

Also my impression (I stepped down as Technical Director for the SIP Forum
earlier this year), with the addition that

   - at least some of the (and they weren't all telecom-ish) SIP folk
   thought their B2BUA knew better than any endpoint possibly could know what
   it actually meant,
   - a significant part of the SIP B2BUA business was gatewaying into PTSN
   networks that weren't doing SIP anyway, which could give you kind of a
   cavalier attitude about dorking with header fields with the networks that
   were doing SIP, and
   - a significant part of the Acme Packet B2BUA business, at least, was
   doing protocol repair between endpoint implementations, which turns out to
   be largely adding, changing, and deleting header fields,

so, yeah, often the next SIP outgoing leg doesn't look much like the last
incoming leg at all :)

Spencer

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 04 Sep 2017 09:54:22 -0400

> have some salvageable content.

For those of us who may have been out of the room at a critical moment, 
what’s greasing?

—aaron

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Sep 2017 08:51:35 +1000

> For those of us who may have been out of the room at a critical moment,

https://datatracker.ietf.org/doc/draft-ietf-tls-grease/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 4 Sep 2017 20:58:43 -0500

Hi, Martin,

On Sep 4, 2017 17:51, "Martin Thomson" <[email-masked]> wrote:

On behalf of the non-TLS QUIC participants, thanks!

Spencer

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 5 Sep 2017 19:10:28 +0200

Sorry for top-posting but I believe my thoughts might fit best as reply to 
this message.

So I'm actually not very familiar with the details of greasing in TLS and I'm 
sure that it addresses (successfully) the problem described below, however, I 
always feel sorry that we actually have to do that because it feels a bit 
like adding quite a lot of complexity without getting any additional 
functionality. I know the big real win is that you get some implementation 
verification that may also help to address future ossification/extension 
problems. However, I'm still thinking, isn't there a better way than greasing...?

So maybe the statement should be that if you have an extensible protocol you 
need to take additional measures to make sure it's implemented correctly (in 
the endpoint and the path) such that this extensibility is enabled even if 
there are no extensions yet, where greasing is one mechanism to do that (no 
sure if there are others though). So I think what I want to say is that the 
statement should be more on checking implementation correctness than the 
mechanism for it, which at least to me seems right for an IAB statement.

My 2c,
Mirja

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Sep 2017 10:52:16 +1000

On Wed, Sep 6, 2017 at 3:10 AM, Mirja Kühlewind
<[email-masked]> wrote:
> So I'm actually not very familiar with the details of greasing in TLS and
> I'm sure that it addresses (successfully) the problem described below,
> however, I always feel sorry that we actually have to do that because it
> feels a bit like adding quite a lot of complexity without getting any
> additional functionality. I know the big real win is that you get some
> implementation verification that may also help to address future
> ossification/extension problems. However, I'm still thinking, isn't there a
> better way than greasing...?

I don't actually think that greasing is the best solution.  In fact,
it's probably at the point where its utility could be close to zero
where it was originally implemented in TLS extensions.  We don't
implement it and don't really feel its absence.  It's always a
compromise like that though.

The main reason that certain changes in TLS don't work is because
implementations don't see new things often enough.  The real fix here
is to make your extension points critical to the functioning of the
protocol and ensure that they are used *for real use cases* regularly.
I think Diameter had a better approach here with TLVs.

TLS 1.3 is just now making extensions a core part of the protocol
logic, so we should see less problems with TLS extensions once 1.3
becomes a little more mainstream.  That doesn't mean that other
extension points will remain equally flexible.

Ultimately, the aspirational goal of greasing is to make doing the
right thing cheaper than doing the wrong thing.  It's relatively easy
to write bad code that defeats greasing, after all:

version = readVersion()
if (version & 0xf0f0 == 0xa0a0) {
  version = readVersion() // must be greasing
}
if (version != the_one_version_I_like) {
  explode();
}
succeed();

The hope is that implementations will find the correct code easier to
write in the face of this:

do {
  version = readVersion();
  if (version == the_one_version_I_like) {
     succeed();
  }
} while ();
fail();

There's also another aspect of this that I think needs more
consideration: making new versions of protocols deliberately
different.  In QUIC, we're talking about using a fixed encryption key
for all cleartext packets.  This key could change in new versions,
making it impossible for a middlebox to read the packet.  I'm not sure
if this creates the sort of secondary effects we're looking for.
After all, default-deny policies are so easy to deploy.  But it could
work if the keys change often enough.

> mechanism for it, which at least to me seems right for an IAB statement.

There's another aspect to that.  In HTTP/2 we were very strong on
failing hard in the face of implementation errors.  That caused early
pain, but it meant that certain types of errors were stamped out very
rapidly, even the nasty, tricky ones.  It cost us a lot in the first
year or so, but HTTP/2 did a lot for improving the deployment of
forward-secure TLS ciphers, for instance.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 6 Sep 2017 10:24:44 +0200

> On 6 Sep 2017, at 02:52, Martin Thomson <[email-masked]> wrote:
> 

So... greasing, in this sense, is a bit of protocol design scaffolding meant to fill in for actual (future) demand for initially-optional/unused protocol extensibility features. This seems to me like the principle the draft should start from.

>  if (version == the_one_version_I_like) {

Personally, I think the principle is most useful to avoid this case:

// Consume the version number; safe to assume it is always one
// and comparisons risk a branch, which would slow us down.
readVersion(); // #appropriate "unusued return" warning disable pragma here

But I'm a terrible pessimist about software quality.

> work if the keys change often enough.

So this is a really interesting thought experiment space, because it gets into economics: in most of the decisions we're making in QUIC, which is designed to have relatively flexible version negotiation as well as a minimal-penalty fallback, we've got to be clever enough to actually make the protocol work on the networks we know about, but not so clever that any of the many actors we're giving the killswitch to decide it's not worth the effort.

The thing I like about greasing-as-scaffolding is that it basically provides selective pressure to improve the quality of implementations, which is a positive-sum game all around.

Cheers,

Brian

---

From: Lee Howard <[email-masked]>
Date: Wed, 06 Sep 2017 15:23:59 -0400

On 9/4/17, 12:15 AM, "Stackevo on behalf of Martin Thomson"
<[email-masked] on behalf of [email-masked]> wrote:

>> A question: do we want this do be "greasing is good" (which I think
>>would be a fine thing to say), or would we like to expand the scope
>>slightly to "current observations on / guidelines for deossification"
>>(which would perhaps bring in the not-detail-work from path-signals,
>>specifically the "stop leaking stuff you don't mean to" bit)?
>

Use what or lose what?

>A major motivation for greasing is not the paths themselves, but other

What does “greasing” mean?
Oh, you pointed later in the thread:
https://www.ietf.org/archive/id/draft-ietf-tls-grease-00.txt
Advertising random values so certain buggy systems will fail.

>those implementations.  And Langley's maxim definitely applies here.

What’s Langley’s maxim?

>far better than in SIP, the reasons for which are worth spending a

We just published an RFC on how to do protocol transitions, RFC8170
"Planning for Protocol Adoption and Subsequent Transitions.” Sounds like
this is a specific application of Section 2 Extensibility.

Lee

---

From: Lee Howard <[email-masked]>
Date: Wed, 06 Sep 2017 15:34:13 -0400

>protocol and ensure that they are used *for real use cases* regularly.

Don’t we have a philosophical conflict here with Postel’s Robustness
Principle (“be liberal in what you accept…”)?

>extension points will remain equally flexible.

Generalizable principles are good. You mean extension points for protocols
in general, and not just TLS?

>different.  

Doesn’t that raise the bar for implementation?

>forward-secure TLS ciphers, for instance.

As a principle, I could support, “Do what you can to make sure your
implementation is correct,” (not a bold statement) but I think you mean
“Do what you can to make sure the other endpoint’s [!] implementation is
correct."

Lee

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Sep 2017 07:28:16 +1000

Merging streams.

>>I'm leaning towards having "use it or lose it" statement being a clear

The extension point.

> Advertising random values so certain buggy systems will fail.

Right.  Random values that are guaranteed to be meaningless even.

> What’s Langley’s maxim?

The entity that changes last gets the blame.

> this is a specific application of Section 2 Extensibility.

A specialization of perhaps.

> Principle (“be liberal in what you accept…”)?

Oh, it goes WAY deeper than that:
https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/

> in general, and not just TLS?

I'm taking the lessons learned there and am trying to make them more
broadly applicable, yes.

> Doesn’t that raise the bar for implementation?

Maybe.  The cryptographic key thing we are considering in QUIC
doesn't: you have the AEAD already, and all you need is a constant for
the key.  It's actually less code overall in this case (we're
replacing an essentially bespoke integrity algorithm with something
that is MUST-implement elsewhere in the protocol).  The other hack we
considered required nothing more than a modulus with a fixed constant.

Generally though, this could indeed increase the costs, but the
greasing mechanisms I've seen take at most a couple of simple lines of
code to implement correctly on the sender side and close to nothing at
all on the receiver side.

> “Do what you can to make sure the other endpoint’s [!] implementation is

Yes.  Consider it a script from the school of defensive programming.

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 10 Sep 2017 20:40:50 -0700

Brian,

I don't recall seeing any meeting/webex info for tomorrow's telechat.

    Erik

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 11 Sep 2017 10:08:43 -0500

> I don't recall seeing any meeting/webex info for tomorrow's telechat.

Me, either ...

Spencer

>> So... greasing, in this sense, is a bit of protocol design scaffolding
>> meant to fill in for actual (future) demand for initially-optional/unused
>> protocol extensibility features. This seems to me like the principle the
>> draft should start from.
>>
>>
>> So this is a really interesting thought experiment space, because it gets
>> into economics: in most of the decisions we're making in QUIC, which is
>> designed to have relatively flexible version negotiation as well as a
>> minimal-penalty fallback, we've got to be clever enough to actually make
>> the protocol work on the networks we know about, but not so clever that any
>> of the many actors we're giving the killswitch to decide it's not worth the
>> effort.
>>
>> The thing I like about greasing-as-scaffolding is that it basically
>> provides selective pressure to improve the quality of implementations,
>> which is a positive-sum game all around.
>>
>> Cheers,
>>
>> Brian
>>
>>

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 11 Sep 2017 16:03:53 +0000

Me neither and it’s looking like a full day already.

From: Stackevo [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: 11 September, 2017 08:09
To: Erik Nordmark <[email-masked]>
Cc: Stackevo <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; Martin Thomson <[email-masked]>; Mirja Kühlewind <[email-masked]>
Subject: Re: [Stackevo] Stackevo program telechat, 11 September 2017, 20:00 UTC

On Sun, Sep 10, 2017 at 10:40 PM, Erik Nordmark <[email-masked]<mailto:[email-masked]>> wrote:

Brian,

Me, either ...

Spencer

   Erik

On 6 Sep 2017, at 02:52, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Sep 6, 2017 at 3:10 AM, Mirja Kühlewind
<[email-masked]<mailto:[email-masked]>> wrote:
Sorry for top-posting but I believe my thoughts might fit best as reply to
this message.

version = readVersion()

do {
  version = readVersion();

Cheers,

Brian

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

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 11 Sep 2017 18:06:09 +0200

The program *should* have a webex group; I'm still waiting for the details, and will send them to the list as soon as I have them.

Cheers,

Brian

> On 11 Sep 2017, at 18:03, Gabriel Montenegro <[email-masked]> wrote:
>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 11 Sep 2017 18:22:48 +0200

Hi, all, sorry for the delay on details.

To join the meeting (in 3h38m, at 20:00 UTC)

https://ietf.webex.com/meet/stackevo

The bashed agenda with summaries of list discussion (and off-list, if I've seen it):

(1) MaRNEW workshop report review: Spencer and Natasha to release a community-review ready version of this report.  An updated revision with Natasha's edits is at https://github.com/MaRNEW/Report, and there are a few nits from Spencer also to be applies. Natasha sends regrets (traveling), but I think we can confirm next steps with Spencer quickly.

(2) A statement based on draft-hardie-path-signals? Discussion on the list indicates that a short draft along the lines of the present revision would be most useful; we should quickly determine if this is ready for review by the larger IAB for adoption on the stream.

(3) draft-thomson-use-it-or-lose-it: a short IAB-stream document on the desirability of greasing or at least greasing-like architectural patterns. Good input from the discussion on the list so far; we should assign authors to this.

(4) Next steps on draft-trammell-whats-an-endpoint: based on discussion to date, it seems that this question might be muddled enough that no insights will fall out of it after all, but maybe the questions that it leads to are useful. No real progress on this on the list so far; IMHO (no lead hat) I think we should keep this on in the back of our minds and work the rest of this agenda first...

(5) Next steps on the broader encryption question: should we consider a workshop focusing on the impact of encryption network performance measurement and management in general? This is a minefield (cf. TLS in Prague) but perhaps putting the right alignments of interests in the room will lead to some progress or useful guidance falling out (also, in my optimistic maybe-opinion)...

Cheers,

Brian

> On 11 Sep 2017, at 18:06, Brian Trammell (IETF) <[email-masked]> wrote:
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 11 Sep 2017 10:38:11 -0700

Brian,

Could you please send an invite?
Thanks!

Cheers,
Jeff

-----Original Message-----
From: Stackevo <[email-masked]> on behalf of "Brian Trammell (IETF)" <[email-masked]>
Date: Monday, September 11, 2017 at 09:22
To: Stackevo <[email-masked]>
Subject: Re: [Stackevo] Stackevo program telechat, 11 September 2017, 20:00 UTC

    

    

    
    
    Cheers,
    
    Brian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 11 Sep 2017 12:03:16 -0700

I got pulled into something starting at 12:30 my time.  Will join as soon
as I can, which might make me on-time or late depending.

Apologies,

Ted

On Mon, Sep 11, 2017 at 9:22 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> community-review ready version of this report.  An updated revision with
> Natasha's edits is at https://github.com/MaRNEW/Report, and there are a
> few nits from Spencer also to be applies. Natasha sends regrets
> (traveling), but I think we can confirm next steps with Spencer quickly.
>
> (2) A statement based on draft-hardie-path-signals? Discussion on the list
> indicates that a short draft along the lines of the present revision would
> be most useful; we should quickly determine if this is ready for review by
> the larger IAB for adoption on the stream.
>
> (3) draft-thomson-use-it-or-lose-it: a short IAB-stream document on the
> desirability of greasing or at least greasing-like architectural patterns.
> Good input from the discussion on the list so far; we should assign authors
> to this.
>
> (4) Next steps on draft-trammell-whats-an-endpoint: based on discussion
> leads to are useful. No real progress on this on the list so far; IMHO (no
> lead hat) I think we should keep this on in the back of our minds and work
> the rest of this agenda first...
>
> (5) Next steps on the broader encryption question: should we consider a
> measurement and management in general? This is a minefield (cf. TLS in
> Prague) but perhaps putting the right alignments of interests in the room
> will lead to some progress or useful guidance falling out (also, in my
> optimistic maybe-opinion)...
>
> Cheers,
>
> Brian
>
> > The program *should* have a webex group; I'm still waiting for the
> details, and will send them to the list as soon as I have them.
> >
> > Cheers,
> >
> > Brian
> >
> >
> >> Cc: Stackevo <[email-masked]>; Brian Trammell (IETF) <
> [email-masked]>; Martin Thomson <[email-masked]>; Mirja
> Kühlewind <[email-masked]>
> >> So this is a really interesting thought experiment space, because it
> gets into economics: in most of the decisions we're making in QUIC, which
> is designed to have relatively flexible version negotiation as well as a

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 11 Sep 2017 14:10:38 -0500

Because we have a busy agenda today ...

> (traveling), but I think we can confirm next steps with Spencer quickly.

Right, with one addition.

I'd ask people to take a look at the almost entirely new
https://marnew.github.io/Report/#rfc.section.8, and let us know what's
missing, and what's not quite right.

As an example, the text around PLUS says

The PLUS working group forming BoF was unsuccessful with attendees
expressing concern on the privacy issues associated with the data sharing
possibilities of the shim layer proposed.

But I think it's more correct to say

The Path Layer UDP Substrate (PLUS) BoF did not result in the formation of
a PLUS working group, with attendees expressing concern on the privacy
issues associated with the data sharing possibilities of the extensible
shim layer proposed.

So, I bet other people will see other things that we should know about.

Thanks,

Spencer, who knows it's hard to summarize two years of diverse activities
in one draft section :-)

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 11 Sep 2017 21:23:33 +0200

Okay, we'll push path-signals 'til you can call in.

Cheers,

Brian

> On 11 Sep 2017, at 21:03, Ted Hardie <[email-masked]> wrote:
> 
> I got pulled into something starting at 12:30 my time.  Will join as soon as I can, which might make me on-time or late depending.
> 
> Apologies,
> 
> Ted
> 
> On Mon, Sep 11, 2017 at 9:22 AM, Brian Trammell (IETF) <[email-masked]> wrote:

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 11 Sep 2017 19:23:47 +0000

Regrets, may not make it at all.

From: Stackevo [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: 11 September, 2017 12:03
To: Brian Trammell (IETF) <[email-masked]>
Cc: Stackevo <[email-masked]>
Subject: Re: [Stackevo] Stackevo program telechat, 11 September 2017, 20:00 UTC

On Mon, Sep 11, 2017 at 9:22 AM, Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, all, sorry for the delay on details.

Cheers,

Brian

> On 11 Sep 2017, at 18:06, Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On 11 Sep 2017, at 18:03, Gabriel Montenegro <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> From: Stackevo [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Spencer Dawkins at IETF
>> To: Erik Nordmark <[email-masked]<mailto:[email-masked]>>
>> Cc: Stackevo <[email-masked]<mailto:[email-masked]>>; Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Mirja Kühlewind <[email-masked]<mailto:[email-masked]>>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 11 Sep 2017 21:37:59 +0200

hi Spencer,

Have taken a quick look; there are a few minor points here along the lines of the one you point out that it's probably easier just to send a PR against. Will do so, probably after the call at this point.

Cheers,

Brian

> On 11 Sep 2017, at 21:10, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> On Mon, Sep 11, 2017 at 11:22 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> I'd ask people to take a look at the almost entirely new https://marnew.github.io/Report/#rfc.section.8, and let us know what's missing, and what's not quite right.
> 
> The PLUS working group forming BoF was unsuccessful with attendees expressing concern on the privacy issues associated with the data sharing possibilities of the shim layer proposed.
> 
> The Path Layer UDP Substrate (PLUS) BoF did not result in the formation of a PLUS working group, with attendees expressing concern on the privacy issues associated with the data sharing possibilities of the extensible shim layer proposed.
> 
> Spencer, who knows it's hard to summarize two years of diverse activities in one draft section :-)
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Sep 2017 08:40:07 +0200

Just to elaborate a bit here on what I referred to in the call, we have
created several extension mechanisms within the MUD draft.  The basis
for extension work is *mostly* this:

Today MUD deals with network access control functions.  Tomorrow it may
deal with QoS.  There is an example in the draft of the extension
mechanism based on a use case that one of us gave to me, where a device
may want to indicate a capability it *doesn't* have, or conversely
devices who make use of new network capabilities could indicate a
feature they *do* have, such that if those that start using a feature
they are said not to have might arouse some suspicion.

We have, therefore, several use cases for the extension mechanism
involved.  Are they *critical* to the protocol's success?  That is hard
to say in advance, which is one of the issues I think we will have with
"use it or lose it": there is a tension between creating extension
points that will turn out to be meaningless and actually fielding a
protocol in a reasonable time - that is, not trying to test every last
idea one has, but leaving a little room for future proofing.

On greasing, my mind turns to 240.0.0.0/4.  Here we had reserved address
space that became unusable because implementations essentially upchucked
on the range, and could never be counted on to either forward it, or not
do something unexpected.  This is nearly identical to the problem
statement in para 2 in the GREASE draft.

But that's where the similarities seemingly stop.  If the correct
behavior for an intermediary is to simply drop a packet with a reserved
address range, then that address range is forever tainted, which is what
happened with 240/4.  If the correct behavior is to pass the traffic as
unicast packets, then the range is really *not* reserved for future use,
but would be used just as other unicast traffic in perpetuity. 

I think this is a characteristic of a multiparty system (i.e., it is not
simply a layering problem).  Imagine, if you will, a group communication
protocol in which extra space is left for some additional function.  If
the default behavior is to ignore the field, if that field becomes
important, there needs to be some incentive to upgrade.  Greasing only
means that implementations won't do the wrong thing with the field; it
doesn't mean that they will ever have incentive to do the right thing,
once an extension becomes available.

Eliot

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 12 Sep 2017 09:18:45 +0200

(top posting because iPhone, sorry...)

The 240 example is an interesting one... you can't grease the address, but there is an equivalent that might shed a bit of light. This would be language like the following: intermediates must forward if they have a route, routing protocols must not announce, endpoints must not allocate to self outside the scope of an experimental use, with a regime of frequent allocations with expiration dates for experiments. Something like that gives you use it not lose it, albeit without automated code point exercise...

When the actual language around class E was written though we had more implicit faith in our ability to quickly unreserve things in the future. Experience with ECN shows that the time to unreserve is about two decades.

Cheers B

Sent from my iPhone

> On 12 Sep 2017, at 08:40, Eliot Lear <[email-masked]> wrote:
> 
> Just to elaborate a bit here on what I referred to in the call, we have created several extension mechanisms within the MUD draft.  The basis for extension work is *mostly* this:
> 
> Today MUD deals with network access control functions.  Tomorrow it may deal with QoS.  There is an example in the draft of the extension mechanism based on a use case that one of us gave to me, where a device may want to indicate a capability it doesn't have, or conversely devices who make use of new network capabilities could indicate a feature they do have, such that if those that start using a feature they are said not to have might arouse some suspicion.
> 
> We have, therefore, several use cases for the extension mechanism involved.  Are they critical to the protocol's success?  That is hard to say in advance, which is one of the issues I think we will have with "use it or lose it": there is a tension between creating extension points that will turn out to be meaningless and actually fielding a protocol in a reasonable time - that is, not trying to test every last idea one has, but leaving a little room for future proofing.
> 
> On greasing, my mind turns to 240.0.0.0/4.  Here we had reserved address space that became unusable because implementations       essentially upchucked on the range, and could never be counted on to either forward it, or not do something unexpected.  This is nearly identical to the problem statement in para 2 in the GREASE draft.
> But that's where the similarities seemingly stop.  If the correct behavior for an intermediary is to simply drop a packet with a reserved address range, then that address range is forever tainted, which is what happened with 240/4.  If the correct behavior is to pass the traffic as unicast packets, then the range is really not reserved for future use, but would be used just as other unicast traffic in perpetuity.  
> I think this is a characteristic of a multiparty system (i.e., it is not simply a layering problem).  Imagine, if you will, a group communication protocol in which extra space is left for some additional function.  If the default behavior is to ignore the field, if that field becomes important, there needs to be some incentive to upgrade.  Greasing only means that implementations won't do the wrong thing with the field; it doesn't mean that they will ever have incentive to do the right thing, once an extension becomes available.
> 
> Eliot
>