Adding NAT64 to Netfilter

Adding NAT64 to Netfilter

[Alberto Leiva]

Hello

I've been working on Jool, an open source IP/ICMP translator for a
while ([0]). It currently implements SIIT, NAT64 and (if everything
goes according to plan) will later this year also support MAP-T. It
currently works both as a Netfilter module (hooking itself to
PREROUTING) or as an xtables target, and I'm soon going to start
integrating it into nftables.

Actually, it's the same software once advertised by this guy: [1]

Several people have approached me over the years expressing their
desire to have it integrated into the kernel by default. The intent of
this mail is to query whether a merge of Jool into the Netfilter
project woud be well-received. Of course, I'm willing to make
adjustments if needed.

Here are some justifications that have been listed to me. For the sake
of credit, these are all stolen from [2]:

1. IPv6 is getting significantly more exposure
2. NAT64 is getting more required / will be a default thing to do,
along with MAP-E/T
3. OpenBSD already has the functionality in pf
4. Enabling it upstream can potentially help IPv6 migration world wide

Thoughts?

[0] https://jool.mx
[1] https://marc.info/?l=netfilter-devel&m=136271576812278&w=2
[2] https://github.com/NICMx/Jool/issues/273#issuecomment-568721875

Re: Adding NAT64 to Netfilter

[Laura Garcia]

On Fri, Jan 3, 2020 at 7:10 PM Alberto Leiva <ydahhrk@gmail.com> wrote:
>
> Hello
>
> I've been working on Jool, an open source IP/ICMP translator for a
> while ([0]). It currently implements SIIT, NAT64 and (if everything
> goes according to plan) will later this year also support MAP-T. It
> currently works both as a Netfilter module (hooking itself to
> PREROUTING) or as an xtables target, and I'm soon going to start
> integrating it into nftables.
>

Hi Alberto, I was analyzing the impact to add support NAT64/46 several
months ago. It seems that you've done a very good job.

In regards to the iptables approach, do you have any benchmark
compared to the NAT in the same stack?

In regards to the nftables approach, do you mean to integrate the RFC
implementations natively into the nftables infrastructure?

Checking your code, it seems that you use several user space tools
(jool, joold) and a conntrack-like table to store the connection data.
As you know, in the nftables project it has been done a great effort
to avoid several tools for packet mangling so something natively like
the following would be probably required.

nft add table ip6 nat
nft add chain ip6 nat postrouting { type nat hook postrouting priority 100 \; }
nft add rule ip6 nat postrouting oif eth0 snat 1.2.3.4

More thorough study would be the possibility of supporting the
sessions in conntrack and conntrackd but, I believe a first approach
with stateless NAT from ingress could be a great achievement.

Cheers.


> Actually, it's the same software once advertised by this guy: [1]
>
> Several people have approached me over the years expressing their
> desire to have it integrated into the kernel by default. The intent of
> this mail is to query whether a merge of Jool into the Netfilter
> project woud be well-received. Of course, I'm willing to make
> adjustments if needed.
>
> Here are some justifications that have been listed to me. For the sake
> of credit, these are all stolen from [2]:
>
> 1. IPv6 is getting significantly more exposure
> 2. NAT64 is getting more required / will be a default thing to do,
> along with MAP-E/T
> 3. OpenBSD already has the functionality in pf
> 4. Enabling it upstream can potentially help IPv6 migration world wide
>
> Thoughts?
>
> [0] https://jool.mx
> [1] https://marc.info/?l=netfilter-devel&m=136271576812278&w=2
> [2] https://github.com/NICMx/Jool/issues/273#issuecomment-568721875

Re: Adding NAT64 to Netfilter

[Laurent Fasnacht]

[-- Attachment #1.1: Type: text/plain, Size: 693 bytes --]

Hello,

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, January 3, 2020 7:09 PM, Alberto Leiva <ydahhrk@gmail.com> wrote:

> Hello
> 

> I've been working on Jool, an open source IP/ICMP translator for a
> while ([0]). It currently implements SIIT, NAT64 and (if everything
> goes according to plan) will later this year also support MAP-T. It
> currently works both as a Netfilter module (hooking itself to
> PREROUTING) or as an xtables target, and I'm soon going to start
> integrating it into nftables.

That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible.

Cheers,

Laurent
ProtonVPN R&D

[-- Attachment #1.2: publickey - lf@o-t.ch - 0x0007104B.asc --]
[-- Type: application/pgp-keys, Size: 631 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 217 bytes --]

Re: Adding NAT64 to Netfilter

[Alberto Leiva]

Hi!

> In regards to the iptables approach, do you have any benchmark
> compared to the NAT in the same stack?

I think we do, but they are old to the point of pointlessness. But we
can allocate some testing efforts in February, if you would confirm
the desirability of this information.

> In regards to the nftables approach, do you mean to integrate the RFC
> implementations natively into the nftables infrastructure?

I would say "yes," but I'm not sure we mean the same thing.

Jool is currently a box of translating code that interfaces with the
kernel by way of wrappers.

ie. The Netfilter wrapper receives packets by registering itself to
nf_register_hooks(), and the iptables wrapper receives packets by
registering itself to xt_register_targets().

What I mean by integrating Jool into nftables is to create a wrapper
that would receive packets by means of something like
nft_register_expr(). (I'm not entirely sure this is what I'm supposed
to do because I haven't started analyzing this task yet. But that
would be my starting point.)

Does this answer your question?

> Checking your code, it seems that you use several user space tools
> (jool, joold) and a conntrack-like table to store the connection data.
> As you know, in the nftables project it has been done a great effort
> to avoid several tools for packet mangling so something natively like
> the following would be probably required.

I'm not averse to the idea of adapting code to fulfill the standards
of the Netfilter project. Jool's core itself has naturally changed
substantially over the years to account for emerging RFCs and feature
requests. It wouldn't be my first major overhaul.

But I admit I don't presently understand how things like the EAM table
([0] [1]) are meant to fit in this model.

(Then again, I don't know much about nftables just yet.)

[0] https://jool.mx/en/eamt.html
[1] https://jool.mx/en/usr-flags-eamt.html

> That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible.

Thank you! :)

On Tue, Jan 7, 2020 at 8:14 AM Laurent Fasnacht <lf@o-t.ch> wrote:
>
> Hello,
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, January 3, 2020 7:09 PM, Alberto Leiva <ydahhrk@gmail.com> wrote:
>
> > Hello
> >
>
> > I've been working on Jool, an open source IP/ICMP translator for a
> > while ([0]). It currently implements SIIT, NAT64 and (if everything
> > goes according to plan) will later this year also support MAP-T. It
> > currently works both as a Netfilter module (hooking itself to
> > PREROUTING) or as an xtables target, and I'm soon going to start
> > integrating it into nftables.
>
> That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible.
>
> Cheers,
>
> Laurent
> ProtonVPN R&D

Re: Adding NAT64 to Netfilter

[Alberto Leiva]

Hi

I have a working prototype of a Jool wrapper for the nftables
framework. Details can be found here: [0]. Of course, it's not the
full integration you're hoping for (the rules simply send packets to a
Jool instance, in accordance to the current model), but it should keep
users happy while the transition happens.

However, I noticed that nft is not extensible (like iptables), so I
need to provide a custom nft build ([1][2]) instead of a plugin. I
don't think it's viable to expect my more casual users to build nft if
they need cooperation between Jool and nftables, thus I believe I need
to propose a merge of this early code into the nftables project.

Is this acceptable?

[0] https://github.com/NICMx/Jool/issues/285#issuecomment-575400539
[1] https://github.com/ydahhrk/nftables
[2] https://github.com/ydahhrk/libnftnl

On Tue, Jan 7, 2020 at 5:09 PM Alberto Leiva <ydahhrk@gmail.com> wrote:
>
> Hi!
>
> > In regards to the iptables approach, do you have any benchmark
> > compared to the NAT in the same stack?
>
> I think we do, but they are old to the point of pointlessness. But we
> can allocate some testing efforts in February, if you would confirm
> the desirability of this information.
>
> > In regards to the nftables approach, do you mean to integrate the RFC
> > implementations natively into the nftables infrastructure?
>
> I would say "yes," but I'm not sure we mean the same thing.
>
> Jool is currently a box of translating code that interfaces with the
> kernel by way of wrappers.
>
> ie. The Netfilter wrapper receives packets by registering itself to
> nf_register_hooks(), and the iptables wrapper receives packets by
> registering itself to xt_register_targets().
>
> What I mean by integrating Jool into nftables is to create a wrapper
> that would receive packets by means of something like
> nft_register_expr(). (I'm not entirely sure this is what I'm supposed
> to do because I haven't started analyzing this task yet. But that
> would be my starting point.)
>
> Does this answer your question?
>
> > Checking your code, it seems that you use several user space tools
> > (jool, joold) and a conntrack-like table to store the connection data.
> > As you know, in the nftables project it has been done a great effort
> > to avoid several tools for packet mangling so something natively like
> > the following would be probably required.
>
> I'm not averse to the idea of adapting code to fulfill the standards
> of the Netfilter project. Jool's core itself has naturally changed
> substantially over the years to account for emerging RFCs and feature
> requests. It wouldn't be my first major overhaul.
>
> But I admit I don't presently understand how things like the EAM table
> ([0] [1]) are meant to fit in this model.
>
> (Then again, I don't know much about nftables just yet.)
>
> [0] https://jool.mx/en/eamt.html
> [1] https://jool.mx/en/usr-flags-eamt.html
>
> > That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible.
>
> Thank you! :)
>
> On Tue, Jan 7, 2020 at 8:14 AM Laurent Fasnacht <lf@o-t.ch> wrote:
> >
> > Hello,
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, January 3, 2020 7:09 PM, Alberto Leiva <ydahhrk@gmail.com> wrote:
> >
> > > Hello
> > >
> >
> > > I've been working on Jool, an open source IP/ICMP translator for a
> > > while ([0]). It currently implements SIIT, NAT64 and (if everything
> > > goes according to plan) will later this year also support MAP-T. It
> > > currently works both as a Netfilter module (hooking itself to
> > > PREROUTING) or as an xtables target, and I'm soon going to start
> > > integrating it into nftables.
> >
> > That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible.
> >
> > Cheers,
> >
> > Laurent
> > ProtonVPN R&D