On Wed, May 23, 2012 at 10:52 AM, Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> wrote: > > 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. Actually, this is not really how it works in the general case. The address advertisements are optional. A multihomed/multiaddressed host A can implicitly establish subflows with its addresses A1 and A2, and the other end host, B, can do it equally with its addresses B1 and B2, as far as new TCP connections are accepted in both directions. The advertisements exist for practical purposes and in the case of middleboxes preventing one host from establishing new subflows -- which are actually new TCP connections. An end-host receiving the ADD_ADDR advertisement will keep the new address in memory and try to establish the new subflow to that address only if it decides to. So, this is actually not something I care about right now. Well, after reading your answer, I realize I might not have been so clear about what I want (and actually, I'm not sure it was very clear in my own head at that time). Sorry. I am pretty sure I can't use the "expectation framework" as is since it requires one to expect a new connection from a known address/port combination. In the general case, these are unknown. The way SYN packets of new subflows are validated for acceptation is by verifying a token enclosed in it. What I have thought of, however, is to mark that SYN packet as "RELATED" (or NEW_SUBFLOW or anything) in a early stage at the packet reception and then have a rule to accept those packets. > > 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. As explained above, I can't use an "expectation" as is, anyway. However, I'd like to know if there is an easy way for "marking" a packet as RELATED (or NEW_SUBFLOW or whatever) without using that expectation system. The goal would be to be able to configure iptables like this: $ iptables -m conntrack --ctstate NEW_SUBFLOW -j ACCEPT By the way, if I understand well the conntrack match does the same and more than the state match. So if I had to implement this, I would have to modify the conntrack match, right? > 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. I'm not sure to understand well. In terms of iptables command line, it would give something like: $ iptables -m mptcp -j SUBFLOW_ACCEPT ? It looks to me that it wouldn't be very clean to have a target available only for a given match module. I'm not an advanced user of iptables so someone has probably something to tell me about that. A third possibility would be something like: $ iptables -m mptcp_state --state NEW_SUBFLOW -j ACCEPT which might (or not) allow avoiding messing with the connection tracking match. I think the first solution is cleaner and does not harm the security. But I'm not sure what is the best in the absolute, if it were to be accepted in the tree. What do you think? Thank you. -- Nicolas Maître -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
