Subject: [tcpm] TR: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt

From: <[email-masked]>
Date: Tue, 11 Feb 2014 14:06:09 +0100

Dear all,

This version tries to address most of the comments received so far. 

A diff to check the main changes is available at: http://www.ietf.org/rfcdiff?url2=draft-williams-exp-tcp-host-id-opt-01. 

If you think your issue is not well covered in the new version, please let us know.

Comments and reviews are more than welcome.

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 11 février 2014 14:01
À : [email-masked]
Objet : I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Experimental Option for TCP Host Identification
        Authors         : Brandon Williams
                          Mohamed Boucadair
                          Dan Wing
	Filename        : draft-williams-exp-tcp-host-id-opt-01.txt
	Pages           : 9
	Date            : 2014-02-11

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-williams-exp-tcp-host-id-opt-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 11 Feb 2014 20:01:31 +0000

I wonder where the document discusses how to deal with multiple occurrences of the option, possibly in combination with middleboxes that reorder the options, as discussed on the list.

As a side note, I am not sure if I understand the new sentence "The HOST_ID option MUST NOT be added or modified en-route by any device that does not modify the IP header or the transport header". What about devices that modify the TTL value and/or ECN bits in the IP header?

Michael

________________________________________
Von: tcpm [[email-masked]]&quot; im Auftrag von &quot;[email-masked] [[email-masked]]
Gesendet: Dienstag, 11. Februar 2014 14:06
Bis: [email-masked]
Betreff: [tcpm] TR: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt

Dear all,

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 11 février 2014 14:01
À : [email-masked]
Objet : I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt

Abstract:

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Feb 2014 12:12:03 -0800

On 2/11/2014 12:01 PM, Scharf, Michael (Michael) wrote:
> I wonder where the document discusses how to deal with multiple
> occurrences of the option, possibly in combination with middleboxes
> that reorder the options, as discussed on the list.
>
> As a side note, I am not sure if I understand the new sentence "The
> HOST_ID option MUST NOT be added or modified en-route by any device that
> does not modify the IP header or the transport header". What about
> devices that modify the TTL value and/or ECN bits in the IP header?

Only devices that modify the existing identity have any business setting 
the option identity.

I.e., they need to modify TCP ports and/or IP addresses to have any 
reason to modify the HOST_ID option.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 11 Feb 2014 23:12:55 -0500

On 2/11/2014 3:01 PM, Scharf, Michael (Michael) wrote:
> HOST_ID option MUST NOT be added or modified en-route by any device 
> that does not modify the IP header or the transport header". What 
> about devices that modify the TTL value and/or ECN bits in the IP 
> header?
> 

It's at least half a tautology, since (by definition) anything that adds
or modifies the option is modifying the transport header that the option
is a part of. :)

I think instead of "header" it should just be talking about the address
and port fields (just like Joe mentioned).

That said, I looked at the changes in the draft, and don't have any real
comments.

On the topic of WG adoption, I'm not sure why that's needed. The I-D
exists in the repository, and the ExID is registered ... anyone can go
play with it. What value is an additional RFC beyond the I-D at this point?

I say that because while it's nicely written, I don't think the IETF
should publish a consensus document about hacking little things into TCP
headers via middleboxes so that other layers can cope. It doesn't solve
problems with TCP nor problems that TCP causes; the TCP header is just a
convenient place to stash the bits. This is not something that any
amount of edits to the document are going to alter :).

That said, if there was a significant mass of the vendors that insist on
doing this stuff in their products, then it's definitely better to have
the spec for it done here, ***assuming*** they would actually converge
on it and not do N different things in conjunction.  The middisc draft
is a good example ... it made sense to do because several vendors all
said they could and would move to the common format / option number.  I
don't know whether that's the case here or not.

-- 
Wes Eddy
MTI Systems

---

From: <[email-masked]>
Date: Wed, 12 Feb 2014 09:50:04 +0100

Hi Michael,

Please see inline.
Cheers,
Med

>De : Scharf, Michael (Michael) [mailto:[email-masked]]
>Envoyé : mardi 11 février 2014 21:02
>À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
>Objet : Re: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt
>
>I wonder where the document discusses how to deal with multiple occurrences
>of the option, possibly in combination with middleboxes that reorder the
>options, as discussed on the list.
[Med] Three points were raised: (1) the order of appearance, (2) middleboxes changing the order of options, and (3) the processing order when TCP-AO is used. 

