netdev - Re: [XFRM]: Optimize MTU calculation

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

Date:	Wed, 04 Apr 2007 15:07:34 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	DiegoB <diego.beltrami@...t.fi>
CC:	Kernel Netdev Mailing List <netdev@...r.kernel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Miika Komu <miika@....fi>
Subject: Re: [XFRM]: Optimize MTU calculation

DiegoB wrote:
> Patrick McHardy wrote:
> 
>> I've updated my IPsec MTU optimization patch I've posted a couple
>> of month ago to net-2.6.22 and added the further optimization
>> suggested by Herbert to account for the space lost due to alignment
>> in the room reserved for IP options in transport mode.
>>
>> Tested with IPv4 and IPv6 in tunnel and transport mode. Beet mode
>> is untested since no keying daemon seems to support it.
> 
> 
> Actually for BEET mode you can check the following:
> 
> http://hipl.hiit.fi/
> http://www.openhip.org/
> http://www.hip4inter.net/

Thanks for the pointers, I'm using manual keying for testing now.
It took me a while to properly set it up though since I wasn't
expecting that I need to specify a selector for the inbound SA.
Is there a reason for not using x->props.saddr/x->id.daddr during
inbound processing as on the output side?

draft-nikander-esp-beet-mode-06.txt states ".. MUST contain the
outer source and destination addresses, as defined in the SA"
for both inbound and outbound processing, so I think it would
be easier to handle this symetrical.
-
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