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

From: Brandon Williams <[email-masked]>
Date: Fri, 09 May 2014 10:45:33 -0400

Lars and Wes,

I understand and share the objections to adding options in-transit that 
have been raised on the list. It's bad and should be avoided if there is 
any other technically feasible option for solving a problem. On the 
other hand, I also recognize that NATs do exist and they frequently 
cause significant problems, including load-balancing, policy control, 
and attack-mitigation. Is there something specific in our analysis of 
the problem and possible solution sets that you consider to be flawed? 
Or is it simply your opinion that the negative side-affects of adding 
options in-transit are worse than the negative consequences of treating 
all hosts behind a NAT as if they were the same entity?

Considering the fact that some day (fingers crossed) IPv6 will become 
the norm and NATs will fall out of use, I'm more interested in focusing 
on the proxy use case. I have a harder time understanding your 
objections in the context of this use case (esp. for transport layer 
proxies), since the option is applied to the packet by the TCP stack 
itself, rather than being applied in-transit. In reference to the 
application proxy use case, Wes has said previously "[It] is better done 
at the application layer. ... I wouldn't feel strongly against [this 
case], it's just not good architecture." But what about the case of 
transport layer proxies that aren't involved at the application layer? 
Or receiver-side use cases where the information must be applied before 
the data stream even shows up to be delivered? Is it that you just don't 
consider these to be legitimate use cases?

In addition to the above, an argument was made on the list (by Wes) that 
there is value to driving vendors to converge on a common option rather 
than continuing with the fragmented solution space that exists today. It 
is already the case that multiple vendors (those the authors represent) 
are attempting to use the draft for this purpose, and we have every 
reason to believe, based on our interactions with other vendors (see for 
example a thread on the list re: the dante socks proxy), that some other 
vendors would move to the common format if the draft is adopted and 
published. What number of vendors moving to a common format would be 
considered large enough for this argument to be persuasive?

If you have the time, any further elaboration from you on the above 
questions would be greatly appreciated.

Thanks,
--Brandon

On 04/30/2014 03:18 PM, Wesley Eddy wrote:
> On 4/30/2014 10:51 AM, Eggert, Lars wrote:
>> For the record, I am opposed to the WG taking this document on, and I
>> am opposed to it being published as an RFC on any stream.
>>
>
>
> My opinion is similar.
>
> An RFC isn't necessary to use an ExID.  It doesn't require IETF
> approval, and is unlikely to get IETF approval, in order to do
> this in a system, if you really want to discount the problems
> and do it anyways.
>
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 May 2014 14:33:27 -0700

Hi, all,

Although I appreciate some concerns about this doc, I don't quite share 
them.

A key concern is whether this encourages middleboxes to alter TCP options.

IMO, a middlebox that alters an IP address and TCP port is taking on the 
role of "host" to the public side. In that case, it is responsible for 
any options that are related to those values - including this one.

I.e., so long as we restrict this to devices that set IP addresses 
and/or TCP ports, I see no problem. If the issue is that "middleboxes 
shouldn't alter TCP options", then the real issue is that such 
middleboxes shouldn't alter IP addresses or ports.

Joe

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 13 May 2014 07:15:16 +0000

Hi,

apart from the technical disagreement I have with the document, there is a broader political issue here.

The IETF has come to broad consensus that pervasive surveillance represents an attack on the Internet, and that we are taking engineering steps to protect privacy. (See http://www.ietf.org/blog/2013/11/ for example.)

Having middleboxes tag flows with options that make identifying individuals easier goes directly against that stated goal.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 13 May 2014 09:49:51 +0000

PS: http://tools.ietf.org/html/rfc7258 came out today

On 2014-5-13, at 9:15, Eggert, Lars <[email-masked]> wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Brandon Williams <[email-masked]>
Date: Tue, 13 May 2014 08:56:13 -0400

Hi Lars,

Regarding the privacy concern, is there something that we have missed in 
the section about privacy contained in the document? If the guidance 
provided in the document is followed, then I don't see how the use of 
this option makes identifying individuals easier.

In addition, I argue that the privacy concern is an argument in favor of 
adopting this draft. TCP options of this nature are in use on the 
Internet today and will continue to be used going forward. As long as 
there is no move toward consensus on the option format, number, etc. and 
as long as people active in the WG actively discourage authors from 
publishing documents related to this use of the option space, it will be 
difficult for anonymizing systems to recognize such options and protect 
anonymity. This is part of the reason why we give direct guidance on 
this topic in draft.

--Brandon

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 May 2014 08:14:52 -0700

> apart from the technical disagreement I have with the document, there is a broader political issue here.

I certainly hope not, but the IESG Chair warned us about this (see 
below), so we shouldn't be surprised.

> The IETF has come to broad consensus that pervasive surveillance represents an attack on the Internet,

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

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

---
3) The document, particularly as a BCP, could be used to block documents 
by ADs in an unreasonable fashion. There was considerable concern about 
this. However, the IESG process for document approval is most commonly 
not based on specific rules in existing RFCs, but rather specific 
technical concerns of the individual AD reviewers. ADs occasionally 
raise invalid issues on documents, and we expect (and get) pushback when 
that happens. I have certainly made mistakes when filing a Discuss. 
These are resolved through discussion. In more severe cases, we have 
override procedures, appeals, discussions with the Nomcom, and recall 
procedures to deal with these issues. In other words, if we start from 
the assumption of a misbehaving AD, no new documents are needed to file 
an inappropriate Discuss. Any AD can raise concerns about pervasive 
monitoring under the current Discuss criteria, and this document doesn't 
change that. We don't think this document will significantly change 
things for the worse. However, the IESG felt that there is an 
opportunity to clarify our procedures with regards to this specific case:

