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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.