netdev - Re: [Fwd: Re: [PATCH] Multicast packet reassembly can fail]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Oct 2009 12:05:58 -0500
From:	Steve Chen <schen@...sta.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [Fwd: Re: [PATCH] Multicast packet reassembly can fail]

On Wed, 2009-10-28 at 16:32 +0100, Eric Dumazet wrote:
> Steve Chen a écrit :
> > Following is the e-mail I replied to Rick Jones in case you haven't got
> > it yet.  I have not posted the test code yet.  The test code is a tar gz
> > file about 11k in size.  Lot of people will get very upset if I send it
> > to the mailing list.  If you can suggest a place to up load, I'll be
> > happy to do so.
> > 
> > Regards,
> 
> > Here is the scenario this patch tries to address
> > 
> > <src node> ---->  <switch>  ----> <eth0 dest node>
> >                             \--->  <eth1 dest node>
> 
> If each fragment is received twice on host, once by eth0, once by eth1,
> should we deliver datagram once or twice ?

The application received it once.  IIRC the duplicate packet is drop in
the routing code.

> 
> Once should be enough, even if in the non fragmented case, it will
> be delivered twice (kernel cannot detect duplicates, user app might do itself)

Routing code drops the duplicate packet for none-fragmented case as
well.

> 
> 
> > 
> > For this specific case, src/dst address, protocol, IP ID and fragment
> > offset are all identical.  The only difference is the ingress interface.
> > A good follow up question would be why would anyone in their right mind
> > multicast to the same destination?  well, I don't know.  I can not get
> > the people who reported the problem to tell me either.   Since someone
> > found the need to do this,  perhaps others may find it useful too.
> > 
> 
> Then, if a 2000 bytes message is fragmented in two packets, one coming
> from eth0, one coming from eth1, I suspect your patch drops the message,
> unless eth0/eth1 are part of a bonding device...

Actually, the patch tries to prevent packet drop for this exact
scenario.  Please consider the following scenarios
1.  Packet comes in the fragment reassemble code in the following order
(eth0 frag1), (eth0 frag2), (eth1 frag1), (eth1 frag2)
Packet from both interfaces get reassembled and gets further processed.

2. Packet can some times arrive in (perhaps other orders as well)
(eth0 frag1), (eth1 frag1), (eth0 frag2), (eth1 frag2)
Without this patch, eth0 frag 1/2 are overwritten by eth1 frag1/2, and
packet from eth1 is dropped in the routing code.

> 
> That would break common routing setups, using two links to aggregate bandwidth ?

I don't believe it would.  The aggregate bandwidth will work the same as
before.  The attributes (src/dst addr, protocol, interface, etc.) should
generate a unique hash key.  If hash collision should happen with the
addition of iif << 5, the code still compare the original src addr along
with interface number, so there should be no issues.

> Nothing in IP forces all packets of a datagram to follow an unique route.
> 
My understanding as well.

Regards,

Steve

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html