Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.txt

["Eggert, Lars" <[e-mail]>]

Hi,

On 2014-5-13, at 17:14, Joe Touch <[e-mail]> wrote:
> It would be more useful for the iETF to take positions on devices that undermine its architecture (e.g., NATs) and protocols that are deployed against current technical advice (CUBIC).

We're getting off-topic here, but what "current technical advice" is Cubic violating? 

It's not an IETF standard, and it's on by default in Linux and that's not so nice, but it doesn't seem to be have serious flaws (anymore). So while I wish there was an ID we could progress (and I have it on my list to talk to Injong and get his OK for someone else to carry the torch), I think you're overstating things.

>> and that we are taking engineering steps to protect privacy. (See http://www.ietf.org/blog/2013/11/ for example.)
> 
> The IESG Chair's report on the conclusion of community discussion specifically addressed the use of this document to block other docs:

The text you quoted is entirely about what ADs should and should not do *during IESG processing*. I'm not an AD (anymore), and I am certainly free to make this argument as an individual *during a call for WG adoption*.

>> Having middleboxes tag flows with options that make identifying individuals easier goes directly against that stated goal.
> 
> First, we're talking about use of this option by middleboxes and endpoints that already change host IDs (not personal IDs).

Sure. But I don't see why this is relevant.

In some sense CGNs - as problematic as they are - actually increase privacy, because more users share an IP address. This document is about counteracting this increased privacy. And since we don't know by what mechanism these host IDs get set, and given that the document talks about potentially quite large ID namespace (32bits), you could actually identify things at a finer granularity than hosts.

> Second, this mechanism can easily be used to obfuscate the identification hosts, to re-group them in alternate ways.

How and by whom? Even if hosts end up setting it, it'll get stripped out or rewritten by an ISP middlebox that can set it based on subscriber information and current connection context.

> Finally, I sincerely hope this draft's process doesn't become the poster child of the process fears raised by the IESG Chair in approving perpass and recommending it as BCP.

So I actually hope it does. In my view, the reason that the text you quoted was entirely about the IESG process was to not have late surprises happen to stuff that are already WG documents or in IETF last call.

But that's not the case here. This is not a WG document, and using the BCP - that we have IETF consensus on - as an argument to not *start* problematic work is entirely reasonable. If not, what *can* we use that consensus BCP for? Feeling good about ourselves without actually doing anything?

Lars