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

From: Brandon Williams <[email-masked]>
Date: Fri, 10 Jan 2014 11:35:39 -0500

-------- Original Message --------
Subject: New Version Notification for 
draft-williams-exp-tcp-host-id-opt-00.txt
Date: Fri, 10 Jan 2014 11:29:11 -0500
From: [email-masked] <[email-masked]>
To: Williams, Brandon <[email-masked]>, Dan Wing 
<[email-masked]>, Mohamed Boucadair <[email-masked]>

A new version of I-D, draft-williams-exp-tcp-host-id-opt-00.txt
has been successfully submitted by Brandon Williams and posted to the
IETF repository.

Name:		draft-williams-exp-tcp-host-id-opt
Revision:	00
Title:		Experimental Option for TCP Host Identification
Document date:	2014-01-10
Group:		Individual Submission
Pages:		8
URL: 
http://www.ietf.org/internet-drafts/draft-williams-exp-tcp-host-id-opt-00.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-00

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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 14 Jan 2014 12:11:37 +0000

Hi Brandon,

Thanks for this heads up. One specific question related to the IANA section:

   This document specifies a new TCP option that uses the shared
   experimental options format [RFC6994], with ExID=0x0348 (840) in
   network-standard byte order.  This ExID has already been registered
   with IANA.

However, I don't find that ExID in the IANA registry so far. Has this ExID indeed been registered?

During publication of RFC 6994, I've been told that IANA would process such requests fast - and this is why I am curious whether this is true.

Apart from that, do the authors have any plans how to proceed? Given the draft name, I assume that you don't plan to ask for WG adoption in TCPM, right?

Thanks

Michael

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Friday, January 10, 2014 5:36 PM
> To: [email-masked]
> Subject: [tcpm] Fwd: New Version Notification for draft-williams-exp-
> tcp-host-id-opt-00.txt
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: <[email-masked]>
Date: Tue, 14 Jan 2014 14:40:34 +0100

Dear Michael,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : tcpm [mailto:[email-masked]] De la part de Scharf, Michael
>(Michael)
>Envoyé : mardi 14 janvier 2014 13:12
>À : Brandon Williams
>Cc : [email-masked]
>Objet : Re: [tcpm] Fwd: New Version Notification for draft-williams-exp-
>tcp-host-id-opt-00.txt
>
>Hi Brandon,
>

[Med] It is registered. Please see: http://www.iana.org/assignments/tcp-parameters/tcp-parameters.txt 

      Value                      Description                                  Reference
   0x0348      Host ID                                         [draft-williams-exp-tcp-host-id-opt]

>
>During publication of RFC 6994, I've been told that IANA would process such
>requests fast - and this is why I am curious whether this is true.
>
>Apart from that, do the authors have any plans how to proceed?

[Med] We would like to see this experimental option published as an RFC. If tcpm accepts to take this work, this would work for us. 

 Given the
>draft name, I assume that you don't plan to ask for WG adoption in TCPM,
>right?

[Med] We would appreciate if a call for adoption is issued in tcpm. Thanks.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 14 Jan 2014 13:54:50 +0000

> >However, I don't find that ExID in the IANA registry so far. Has this
> ExID
> >indeed been registered?
> 
> [Med] It is registered. Please see:
> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.txt
> 
>       Value                      Description
> Reference
>    0x0348      Host ID                                         [draft-

I checked out this site: http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml

Apparently, that site is not up to date. Sorry for my confusion.

> [Med] We would like to see this experimental option published as an
> RFC. If tcpm accepts to take this work, this would work for us.
> 
>  Given the
> [Med] We would appreciate if a call for adoption is issued in tcpm.

Thanks for the information. It is not clear to me whether the overall topic would be within the current TCPM charter, and IMHO this will require discussion.

Anyway, thoughts from the community would be highly appreciated.

Michael

> Thanks.
> >> http://www.ietf.org/internet-drafts/draft-williams-exp-tcp-host-id-
> opt-
> >> 00.txt
> >> Status:

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 14 Jan 2014 08:54:59 -0500

> Apart from that, do the authors have any plans how to proceed? Given the draft name, I assume that you don't plan to ask for WG adoption in TCPM, right?

I think we should not proceed at all on this.

Intermediate devices shouldn't play with TCP options.

My guess is that there may even be strong consensus on this.

-- 
Wes Eddy
MTI Systems

---

From: Brandon Williams <[email-masked]>
Date: Tue, 14 Jan 2014 09:43:19 -0500

Hi Wes,

I think you may be making assumptions about the nature of the 
intermediate devices. While there are some use cases where the option 
would be inserted into packets as they traverse an intermediate device, 
there are also cases where the TCP connections on both sides of the 
device are distinct (i.e. the intermediate device is the endpoint for 
both connections). An application proxy would be one common example of 
the later.

If I've misunderstood your objection, please provide further elaboration.

Thanks,
--Brandon

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

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 14 Jan 2014 10:08:45 -0500

> If I've misunderstood your objection, please provide further elaboration.

Hi Brandon, I think your understand it.

If the use-cases are divided into:

1) use by application proxies that terminate the TCP connections

