diff mbox

extensions: libip6t_mh: Add translation to nft

Message ID 20160114174009.GA4252@gmail.com
State Changes Requested
Delegated to: Pablo Neira
Headers show

Commit Message

Shivani Bhardwaj Jan. 14, 2016, 5:40 p.m. UTC
Add translation for mobility header to nftables.

Examples:

$ sudo ip6tables-translate -A INPUT -p mh -j ACCEPT
nft add rule ip6 filter INPUT ip6 nexthdr mobility-header counter accept

$ sudo ip6tables-translate -A INPUT -p mh --mh-type 1 -j ACCEPT
nft add rule ip6 filter INPUT ip6 nexthdr mobility-header mh type 1 counter accept

$ sudo ip6tables-translate -A INPUT -p mh --mh-type 1:3 -j ACCEPT
nft add rule ip6 filter INPUT ip6 nexthdr mobility-header mh type 1-3 counter accept

Signed-off-by: Shivani Bhardwaj <shivanib134@gmail.com>
---
 extensions/libip6t_mh.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

Comments

Pablo Neira Ayuso Jan. 19, 2016, 8:50 p.m. UTC | #1
On Thu, Jan 14, 2016 at 11:10:09PM +0530, Shivani Bhardwaj wrote:
> Add translation for mobility header to nftables.
> 
> Examples:
> 
> $ sudo ip6tables-translate -A INPUT -p mh -j ACCEPT
> nft add rule ip6 filter INPUT ip6 nexthdr mobility-header counter accept
> 
> $ sudo ip6tables-translate -A INPUT -p mh --mh-type 1 -j ACCEPT
> nft add rule ip6 filter INPUT ip6 nexthdr mobility-header mh type 1 counter accept
> 
> $ sudo ip6tables-translate -A INPUT -p mh --mh-type 1:3 -j ACCEPT
> nft add rule ip6 filter INPUT ip6 nexthdr mobility-header mh type 1-3 counter accept

I think this translation will not work as the mobility header may not
be exactly the next header, in IPv6 you can get several extension
headers one after another.

By now I'd suggest:

... meta l4proto mobility-header mh type 1 counter

Anyway, the extension header expression needs some care, it would be
good to keep this documented in the wiki page.

While at this, it would be good if you can verify that our definition
in nftables matches rfc6275 (see nftables/src/exthdr.c), I already
detected wrong header definitions in the past.

It would be also good if you can go back to all your translations and
validate what we already got into the tree from the packet path, ie.
generate traffic that matches the rule in ip6tables and nftables. Note
sure if you made this checks.

Some of them should be easy to test, some other may take a while,
python scapy may help in some cases to forge and to inject a packet
with a specific layout.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/extensions/libip6t_mh.c b/extensions/libip6t_mh.c
index 686a293..55ce028 100644
--- a/extensions/libip6t_mh.c
+++ b/extensions/libip6t_mh.c
@@ -202,6 +202,26 @@  static void mh_save(const void *ip, const struct xt_entry_match *match)
 		printf(" --mh-type %u", mhinfo->types[0]);
 }
 
+static int mh_xlate(const struct xt_entry_match *match,
+		    struct xt_buf *buf, int numeric)
+{
+	const struct ip6t_mh *mhinfo = (struct ip6t_mh *)match->data;
+
+	if (mhinfo->types[0] == 0 && mhinfo->types[1] == 0xFF)
+		return 0;
+
+	if (mhinfo->types[0] != mhinfo->types[1])
+		xt_buf_add(buf, "mh type%s %u-%u ",
+			   mhinfo->invflags & IP6T_MH_INV_TYPE ? " !=" : "",
+			   mhinfo->types[0], mhinfo->types[1]);
+	else
+		xt_buf_add(buf, "mh type%s %u ",
+			   mhinfo->invflags & IP6T_MH_INV_TYPE ? " !=" : "",
+			   mhinfo->types[0]);
+
+	return 1;
+}
+
 static const struct xt_option_entry mh_opts[] = {
 	{.name = "mh-type", .id = O_MH_TYPE, .type = XTTYPE_STRING,
 	 .flags = XTOPT_INVERT},
@@ -220,6 +240,7 @@  static struct xtables_match mh_mt6_reg = {
 	.print		= mh_print,
 	.save		= mh_save,
 	.x6_options	= mh_opts,
+	.xlate		= mh_xlate,
 };
 
 void _init(void)