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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 19 May 2015 06:50:44 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Florian Westphal <fw@...len.de>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	hannes@...essinduktion.org, edumazet@...gle.com
Subject: Re: [PATCH -next] net: preserve geometry of fragment sizes when
 forwarding

On Mon, May 18, 2015 at 11:33:29PM +0200, Florian Westphal wrote:
>
> > Every objection has been of the form "this special case" (this time
> > SIP) is not easy.
> 
> Yes, but these objections are not some random hand-waving gesture.
> It presents us with certain dilemmas, e.g. single udp packet:
> 
> 1280 1280 1280 542
> 
> sip nat helper has to do nat/pat and replaces 10.2.3.4 with 192.168.2.3
> (lets assume we'd have helpers that deal with addresses split over 2
>  fragmented skbs so we can deal with 10.2 appearing in fragment #2
>   and .3.4 in fragment #3)
> 
> We can then end up with something like
> 1283 1281 1282 542
> 
> ... and what should we do then?

I think what David is saying that you can apply your special
logic to these edge cases, e.g., linearise them and on output
use your MTU cap to refragment.

However, for the vast majority of fragments that you receive,
which would not be modified by NAT, they should retain their
original geometry.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