Ocedo’s SDN adoption enables them to offer an automatic enterprise grade SDN-driven Virtual Private Network (VPN) solution. Their VPN product is an infrastructure “always on” service, offering customers the ability to connect dispersed geographic sites supporting end-to-end communication flow. The architecture is not tied to a singular topology model, providing design flexibility for different site types, such as data centre hub and branches. Globally dispersed sites are interconnected automatically with a point-to-point full mesh or a hub and spoke tunnel VPN architecture. Automation is a key component of Ocedo’s SDN-driven VPN product.
Network connectivity models support Layer 2 and Layer 3 VPNs, with a scalable and robust solution based on open standards and well defined security algorithms. Ocedo’s philosophy is not to reinvent the wheel and complicate network design. Simplicity and proven architectures are key to an optimum and stable design. The foundation of their SDN VPN product is based around this philosophy. If there is a well defined and widely adopted security and tunneling mechanism proven to work in a variety of complicated scenarios, then Ocedo will continue with this best practice design.
It is for these reasons that they use GRE tunneling, IPsec (StrongSwan) and Openvswitch (OVS) to form the base of their Layer 2 and Layer 3 VPN offering. Ocedo follows a tested design and adopts best practices from an SDN architecture, such as controller central viewpoints and data plane abstraction. By fully understanding and employing historically proven design principles, enables Ocedo to connect globally dispersed customers at Layer 2 and/or Layer 3.
The diagram below displays a canvas style page from the Ocedo Controller. It displays company sites that are connected together by either a full mesh or leaf VPN.
Controller Authority – Pull Control Plane
The SDN controller is authoritative for their VPN product, bringing agility and automation to customer connectivity models. Agility is a common buzzword with SDN and it basically means time is not wasted on network changes. The controller’s central viewpoint enables automatic control and creation of Layer 2 and Layer 3 tunnels between customer sites. Ocedo’s Access or Gateway physical nodes interested in tunnel creation need to get “some” information from the controller. Even though Ocedo opted for local intelligence/control plane for each device, they rely on the controller to get initial “configurational items” for endpoint site connectivity. For Layer 3 and Layer 2 tunnels, this would be a pseudo IP address that connects to remote rendezvous points, which directs them to the correct controller for further information. Rendezvous and controller site locations are located at customer sites or in public/private cloud locations.
The architecture is based on a pull control plane, in comparison to a push control plane. Advertisement of reachability information between routing protocol neighbors is an example of push-based control plane. Push control planes have challenges with central policy control. For example, implementation of endpoint access control may require configuration on all distributed nodes. A pull control plane don’t share this problem. The central controller has authority and visibility of all endpoints. Locator/ID Separation Protocol (LISP) is another example of a pull control plane, where EID’s are registered to the Mapping Server (MS) by their Routing Locators (RLOCs). The mapping servers have complete control and visibility of all endpoints. It is for these reasons that the LISP control plane (pull control) is expanding for use with other non LISP data plane mechanisms, such as VXLAN, i.e., LISP control plane and VXLAN data plane. Ocedo’s pull control plane architecture gives them much better visibility and control over the Layer 2.
Layer 2 and Layer 3 VPNs
Ocedo’s Layer 2 VPN offering is both internal to a site i.e., INTRA VPN (known as iXLAN) or external to a site, i.e., INTER VPN. The use case for a Layer 2 VPN could be to transport non routable packets between sites or some other type of keepalive packet that can’t be Layer 3 routed. Within a site, Layer 2 tunnels are used to form adjacencies over third-party products that you don’t have access to but need to establish connectivity over their data plane path. The logical construct is based on GRE within a site and GRE with IPsec security services for outside a site. The Openvswitch (OVS) uses GRE tunnels between two endpoints as a way of encapsulating traffic and creating an overlay network. Other encapsulation methods are available, such as STT or VXLAN. These would change the protocol header but nothing else. Ocedo believes in network simplicity and while other encapsulation are newer and more widely discussed, GRE is fit for purpose. Deploying other encapsulation methods would not bring any immediate advantages. VMware NSX platform also uses GRE for network overlays.
Ocedo employs an RFC standard for end point discovery known as mDNS (Multicast DNS). mDNS performs DNS-like operations on the local link and does not require a unicast DNS server. It operates by using a server discovery protocol over UDP. Each device announces its iXLAN service location and mDNS is used for node and endpoint discovery. The controller is still authoritative and makes the Layer 2 tunnels deterministic. For intra site scalability, Layer 2 tunnels are formed with a hub and spoke architecture.
WAN links have a defined bandwidth and zero latency so Layer 2 inter site VPN’s do not use mDNS. Each gateway device has a special IP address used to source the GRE tunnel. There is no need for automatic discovery. IPsec is used to secure traffic to external destinations.
Due to the extra overhead of GRE both Inter and Intra Layer 2 VPNs use MMS clamping. Linux has an automatic feature that can detect and send the highest possible MSS. MSS clamping is used to avoid the undesirable effect of fragmentation. Fragmentation should be avoided at all costs as it severely affects network performance.
Layer 3 VPNs have a simpler design to their Layer 2 VPNs counterpart. There is no GRE encapsulation or mDNS Discovery. It is IPsec without GRE, based on StrongSwan, which is available under GNU General Public License. Inter Layer 2 VPNs also use the StrongSwan feature set.
StrongSwan is a well known, openSource IPsec-based VPN solution for Linux. The strength for the StrongSwan project lies on the strong Authentication by means of X.509-Certificates, which Ocedo takes advantage of. IPSec uses IKE protocol to negotiate and establish secure VPN tunnels and Ocedo operate with IKEv2. Ocedo protect the entire IP packet with Tunnel mode for every connection. They use AES256/SHA512 for VPN encryption with Brainpool Elliptic Curve Groups. For efficient operation, Ocedo employ IPSec-over-UDP to get through any NAT devices; IPsec traffic gets encapsulated in UDP. This is a well known standard for adopting to NAT devices present in the end-to-end transit path.
Tunnel Control Points
While the VPN tunnels are created automatically, access controls and policies are set by the controller. Ocedo use IPtables on the gateway nodes that have two default rules a) Allows all users to the Internet and b) Allows all guest users to the Internet. All other traffic paths including the VPN tunnels must be specified and set with a high level policy on the controller. Controls are set on the controller and pushed down to Ocedo’s physical nodes. The policies and rules apply only to Layer 3 VPN. Layer 2 tunneling gives you a clean slate. No filtering or security services are implemented for Layer 2 VPNs.
Ocedo’s Layer 2 and Layer 3 VPN product is an automatic “lights on” product, tightly controlled by policies defined by the central SDN controller. Well known security and design standards are used to form a stable and optimum SDN-Driven VPN product. For more information on how Ocedo can securely connect your sites, you might want to join our Live-Webinar
- by Matthew Conran, Network Insight
Thank you, your comment successfully submitted
your comment has been submited, it might take a while to be moderated.