Re: Using RELATED for a level4 protocol (MPTCP)

[Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>]

On Tue, 22 May 2012, Nicolas Maître wrote:

> I'm a complete newbie in netfilter hacking and I'm trying to implement
> the support of MPTCP [0] (standing for MultiPath TCP) in netfilter in
> the context of a master's thesis.
> 
> I'll just summarize some points of MPTCP here to get a chance to be
> understood with my request.
> MPTCP is an extension of TCP which enables it to use multiple paths as
> part of a single "MPTCP connection", answering to a multihoming and
> performance demand. It acts as a higher-level, using TCP connections
> as subflows and it has been designed to be backward-compatible with
> regular TCP.
> It exposes a similar interface to TCP to the application layer. A
> figure might help to get the whole thing:
> 
>        +-------------------------------+
>        |           Application         |
>        +-------------------------------+
>        |             MPTCP             |
>        + - - - - - - - + - - - - - - - +
>        | Subflow (TCP) | Subflow (TCP) |
>        +-------------------------------+
>        |       IP      |      IP       |
>        +-------------------------------+
> (If you cannot read it properly, the 2 figures in this mail are taken
> from [0] where they are displayed correctly with a monospace font).
> 
> It's currently being standardized by the IETF.
> Furthermore, a Linux implementation is already available and working fine [1].
> 
> Now, what I'd like some help with is for the handling of additional
> subflows.  Here is a figure to illustrate the setup of an additional
> subflow.
> 
>               Host A                                  Host B
>      ------------------------                       ----------
>      Address A1    Address A2                       Address B1
>      ----------    ----------                       ----------
>          |             |                                |
>          |             | SYN + MP_CAPABLE               |
> Initial subflow negotiation
>          |--------------------------------------------->|
>          |<---------------------------------------------|
>          |          SYN/ACK + MP_CAPABLE(Key-B)         |
>          |             |                                |
>          |        ACK + MP_CAPABLE(Key-A, Key-B)        |
>          |--------------------------------------------->|
>          |             |                                |
>          |             |   SYN + MP_JOIN(Token-B, R-A)  |
> Additional subflow
>          |             |------------------------------->|
>          |             |<-------------------------------|
>          |             |  SYN/ACK + MP_JOIN(MAC-B, R-B) |
>          |             |                                |
>          |             |      ACK + MP_JOIN(MAC-A)      |
>          |             |------------------------------->|
>          |             |                                |
> 
> As subflows are negotiated (and authenticated) with an option in a
> regular TCP handshake, I'd like to know if there is currently a simple
> way of accepting new subflow packets with netfilter.
> Specifically, I thought of handling the MP_JOIN with a kind of
> conntrack's RELATED state. Indeed, the first packet of the MP_JOIN
> step can be "expected" and verified to be originating from the same
> host than the initial subflow.

As far as I see, after the hosts advertised their addresses (which can 
later be updated) any one of them may initiate a subflow to the possible 
advertised addresses/ports of the other side.

There are two possibilities:

a. conntrack helper: Whenever an address advertisement is detected,
   a corresponding expectation is created. It's not very nice that
   the expectation may never be used and thus created unnecessarily.
b. mptcp target and match: The target keeps record of 
   the ids/addresses/ports from the advertisements. New subflows
   can be allowed by the match, which searches for a match in the
   pool of the id/address/port entries.

The target/match looks nicer and thus one could have a little bit firmer 
grasp on the protocol - it looks quite easy to force opening up any 
address/port by the firewall if MPTCP is blindly accepted.
 
> After inspection of the code, I doubt that this would be possible as
> the expectation setup takes the ip addresses and ports as parameters.
> I therefore assume that the whole expectation system is only usable
> for protocols on the application level?
> Could you confirm that it's not the good way to go?
> But then, do you see any tool in the framework that would be helpful
> to me? Or give me some advices/pointers to integrate this in an
> elegant way into netfilter ?
> 
> In advance, thank you!
> 
> 
> [0] http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-07
> [1] http://mptcp.info.ucl.ac.be/

Best regards,
Jozsef
-
E-mail  : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary