[ovs-discuss] discuss Digest, Vol 5, Issue 15

John Galgay john at telivo.net
Thu Nov 19 21:21:16 UTC 2009


Keith -- 

Yes, I appreciate the difference between the problem and a solution.  I
desire to address the risk associated with a broadcast packet (especially
one that  is requesting an IP address) across the virtual switching
infrastructure inside the VM Host.

VLANs can segment the receivers to be within the "trusted group" of a common
party.

Even on a broadcast domain of trusted parties, I desire to prevent the
accidental activity of a DHCP server to assign an IP address as an
unauthorized DHCP server.  I can do this with filters on each potential
receiver, but addressing the risk also at the source (or source network
interface - vswitch port) is the objective.

Lastly, the DHCP may be on or off the broadcast domain ... as is common
today.

Thanks for your consideration.

John 

-----Original Message-----
From: discuss-bounces at openvswitch.org
[mailto:discuss-bounces at openvswitch.org] On Behalf Of
discuss-request at openvswitch.org
Sent: Tuesday, November 17, 2009 11:01 AM
To: discuss at openvswitch.org
Subject: discuss Digest, Vol 5, Issue 15

Send discuss mailing list submissions to
	discuss at openvswitch.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
or, via email, send a message with subject or body 'help' to
	discuss-request at openvswitch.org

You can reach the person managing the list at
	discuss-owner at openvswitch.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of discuss digest..."


Today's Topics:

   1. Re: Controlling / Constraining / Directing DHCP (Keith Amidon)


----------------------------------------------------------------------

Message: 1
Date: Mon, 16 Nov 2009 16:57:13 -0800
From: Keith Amidon <keith at nicira.com>
Subject: Re: [ovs-discuss] Controlling / Constraining / Directing DHCP
To: discuss at openvswitch.org
Message-ID: <1258419433.15364.15.camel at kea-nicira-lt.nicira.com>
Content-Type: text/plain; charset="windows-1251"

Hi John,

Could you explain your use-case from the perspective of the result you
would like to achieve instead of a suggested implementation?  I could
guess at what that result is from the suggested implementation but I
think it would be better to get your perspective directly.

              --- Keith


On Fri, 2009-11-13 at 15:39 -0600, John Galgay wrote:

> I am thinking about the DHCP broadcast issue across the multi-tenant
> cloud switching fabric.  This includes intra-host openvswitch, the
> multi-host openvswitch, and openvswitch+real switch scenarios.  The
> objective is obviously to constrain the ability of any entity besides
> the desired server to answer the DHCP request and assign IP addresses.
> 
> The best solution is always a dual wall solution ? 1 wall to prevent
> an event, the other in case it does anyways.  In this case, the first
> wall is a receiver wall and common practice is to use firewall/ip
> tables to prevent DHCP requests from entering / DHCP offers from
> leaving a host that could receive the Request broadcast and act as an
> unauthorized DHCP server.  This  solution however assumes
> administrative control off all receivers or the infrastructure
> connecting all receivers (such is a best practice with cable
> modems).  
> 
> The second wall is a sender wall.  The objective would be to send
> DHCP requests directly to the  DHCP server and have the answers send
> directly back to the requesting host.  We are all aware of DHCP
> forwarding services that can be provided by a router  (also called IP
> Helper by some vendors) to an off-LAN DHCP server --- whereby the
> router picks up the DHCP request, stamps itself as the Gateway, and
> unicast forwards the request to a configured DHCP server(s) anywhere.
> The unicast Offer responses are received by the router and sent
> directly to requesting MAC address. 
> 
> I see this as a useful feature of the openvswitch residing in a VM
> Host, whereby the ovs will intercept the DHCP Requests on selected
> ports, stamp its internal (bridge) IP address as the gateway, unicast
> forward the request to  the configured DHCP server(s) ? [could be a
> host on the same network or a host on a different network].  The Offer
> will be unicast returned to the internal IP address of the ovs switch,
> and forwarded to the requesting VM out the originally received port.
> 
> This service will  effectively keep DHCP broadcast Request / Offer
> traffic off of the entire multi-tenant cloud switching fabric all
> together.  The only entity that will see the DHCP request is the ovs
> switch instance ? and the only answer can come from the authorized
> DHCP servers ? and all traffic between these entities will be unicast
> and may optionally be secured / encrypted.
> 
> Any thoughts on this capability for openvswitch ??
> 
> Thanks.
> 
> John
> 
> 
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://openvswitch.org/pipermail/discuss_openvswitch.org/attachments/200911
16/001e8ff7/attachment-0001.html>

------------------------------

_______________________________________________
discuss mailing list
discuss at openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org


End of discuss Digest, Vol 5, Issue 15
**************************************






More information about the discuss mailing list