2) use by invisible middleboxes that tamper with TCP flows that
   path through them

Then, number 2 is what I think there should be no support or
encouragement for at the moment.

In my opinion, it would seem that enhanced signalling for number 1
is better done at the application layer, and that it's awkward to
do via TCP, since it would require application changes anyways to
set and make use of the information (i.e. it's not a part of the
socket API).  So, while I wouldn't feel strongly against number 1,
it's just not good architecture.

-- 
Wes Eddy
MTI Systems

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 14 Jan 2014 15:34:37 +0000

> My guess is that there may even be strong consensus on this.

Fully agreed.

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Jan 2014 14:46:19 -0800

> Apparently, that site is not up to date. Sorry for my confusion.

It was correct when I looked at both URLs.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Jan 2014 14:56:44 -0800

>> My guess is that there may even be strong consensus on this.

I'm confused about the concern.

Although I completely agree that intermediate devices shouldn't play 
with TCP options, they already DO play with TCP fields that they 
shouldn't - e.g., NATs change IP source address and port numbers.

AFAICT, this document's intent in using intermediate devices is to have 
the NAT preserve some variant/derivative of the origin IP address/port 
info, i.e., so the receiving system can (if it wants) determine the 
difference between different origin hosts vs. different connections from 
the same origin host, even when all are behind a NAT.

I agree it's ugly, but it seems that having NATs is what creates the 
ugliness. NATs need to do one of two things, and neither one is 
architecturally more corrrect:

	1. enforce the notion that they are the single address for
	all hosts behind them

	2. allow different hosts behind them to be exposed as such

So while I agree that a generic intermediate device should NEVER do 
this, IMO a NAT doing this is different - it's more like cleaning up a 
problem it creates, vs. making things worse.

My conclusion is that ONLY devices that change IP source addresses 
and/or ports MAY do this (and only devices that add the option should 
ever remove it, e.g. in the reverse direction), but other intermediate 
devices MUST NOT change these values.

I don't agree that this is either an elegant, appropriate, or necessary 
solution. But it's not 'evil' for the reasons presented thus far.

There are other issues, e.g., TCP-AO includes an experimental NAT 
variant that this is incompatible with, but we can discuss those if this 
becomes a WG doc.

Joe

PS - IMO, this document misrepresents the contents of RFC6967 in its intro:

    [RFC6967] provides analysis of various solutions to the problem of
    revealing the sending hosts's identifier (HOST_ID) information to the
    receiver, which indicates that a solution using a TCP [RFC0793]
    option for this purpose can be successfully applied to a broad range
    of use cases with limited performance impact.

RFC6967 never says that the TCP solution can be successful in the way 
claimed; in fact, it lists a large number of issues with a TCP solution.

RFC6967 didn't recommend a solution:

    This document analyzes a set of potential solutions for revealing a
    host identifier and does not recommend a particular solution,
    although it does highlight the hazards of some approaches.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 15 Jan 2014 08:25:30 +0000

> >>     0x0348      Host ID
> [draft-
> >> williams-exp-tcp-host-id-opt]
> >

Indeed, I checked the xhtml site several times yesterday and it was finally updated in the late evening.

Michael

---

From: <[email-masked]>
Date: Wed, 15 Jan 2014 14:06:22 +0100

Dear Wes, 

An additional deployment model, in addition to the ones you mentioned, is to set the option by the end host or the CPE while the address sharing device in the network would be configured to check the value included in such option. This model is suitable for DS-Lite deployments (RFC6333) where there is no NAT anymore in the CPE side, but a CGN function in the network side. An IPv4-in-IPv6 encapsulation scheme is used to between the host/CPE and the CGN. The HOST_ID as defined in the draft can be used by the host/CPE to inject some bits of the IPv6 address assigned to the CPE, this bits will be used to distinguish hosts serviced behind the same CGN device. Is there something harmful in this deployment model?

Note, that a similar approach would be adopted for A+P schemes (see draft-ietf-softwire-map)

