| 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
| ||
|
Date: Thu, 4 Oct 2012 08:12:14 -0700 From: Stephen Hemminger <shemminger@...tta.com> To: Eric Dumazet <eric.dumazet@...il.com> Cc: Jesse Gross <jesse@...ira.com>, davem@...emloft.net, netdev@...r.kernel.org Subject: Re: [PATCH 3/3] vxlan: virtual extensible lan On Thu, 04 Oct 2012 08:34:50 +0200 Eric Dumazet <eric.dumazet@...il.com> wrote: > On Wed, 2012-10-03 at 21:02 -0700, Stephen Hemminger wrote: > > > > > Since port is always a pair, there is no need to restrict range, unless > > there was a broken firewall in the way. One bug there is that random32() > > can return 0 which is not a valid port number. A better fallback > > would be a hash of the MAC header. > > But using up to 65536 values for the port means that if vxlan traffic > crosses a statefull firewall (eg netfilter with conntrack), this might > need 65536 contexts/sessions. This is UDP, there is no usable state to be found. But as a practical matter it only needs to be wide enough to hit the number of receive channels. Therefore even 64 is probably enough for most people. > So random32() is not needed. > > What might be needed is additional parameters for a vxlan tunnel, to > give an optional range for the source port. It could be per vxlan without a lot of pain. or just derive it value from existing ephermeral port range. -- 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