netdev - Re: MPTCP: TCP-option or "experimental option"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sun, 05 Feb 2012 11:21:34 +0100
From:	Christoph Paasch <christoph.paasch@...ouvain.be>
To:	Eric Dumazet <eric.dumazet@...il.com>,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: MPTCP: TCP-option or "experimental option"

(cc-ing netdev and Ilpo)

On 02/05/2012 10:49 AM, Eric Dumazet wrote:
> Le dimanche 05 février 2012 à 10:05 +0100, Christoph Paasch a écrit :
>> Hello David & Eric,
>>
>> the MPTCP working-group at the IETF is about to finalize the protocol
>> specification. As MPTCP is currently not yet in Standards-Track, one
>> point of discussion is wheter we should request IANA for an early
>> assignment of a permanent TCP-option number or rather use the
>> experimental option with a "magic number" as described by
>> draft-ietf-tcpm-experimental-options-00
>>
>> My question is, whether the use of the experimental option would be a
>> blocker for upstream inclusion of our MPTCP-implementation? Especially,
>> as we then would have a hybrid situation as soon as MPTCP receives a
>> permanent TCP-option number.
>>
>>
> 
> Hi Christoph
> 
> Your question reminds me the TCPOPT_COOKIE still using 253, even in RFC
> 6013...

Oh... Is there any plan on how to handle this, as soon as TCP-cookies
receives a "real" option-number?
Because there will be a situation where one implementation (using the
new number) cannot talk to the other one (using 253).

> Using an experimental option tends to stay as is a long time...

Yes, probably...

> Adding a magic number consumes a lot of space in tcp option space, so it
> will be hard to use SACK + timestamps + MPTCP_with_magic_number ?

Yes. MPTCP is already using quite a lot of option-space. The
magic-number would make it even worse and give even less space for
SACK-blocks.

> Apparently, IANA is reluctant to consume some values on the ~200
> remaining values of tcp options ?

tcpcrypt is using two unassigned numbers in their implementation (as we
do for MPTCP ;) ).
This has been critized in an e-mail thread on tsvwg
(http://www.ietf.org/mail-archive/web/tsvwg/current/msg10957.html)

Upon this, a first draft has been proposed
(http://www.ietf.org/mail-archive/web/tcpm/current/msg06653.html),
resulting later-on in draft-ietf-tcpm-experimental-options-00 .

> How long does it take to get an official value from IANA ?

I don't think the problem is the time it takes to get this value (it
should not take very long).
The problem is rather, if there are compelling arguments for an early
assignment of an official value.
I fear that if the working-group concludes on the experimental option,
we have to wait for MPTCP going into standards-track before receiving an
official number. And going the standards-track may still take a lot of time.

Personally, I would prefer to see MPTCP receiving an official TCP-option.

But my opinion doesn't really matter for the question if you guys at
netdev are for or against including code using this experimental option.
Especially due to the problem of this hybrid situation to support
interoperability among the kernel-versions.

Cheers,
Christoph

-- 
Christoph Paasch
PhD Student

IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
Université Catholique de Louvain
-- 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html