Subject: Re: [arch-d] [IAB] Call for Comment: <draft-iab-path-signals-02> (Transport Protocol Path Signals)

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Sat, 1 Dec 2018 11:26:26 +0100

Hi Stephen, Ted, all... 

(in-line)

Sent from my iPhone

> On 30 Nov 2018, at 23:19, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
>> On 30/11/2018 21:53, Ted Hardie wrote:
>> Do these changes make sense to you?  
> 
> Yep.
> 
>> Are they enough, or do we need to say
>> more?
> 
> They're fine by me, thanks.
> 
> I would offer one other bit of text, maybe along the
> lines of:
> 
> "Note: There are significant unsolved problems with
> supporting non-endpoints in verifying signal integrity
> or being enabled to modify signals while preserving
> security. It is therefore likely that integrity
> protection can only be applied by, and can only be
> verified by, end-points."

I’d second adding text like this.

It might make sense to point out here, too, that while we know that doing this right is hard, advances in generalizable methods for allowing integrity protection verifiable by other than the endpoints are a necessary missing building block for deploying more complex path signaling approaches in the Internet. Not sure how emphatically we want to encourage work in a space that may well be futile, though.

Cheers, B

> But your suggested text is good enough if you'd rather
> not add more.
> 
> Cheers,
> S.
> <0x5AB2FAF17B172BEA.asc>
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 1 Dec 2018 23:40:44 +0000

Hiya,

On 01/12/2018 10:26, Brian Trammell (IETF) wrote:
> It might make sense to point out here, too, that while we know that
> doing this right is hard, advances in generalizap than the endpoints
> are a necessary missing building block for deploying more complex
> path signaling approaches in the Internet. Not sure how emphatically
> we want to encourage work in a space that may well be futile,
> though.
Yep, "resistance is futile", as the saying goes:-)

I'd agree it might be wise (and kind) for the IAB to ack that
it's perhaps not entirely realistic to expect significant new
developments here. (OTOH, while it's a fun problem, it's not
one that's attracted much attention in the last while afaik,
so who knows, maybe smart people will find new smart answers).

Cheers,
S.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 3 Dec 2018 18:57:40 +0000

A balanced summary of a somewhat contentious issue.  Well done, Ted and IAB.

-----Original Message-----
From: IETF-Announce <[email-masked]> On Behalf Of IAB Executive Administrative Manager
Sent: Wednesday, November 28, 2018 1:55 PM
To: IETF Announcement List <[email-masked]>
Subject: Call for Comment: <draft-iab-path-signals-02> (Transport Protocol Path Signals)

This is an announcement of an IETF-wide Call for Comment on draft-iab-path-signals-02.

The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection at:
<https://datatracker.ietf.org/doc/draft-iab-path-signals/>

The Call for Comment will last until 2018-12-25. Please send comments to [email-masked] and [email-masked].

Abstract

   This document discusses the nature of signals seen by on-path
   elements examining transport protocols, contrasting implicit and
   explicit signals.  For example, 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.  Often, the removal of those signals is intended by
   those moving the messages to confidential channels.  Where the
   endpoints desire that network elements along the path receive these
   signals, this document recommends explicit signals be used.

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 03 Dec 2018 17:17:40 -0500

Hi Stephen-

> verified by, end-points."

For those of us playing along at home, could you provide a hint / 
example / link regarding the ‘significant unsolved problems’ around 
middleboxes verifying signal integrity?  My first thought goes to the 
DoS vulnerability if the middlebox is discarding traffic that fails the 
integrity check but I sense you have something more in mind.

--aaron

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 3 Dec 2018 22:49:03 +0000

Hi Aaron,

On 03/12/2018 22:17, Aaron Falk wrote:
> example / link regarding the â€˜significant unsolved problemsâ€™ around

I guess so, but as usual, my logic is more prosaic:-)

If integrity isn't cryptographic, then all bets are off.

If integrity uses symmetric crypto, then how can endpoint(s)
share keys with middleboxes they've never heard of? That
seems like a showstopper outside of e.g. an enterprise n/w.
(Where presumably better options exist in any case.)

If integrity uses signatures and a PKI then it's still hard
to know what trust points (CAs/roots/whatever you want to
call 'em) will be acceptable to a middlebox, from a signing
endpoint. (Since there's no negotiation.) If your transport
is bidirectional, and some middleboxes need to be able to
verify signals from either side, then that seems to force
both endpoints to use the same set of trust points. So one
ends up with the best one can see is one PKI to rule them
all, kind of like DNSSEC I guess, but how could such a PKI
certify endpoints for this purpose and what'd that mean?
(End of "permissionless" maybe? - every transport endpoint
needs a DS resource record equivalent perhaps.)

I think the problem in the para above seems true regardless
of what kind of PKI one invents (x.509, DNSSEC, spki, pgp...)

One might consider integrity with signatures and TOFU, but
that seems to only make sense if the same endpoint sends
many signals via one middlebox, which has lots of other
downsides, e.g. tracking.

And of course signatures aren't tiny either, nor are key
ids that could work in such a context so it seems a bit
theoretical in any case. One could imagine amortising bits
of a signature over multiple packets I guess, but that'd
be yet another bit of research.

And all of the above is before one even gets to where you
started from - that we'd be creating new DoS vectors most
likely etc.

Hope that helps,
S.