netdev - Re: [PATCH][IPSEC][6/7] inter address family ipsec 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:	Fri, 01 Dec 2006 14:07:04 +0900
From:	Kazunori MIYAZAWA <kazunori@...azawa.org>
To:	David Miller <davem@...emloft.net>
CC:	miika@....fi, Diego.Beltrami@...t.fi, herbert@...dor.apana.org.au,
	netdev@...r.kernel.org, usagi-core@...ux-ipv6.org
Subject: Re: [PATCH][IPSEC][6/7] inter address family ipsec tunnel

David Miller wrote:
> From: Kazunori MIYAZAWA <kazunori@...azawa.org>
> Date: Fri, 24 Nov 2006 14:39:01 +0900
> 
>> This patch fixes mtu calculation of IPv4
>>
>> ip_append_data should refer the mtu of "dst" not "path".
>> if "dst" is stacked, "path" is the actual dst_entry in
>> the routing table.
>> therefore the mtu of "path" equals link mtu which is
>> depends on the device so that it ignores the header length
>> and the trailer length
>> "dst" has mtu for creating packet.
>>
>> Signed-off-by: Miika Komu <miika@....fi>
>> Signed-off-by: Diego Beltrami <Diego.Beltrami@...t.fi>
>> Signed-off-by: Kazunori Miyazawa <miyazawa@...ux-ipv6.org>
> 
> I'm not sure about this change.
> 
> If you look at the code in this function, "mtu" is always used with
> adjustments via 'exthdrlen' (which is set to rt->u.dst.header_len).
> So it seems the encapsulation is taken into account.
> 

Oh, sorry. I misread the code.
I tested with IPv4 over IPv4 IPsec tunnel. The original code works.
Sorry this patch was wrong. Please throw away [6/7] and [7/7].

> Perhaps any problem you are seeing is some artifact of the ipv6 in
> ipv4 tunnel implementation.  Otherwise we'd have other reports of this
> problem, wouldn't we?

The easy test is that you create IPv6 over IPv6 IPsec tunnel between 2 
hosts, the tunnel is terminated by themselves, and send icmp echo
packets which are longer than the mtu such as 2000. Then it seems
that the kernel  returns too big messages to ping6.
I guess mtu calculation and/or building packets of IPv6 has some problem

If you use another host (SGW) to encapsulate the packets,
I think it succeeds because SGW returns a too big message and the
packet sending host learns and fragments properly.

I had same situation like IPv6 over IPv6 IPsec self tunneling
under IPv6 over IPv4 IPsec tunneling test.

I'm going to trace the problem.

Thank you.

--
Kazunori Miyazawa
-
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