Internet Service Bus and Classic VPN Comparison

4/1/2014

This document discusses the Virtual Node connectivity options using Virtual Private Network and Internet Service Bus. Parallel comparisons are drown between the two technologies in terms of security, flexibility and costs.

Virtual Node Administrator’s Guide

Revision History

Change Record

Version Number Description of Change Change

Effective DateChange

Entered By1.0.00 Initial Draft April 1, 2014 Dr. Yunhao

Zhang

ii

Virtual Node Administrator’s Guide Page 3 of 11

Table of Contents

1 Internet Service Bus and Virtual Private Network.....................................41.1 What Is VPN and Internet Service Bus................................................41.2 The Virtual Node Connector.................................................................4

2 Security Mechanisms...................................................................................63 Configuration and Set Up............................................................................74 Attack Surface..............................................................................................7

4.1 Firewall holes........................................................................................84.2 Local Network Exposure......................................................................84.3 IP Address Exposure............................................................................8

5 Network Complexity.....................................................................................96 Costs.............................................................................................................97 Standards and Interoperability...................................................................98 Conclusion..................................................................................................109 References...................................................................................................10

Doc Ref # & Location 5/6/2023

Virtual Node Administrator’s Guide Page 4 of 11

1 Internet Service Bus and Virtual Private Network

One of the major challenges in cloud computing is network connectivity where hosted applications and services must be integrated with on-promise resources. This is especially true for virtual node as it must be able to interact with remote databases in the state infrastructure.

This paper discusses two main options for interconnecting virtual node and backend databases: Internet Service Bus (ISB) and Virtual Private Network (VPN). While we are going to compare the two technologies with pros and cons, it should be emphasized that they both prove to be viable options and node owner should choose the best fit.

1.1 What Is VPN and Internet Service Bus

A VPN is an extension of a private network that allows a computer to establish point to point connection to a local network through the Internet. VPN has been widely used by enterprises to allow employees to remotely access local domain network. The remote computer typically joins the local domain as the member and has access to domain network resources.

The Internet Service Bus provides a hosted, secure, and widely available infrastructure for application to application communication, event distribution, naming, and service publishing. Service Bus provides connectivity options for Windows Communication Foundation (WCF) and other service endpoints, including REST endpoints that would otherwise be difficult or impossible to reach. Endpoints can be located behind Network Address Translation (NAT) boundaries, or bound to frequently changing, dynamically assigned IP addresses, or both.

While VPN provides low level network connectivity (network layer 2 or layer 3), Internet Service Bus offers application level connectivity - connecting applications and services in the cloud or on-premises without opening ports or changing firewall configurations.

1.2 The Virtual Node Connector

Developed using the Internet Service Bus technologies by the CDX R/D team, the virtual node connector is a component for establishing secure network connectivity between virtual node in the cloud and database server in your enterprise environment without opening firewall.

Doc Ref # & Location 5/6/2023

Virtual Node Administrator’s Guide Page 5 of 11

The process of how the Virtual Node Connector works is outlined below:

1. The owner of a virtual node sends a request to node helpdesk for a secure connection token (key) and the token will be issued upon approval. The token is valid only for connecting to the virtual node namespace.

2. The virtual node owner installs the virtual node connector using the supplied token and assigns IP address and local port for the database server during installation.

3. The virtual node connector makes an outgoing call on port 443 to the Internet service bus (ISB) and authenticates itself against the Service Bus Access Control Services (SBACS) on startup. The ISB keeps the connection open by sending keep-alive messages periodically.

4. On the virtual node in Microsoft Azure, the virtual node owner configures a Data Source using a local port that is mapped to the Virtual Node Connector’s namespace.

5. When a request is received from the Virtual Node, it connects to the ISB using the same secure token, and then sends the request to the service bus through a TCP/IP channel secured by IPSec.

Doc Ref # & Location 5/6/2023

Virtual Node Administrator’s Guide Page 6 of 11

6. The service bus relays TCP/IP packets to the Virtual Node Connector and the connector forwards to the database server. Once the TCP/IP connection is formed, the virtual node performs the second authentication against the database server using a database account supplied by the node owner in the Data Source configuration.

In summary, the Virtual Node Connector together with Internet Service Bus establishes a point-to-point secure communication tunnel using key-based authentication and strong encryption algorithms. It solves the challenges of communicating between on-premises database server and the virtual node in the cloud environment without changing firewall configurations.

2 Security Mechanisms

