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: <OFD5BD589B.1842E46B-ON85257B7B.00610E03-85257B7B.0062F480@us.ibm.com>
Date:	Thu, 30 May 2013 14:00:51 -0400
From:	David Stevens <dlstevens@...ibm.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
Cc:	netdev@...r.kernel.org, netdev-owner@...r.kernel.org
Subject: Re: RFC - VXLAN port range facility

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.

> 
> Port ranges are critical to retaining scaling in multi-path 
infrastructure.
> Otherwise all traffic will arrive on a single queue in NIC.

I agree, but I don't think there need to be so many, and whatever
the VXLAN draft says, it can't  start causing problems for existing
UDP applications. VXLAN simply shouldn't be using ports allocated
to other applications; it can only do this because the implementation
is not using the real UDP stack to send the packets, but it still
should follow the rules  just as all other UDP servers must do. How
that's enforced is an implementation issue, but I think it must be
enforced.

I think it should be binding to all ports it uses as sources, and
the default range should be min and max of the bind port. People
who need to spread flows have the capability, but that doesn't mean
they need it on by default, or that it has to be so many, or that
it has carte blanche to interfere with existing UDP applications.

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