Bug 190439

Summary: IPv6 netfilter: bug in esp and icmp with option header match
Product: Red Hat Enterprise Linux 4 Reporter: Peter Bieringer <pb>
Component: kernelAssignee: Thomas Graf <tgraf>
Status: CLOSED CANTFIX QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 4.0CC: davem, jbaron, rkhan, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-10 12:48:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 176344    

Description Peter Bieringer 2006-05-02 12:18:20 UTC
+++ This bug was initially created as a clone of Bug #144832 +++

Description of problem:
During setup of IPv6 firewalling I found that IPv6 netfilter code has
two bugs, one about matching on esp, the other matching on icmpv6 with
options. With help of developers, I got fixes which solve the issues.

Version-Release number of selected component (if applicable):
kernel-2.6.10-1.737_FC3

How reproducible:
Always

Steps to Reproduce:
1. setup rule which should match IPv6 esp packages
2. setup rule which should match ICMPv6 packages regardless packages
contain option headers

    

Actual Results:  No match

Expected Results:  Match

Additional info:

See threads:
http://www.linux-ipv6.org/ml/usagi-users/msg03166.html
http://oss.sgi.com/projects/netdev/archive/2005-01/msg00015.html

And here the patch:

--- net/ipv6/netfilter/ip6_tables.c.orig        2004-12-26
19:16:57.461634470 +0100
+++ net/ipv6/netfilter/ip6_tables.c     2004-12-26 19:17:45.456219406
+0100
@@ -220,7 +220,7 @@
                u_int16_t ptr;          /* Header offset in skb */
                u_int16_t hdrlen;       /* Header */