There are two main aspects in guarding remote access over the Internet: user authentication and data protection. User authentication ensures that only authorized parties can access the network, and data protection safeguards the confidentiality and integrity of the communication channel. Both VPN and Internet Service Bus offer sufficient mechanisms in these areas.Common VPN authentication mechanisms are passwords or digital certificates. User authentications involving human intervention, such as biometric and multi-factor, are not feasible in our service-to-service interactions. VPN channel protection and encryptions are typically implemented through communication protocols, i.e., TLS/SSL, PPTP(Point to point tunneling protocol), or L2TP (Layer 2 tunneling protocol). Some of the newer VPN products also support IPSec (Internet Protocol Security). Authorization of access to network resources is considered outside of VPN.

The Virtual Node Connector/Internet Service Bus employees multiple layers of security to safeguard the communication channel and its access:

1. Token Authentication: The virtual node connector connects to the Internet Service Bus using a secure authentication token that is issued by Windows Azure Access Control Service. Since the token is much longer than typical password, it doesn’t suffer from the common password attacks.

2. Transport Security: All communications between the virtual node and database server are encrypted and signed using very strong IPSec (IP Protocol Security) algorithms.

3. Application Authentication: Database layer authentication is enforced by the virtual node. All incoming request to database servers are authenticated. The owner of the Virtual Node must set up Data Source using authorized database server account.

Doc Ref # & Location 5/6/2023

Virtual Node Administrator’s Guide Page 7 of 11

4. Node Access: All requests to Virtual Node must be authenticated through NAAS and service authorizations are enforced using NAAS policies.

5. Connection Privacy: The owner of the Virtual Node Connector can assign a private sub-namespace on the Internet Service Bus (specified during installation), the sub-namespace is mapped to a private local port (an integer) that is known only to the owner of the virtual node.

Unlike the low level VPN mechanism, the Internet Service Bus technology is an application level connectivity solution, which allows us to inject/implement powerful protections into the communication channel that would be otherwise not possible in typical VPN.

3 Configuration and Set Up

For the virtual node to connect to a database server in a private network using VPN, the owner of the private network must provide an external IP address and a port open to the Internet. There is typically a security review and approval process before opening firewall. On the virtual node, VPN client software must be installed in order to connect to the private network. Unfortunately, due to lack of standardization, the VPN client typically has to match the vender and version of the server software in order to be interoperable. So, there could potentially be multiple VPN clients in the virtual node environment that are not compatible with each other.

In the Internet Service Bus configuration, on the other hand, a Virtual Node Connector will be distributed to virtual node owners for installation in the private network. The virtual node connector, after installation, initiates outgoing connection to the Internet Service Bus using a secure key and negotiates an end-to-end encryption algorithm with ISB. There should be no opening port, external IP address and firewall changes for such connection. Since the ISB uses standard network protocols, one client on the virtual node will be able to interact with all virtual node connectors.

4 Attack SurfaceAttack surface, or attack vector, is the area of points where an unauthorized user could potentially break into an network environment. So, minimizing attack surface could reduce security risks in general.

Note that attack surface discussed in this section is deemed as Potential risk and there are mitigations options available.

Doc Ref # & Location 5/6/2023

Virtual Node Administrator’s Guide Page 8 of 11

4.1 Firewall holesFirewall was invented to protect a private network from unauthorized access. However, there are many situations where ports have to be opened for external access, and the ports are mapped to target devices or computers with distinct IP addresses. These ports, also referred to as firewall holes, are targets for attacks.

When VPN is used for virtual node backend connectivity, firewall must be changed to allow virtual node to access through an open port. It is possible to allow only the IP address of virtual node to get in, but the IP address may change and are not under our control unfortunately.

Using the virtual node connector, there should be no firewall changes as the secure tunnel is established through an outgoing connection to the ISB. Thus, the connection is not exposed to the internet, and it is only available to the virtual node.

4.2 Local Network Exposure

There are two major types of VPN based on network topology: point-to-site or site-to-site. While site-to-site joins two private networks together, the point-to-site allows a remote computer to join a local network (LAN). When a computer connects to a network through VPN (point-to-site), it might have accesses to many resources in the private network including printers, shared volumes and other computers within the network based on security policies. Such resource exposure is largely unnecessary for information exchange using the virtual node.

The connectivity offered by Virtual Node Connector, in contrast, has a very limited scope. The connection doesn’t have access to any other network resources in the local network domain except the target database server. So, it is a truly point-to-point secure channel that interconnects two computers. Furthermore, the connection prevents the remote client from even accessing local resources, such as hard drives and USB devices on the target computer directly. This is due to the fact that the virtual node connector relays all requests to only the database port. In other words, the connectivity is only for accessing the authorized databases on the database server. The severe limitation in access scope is one of highly preferable features of the Virtual Node Connector.

4.3 IP Address Exposure

