From: Pablo Neira Ayuso <pablo@netfilter.org>
To: James Chapman <jchapman@katalix.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH v5] netfilter: introduce l2tp match extension
Date: Fri, 3 Jan 2014 16:16:52 +0100 [thread overview]
Message-ID: <20140103151652.GA4496@localhost> (raw)
In-Reply-To: <1388757711-13712-1-git-send-email-jchapman@katalix.com>
On Fri, Jan 03, 2014 at 02:01:51PM +0000, James Chapman wrote:
> Introduce an xtables add-on for matching L2TP packets. Supports L2TPv2
> and L2TPv3 over IPv4 and IPv6. As well as filtering on L2TP tunnel-id
> and session-id, the filtering decision can also include the L2TP
> packet type (control or data), protocol version (2 or 3) and
> encapsulation type (UDP or IP).
>
> The most common use for this will likely be to filter L2TP data
> packets of individual L2TP tunnels or sessions. While a u32 match can
> be used, the L2TP protocol headers are such that field offsets differ
> depending on bits set in the header, making rules for matching generic
> L2TP connections cumbersome. This match extension takes care of all
> that.
>
> An iptables patch will be submitted separately.
>
> Signed-off-by: James Chapman <jchapman@katalix.com>
>
> ---
> Changes in v2:
> Address comments from Patrick McHardy:-
> - Added checkentry function to check args passed into kernel.
>
> Changes in v3:
> Address comments from Pablo Neira Ayuso:-
> - Remove debug code.
> - Avoid multiple nested if statements when they are unnecessary.
> - Fix data access to use skb_header_pointer() properly.
> - Use #defines for L2TP packet header bit definitions.
> - Improve comments to clarify how variations in L2TP header field
> locations are handled when parsing header fields.
>
> Changes in v4:
> Address comments from Pablo Neira Ayuso:-
> - Remove packet layout diagrams which are c&p'd from the RFCs.
> - Use ip6_find_hdr() to get the IP protocol inside IPv6
> packets. After this change, the common match code path thru
> l2tp_mt_common() was not useful so has been removed and
> l2tp_mt_udp() or l2tp_mt_ip() is called directly instead.
> - Require encap to be specified
>
> Changes in v5:
> Address comments from Pablo Neira Ayuso:-
> - Add log messages to help users identify kernel parameter problems.
> - Do not modify the info struct when checking parameters. Don't try to
> derive encap from other parameters if it isn't specified. Instead,
> just require that it is specified.
>
> Is there a way in checkentry() to check that a UDP match has also been
> specified, for the case when L2TP UDP encap is being used? This would
> ensure that specific UDP ports are matched.
Yes. See net/netfilter/xt_ecn.c for instance. In your case, this
should look like:
const struct ipt_ip *ip = par->entryinfo;
switch (ip->proto) {
case IPPROTO_UDP:
...
break;
case IPPROTO_L2TP:
...
break;
}
Note that par->entryinfo layout depends on ipv4/ipv6, so you'll need a
checkentry() function for each layer 3 family.
That ip->proto field is set via -p option.
I think this can also be used to remove the --encap option as -p would
specify the encapsulation type.
prev parent reply other threads:[~2014-01-03 15:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 14:01 [PATCH v5] netfilter: introduce l2tp match extension James Chapman
2014-01-03 14:26 ` Florian Westphal
2014-01-03 14:47 ` James Chapman
2014-01-03 15:16 ` Pablo Neira Ayuso [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140103151652.GA4496@localhost \
--to=pablo@netfilter.org \
--cc=jchapman@katalix.com \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).