(1) is covered in the text: 

"
The device MUST be configured with the behavior to follow when a HOST_ID TCP option is already present in the message:
[..]
 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. "

(2) This point was not recorded in the -01. Thanks for catching this. I suggest to add this NEW text:

         Note: Because the order of appearance of TCP options may be
         modified by some middleboxes, deployments relying on
         manipulating multiple occurrences of the HOST_ID option may
         experience some complications.  These complications can be
         soften if the devices injecting HOST_ID options belong the same
         administrative domain.  The administrative entity managing that
         domain should ensure involved middleboxes do not alter the
         order of TCP options.

(3) This sentence was added to the -01 to recall the recommended behavior:

"   As specified in [RFC5925], TCP-AO must be the first TCP option
   processed on incoming segments. " 

>
>As a side note, I am not sure if I understand the new sentence "The HOST_ID
>option MUST NOT be added or modified en-route by any device that does not
>modify the IP header or the transport header". What about devices that
>modify the TTL value and/or ECN bits in the IP header?
[Med] Only devices modifies IP addresses and/or TCP ports are allowed to inject the HOST_ID option. The NEW text is now:

"The HOST_ID option MUST NOT
   be added or modified en-route by any device that does not modify IP
   addresses and/or TCP port numbers."

Better?
 
>Von: tcpm [[email-masked]]&quot; im Auftrag von
>&quot;[email-masked] [[email-masked]]
>A diff to check the main changes is available at:
>http://www.ietf.org/rfcdiff?url2=draft-williams-exp-tcp-host-id-opt-01.
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 12 Feb 2014 09:39:16 +0000

On 2014-2-12, at 5:12, Wesley Eddy <[email-masked]> wrote:
> I don't think the IETF

Agree with Wes.

Lars

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 12 Feb 2014 10:12:18 +0000

> don't know whether that's the case here or not.

+1 on all

Michael (chair hat off)

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 12 Feb 2014 10:25:40 +0000

> occurrences
> [Med] Three points were raised: (1) the order of appearance, (2)
> middleboxes changing the order of options, and (3) the processing order
> when TCP-AO is used.
> 
> The device MUST be configured with the behavior to follow when a
> HOST_ID TCP option is already present in the message:
> [..]

Well, that may be possible inside one administrative domain, but my understanding so far was is the option shall also be used in the Internet, right?

In the Internet, there is no easy way to know what middleboxes exist. A good protocol design would better try to be robust. In particular, if the use case is left open.

>    processed on incoming segments. "

I don't know whether this is indeed implemented today this way.

> HOST_ID
> [Med] Only devices modifies IP addresses and/or TCP ports are allowed
> to inject the HOST_ID option. The NEW text is now:
> 

At least this seems what you want to state.

Michael

> >If you think your issue is not well covered in the new version, please
> let
> >us know.
> >

---

From: <[email-masked]>
Date: Wed, 12 Feb 2014 13:21:22 +0100

Re-,

Please see inline.

Cheers,
Med

>Envoyé : mercredi 12 février 2014 11:26
>Objet : RE: I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt
>
>Well, that may be possible inside one administrative domain, but my
>understanding so far was is the option shall also be used in the Internet,
>right?
[Med] Yes, but the note above is specific to the case where ** multiple ** HOST_ID options are received in packet. 

>
>In the Internet, there is no easy way to know what middleboxes exist.

[Med] That's why the NEW text recommend to maintain multiple options only within the same administrative domain; otherwise only one occurrence should be used. 

 A
>good protocol design would better try to be robust.

[Med] Agree.

---

From: <[email-masked]>
Date: Wed, 12 Feb 2014 13:41:41 +0100

Dear Wes,

Please see inline.

Cheers,
Med

>De : Wesley Eddy [mailto:[email-masked]]
>Envoyé : mercredi 12 février 2014 05:13
>À : Scharf, Michael (Michael); BOUCADAIR Mohamed IMT/OLN; [email-masked]
>Objet : Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt
>

[Med] Will be fixed in the next revision.

>play with it. What value is an additional RFC beyond the I-D at this point?

[Med] There is a real value in having a unified approach and a specification reviewed by tcp experts. The document is intended to be published in the experimental track; just like many other RFCs produced by the IETF. Having a unified format is important for interoperability. 

>
>I say that because while it's nicely written,

[Med] Thanks.

 I don't think the IETF
>convenient place to stash the bits.