-               ptr = IPV6_HDR_LEN;
+               ptr = ((char *) ipv6 - (char *) skb->data) + IPV6_HDR_LEN;

                while (ip6t_ext_hdr(currenthdr)) {
                        /* Is there enough space for the next ext
header? */
@@ -232,7 +232,7 @@
                         * we will change the return 0 to 1*/
                        if ((currenthdr == IPPROTO_NONE) ||
                                (currenthdr == IPPROTO_ESP))
-                               return 0;
+                               break;

                        hdrptr = (struct ipv6_opt_hdr *)(skb->data + ptr);

-- Additional comment from davej on 2005-07-15 14:34 EST --
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

-- Additional comment from pb on 2005-08-13 10:38 EST --
At least the problem with the option header still exist:

Aug 13 16:34:59 host kernel: FW6-default-DROP-intOUT:IN= OUT=eth0
SRC=fe80:0000:0000:0000:0280:c8ff:feb9:cef9
DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=96 TC=0 HOPLIMIT=1 FLOWLBL=0
PROTO=ICMPv6 TYPE=143 CODE=0

Roule still does't match:

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     icmpv6    *      *       fe80::/10           
ff02::16/128       ipv6-icmp type 143 HL match HL == 1
    0     0 ACCEPT     icmpv6    *      *       ::/128              
ff02::16/128       ipv6-icmp type 143 HL match HL == 1
    6   400 ACCEPT     icmpv6    *      *       ::/0                 ::/0      
        

Kernel: 2.6.12-1.1398_FC4

-- Additional comment from pb on 2005-08-13 10:43 EST --
Note that while kernel log do no longer show "OPT ( )", a Hop-By-Hop option is
still in the packet:

Frame 1 (110 bytes on wire, 110 bytes captured)
    Arrival Time: Aug 13, 2005 16:43:19.386977000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 0.000000000 seconds
    Frame Number: 1
    Packet Length: 110 bytes
    Capture Length: 110 bytes
    Protocols in frame: eth:ipv6:icmpv6
Ethernet II, Src: D-Link_b9:ce:f9 (00:80:c8:b9:ce:f9), Dst:
IPv6-Neighbor-Discovery_00:00:00:16 (33:33:00:00:00:16)
    Destination: IPv6-Neighbor-Discovery_00:00:00:16 (33:33:00:00:00:16)
    Source: D-Link_b9:ce:f9 (00:80:c8:b9:ce:f9)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6
    Version: 6
    Traffic class: 0x00
    Flowlabel: 0x00000
    Payload length: 56
    Next header: IPv6 hop-by-hop option (0x00)
    Hop limit: 1
    Source address: fe80::280:c8ff:feb9:cef9 (fe80::280:c8ff:feb9:cef9)
    Destination address: ff02::16 (ff02::16)
Hop-by-hop Option Header
    Next header: ICMPv6 (0x3a)
    Length: 0 (8 bytes)
    Router alert: MLD (4 bytes)
    PadN: 2 bytes
Internet Control Message Protocol v6
    Type: 143 (Multicast Listener Report Message v2)
    Code: 0 (Should always be zero)
    Checksum: 0xd3b5 [correct]
    Changed to exclude: ff05::1:3 (ff05::1:3)
        Mode: Changed to exclude
        Aux data len: 0
        Multicast Address: ff05::1:3
    Changed to exclude: ff02::1:2 (ff02::1:2)
        Mode: Changed to exclude
        Aux data len: 0
        Multicast Address: ff02::1:2


-- Additional comment from davej on 2005-09-30 02:52 EST --
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.


-- Additional comment from pb on 2005-10-03 16:36 EST --
I can confirm that match works now (btw: packets are generated by dhcp6s):

    2   192 ACCEPT     icmpv6    *      *       fe80::/10           
ff02::16/128       ipv6-icmp type 143 HL match HL == 1


+++ End of original bug report

Same seen now on RHEL4 running kernel-2.6.9-34.EL during adding a new IPv6
address on a running system:

# ip addr add 2001:7b0:1101:1::37:2/64 dev eth0

causes:
May  2 13:37:42 rhel4 OUTPUT-FW6/cleanup:IN= OUT=eth0
SRC=fe80:0000:0000:0000:0240:63ff:fedb:ff6b
DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=196 TC=0 HOPLIMIT=1 FLOWLBL=0
OPT ( ) PROTO=ICMPv6 TYPE=143 CODE=0

Comment 1 Peter Bieringer 2006-08-10 15:18:00 UTC
Can it be that the same bug prevents me from using RHEL4's IPsec configuration?

After successful using IPsec host-to-host with IPv4, I play now with IPv6, but
strange things are happen here.

Config on both hosts (only src/dst exchanged):
ifcfg-ipsec0
SRC=2001:db8:1234:1::54:1
DST=2001:db8:1234:1::164:1
TYPE=IPSEC

IKE_METHOD=PSK
IKE_PSK=secret
ESP_PROTO=aes128

IPv6 firewalling is active on both hosts, too.

While IKE (phase 1) and IPsec (phase 2) are proper established, a ping6 or a ssh
connect results in:

Dst host:

Aug 10 17:10:59 host INPUT-FW6/cleanup:IN=eth0 OUT=
MAC=00:40:63:**:**:**:00:e0:1e:56:91:**:**:**
SRC=2001:0db8:1234:0001:0000:0000:0164:0001
DST=2001:0db8:1234:0001:0000:0000:0054:0001 LEN=140 TC=0 HOPLIMIT=60 FLOWLBL=0
OPT ( ) OPT ( ) PROTO=59

It only let the traffic pass, if I append following rule:
ip6tables -I INPUT -s 2001:db8:1234::/48 -d 2001:db8:1234::/48 -j ACCEPT

If I replace it by e.g.
ip6tables -I INPUT -s 2001:db8:1234::/48 -d 2001:db8:1234::/48 -j ACCEPT -p tcp

traffic is blocked.

Used: kernel-2.6.9-34.0.2.EL

Could one please check if the upper shown minor patch is included in latest
RHEL4 U4 candidate kernel, and if not, please include it.





Comment 2 RHEL Program Management 2007-05-09 10:28:40 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 3 RHEL Program Management 2007-09-07 19:44:58 UTC
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time.  This request will be
reviewed for a future Red Hat Enterprise Linux release.

Comment 4 Thomas Graf 2012-05-10 12:48:20 UTC
RHEL4 has entered the Extended Life Phase. There will be no more minor releases.

I'm closing this bug due to inactivity.

Please reopen and provide an explanation if you need this issue to be addressed in RHEL4. Please note that only security and critical bugfixes are considered at this point.