netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130531091338.12fc7df5@nehalam.linuxnetplumber.net>
Date:	Fri, 31 May 2013 09:13:38 -0700
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	netdev@...r.kernel.org, netdev-owner@...r.kernel.org
Subject: Re: RFC - VXLAN port range facility

On Thu, 30 May 2013 14:00:51 -0400
David Stevens <dlstevens@...ibm.com> wrote:

> netdev-owner@...r.kernel.org wrote on 05/30/2013 12:41:41 PM:
> 
> > From: Stephen Hemminger <stephen@...workplumber.org>
> > 
> > The source port is not related to what some application receives.
> > A RFC conforming VXLAN endpoint will never send traffic back tot the
> > senders source
> > port. If VXLAN traffic got an ICMP response form an router like
> > DESTINATION_UNREACHABLE there should be a match on destination port as 
> well.
> 
> It'd be sent to the source port of the sender and it need not be bound to
> a remote port -- for example, a netfilter rule blocking the destination
> would send an administratively-prohibited ICMP error to a UDP
> application that did not trigger the traffic that caused the error.
> 
> Quite simply, VXLAN uses UDP so it needs to follow the rules of UDP.
> 
> But I don't think there's particular advantage in splitting it up 30,000
> ways when 10 ways would be both practical, for binding, and spread
> traffic to 10 flows potentially.
>

RFC text:
 Outer UDP Header:  This is the outer UDP header with a source
        port provided by the VTEP and the destination port being a well
        known UDP port to be obtained by IANA assignment. It is recommended
        that the source port be a hash of the inner Ethernet frame's headers
        to obtain a level of entropy for ECMP/load balancing of the VM to VM
        traffic across the VXLAN overlay.


You can restrict to a smaller range if that is a requirement of your infrastructure.

Normal UDP applications assign their source port from the ephemeral port range,
so that is what VXLAN does.
--
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