One additional observation:
* This option is trying to solve some of the issues raised by NATs. We can ignore that NATs are there, but this does not solve real problems encountered in operational networks. 

Cheers,
Med

>De : tcpm [mailto:[email-masked]] De la part de Wesley Eddy
>Envoyé : mardi 14 janvier 2014 16:09
>À : Brandon Williams; Scharf, Michael (Michael)
>Cc : [email-masked]

---

From: Brandon Williams <[email-masked]>
Date: Wed, 15 Jan 2014 10:27:36 -0500

I think you've captured our intent fairly well. This is an attempt to 
solve a problem introduced by the use of address sharing. We have no 
illusion that the proposed solution is elegant. There certainly are 
issues associated with the approach, especially when applied by an 
in-path NAT device. That said, all potential solutions to this problem 
set have issues. The purpose of the I.D. is to help us better evaluate 
this specific proposed solution.

Regarding the representation of RFC6967, it was not our intent to 
indicate that the RFC "recommends" the TCP option over other options, 
nor to minimize the concerns raised about the approach in that RFC. I do 
think that "can be successfully applied to a broad range of use cases 
with limited performance impact" is a fair representation of the tcp 
option solution analysis in section 5 of RFC6967. All we're really 
trying to indicate is that the RFC seems to justify continued 
experimentation in order to better evaluate whether this approach adds 
enough value to outweigh the shortcomings. We'll attempt to clarify our 
intent in the next revision.

--Brandon

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 15 Jan 2014 22:37:30 +0000

Could the authors perhaps provide some additional explanation about this "continued experimentation" that is apparently planned with draft-williams-exp-tcp-host-id-opt? Personally, I do not follow any NAT work in the IETF, and this may apply to other TCPM contributors as well. So it seems to me like a valid question that could facilitate the discussion.

Regarding the overlay use case, I recall some explanation of draft-williams-overlaypath-ip-tcp-rfc on this list, but the option format now changed, and I wonder whether this change would affect experiments. (Also, enabling interoperable implementations in the Internet could require a specification of the content, which only draft-williams-overlaypath-ip-tcp-rfc provides.) 

Other potential use cases are apparently documented e.g. in draft-boucadair-intarea-host-identifier-scenarios-03, but this draft has expired, and it is basically a survey.

Given that all these topics are outside the typical focus of TCPM, I think it could be useful to provide some background to this group. Specifically, I wonder about pointers to running code and details regarding planned use of draft-williams-exp-tcp-host-id-opt in real-world experiments.

Thanks

Michael

________________________________________
Von: tcpm [[email-masked]]&quot; im Auftrag von &quot;Brandon Williams [[email-masked]]
Gesendet: Mittwoch, 15. Januar 2014 16:27
An: Joe Touch; Eggert, Lars; Wesley Eddy
Cc: [email-masked]
Betreff: Re: [tcpm] New Version Notification    for     draft-williams-exp-tcp-host-id-opt-00.txt

--Brandon

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Jan 2014 15:01:59 -0800

FWIW, some other suggestions:

	- the info should only be added by a party that changes the
	IP header anyway, e.g., a NAT, or by the origin host

	it MUST NOT be added or modified en-route by a party that does
	not modify the IP header

	- the info SHOULD correlate to the IP header change

	- the info MUST be advisory only; e.g., as an optimization

	this is because the info isn't authenticated or protected
	from other on-path modification

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Sat, 18 Jan 2014 23:04:43 -0500

>     from other on-path modification

I could almost agree to that, except I think this is a bit
beyond the typical NAT behavior (and potential harmfulness)
because it's assuming:

- there is actually room to add the option without impacting
  later use during the connection of other options
- adding this option doesn't conflict with any other options

Those points, I think, are troublesome for the general
approach, and in my opinion, make it difficult to get right
such that it won't ultimately create a headache N years later.

-- 
Wes Eddy
MTI Systems

---

From: Brandon Williams <[email-masked]>
Date: Tue, 21 Jan 2014 09:50:43 -0500

Yes, both the topics of continued experimentation and important use 
cases clearly need some discussion in the document. We will attempt to 
clarify both of these in the next version of the document. Since this 
option format is meant to be a unified replacement for the three 
previous independent specifications, it would probably also be good for 
us to add a section that describes how this option could be used to get 
the functionality of each of the three options that it replaces.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Tue, 21 Jan 2014 10:02:54 -0500

These points describe the intended use and add some needed clarity. 
Thanks for the suggestions.

We already intend to flesh out the security consideration section a bit, 
especially around the trust relationship between the sender and receiver 
(i.e. there is none, unless it's provided by a method outside of this 
I.D.) and the advisory nature of the option when used outside a context 
that provides trust guarantees.

