netdev - Re: [PATCH net-next 0/2] netfilter: IPv4/v6 IPcomp match support

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-prev] [day] [month] [year] [list]

Message-ID: <20131224181614.GA26270@localhost>
Date:	Tue, 24 Dec 2013 19:16:14 +0100
From:	Pablo Neira Ayuso <pablo@...filter.org>
To:	Fan Du <fan.du@...driver.com>
Cc:	davem@...emloft.net, steffen.klassert@...unet.com,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/2] netfilter: IPv4/v6 IPcomp match support

On Tue, Dec 24, 2013 at 02:19:57PM +0800, Fan Du wrote:
> For a packet encapsulated in order of ah->esp->ah->original packet, as you said
> par->thoff is set at esp, that's why netfilter esp has a unified implementation
> in net/netfilter/xt_esp.c, because it's always the last parse header netfilter
> can reach.
> 
> The same rule apply with IPcomp, for example,
> (1) ah->ipcomp->original packet
>          ^par->thoff
> (2) ipcomp->ah->original packet
>       ^par->thoff
> 
> Both cases (1) and (2) par->thoff can only point into IPcomp header, so in such
> circumstance, a unified implementation for both IPv4/6 is feasible, and I have
> tested (2) in such implementation, it works anyway.
> 
> IMO, a unified implementation suggested by you previous is ok for this round review.

Your right, I forgot the fact that ipcomp "hides" what it
encapsulates, so it's basically the last header we can see.
--
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