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

From: Joe Touch <[email-masked]>
Date: Sun, 02 Feb 2014 17:44:52 -0800

The section on TCP-AO is inaccurate; it includes a per-connection flag 
that determines whether TCP options are included. Use of this option is 
compatible with TCP-AO when that flag indicates not to include the 
options. The only problem would be when using the host ID *and* using 
NAT - but it's not the host ID that causes the issue, it's the NAT. Once 
an address is translated, all bets are off for any host ID coordination 
unless the same device that does the NAT inserts the host ID before 
doing NAT translation.

Also, there's an experimental variant of TCP-AO that supports NAT 
traversal that would further be compatible with the host ID, again fi 
the TCP options are not covered (rfc6978).

There ought to be an indication of order, both of the options and of the 
processing. TCP-AO must be processed first (otherwise its protection 
would be meaningless), even when it doesn't protect the remaining options.

I don't understand "to save space...[this option] can break 
word-alignment". You cannot override the definition of other options in 
this document unless this document updates those RFCs as well, and that 
is known and approved.

I don't know what this option even means in the presence of the 
(inaccurately named) multipath option. TCP considers IP addresses to be 
endpoints, and MPTCP allows more than one IP address as an endpoint. 
What happens if different IP addresses end up with different host IDs? 
How do you ensure this won't happen?

On 1/30/2014 11:15 PM, [email-masked] wrote:
> 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
>
>> -----Message d'origine-----
>> 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]
>> Objet : Re: [tcpm] New Version Notification for draft-williams-exp-tcp-
>> host-id-opt-00.txt
>>
>> 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
>>
>> On 1/21/2014 7:29 AM, Scharf, Michael (Michael) wrote:
>>> 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
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> 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
>>>>
>>>> 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
>>>>
>>>> On 01/15/2014 05:37 PM, Scharf, Michael (Michael) wrote:
>>>>> 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
>>>>>
>>>>> 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
>>>>>
>>>>> On 01/14/2014 05:56 PM, Joe Touch wrote:
>>>>>>
>>>>>>
>>>>>> On 1/14/2014 7:34 AM, Eggert, Lars wrote:
>>>>>>> On 2014-1-14, at 14:54, Wesley Eddy <[email-masked]> wrote:
>>>>>>>> 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.
>>>>>>>
>>>>>>> Fully agreed.
>>>>>>>
>>>>>>> Lars
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>>
>>>>>
>>>>> --
>>>>> Brandon Williams; Senior Principal Software Engineer
>>>>> Emerging Products Engineering; Akamai Technologies Inc.
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>
>>>>
>>>> --
>>>> Brandon Williams; Senior Principal Software Engineer
>>>> Emerging Products Engineering; Akamai Technologies Inc.
>>> _______________________________________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Sun, 02 Feb 2014 17:53:06 -0800

to avoid some potential ambiguity:

> The section on TCP-AO is inaccurate; it includes a per-connection flag

it= TCP-AO

> that determines whether TCP options are included. Use of this option is

this option = host-id

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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 3 Feb 2014 14:18:20 +0000

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

But what does the TCP receiver do in that case? How does it distinguish between the different HOST_ID types? Do you assume that the receiver exactly knows the ordering of middleboxes on the path? How?

I hope that nobody has deployed in the Internet a TCP proxy that shuffles the order of options - but do you know that for sure?

If the host identifier field inside the option needs another internal identifier for unique identification, this will be really a waste of option space.
 
Michael 

> We may consider adding an example to illustrate how it works (e.g., CGN
> + CDN use case).
> 
> Cheers,
> Med
> 
> >De : tcpm [mailto:[email-masked]] De la part de Scharf, Michael
> >(Michael)
> >Envoyé : mardi 21 janvier 2014 16:29
> >À : Brandon Williams
> >Cc : [email-masked]

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 03 Feb 2014 18:21:18 -0500

> I hope that nobody has deployed in the Internet a TCP proxy that shuffles the order of options - but do you know that for sure?

Shuffling the order of options is implemented by some people, and
they view it as a feature for raising the difficulty of OS
fingerprinting.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Mon, 03 Feb 2014 15:49:21 -0800

> they view it as a feature for raising the difficulty of OS

Maybe if we had a preferred order for the options, they couldn't be used 
for fingerprinting, and we wouldn't have this problem.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 4 Feb 2014 08:29:46 +0000

> > I hope that nobody has deployed in the Internet a TCP proxy that
> shuffles the order of options - but do you know that for sure?
> 

Thanks for the pointer! I haven't considered the fingerprinting issue.

Maybe it would be worthwhile do document these issues (something like "Guidelines for the Use of New TCP Options")? That could also be one way to document all the problems that result from adding (modifying) TCP options on the path, i.e., why this should be avoided as far as possible.

Just a thought...

Michael

---

From: Joe Touch <[email-masked]>
Date: Tue, 04 Feb 2014 11:38:34 -0800

On 1/21/2014 7:02 AM, Brandon Williams wrote:
> 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?

I mean that there are only two parties that should set this option - the 
one that sets the original IP address (source), or the one that changes 
that IP address *the first time* (first NAT). Everyone else is guessing 
or interfering.

Joe

>
> --Brandon
>
> On 01/17/2014 06:01 PM, Joe Touch wrote:
>> 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
>>
>> On 1/15/2014 7:27 AM, Brandon Williams wrote:
>>> 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
>>> nor to minimize the concerns raised about the approach in that RFC. I do
>>> experimentation in order to better evaluate whether this approach adds
>>> enough value to outweigh the shortcomings. We'll attempt to clarify our
>>>> AFAICT, this document's intent in using intermediate devices is to have
>>>> the NAT preserve some variant/derivative of the origin IP address/port
>>>> this, IMO a NAT doing this is different - it's more like cleaning up a
>>>> 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
>>>> I don't agree that this is either an elegant, appropriate, or necessary
>>>>       revealing the sending hosts's identifier (HOST_ID) information to
>>>> the
>>>>       receiver, which indicates that a solution using a TCP [RFC0793]
>>>> RFC6967 never says that the TCP solution can be successful in the way

---

From: Joe Touch <[email-masked]>
Date: Tue, 04 Feb 2014 11:41:21 -0800

On 2/4/2014 12:29 AM, Scharf, Michael (Michael) wrote:
> Maybe it would be worthwhile do document these issues (something
> like "Guidelines for the Use of New TCP Options")? That could also be
> one way to document all the problems that result from adding
> (modifying) TCP options on the path, i.e., why this should be avoided
> as far as possible.

Having had some students dive into them recently in both Linux and 
FreeBSD, the horrible state of current implementations is the bigger issue.

I.e., they don't reflect existing requirements in the order of 
processing, or even the way specific options implemented.

Until that's been cleaned up, there's not much point in diving deeper 
into what we should be doing that's better than existing specs.

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 10 Feb 2014 01:04:00 -0800

Hi Med,

Thanks for the clarification and sorry for slow response.

On Thu, Jan 30, 2014 at 11:34 PM, <[email-masked]> wrote:

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

I see...  I felt a bit uneasy for the great flexibility, but we can discuss
this later if this is an important point.

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

My concern is that for example, Section 5 in
draft-wing-nat-reveal-option-03 contains some kind of rules for the option
usage and Section 5 in draft-williams-overlaypath-ip-tcp-rfc-04 also
contains similar ones. If these information is different from what is
described in Section 4 of this draft, I think it will be confusing for
implementers. I think it would be good if other drafts don't have this kind
of info in order to avoid confusions.
I prefer if you can clarify which info should be written in this draft and
which should be written in other companion drafts.

Thanks,
--
Yoshifumi