From: Masahide NAKAMURA <nakam@linux-ipv6.org>
To: rdenis@simphalempin.com
Cc: netfilter-devel@lists.netfilter.org, usagi-core@linux-ipv6.org,
Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
Subject: Re: [NETFILTER]: ip6_tables: Support MH match.
Date: Tue, 30 Jan 2007 13:23:19 +0900 [thread overview]
Message-ID: <45BEC837.2060001@linux-ipv6.org> (raw)
In-Reply-To: <200701290507.l0T57mwf015698@toshiba.co.jp>
Hello,
When you reply, can you include my address because I've not subscribed the
netfilter-devel list?
Please find my answer inline.
> From: Remi Denis-Courmont <rdenis@simphalempin.com>
> > Date: Sat, 27 Jan 2007 17:34:42 +0200
> >
>> > > Hello,
>> > >
>> > > Le vendredi 26 janvier 2007 11:53, Yasuyuki KOZAKAI a ecrit :
>>> > > > MH is defined as extention header in RFC3775, but this patch handles
>>> > > > it as layer 4 protocol header like ICMPv6 header.
>>> > > >
>>> > > > The reasons are
>>> > > > - The reason why it's defined as extentin header is mainly for
>>> > > > 'piggy back'. But that feature was not specified in RFC3775 after
>>> > > > all. - No header follow MH. RFC3775 says
>>> > > > Implementations conforming to this specification SHOULD set
>>> > > > the payload protocol type to IPPROTO_NONE (59 decimal).
>> > >
>> > > What happens if a node (including a non-Linux one) receives a MH packet
>> > > with a non-none next protocol? I might be wrong, but I would assume it
>> > > parses it, at least in some cases.
The node will send ICMP parameter problem back with code depending on
whether the node supports MH or not.
If it supports, the code is 0 (erroneous header field) as RFC3775.
Otherwise, the code 1 (unrecognized Next Header).
>> > > If this is trye, this patch might introduce a trivial way to evade
>> > > firewall rules, as firewall admins will assume the next protocol is
>> > > none, while it might not be.
>> > >
>> > > Of course, I could be plain wrong, since I do not know MH.
If the sender creates MH with nexthdr=TCP for example,
it may go through the firewall which is configured even MH=ACCEPT
TCP=DROP. However, the receiver cannot handle it as TCP.
Can I add nexthdr check, or should I rewrite it as "-m" module
to treat MH as an extension header?
>>> > > > - Many parts in RFCs assume that it's like layer 4 protocol header.
>>> > > > - Actually Linux IPv6 stack, XFRM, setkey, iproute2... handle it as
>>> > > > if it's layer4 protocol.
>> > >
>> > > Slightly off-topic, but anyway, what about socket() syscall - can you
>> > > create a IPPROTO_MH raw socket with it?
Yes we can. Actually kernel never originates MH but application
creates MH to send it through the raw socket.
Thanks,
--
Masahide NAKAMURA
next prev parent reply other threads:[~2007-01-30 4:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-26 9:53 [NETFILTER]: ip6_tables: Support MH match Yasuyuki KOZAKAI
2007-01-27 15:34 ` Rémi Denis-Courmont
[not found] ` <200701290507.l0T57mwf015698@toshiba.co.jp>
2007-01-30 4:23 ` Masahide NAKAMURA [this message]
2007-02-01 1:41 ` Yasuyuki KOZAKAI
2007-02-02 11:05 ` Jozsef Kadlecsik
2007-02-09 6:22 ` Masahide NAKAMURA
2007-02-10 8:32 ` Masahide NAKAMURA
2007-02-12 10:09 ` Patrick McHardy
[not found] <200701260953.l0Q9rvV8006278@toshiba.co.jp>
2007-01-26 14:26 ` Patrick McHardy
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=45BEC837.2060001@linux-ipv6.org \
--to=nakam@linux-ipv6.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=rdenis@simphalempin.com \
--cc=usagi-core@linux-ipv6.org \
--cc=yasuyuki.kozakai@toshiba.co.jp \
/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).