The IESG intends to make a change to its Discuss criteria statement [3]. 
While the general thrust of the statement already indicates that AD 
disagreement with informed WG consensus is a NOT an acceptable basis for 
a discuss, we wanted to say that more explicitly in the specific context 
of adequate consideration for pervasive monitoring issues. Section 3.2 
of the Discuss criteria statement is about criteria that are not 
appropriate basis for a Discuss. We plan to say that while it is 
generally necessary that IETF work considers the impact of specific 
threats such as pervasive surveillance, informed and rational community 
decisions about the particular protocols and the possible need for 
mitigating mechanisms will be respected.

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

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

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.

Joe

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 13 May 2014 16:30:26 +0000

Hi,

On 2014-5-13, at 17:14, Joe Touch <[email-masked]> 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.

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

> 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

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 May 2014 09:56:11 -0700

On 5/13/2014 9:30 AM, Eggert, Lars wrote:
> It's not an IETF standard,

RFC5681

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

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

> 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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 19 May 2014 17:53:54 +0000

Hi Brandon, all,

Thanks a lot for this update. Indeed, the update takes into account TCPM feedback, and this is excellent.

However, based on the list discussion so far, it seems to the chairs that this document would be a better fit to an independent stream submission. The TCP option described in this document actually does not modify any TCP logic. Identifying the hosts that are hidden behind a shared address/prefix sharing device or application-layer proxy seems like a new service that current TCP does not offer. TCPM is only chartered for minor TCP extensions.

Also, in its current form, it seems that this document formally does not require TCPM adoption. While TCPM documents probably (hopefully!) have more weight among end-system TCP stack implementers, it is much less clear whether a TCPM document on this specific topic will indeed foster implementation convergence among middleboxes. We have no empirical evidence for that.

TCPM is used to adopt new working group items based on rather strong consensus. According to the list discussion so far, the TCPM chairs currently understand that there is no consensus in the TCPM community to adopt this document at this point in time. 

Obviously, as usual in the IETF, further list discussion is welcome.

Best regards

Michael
on behalf of the TCPM chairs 

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Wednesday, April 30, 2014 4:44 PM
> To: [email-masked]
> Subject: [tcpm] Fwd: New Version Notification for draft-williams-exp-
> tcp-host-id-opt-03.txt
> 
> We have updated the draft based on feedback on the list and in London.
> In particular, we have attempted to provide a clearer explanation of
> the
> use cases we are attempting to address and why solutions at other
> layers
> in the protocol stack do not work for these use cases. Previous updates
> had already attempted to provide stronger limiting guidance for option
> usage.
> 
> As we have indicated previously on the list, we would prefer to see WG
> adoption of this I.D. rather than working toward publishing as an
> individual submission. We think WG adoption has a few benefits, even in
> the absence of clear consensus on the question of whether this is a
> good
> idea. First and foremost, WG adoption would mean that the limiting
> guidance on usage carries more weight. And second, WG adoption would
> more strongly encourage individual implementations that are already in
> use to converge on a single option format.
> 
> We look forward to your feedback.
> 
> Thanks,
> --Brandon
> 
> 
> -------- Original Message --------
> Subject: New Version Notification for
> draft-williams-exp-tcp-host-id-opt-03.txt
> Date: Wed, 30 Apr 2014 10:22:20 -0400
> From: [email-masked] <[email-masked]>
> To: Williams, Brandon <[email-masked]>, Dan Wing
> <[email-masked]>, Mohamed Boucadair <[email-masked]>,
> Mohamed Boucadair <[email-masked]>, Dan Wing
> <[email-masked]>, Williams, Brandon <[email-masked]>
> 
> 
> A new version of I-D, draft-williams-exp-tcp-host-id-opt-03.txt
> has been successfully submitted by Brandon Williams and posted to the
> IETF repository.
> 
> Name:		draft-williams-exp-tcp-host-id-opt
> Revision:	03
> Title:		Experimental Option for TCP Host Identification
> Document date:	2014-04-29
> Group:		Individual Submission
> Pages:		11
> URL:
> http://www.ietf.org/internet-drafts/draft-williams-exp-tcp-host-id-opt-
> 03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/
> Htmlized:
> http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-03
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-williams-exp-tcp-host-id-opt-03
> 
> Abstract:
>     Recent IETF proposals have identified benefits to more distinctly
>     identifying the hosts that are hidden behind a shared
> address/prefix
>     sharing device or application-layer proxy.  Analysis indicates that
>     the use of a TCP option for this purpose can be successfully
> applied
>     to a broad range of use cases.  This document describes a common
>     experimental TCP option format for host identification.
> 
> 
> 
> 
> 
> 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
> 
> 
> --