Subject: Re: [Stackevo] Fwd: New Version Notification for draft-hardie-path-signals-02.txt

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jan 2018 16:14:34 +1100

I also think that we should explicitly identify not encrypting as an
option.  We could still have integrity protection.  Of course, we
should then make it clear that rampant misguided inference is why we
are encrypting.  I'd put something in the introduction to Section 4
there.

I have one consideration to add, probably to security considerations
(more on that below).  Explicit signals can be disconnected from the
protocol signaling machinery.  Doing so might be necessary to avoid
path entities inferring more from the signal than is intended.  If
QUIC takes a spin bit, that's a clear example of where we take RTT
information and signal that, but we separate that signal from all of
the rich acknowledgment information the protocol really needs.
However, this split creates a potential for those signals to be
incorrect or even for them to be falsified, presumably with the intent
of manipulating path entities in some way.

I don't think that we need any specific mitigation, but we should
recognize that this is a natural consequence of the recommendations in
the draft.  That isn't strictly a negative outcome either.  One
conceivable - but actually highly unlikely - outcome of designing
explicit signals is that intermediaries might insist on a certain set
of signals before a packet is allowed to pass ("give me SNI or I kill
your flow").  A signal that isn't directly coupled to the actual
protocol machinery can be falsified to appease a middlebox, even in
cases where the endpoint might otherwise prefer not to provide the
information.  I wouldn't include all that exposition though, just note
that falsification is possible, without affecting the e2e protocol
operation.

On structure, I think that the bulk of the security considerations are
better moved elsewhere.  The bullet list seems to belong in Section 5.

(I agree with Eliot regarding editing.  There are quite a number of
typos that I would have sent a PR for, had there been a destination
that a PR could be directed toward.)

On Fri, Dec 22, 2017 at 12:00 AM, Eliot Lear <[email-masked]> wrote:
> Hi Ted,
>
> Following up on Brian's comment, as I wrote to you the last time, I really
> like this draft.  For some reason, Section 3.1.1 seems to have suffered
> editorially and needs just a bit of work.
>
> Eliot
>
>
> On 01.12.17 00:40, Ted Hardie wrote:
>
> As discussed in the last meeting, I have updated this slightly and brought
> it back into circulation.  The changes are very small (updating a reference,
> slightly enlarged pointer to fingerprinting risk).
>
> Hack away,
>
> Ted
>
>
> ---------- Forwarded message ----------
> From: <[email-masked]>
> Date: Thu, Nov 30, 2017 at 3:39 PM
> Subject: New Version Notification for draft-hardie-path-signals-02.txt
> To: Ted Hardie <[email-masked]>
>
>
>
> A new version of I-D, draft-hardie-path-signals-02.txt
> has been successfully submitted by Ted Hardie and posted to the
> IETF repository.
>
> Name:           draft-hardie-path-signals
> Revision:       02
> Title:          Path signals
> Document date:  2017-11-30
> Group:          Individual Submission
> Pages:          8
> URL:
> https://www.ietf.org/internet-drafts/draft-hardie-path-signals-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-hardie-path-signals/
> Htmlized:       https://tools.ietf.org/html/draft-hardie-path-signals-02
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hardie-path-signals-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-hardie-path-signals-02
>
> Abstract:
>    TCP's state mechanics uses a series of well-known messages that are
>    exchanged in the clear.  Because these are visible to network
>    elements on the path between the two nodes setting up the transport
>    connection, they are often used as signals by those network elements.
>    In transports that do not exchange these messages in the clear, on-
>    path network elements lack those signals.  This document discusses
>    the nature of the signals as they are seen by on-path elements and
>    reflects on best practices for transports which encrypt their state
>    mechanics.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo
>
>
>
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Jan 2018 09:37:11 -0800

Howdy,

On Thu, Dec 21, 2017 at 3:25 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> hi Ted,
>
> I still think that, as a statement of principles, this document is pretty
> much Ready To Go. The concrete signal and path property analysis ekr
> requested at the retreat in Montreal, on the other hand, seems like a thing
> PANRG could take up (indeed, see question 1 in draft-trammell-panrg-
> questions).
>
> I'd be interested to get your opinion on the relationship between this and
> draft-trammell-wire-image, which we started to have a concise reference for
> what it is we mean when we say "wire image", but turns out, I think, to be
> quite complementary to this document in ways that it might make sense to
> consider merging them. Thoughts?
>
>
My apologies for the delay in replying; my office was moved while I was at
the IGF, and the systems didn't come up properly.  Since I was away on
holiday, this created a bit of delay.

I'd be fine with emitting this as a statement of principles, then
incorporating some of the text into draft-trammell-wire-image; there's no
reason not to do both, as far as I can tell.

Does that work for you?

Ted

> Cheers,
>
> Brian
>
>
> > On 1 Dec 2017, at 00:40, Ted Hardie <[email-masked]> wrote:
> >
> > As discussed in the last meeting, I have updated this slightly and
> brought it back into circulation.  The changes are very small (updating a
> reference, slightly enlarged pointer to fingerprinting risk).
> >
> > Hack away,
> >
> > Ted
> >
> >
> > URL:            https://www.ietf.org/internet-drafts/draft-hardie-path-
> signals-02.txt
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardie-path-
> signals-02
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-hardie-path-
> signals-02
> >
> > Abstract:

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Jan 2018 09:38:13 -0800

On Thu, Dec 21, 2017 at 5:00 AM, Eliot Lear <[email-masked]> wrote:

> I'll take a look, but if you have preferred text, I'd be happy to get the
suggestion.

regards,

Ted

> it back into circulation.  The changes are very small (updating a
> URL:            https://www.ietf.org/internet-
> drafts/draft-hardie-path-signals-02.txt
> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-hardie-path-signals-02
> Diff:           https://www.ietf.org/rfcdiff?
> url2=draft-hardie-path-signals-02
>
> Abstract:
> Stackevo mailing [email-masked]://www.iab.org/mailman/listinfo/stackevo
>
>
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Jan 2018 09:51:59 -0800

On Mon, Jan 1, 2018 at 9:14 PM, Martin Thomson <[email-masked]>
wrote:

> path entities inferring more from the signal than is intended.

As a confirmation/friendly amendment, does rephrasing this as "protocol
state machinery" work for you?  If so, I would actually strengthen this to
"should be disconnected".  Ideally, I would like the path elements to
consume the signals explicitly for them even if there is an unencrypted
portion of a flow; inferring from that tends to ossify things and avoiding
that is a key part of our aim.

> If
I'll get it onto github.  Since I generally start that by cloning one of
your repos, which is the current one to crib from?

Ted

> brought
> reference,

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Jan 2018 08:34:28 +1100

> that is a key part of our aim.

Sure, the point is that the signaling that drives the protocol state
machinery at either end is distinct from the explicit signals to the
path.  I'd say that should is appropriate (even in the 2119 sense).

> your repos, which is the current one to crib from?

I generally point people at
https://github.com/martinthomson/i-d-template/blob/master/doc/REPO.md#fast-setup
now.  But you can crib from
https://github.com/martinthomson/postel-was-wrong/ which I keep up to
date.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Jan 2018 13:50:34 -0800

The new repo is at:

https://github.com/hardie/path-signals

PR away....

Ted

On Tue, Jan 2, 2018 at 1:34 PM, Martin Thomson <[email-masked]>
wrote:

> > On Mon, Jan 1, 2018 at 9:14 PM, Martin Thomson <[email-masked]
> >
> > wrote:
> >>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 3 Jan 2018 11:33:28 -0500

Hi and happy new year to all,

> are encrypting.  I'd put something in the introduction to Section 4

Speaking as someone who works with a company that has done some of that
interference, I am aware that some of it was misguided, but when it
comes to writing this down, let's mind the tone.  There are reasons that
firewalls came to be, and continue to be important.  We've now in the
last two months had two major examples of how endpoints aren't in a
position to protect themselves on their own, and probably never will
be.  I'm not suggesting that we replay that entire discussion this
document, but much of the "interference" is precisely what the
administrator intends, and it is not misguided.

> that falsification is possible, without affecting the e2e protocol

I think it's probably worth expanding this point.  Falsification of
signaling means that middleboxes will not trust it.  To what degree that
holds true will depend on circumstances, but if it becomes the general
case, one has to ask what the point of including it was in the first
place?  That way lies dragons.

Eliot

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 Jan 2018 09:25:58 +1100

> place?  That way lies dragons.

That's why I think we are better avoiding saying anything.  The value
of signals will depend greatly on whether endpoints provide accurate
values, and that in turn will depend on the consequences that are
attached to either faithful or falsified values.  I can't predict the
outcome, which remains the big open question in this entire space.
It's certainly true that there is a case for mutual benefit to be
gained by filling explicit signals accurately, but it's not clear if
the gains are as well understood as for other voluntary things, such
as using a sane congestion control algorithm [1].

[1] Side discussion for bonus credit: In TCP, an endpoint that fails
to observe proper sender behaviour with respect to congestion control
can be managed in the network by terminating their TCP connections.
End-to-end protection of the transport prevents that.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Jan 2018 11:12:20 +0100

> as using a sane congestion control algorithm [1].

Ok, you guys decide, but I think you just spoke quite eloquently in
writing on the current state of affairs, and that's not a bad thing for
the IAB folk to do ;-)

Eliot

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 8 Jan 2018 13:55:23 +0100

> On 2 Jan 2018, at 18:37, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> On Thu, Dec 21, 2017 at 3:25 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> hi Ted,
> 
> I still think that, as a statement of principles, this document is pretty much Ready To Go. The concrete signal and path property analysis ekr requested at the retreat in Montreal, on the other hand, seems like a thing PANRG could take up (indeed, see question 1 in draft-trammell-panrg-questions).
> 
> I'd be interested to get your opinion on the relationship between this and draft-trammell-wire-image, which we started to have a concise reference for what it is we mean when we say "wire image", but turns out, I think, to be quite complementary to this document in ways that it might make sense to consider merging them. Thoughts?
> 
> 
> My apologies for the delay in replying; my office was moved while I was at the IGF, and the systems didn't come up properly.  Since I was away on holiday, this created a bit of delay.
> 
> I'd be fine with emitting this as a statement of principles, then incorporating some of the text into draft-trammell-wire-image; there's no reason not to do both, as far as I can tell.
> 
> Does that work for you?

Yep, that makes sense.

Cheers,

Brian

> > As discussed in the last meeting, I have updated this slightly and brought it back into circulation.  The changes are very small (updating a reference, slightly enlarged pointer to fingerprinting risk).
> >
> > Hack away,
> >
> > Ted
> >
> >
> > URL:            https://www.ietf.org/internet-drafts/draft-hardie-path-signals-02.txt
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardie-path-signals-02
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-hardie-path-signals-02
> >
> > Abstract:

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 8 Jan 2018 14:05:09 +0100

> On 3 Jan 2018, at 23:25, Martin Thomson <[email-masked]> wrote:
> 

For what it's worth, https://tools.ietf.org/html/draft-trammell-quic-spin-01#section-7 addresses this issue in particular for the spin bit in the last two paragraphs of section 7. IMO it might make sense to mention this in the general case, and to note that the specifics of trustworthiness have to be considered separately for each signal.

> End-to-end protection of the transport prevents that.

Keeping a LRU stateful flow rule to drop all packets for a five-tuple, refreshed on every packet seen, is sufficient for a forwarding middlebox to terminate a connection identifiable by five-tuple. AFAIK at least one of the famous stateless RST-emitting censorship firewalls has migrated to stateful operation along these lines, so there's at least one existence proof for stateful connection killing that scales (if you're motivated to pay for it).

Breaking the five-tuple = connection equivalency is necessary to really screw thing up. :) So, more accurately, end-to-end protection of the transport together with aggressive connection migration or multipathing prevents that.

Cheers,

Brian