netdev - Re: [PATCH net-next] {ipv4,xfrm}: Introduce xfrm_tunnel

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

Date:	Tue, 27 Aug 2013 09:29:40 +0800
From:	Fan Du <fan.du@...driver.com>
To:	David Miller <davem@...emloft.net>
CC:	<steffen.klassert@...unet.com>, <saurabh.mohan@...tta.com>,
	<herbert@...dor.hengli.com.au>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] {ipv4,xfrm}: Introduce xfrm_tunnel_notifier
 for xfrm tunnel mode callback

Hi, Dave

Thanks for your reply :)

On 2013年08月27日 04:21, David Miller wrote:
> From: Fan Du<fan.du@...driver.com>
> Date: Fri, 23 Aug 2013 14:47:04 +0800
>
>> Some thoughts on IPv4 VTI implementation:
>>
>> The connection between VTI receiving part and xfrm tunnel mode input process
>> is hardly a "xfrm_tunnel", xfrm_tunnel is used in places where, e.g ipip/sit
>> and xfrm4_tunnel, acts like a true "tunnel" device.
>>
>> In addition, IMHO, VTI doesn't need vti_err to do something meaningful, as all
>> VTI needs is just a notifier to be called whenever xfrm_input ingress a packet
>> to update statistics.
>>
>> So this patch introduce xfrm_tunnel_notifier and meanwhile wipe out vti_erri
>> code.
>>
>> Signed-off-by: Fan Du<fan.du@...driver.com>
>
> I don't understand why VTI doesn't need to propagate a PMTU update via
> ipv4_update_pmtu().  Why is it different from a real xfrm_tunnel?
   ^^^^^^^^^^^^^^^^

A IPsec protected packet is first handled by protocol handlers, e.g AH/ESP,
to check packet authentication or encryption rightness. PMTU update is taken
care of in this stage by protocol error handler.

Then the packet is rearranged properly depending on whether it's transport
mode or tunnel mode packed by mode "input" handler. The VTI handler code
takes effects in this stage in tunnel mode only. So it neither need propagate
PMTU, as it has already been done if necessary, nor the VTI handler is
qualified as a xfrm_tunnel.

IMHO, xfrm_tunnel is protocol layer specific only, which denotes a method
how IPPROTO_IPIP inner packet is handled, while as VTI reform XFRM policy into
a routable net device. That's the difference between them.

>
> Your changelog has to explain this better and in more detail.
> Thanks.
>

-- 
浮沉随浪只记今朝笑

--fan
--
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