I'm not completely certain what you mean by "SHOULD correlate to the IP 
header change". One of the options being replaced by this uses a 16-bit 
identifier instead of carrying the hidden info directly over from the 
ingress packets. The identifier would represent a NAT connection mapping 
for the life of the connection, but would not directly provide the 
client's address or port. Would this fit what you think of as 
correlating with the IP header change?

--Brandon

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 21 Jan 2014 15:29:03 +0000

As a side note, you may also want to consider what happens if the same packet hits two of the intended use cases at the same time. For instance, what happens if a residential NAT adds a host ID and the packet then gets routed over an overlay? Then the same option could appear twice in the packet, right? (If option space permits this.)

Michael

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2014 3:51 PM
> To: Scharf, Michael (Michael)
> Cc: [email-masked]
> Subject: Re: [tcpm] New Version Notification for draft-williams-exp-
> tcp-host-id-opt-00.txt
> 
> > Could the authors perhaps provide some additional explanation about
> this "continued experimentation" that is apparently planned with draft-
> williams-exp-tcp-host-id-opt? Personally, I do not follow any NAT work
> in the IETF, and this may apply to other TCPM contributors as well. So
> it seems to me like a valid question that could facilitate the
> discussion.
> >
> > Regarding the overlay use case, I recall some explanation of draft-
> williams-overlaypath-ip-tcp-rfc on this list, but the option format now
> changed, and I wonder whether this change would affect experiments.
> (Also, enabling interoperable implementations in the Internet could
> require a specification of the content, which only draft-williams-
> overlaypath-ip-tcp-rfc provides.)
> >
> > Other potential use cases are apparently documented e.g. in draft-
> boucadair-intarea-host-identifier-scenarios-03, but this draft has
> expired, and it is basically a survey.
> >
> > Given that all these topics are outside the typical focus of TCPM, I
> think it could be useful to provide some background to this group.
> Specifically, I wonder about pointers to running code and details
> regarding planned use of draft-williams-exp-tcp-host-id-opt in real-
> world experiments.
> >
> > Thanks
> >
> > Michael
> >

---

From: Brandon Williams <[email-masked]>
Date: Tue, 21 Jan 2014 10:51:24 -0500

I think we're in agreement about how difficult it may be to get this 
right in a NAT environment. The spec already attempts to call out some 
of the issues related to packet sizes and conflicts with other options, 
and we would be happy to get some feedback about those parts of the 
document, since improving the discussion of potential problems will be 
critical to further assessment of the effectiveness (or lack thereof) of 
the solution.

--Brandon

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Jan 2014 09:22:45 -0800

Hi, Wes (et al.),

Agreed - I'll go back to my first observation, though:

 >>> I agree it's ugly, but it seems that having NATs is
 >>> what creates the ugliness.

I.e., I appreciate the concern about on-path devices inserting/removing 
TCP options, but I'm sorry if I can't get all worked up about that 
compared to what NATs do.

IMO, if this is done in the same spirit as NATs, it could be as (un)safe.

E.g., one view of a NAT is that it completely violates E2E identities. A 
different view is that a NAT is really the true Internet endpoint, and 
it's providing a proxy function for devices behind it. I would say that 
the NAT is on the Internet, and the devices behind it have some access 
to some Internet services, but they're definitely NOT on the Internet.

So yes, this will be difficult to get right, but IMO if this is 
restricted to being manipulated by devices we *already* allow to modify 
IP addresses (e.g., sources and NATs), then it could be *as (un)safe* as 
NATs.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Jan 2014 09:37:09 -0800

Interactions with other options needs to be discussed, esp. impact on 
option order, processing order, and whether multiples of the same option 
are even permitted.

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 22 Jan 2014 00:49:15 -0800

Hi Brandon,

I personally have the following comments on the draft.

1: It seems to me that the option format might be too simple to accommodate
multiple proposals.
    I'm not very sure how the receiver can identify which proposal has been
used.

2: Section 4 seems to contain similar information on option usages which
described in other detailed proposals.
    Isn't it a bit redundant? Or, is there any conflicts between the usages
in the draft and other proposals?

3: It seems to me that this draft describe basic framework and more
detailed behavior and usages are described in each proposal. Can we proceed
this draft without checking detailed behavior in other drafts?

Thanks,
--
Yoshifumi

On Tue, Jan 21, 2014 at 7:51 AM, Brandon Williams <
[email-masked]> wrote:

