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

[Joe Touch <[e-mail]>]

On 5/13/2014 9:30 AM, Eggert, Lars wrote:
> 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,

RFC5681

>>> 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*.

Agreed. However, the entirety of the message indicated basically that 
the Chair was taking very rough - at best - consensus about a draft and 
making it BCP even though the community is widely split on the issue.

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

Middleboxes create a problem that this is intended to let *them* fix.

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

It's about letting *them* not provide that privacy where privacy wasn't 
intended.

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

You can also use ARP to find out the manufacturer of a NIC. We aren't 
deprecating ARP because of privacy concerns.

You can also have existing NATs and CGNs expose host privacy in the 
source IP and port number selected, as well as in other fields that 
could easily be modified for their nefarious uses (e.g., ISNs).

I don't see this new political statement as requiring WGs to scrub their 
protocols for all *potential* or *perceived* issues with privacy.

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

First, that depends on whether they're protected by the endpoint or not 
- e.g., IPsec or TCP-AO could allow the source endpoint to set this 
information usefully, and prevent a middlebox from obfuscating it.

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

If so, I predict it will be the death of the IETF as a technical body. I 
can't speak for others, but I don't participate here to express my 
political positions.

> But that's not the case here. This is not a WG document, and using
> theBCP - that we have IETF consensus on

Every rough consensus, and an IESG Chair that set the document type 
*after* last call.

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

In this case, it can and should drive the use cases discussed and 
security considerations presented.

However, unless this mechanism provides more opportunity for tracking 
than existing protocols and mechanisms, I don't think it should be used 
to block it.

Joe