VPN section first pass

Author: drbruced12

figures/Slide43.png

@@ -226,9 +226,14 @@ stored in various files in directory in the user’s home directory. For
 example, file ``~/.ssh/known_hosts`` records the keys for all the
 hosts the user has logged into, file ``~/.ssh/authorized_keys``
 contains the public keys needed to authenticate the user when logging
-into this machine (i.e., they are used on the server side), and file
-``~/.ssh/id_rsa`` contains the private keys needed to authenticate the
-user on remote machines (i.e., they are used on the client side).
+into this machine (i.e., they are used on the server side). The
+private keys needed to authenticate the user on remote machines (i.e.,
+keys that are used on the client side) are stored in a file whose name
+depends on the algorithm. For example, an RSA key would be stored in a
+file ``~/.ssh/id_rsa``; an ECDSA key would be stored in
+``~/.ssh/id_edcsa`` and so on. These files are usually encrypted with
+a secret passphrase to protect against the possibility of the private
+key being compromised by an attacker who gains access to the file.
 
 .. _fig-ssh-tunnel:
 .. figure:: figures/f08-14-9780123850591.png
@@ -387,12 +392,12 @@ we discuss below.
 ------------------------------------
 
 A virtual private network (VPN) can be built using a wide variety of
-different technolgies, but any VPN requires that we establish
+different technologies, but any VPN requires that we establish
 connectivity among a set of endpoints. The connections must
 offer some level of privacy to the principals communicating between
 those endpoints. Furthermore, to qualify as a *virtual* private
 network, a VPN creates the illusion of being dedicated to a group of
-users, even though the underlying infrastucture is shared more
+users, even though the underlying infrastructure is shared more
 widely. In practice, this means that a VPN is almost always built as
 some sort of overlay on shared infrastructure.
 
@@ -419,7 +424,8 @@ corporate office.
 
 *Site-to-Site VPNs* are generally used to interconnect the sites of an
 enterprise, which could include datacenters, main corporate offices,
-and branch offices. Figure xxy.
+and branch offices. :numref:`Figure %s <fig-sitevpn>` shows a simple
+example for three sites of difference sizes.
 
 .. _fig-sitevpn:
 .. figure:: figures/sitevpn.png
@@ -429,35 +435,208 @@ and branch offices. Figure xxy.
    A corporate VPN connects a main office, a branch office, and a datacenter.
 
 Viewed at this level of abstraction, there are obvious similarities
-between VPN classes. They are not entirely non-overlapping but they
-help us identify the key requirements. The differences become apparent
+between these VPN classes. They are not entirely non-overlapping but they
+help us identify the requirements. The differences become apparent
 when we look at the types of devices that terminate tunnels and the
 methods used to establish them.
 
-Remote access VPNs usually establish tunnels directly from a client device,
-such as a phone or a laptop, to some sort of VPN gateway or
-concentrator. Some sort of VPN client software performs this task,
-with Wireguard and OpenVPN being two examples of open source,
-multi-platform clients.
+Remote access VPNs usually establish tunnels directly from a client
+device, such as a phone or a laptop, to a device at the edge of the
+corporate network called a VPN gateway or concentrator. Some VPN
+client software performs this task, with WireGuard and OpenVPN being
+two examples of open source, multi-platform clients. There are plenty
+of proprietary options as well.
 
 OpenVPN leverages TLS to build the encrypted tunnels from client to
 server. While this mostly follows the same protocol as described in
 Chapter 6, the additional step of authenticating the client is almost
 always required in VPN use cases, unlike most Web usages of
 TLS. Client certificates may be used, but this raises the issue of how
 certificates can be reliably distributed to client devices. One option
-is that they are provisioned by a corporate IT deparment as part of
+is that they are provisioned by a corporate IT department as part of
 setting up client devices. OpenVPN also allows for other
 authentication methods including username plus password and optionally
 multi-factor authentication.
 