> I think we're in agreement about how difficult it may be to get this right
> in a NAT environment. The spec already attempts to call out some of the
> issues related to packet sizes and conflicts with other options, and we
> would be happy to get some feedback about those parts of the document,
> since improving the discussion of potential problems will be critical to
> further assessment of the effectiveness (or lack thereof) of the solution.
>
> --Brandon
>
>

---

From: <[email-masked]>
Date: Fri, 31 Jan 2014 08:13:34 +0100

Dear Michael,

Good point. 

We had some text in the draft that governs that case: 

   o  The device may be configured to maintain any existing HOST_ID TCP
      option(s) in the received message, the device MUST NOT remove
      those instances of the option.  Furthermore, it MUST add a new
      HOST_ID TCP option while preserving the order of appearance in the
      message.  In particular, the local HOST_ID TCP option MUST appear
      as the last occurrence of the HOST_ID TCP option in the message.

We may consider adding an example to illustrate how it works (e.g., CGN + CDN use case).

Cheers,
Med

>Envoyé : mardi 21 janvier 2014 16:29
>À : Brandon Williams
>Cc : [email-masked]
>Objet : Re: [tcpm] New Version Notification for draft-williams-exp-tcp-
>host-id-opt-00.txt
>
>As a side note, you may also want to consider what happens if the same
>packet hits two of the intended use cases at the same time. For instance,
>what happens if a residential NAT adds a host ID and the packet then gets
>routed over an overlay? Then the same option could appear twice in the
>packet, right? (If option space permits this.)
>
>Michael
>
>
>

---

From: <[email-masked]>
Date: Fri, 31 Jan 2014 08:15:37 +0100

Hi Joe,

FWIW, the draft already include some text to discuss the interaction with other options: http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-00#section-5 

Comments and suggestions to enrich that section are more than welcome.

Cheers,
Med

>De : tcpm [mailto:[email-masked]] De la part de Joe Touch
>Envoyé : mardi 21 janvier 2014 18:37
>À : Scharf, Michael (Michael); Brandon Williams
>Cc : [email-masked]

---

From: <[email-masked]>
Date: Fri, 31 Jan 2014 08:34:10 +0100

Dear Yoshifumi,

Thank you for the comments.

Please see inline.
Cheers,
Med

De : tcpm [mailto:[email-masked]] De la part de Yoshifumi Nishida
Envoyé : mercredi 22 janvier 2014 09:49
À : Brandon Williams
Cc : [email-masked]
Objet : Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt

Hi Brandon,

1: It seems to me that the option format might be too simple to accommodate multiple proposals.
    I'm not very sure how the receiver can identify which proposal has been used.
[Med] We have discussed that point among authors and we decided to not include a field to indicate what information is carried in the HOST_ID field (e.g., IP address, port number, etc.) for following reasons:

·         Cases where only a single identifier is required are more common (i.e., the default behavior is to inject some bits of the internal IP address in the HOST_ID field).

·         Cases that require multiple identifiers to be included (e.g., source IP address:source port number, or a list of IP addresses) are those where the same administrative entity is managing the entity that injects the HOST_ID option and the one server that will make use of that option. A typical use case is the load-balancing scenario.
This point was recorded in the draft:

"Note, there is no need
   to signal the semantic of the included data as this specification
   assumes the service is aware of that information by out of band means
   (e.g. both the service and the address sharing device are managed by
   the same administrative entity).

"
The beauty of advancing this effort in the experimental track is to assess whether these assumptions are valid ones, identify whether there are use cases which require a means to explicitly indicate the semantic of the included data, etc.

2: Section 4 seems to contain similar information on option usages which described in other detailed proposals.
    Isn't it a bit redundant? Or, is there any conflicts between the usages in the draft and other proposals?
[Med] One of the goals of this document is to have a unified specification that would cover the use cases we have on the table. As such, this document is self-contained. An implementor can develop the option specified in this draft without reading the other proposals.

3: It seems to me that this draft describe basic framework and more detailed behavior and usages are described in each proposal. Can we proceed this draft without checking detailed behavior in other drafts?
[Med] See above.

Thanks,
--
Yoshifumi

On Tue, Jan 21, 2014 at 7:51 AM, Brandon Williams <[email-masked]<mailto:[email-masked]>> wrote:
I think we're in agreement about how difficult it may be to get this right in a NAT environment. The spec already attempts to call out some of the issues related to packet sizes and conflicts with other options, and we would be happy to get some feedback about those parts of the document, since improving the discussion of potential problems will be critical to further assessment of the effectiveness (or lack thereof) of the solution.

--Brandon

[email-masked]<mailto:[email-masked]>