Integer match in filter rule set

[gdamore]

With the introduction of nanomsg (nng) over ZeroTier (see the zerotier branch of the github.com/nanomsg/nng repo) it is desirable that zerotier's filter rules have the ability to filter on the "nn" port numbers and protocol. Given that ZT's filter rules only know about IP (and a few other L3 protocols, like IPv6 and ARP), we will need to either add a generic facility or specific knowledge of nanomsg's ZT transport to ZT itself.

Note that our L2 protocol has specific things set at fixed offsets. For example the 24-bit source and destination ports are located at fixed offsets 5 and 9 of the L2 payload.

We think that while a richer, more generic filtering capability would be nice (with selectable offsets, sizes, bitmasks, and endianness attributes), this would be a fair amount of work (even though still stateless).

Per discussion with @janjaapbos we think it may be simpler to add support for a couple of new keywords in the filtering language (perhaps "nnproto", "nnsport", and "nndport" (though perhaps we can leverage existing "sport" and "dport", provided they aren't restricted to 16-bits) to the ZeroTierOne core. We will also need a way to identify that this is an NN protocol packet, which is ethertype 0x901, but we will probably want to add a human friendly alias for this.

This all should actually be a fairly modest effort.

I'm prepared to contribute the above functionality per @janjaapbos as a PR, but want to check with the ZT team -- what are your thoughts here? Any objections to such a direction? Any problems you foresee?

[adamierymenko]

Under the hood I think this should be implemented via binary match rules. These would be easy to implement.

[adamierymenko]

Then we could add keywords to the language that are syntactic sugar for those.

Actually binary match and integer range would be useful. Let me stub out what I'm thinking of in dev.

[gdamore]

cool. remember we need integers of different sizes (24-bit in this case) and endianness.

…

On Tue, Sep 19, 2017 at 8:19 AM Adam Ierymenko ***@***.***> wrote: Then we could add keywords to the language that are syntactic sugar for those. Actually binary match and integer range would be useful. Let me stub out what I'm thinking of in dev. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#588 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPDfZ8UoYirjTGSieclHWQFTl1hTkkzks5sj9uAgaJpZM4PbrNT> .

[adamierymenko]

Yeah, I think a general variable length integer range match with endian selection will work, then we can do the nanomsg stuff as syntactic sugar in the rule language.

[adamierymenko]

`

	/**
	 * Arbitrary endian integer range
	 *
	 * This allows matching of ranges of integers up to 64 bits wide where
	 * the range is +/- INT32_MAX. It's packed this way so it fits in 16
	 * bytes and doesn't enlarge the overall size of this union.
	 */
	struct {
		uint64_t start; // integer range start
		int32_t delta; // +/- offset from start of integer range end
		uint16_t idx; // index in packet of integer
		uint8_t bits; // number of bits in integer (range: 1-64)
		uint8_t endian; // endianness of integer in packet (0 == big, 1 == little)
	} intRange;

`

[adamierymenko]

That would be the new rule's definition in the ZT_VirtualNetworkRule union.

[adamierymenko]

@gdamore Does that capture your needs?

[gdamore]

@adamierymenko yes, I think this is pretty close to what I want, or rather a super set of it. I probably dont need arbitrary bit widths, but I can imagine extracting some bits might be useful -- e.g. just a couple of bits for TCP packet status, etc.

I'm not sure I understand the use of start and delta though. Presumably idx is the offset from the start of the packet, how are the other two used?