+WireGuard is a more recent implementation of encrypted tunnels that
+aims to address some shortcomings that have emerged over years of
+using IPsec and OpenVPN tunnels. The paper below from NDSS 2017 lays
+out the design philosophy of WireGuard. Compared to OpenVPN, it is
+less complex by virtue of reducing the set of cryptographic algorithms
+that it supports. It establishes "stateless" tunnels that are more like
+IPsec than TLS—that is, there is no transport connection to
+establish. It also uses the idea of pre-shared public keys for mutual
+authentication, similar to the approach used in SSH. Finally, it is
+implemented in the operating system kernel, another contrast to
+OpenVPN that improves performance. For further details we refer you to
+the paper. 
 
+.. admonition:: Further Reading
 
-https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/wireguard-next-generation-kernel-network-tunnel/
-
-7.4.1 Mesh VPNs
+   J. Donenfeld. `WireGuard: Next Generation Kernel Network Tunnel
+      <https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/WireGuard-next-generation-kernel-network-tunnel/>`__.
+      NDSS, 2017.
+
+One of these types of tunnels plus a gateway or concentrator to
+terminate them is pretty much all that is needed to deliver a remote
+access VPN. A concentrator is just an appliance that can handle a
+large number of VPN tunnels at once, and provides the necessary
+administrative controls for managing user accounts and interfaces for
+passing the VPN traffic on to the corporate network. Note that a
+remote access VPN will almost always have to solve the problem of how
+to get traffic through the corporate firewall. We cover firewalls in a
+later chapter, but it is generally the case that VPN traffic will be
+allowed to traverse the firewall so that the VPN user can access
+corporate resources. The problems of this approach are discussed in
+the firewalls chapter.
+
+The main difference with site-to-site VPNs is that they aim to connect
+entire networks together, not just the devices of single remote
+users. And because office buildings don't move around the way users
+do, these VPNs are relatively static. Thus, one early approach to
+building site-to-site VPNs was to simply configure tunnels statically
+from a router at the edge of one site to a router at the edge of
+another. Keys could also be statically configured. This would be OK
+for a small VPN, but as the number of sites increases, the
+configuration overhead becomes considerable. Furthermore, there is not
+likely to be an on-site routing and security expert at every branch
+office, so the configuration would have to be set once before the
+router was shipped out to the branch and after that point, changes
+become difficult, especially if the router becomes unreachable for
+some reason. On top of this, if the connectivity among sites is
+anything other than a hub and spoke, then the issue of correctly
+configuring routing protocols to forward traffic across the mesh of
+tunnels becomes significant.
+
+The complexity of configuring and managing a VPN comprised of
+encrypted tunnels is one reason why MPLS VPNs, which outsource
+most of the complexity of VPN management to a service provider, became
+such a successful service offering in the early 2000s. MPLS does not
+protect privacy using encryption, but it does solve the issues of routing
+traffic among large numbers of sites and ensures that the traffic
+belonging to one customer from does not leak to the network of another. 
+
+Several approaches to reduce the configuration overhead for VPNs using
+encrypted tunnels have appeared in recent years. With the rise of
+software-defined networking in the 2010s, several companies hit on the
+idea of using a centralized SDN controller to manage the configuration
+challenges outlined above. This approach, known as
+SD-WAN, became one of the successful commercial applications of SDN.
+
+7.4.1 Software-Defined WANs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Provisioning a VPN using MPLS, while less complex than most earlier
+options, still requires some significant local configuration of both
+the Customer Edge (CE) router located at each customer site, and the
+Provider Edge (PE) router to which that site would be connected. In
+addition, it would typically require the provisioning of a circuit
+from the customer site to the nearest point of presence for the
+appropriate Telco.
+
+With SD-WAN, the assumption is that every branch and head
+office has connectivity to the Internet. An edge router is deployed at
+each site, and a centralized control plane is used to simplify
+configuration. An enterprise wants its sites—and only its authorized
+sites—to be interconnected by the VPN, and it typically wants to apply
+a set of policies regarding security, traffic prioritization, access
+to shared services, and so on. These policies are input to a central
+controller, which can then push out all the necessary configuration to
+the edge router located at the appropriate office. Rather than
+manually configuring a router or (multiple routers) every time a new site is added, or
+configuring tunnels by hand, it is possible to achieve "zero-touch"
+provisioning: an appliance is shipped to the new site with nothing
+more than a certificate and an address to contact, which it then uses
+to contact the central controller and obtain all the configuration it
+needs.  Anything that is necessary to build site-to-site tunnels—IP
+addresses, routing configuration, secrets, etc.—can be pushed out from
+the central controller to the edge router. Changes to configuration or
+policies, which might affect many sites, are input centrally and
+pushed out to all affected sites.  The idea is illustrated in
+:numref:`Figure %s <fig-sd-wan>`.
+
+.. _fig-sd-wan:
+.. figure:: figures/Slide43.png
+    :width: 600px
+    :align: center
+
+    An SD-WAN controller receives policies centrally and pushes them
+    out to edge switches at various sites. The switches build an
+    overlay of tunnels over the Internet or other physical networks,
+    and implement policies including allowing direct access to cloud
+    services.
+
+
+It can be hard to determine exactly what properties of SD-WAN have
+made it popular, especially as vendors promote the features that
+distinguish their solution from the others. Unlike much of SDN, the
+control plane protocols used in SD-WAN tend to be proprietary. But it
+is certainly true that SD-WAN did enough to reduce the complexity of
+building and managing encrypted tunnels to drive adoption of this
+approach, often replacing MPLS-based VPNs.
+
+An important benefit offered by SD-WAN over many earlier VPN
+approaches was to simplify the task of managing access from a branch
+office to a cloud service offered by a third party. It
+seems natural that you would choose to access those services directly
+from an Internet-connected branch, but traditional VPNs would
+*backhaul* traffic to a central site before sending it out to the
+Internet, precisely so that security policies could be controlled
+centrally. With SD-WAN, the central control over security policy is achieved, while the data
+plane remains fully distributed–meaning that remote sites can directly
+connect to the cloud services without backhaul.
+
+
+7.4.2 Mesh VPNs
 ~~~~~~~~~~~~~~~
 
