netdev - RFC - VXLAN port range facility

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

Message-ID: <OF673FF136.10B22631-ON85257B7B.00436301-85257B7B.0045AAB7@us.ibm.com>
Date:	Thu, 30 May 2013 08:40:56 -0400
From:	David Stevens <dlstevens@...ibm.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
Cc:	netdev@...r.kernel.org
Subject: RFC - VXLAN port range facility

Stephen,
        I think there are some issues with the port range facility in
VXLAN. Currently, it picks a random port from a wide range (nearly half 
the
port space) and uses that random value as a source port for a generated
UDP packet.
        There are no checks to see if the port is in use by something 
else.

        I can see the value of using a range of ports, but::

1) VXLAN should use its listen port by default
2) VXLAN should actually bind to any source ports it uses, because...
3) VXLAN should never use a port already exclusively in use by something 
else.

As is, VXLAN is not playing well with other UDP users because, for 
example,
it can trigger ICMP errors which will be delivered to some unwitting 
application
whose port it has hijacked.

I think a port ranges may be useful in the context of a small number (say 
10)
of ports that you are actually bound to, so then as part of multi-port 
binding
support. But then a default range of 32K-61K is too large. It then, at 
least,
has the potential to manage ICMP errors triggered by VXLAN.

I think if you want to use port ranges like a range of empheremal ports, 
it's
less useful, but at a minimum it should be a port that you can legally 
bind
to at the time it's in use. Since actually binding/unbinding for each 
packet
would probably be too expensive, I think it'd be better to:

1) use smaller ranges by default
2) actually bind to the entire range on start-up, to prevent other apps 
from using them
3) fail if any in the range is already bound
4) then, with a range of bound ports, select as currently on sends

                                                +-DLS

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