[Med] The issue is the presence of NATs...that manipulate ports numbers... which belong to the transport layer. There are already IETF documents that specify how to convey IP addresses in TCP options (mptcp). Unlike mptcp, the HOST_ID is not used to initiate any TCP connection, but it helps TCP servers to enforce polices and demux clients sharing the same IP address. The proposed solution does not introduce new harms but tries to solve many induced by address sharing (see http://tools.ietf.org/search/rfc6269). 

 This is not something that any
>don't know whether that's the case here or not.

[Med] This document is by itself a unified format of three existing proposals.

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Feb 2014 08:27:19 -0800

>> amount of edits to the document are going to alter :).

While I agree with the primary point, IMO if we restrict HOST_ID to 
being used only by boxes that already alter the endpoint identifier, 
we're dealing with a problem that NATs create.

Yes, I feel that the above is true, and wish we had never published 
anything about NATs except "they're a violation of the Internet 
architecture", but that's not where we are.

So Wes's second point is more where I am:

>> on it and not do N different things in conjunction.

Rather than assume they'll converge, let's perhaps at least start by 
giving them a spec that can serve as the focus of that convergence.

Otherwise they'll "fix" this in a lot of other, potentially more 
damaging ways.

Joe

---

From: Brandon Williams <[email-masked]>
Date: Wed, 12 Feb 2014 14:30:52 -0500

> don't know whether that's the case here or not.

Your comment about multiple vendors implementing different mechanisms is 
precisely why we would like to get this I.D. published as an RFC, and 
also why we would like to get a broader consensus within the tcpm 
working group on the draft. Although the three of us are in agreement 
about the value of using a common format, we think that getting the I.D. 
published will encourage any other vendors who see the need for such an 
option to use the common format and abide by the common usage 
guidelines. This argument also applies to our desire for WG adoption. 
Although the IESG approval process allows the possibility of publishing 
an experimental RFC as an independent submission, we think that WG 
adoption would help to limit the likelihood of redundant options.

Of course, the process of at least attempting to move toward WG adoption 
also has a value, in that I think it encourages some people on the list 
to comment on the I.D. when they otherwise would not have. We're getting 
that benefit already, regardless of whether or not we eventually get WG 
consensus.

--Brandon

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

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 12:57:20 +0100

Dear all,

In addition to the three proposals already quoted in the draft, there is also this implementation: http://www.inet.no/dante/doc/1.4.x/config/hostid.html. It relies on another proprietary extension.

Cheers,
Med

>De : tcpm [mailto:[email-masked]] De la part de Brandon Williams
>Envoyé : mercredi 12 février 2014 20:31
>À : [email-masked]

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 14 Feb 2014 14:01:02 +0000

Hi Med,

Thanks a lot for the pointer. I was not aware of that.

Given my lack of understanding, some questions: Would this implementation probably use a TCPM standard if TCPM started to work on an option? Would the implementers contribute to TCPM, e.g., by reviews and feedback? Does this implementation require interoperability with other implementations?

Thanks

Michael

________________________________________
Von: tcpm [[email-masked]]&quot; im Auftrag von &quot;[email-masked] [[email-masked]]
Gesendet: Freitag, 14. Februar 2014 12:57
An: Brandon Williams; [email-masked]
Betreff: Re: [tcpm] I-D Action: draft-williams-exp-tcp-host-id-opt-01.txt

Dear all,

Cheers,
Med

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 16:05:39 +0100

Re-,

In fact they support the HOST_ID option in two implementations (a SOCKS proxy and a port bouncer). The second one is available at: http://www.inet.no/barefoot/doc/1.4.x/config/hostid.html. 

I cannot speak on their behalf, but I can get in touch with Karl'Andre and invite him to react in the list.

Cheers,
Med

>Envoyé : vendredi 14 février 2014 15:01
>À : BOUCADAIR Mohamed IMT/OLN; Brandon Williams; [email-masked]
>Given my lack of understanding, some questions: Would this implementation
>probably use a TCPM standard if TCPM started to work on an option? Would
>the implementers contribute to TCPM, e.g., by reviews and feedback? Does
>this implementation require interoperability with other implementations?
>
>Thanks
>
>Michael
>
>
>In addition to the three proposals already quoted in the draft, there is
>also this implementation:
>http://www.inet.no/dante/doc/1.4.x/config/hostid.html. It relies on another
>proprietary extension.
>
>Cheers,
>Med
>