For a client to connect to a VPN server or gateway, the server must have a public IP address that is routable over the Internet. The VPN server may allow only the specific client IP addresses to connect through IP filtering, but the client must have static public IP as well for it to work properly.

Doc Ref # & Location 5/6/2023

Virtual Node Administrator’s Guide Page 9 of 11

Virtual Node Connector makes an outgoing connection to the Internet Service Bus as a client and maintains the connection alive as a tunnel. So, there is no IP address exposed to the public Internet. The point to point encrypted channel allows only a two party communications: The virtual node and the database server via the connector.

5 Network ComplexityHaving a working VPN service involves many different network components and software services ranging from firewall, gateway, router, hub, DNS to domain controllers. It is even more challenging in configuring security aspects of the VPN to support correct protocols, encryptions and authentications in an enterprise environment. So, if you don’t have VPN already up and running, using VPN as the connectivity solution for virtual node may not be a good choice.

The situation is entire different for the Virtual Node Connector. It has a wizard-driven installer and it should be up and running without any additional configuration afterward. The only critical information required during installation is the IP address and port of a database server. The connector does have a dependency to Microsoft .NET Framework 4.0 which should already be installed in typical Windows server configuration.

6 CostsThere are two types of VPN solutions: hardware based and software based. Dedicated VPN appliances are typically more expensive with added security, but sometime software license fees could add up quickly as the number of users increases.

The Virtual Node Connector is free of charge for all Exchange Network partners. But there is a small fee, 0.09/GB at the time of this writing, for cloud bandwidth paid by the Virtual Node operator (EPA or ECOS?).

7 Standards and Interoperability

Although VPN technology has been around for quite some time, due to lack of standards and vender locking-in practices, interoperability among different VPN implementations has been a big challenge. Variations of authentication mechanisms, subtle differences in encryption algorithms, and lack of cross industry interoperability testing are plaguing deployment of VPN beyond enterprise network.

In comparison, the Internet Service Bus connectivity solution is, under the hood, based on web services and common communication protocols such as SOAP,

Doc Ref # & Location 5/6/2023

Virtual Node Administrator’s Guide Page 10 of 11

HTTP/HTTPS and IPSec, which are less susceptible to breakdowns in interoperability. As Microsoft touted in its service bus marketing material:

“Service Bus and Windows Azure Active Directory Access Control are both based on industry standards. Service Bus offers a lightweight, developer-friendly programming model that supports standard protocols such as SOAP and REST. Access Control is provided as a flexible standards-based service that supports the Web Resource Authorization Protocol (WRAP) profiles in OAuth (also known as OAuth WRAP). Access Control supports multiple credentials, including X.509 certificates, and standard protocols, including REST.”

One of the major reasons for pushing Virtual Node Connector as the preferred connectivity solution is that it offers a high level, standard based solution that can be customized based on special business and security requirements of the Exchange Network.

8 ConclusionBoth VPN and Virtual Node Connector prove to be viable connectivity solutions for Virtual Node. VPN is a classical solution and have a long history of trusts from security network engineers while Virtual Node Connector is based on the latest cloud technologies that yet to gain confidence and acceptance. Our researches indicated that Internet Service Bus/Virtual Node Connector poses a securer, simpler and more flexible solution for our backend database connectivity challenges.

9 References

1. The Windows Azure Service Bus and the Internet of Things, http://msdn.microsoft.com/en-us/magazine/dn574801.aspx, February, 2014

2. Windows Azure Network Security, http://download.microsoft.com/download/4/3/9/43902EC9-410E-4875-8800-0788BE146A3D/Windows%20Azure%20Network%20Security%20Whitepaper%20-%20FINAL.docx, November 2013. Microsoft Cooperation.

3. Securing and Authenticating a Service Bus Connection, http://msdn.microsoft.com/library/azure/dd582773.aspx, MSDN, Microsoft Cooperation.

4. Layer Two Tunneling Protocol "L2TP" , RFC 2661, W. Townsley et al.,August 1999

5. Point-to-Point Tunneling Protocol (PPTP) , RFC 2637, K. Hamzeh et al., July 1999

6. Microsoft Technet. "Virtual Private Networking: An Overview".7. Lewis, Mark. Comparing, Designing. And Deploying VPNs. Cisco Press,

20069.

Doc Ref # & Location 5/6/2023

Virtual Node Administrator’s Guide Page 11 of 11

8. Windows Azure Trust Center - Privacy . Windowsazure.com. 2011-09-15. Retrieved 2013-05-28.

9. Technical Overview of Security Features in the Windows Azure Platform , Microsoft, April, 2013.

Doc Ref # & Location 5/6/2023