Subject: [Softwires] RFC7597/9 MAP and iptables/netfilter

From: Richard Patterson <[email-masked]>
Date: Thu, 15 Feb 2018 14:47:40 +0000

Hi All,

Apologies, I was unsure on if this belonged in v6ops, softwires or
elsewhere, but I'll start here.

I've been putting MAP-T through its paces in our lab recently, using
OpenWRT/LEDE as the MAP CE, and have come across a slight issue with
how things are currently implemented.
When using a BMR that overloads a subscriber's IPv4 address, and
allocates each subscriber multiple port sets, OpenWRT currently
instantiates iptables SNAT rules for each port set.

Problem is, netfilter doesn't consider the current conntrack session
state when it's evaluating the rules.  The result is that the first
matching rule is always used, and if all sports in that port set are
consumed, then any new flows are dropped.

Now I don't consider this to be an OpenWRT implementation issue, and I
doubt it will be considered a bug in netfilter either, as I believe
it's known and expected behaviour.
At best I think it's a netfilter feature/enhancement request to be
able to fully support RFC7597/9.

As far as I see it, the mitigations are:
* Use BMRs that assign only a single contiguous port set to each subscriber
* Feature request over on the Netfilter Bugzilla (
https://bugzilla.netfilter.org/show_bug.cgi?id=1227 ) to consider
conntrack sessions before SNATting
* Create specific SNAT rules that match original sport range to the
same outside sport range, and then have a catch-all rule at the end.
(Bit of a kludge and won't stop the catch-all getting overloaded)

Can anyone else think of a better approach to the iptables ruleset, or
even better is anyone in this WG a Netfilter dev?

-Richard

---

From: Ian Farrer <[email-masked]>
Date: Fri, 16 Feb 2018 12:18:17 +0100

Hi Richard,

Please see inline.

Thanks,
Ian

> On 15 Feb 2018, at 15:47, Richard Patterson <[email-masked]> wrote:
> 
> Hi All,
> 

[if - A driver for PSID mechanism is the ability to algorithmically exclude ports 0-1023 from allocation to a client. A BMR that defines a single port range has ‘offset=0’, and so PSID=0 will contain all (or a portion, depending on sharing ratio) of the well-known ports. If this is not  a problem for your clients, then this could be a solution.

Another possibility to make this work would be if it is possible to prevent the v6 prefix which maps to PSID=0 for each IPv6 address  from allocation to a client (e.g. via the DHCPv6 server).

One final suggestion here is that depending on what you’re available address blocks and desired sharing ratios are, you could define the map domain to try and maximise the value of M (RFC7597 Appendix), while keeping the offset a-bits at 6. This will give clients the largest possible contiguous block of ports to use for snat, but the overhead in wasted (either excluded from use by the algorithm, or not being used due to the problem you describe) is going to be high.]

> conntrack sessions before SNATting

[if - I don’t have any personal experience here, but it’s certainly worth a try. I guess it might take a while before something come out of it though]

> (Bit of a kludge and won't stop the catch-all getting overloaded)

[if - The catch-all is the problem here as for any useful sharing ratio, the bulk of outgoing s-ports will be in the catch-all. Another approach might be to map a larger range of outgoing s-ports to the smaller range of external s-ports - e.g. with a 64:1 sharing ratio, offset 6, there will be 63 blocks of 4 external ports allocated, so if original sport 0-1023 SNAT to 1024-1027, 1024-2047 to 2048-2051 etc. (you would need to do something like 63488-25535 at the end)]

> even better is anyone in this WG a Netfilter dev?

[if - Not to my knowledge, but if there is anyone, then please shout!]

> 
> -Richard
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Richard Patterson <[email-masked]>
Date: Fri, 16 Feb 2018 18:07:26 +0000

> One final suggestion here is that depending on what you’re available address blocks and desired sharing ratios are, you could define the map domain to try and maximise the value of M (RFC7597 Appen…

The first option is what I'm currently leaning towards, although your
final suggestion isn't a bad idea either. If we can dimension the
blocks sufficiently at the required ratio, and just overlook the
wastage.

I did notice something else interesting in the Netfilter/iptables
documentaiton today though.  It appears as though up to kernel
2.6.11-rc1, it did have the ability to utilise multiple SNAT source
address ranges (and presumably ports):

""" In  Kernels up to 2.6.10, you can add several --to-source options.
For those kernels, if  you  specify more  than  one  source  address,
either via an address range or multiple --to-source options, a simple
round-robin  (one  after another  in  cycle)  takes place between
these addresses.  Later Kernels (>=  2.6.11-rc1)  don't  have  the
ability  to  NAT  to multiple ranges anymore. """

Might see if I can track that commit down to find out what happened.

-Richard