netfilter buglog - Feb 2014 - [Bug 904] New: Matching ah without optional argument gives unintuitive result

https://bugzilla.netfilter.org/show_bug.cgi?id=904

           Summary: Matching ah without optional argument gives
                    unintuitive result
           Product: iptables
           Version: 1.4.x
          Platform: arm
        OS/Version: Debian GNU/Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: iptables
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: saltyacid at gmail.com
   Estimated Hours: 0.0


Found on version 1.4.19.1 and concerns both iptables and ip6tables.

How to use -m ah is described here:
http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-6.html

# ip6tables -A INPUT -m ah --ahspi 500 -j DROP

# ip6tables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       all      anywhere             anywhere           ah spi:500


However, ignoring the optional argument --ahspi gives a check that we match
SPI=0 (I would think that the normal behavior is to not care about the spi at
all).

So if we do:
# ip6tables -A INPUT -m ah -j DROP

We get:
# ip6tables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       all      anywhere             anywhere           ah spi:0

To me, this should either be changed if possible or else ahspi should not be
optional or it must be well documented as the current implementation fools
people. 

While googling I have seen a few places where:
ip6tables -A INPUT -m ah -j DROP
was used and did definitely not give the correct result (to what the author
wanted)

Of course you can use ! --ahspi 0 to match all but one spi but this is just a
workaround.

I would imagine that the behavior for --espspi is the same.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=904

Phil Oester <netfilter at linuxace.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |netfilter at linuxace.com

--- Comment #1 from Phil Oester <netfilter at linuxace.com> 2014-02-13
17:18:36 CET ---
If you wish to block all ah traffic, you should not be using the ah match. 
Instead, use:

iptables -A INPUT -p ah -j DROP

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=904

Pablo Neira Ayuso <pablo at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |pablo at netfilter.org
         Resolution|                            |WONTFIX

--- Comment #2 from Pablo Neira Ayuso <pablo at netfilter.org> 2014-02-14
11:36:31 CET ---
(In reply to comment #1)
> If you wish to block all ah traffic, you should not be using the ah match. 
> Instead, use:
> 
> iptables -A INPUT -p ah -j DROP
Right.

And regarding Sebastian's request, we cannot change that behaviour (even if
I
agree it's ugly) because there may be people already relying on it (a change
may break backward compatibility).

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=904

--- Comment #3 from Sebastian <saltyacid at gmail.com> 2014-02-18 08:41:37
CET ---
Thank you for your comments!

However, for IPv6 -p ah does not work:

 "-p" uses the first non-extension header (which can never
be AH for IPv6) while "-m ah" matches on AH extension headers.

ip6tables even say so, as using -p ah gives the following warning:
"Warning: never matched protocol: ah. use extension match instead"

So I still think this needs to be explained somewhere - for example when using
the rule.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=904

--- Comment #4 from Phil Oester <netfilter at linuxace.com> 2014-02-19
17:09:12 CET ---
Given this:

   The SPI value of zero (0) is reserved for local, implementation-
   specific use and MUST NOT be sent on the wire.  

Your '! --ahspi 0' plan should work to match all valid (on the wire) AH
traffic.

You could probably also use '! --ahlen 0', which should only match
packets
which have a valid AH header.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=904

--- Comment #5 from Sebastian <saltyacid at gmail.com> 2014-02-20 08:33:29
CET ---
Thanks for your comment!

I agree that my workaround will work for me, but what I'm afraid of is that
someone else uses "ip6tables -A INPUT -m ah -j DROP".

I also agree that we cannot change the behavior of existing code so that the
argument ahspi is mandatory (which is basically the case since matching spi=0
is never what we want).

So I think there are two reasonable ways of improving this::

1) Change the comment "use extension match instead" to "use
extension match
with argument --ahspi instead".

2) While using it without ahspi, give the following output:
"Warning: matching spi 0. To match all AH, use ! --ahspi 0 instead"

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.