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
1.0.00
Description of Change
Initial Draft
ii
Change
Effective Date
Change
Entered By
April 1, 2014
Dr. Yunhao
Zhang
Virtual Node Administrator’s Guide
Page 3 of 11
Table of Contents
1
Internet Service Bus and Virtual Private Network ..................................... 4
1.1
What Is VPN and Internet Service Bus................................................ 4
1.2
The Virtual Node Connector ................................................................ 4
2
Security Mechanisms .................................................................................. 6
3
Configuration and Set Up ............................................................................ 7
4
Attack Surface .............................................................................................. 7
4.1
Firewall holes ........................................................................................ 8
4.2
Local Network Exposure ...................................................................... 8
4.3
IP Address Exposure............................................................................ 8
5
Network Complexity .................................................................................... 9
6
Costs ............................................................................................................. 9
7
Standards and Interoperability ................................................................... 9
8
Conclusion ................................................................................................. 10
9
References ................................................................................................. 10
Doc Ref # & Location
2/17/2016
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
2/17/2016
Virtual Node Administrator’s Guide
Page 5 of 11
sb://nodedb.servicebus.windows.net/
Azure Service Bus
Service Bus Client
Service Bus Access
Authentication
Control Service
(Access Token) Message Broker
Outgoing IPSec Tunnel
TCP Relay Transport Security
(Sign/Encrypt)
TCP Relay Transport Security
(Sign/Encrypt)
Service Bus
Connector
Service Bus
Connector
Virtual Node
QA Server
ORACLE/SQL Server
Database Server
NAAS
ORACLE
Database
Virtual Node in Azure Cloud
Private Enterprise Environment
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
2/17/2016
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 multifactor, 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
2/17/2016
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 Surface
Attack 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
2/17/2016
Virtual Node Administrator’s Guide
4.1
Page 8 of 11
Firewall holes
Firewall 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
2/17/2016
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 Complexity
Having 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 wizarddriven 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 Costs
There 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
2/17/2016
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 Conclusion
Both 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-487588000788BE146A3D/Windows%20Azure%20Network%20Security%20Whitep
aper%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".
Doc Ref # & Location
2/17/2016
Virtual Node Administrator’s Guide
Page 11 of 11
7. Lewis, Mark. Comparing, Designing. And Deploying VPNs. Cisco Press,
20069.
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
2/17/2016