+Another approach to VPNs that combines some of the features of remote
+access VPNs and site-to-site VPNs is referred to as Mesh VPNs. Like a
+remote VPN, a mesh VPN builds tunnels that terminate directly on
+client devices. However, rather than connecting the other end of the
+tunnel to a central VPN gateway or concentrator, mesh VPNs build a
+mesh of tunnels among client devices. The effect is to create a VPN
+that interconnects the set of authorized client devices almost as if
+they were on the same private LAN, even though they can be located
+anywhere in the Internet.
+
+There are numerous implementations of the mesh VPN approach, with
+Tailscale being a well-known implementation that contains a mixture of
+open source and proprietary components. Tailscale is
+built using WireGuard as the tunneling protocol, and adds a control
+and management plane to ease the task of setting up and managing the
+mesh. For example, WireGuard makes the assumption that public keys
+have been set up at the tunnel endpoints before the tunnel is
+established; Tailscale supplies a central coordination service to
+generate and distribute those keys.
+
+One notable aspect of Tailscale is that it assumes that client devices
+are likely to be sitting in networks that use private addresses and
+are connected to the Internet through a NAT (network address
+translation) device. This problem doesn't exist when building a tunnel
+to a VPN concentrator with a public IP address, or between a pair of
+edge routers, but it has to be solved if you want to build
+client-to-client tunnels. There are quite a few details to getting
+this to work, especially given that NAT devices don't all behave the
+same way, and there may be firewalls to travese as well. An IETF
+standard called STUN (Session Traversal Utilities for NAT) plays an
+important part, and the centralized control plane helps to resolve
+some of the more difficult corner cases. You can read more about the
+issues to be solved in the blog post listed below.
+
+
+Because mesh VPNs build tunnels all the way from client to client,
+they also avoid one of the drawbacks of traditional VPNs, which is the
+existence of trusted network zones, such as the network behind the
+firewall to which a remote access or site-to-site VPN would give
+access. In this respect they embrace the idea of zero trust
+networking, a topic we discuss in chapter 9.
+
+
+.. admonition:: Further Reading
+
+   A. Pennarun. `How Tailscale Works <https://tailscale.com/blog/how-tailscale-works>`__.
+      Tailscale blog, 2020.
 
 
 7.5 Web Authentication (WebAuthn) and Passkeys