Add VPN section to Subsystems chapter

systems.rst

@@ -6,9 +6,6 @@ Chapter 7.  Subsystem Security
    general role open source plays in helping secure the Internet --
    lots of eyes on the code).
 
-.. Key parts of this chapter moving out to standalone chapters.
-   It's likely also the case that these are "Other" Example Systems,
-   since new chapters are system focused.
 
 Having focused on how to use the available cryptographic and
 authentication building blocks to secure the transport layer—to the
@@ -229,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
@@ -275,7 +277,8 @@ securing the network infrastructure (as discussed in the next
 chapter), today IPsec is most commonly used to implement secure
 tunnels running on top of the public Internet. These tunnels are often
 part of a Virtual Private Network (VPN), for example, connecting a
-remote user to their "home" enterprise network.
+remote user to their "home" enterprise network. We turn our attention
+to VPNs in the next section.
 
 IPsec is really a framework (as opposed to a single protocol or
 system) for providing a broad set of security services. It provides
@@ -380,12 +383,263 @@ that traverses this virtual link and ensuring that no spurious data is
 received at the far end of the tunnel. Furthermore, tunnels can
 provide traffic confidentiality, since multiplexing multiple flows
 through a single tunnel obscures information about how much traffic is
-flowing between particular endpoints. And as mentioned in the
-introduction to this section, a network of such tunnels can be used to
-implement an entire virtual private network. Hosts communicating over
-a VPN need not even be aware that it exists.
+flowing between particular endpoints. As noted above, a network of
+such tunnels can be used to implement an entire virtual private
+network. But there is more to VPNs than just tunneling mechanisms, as
+we discuss below.
+
+7.4 Virtual Private Networks (VPNs)
+------------------------------------
+
+A virtual private network (VPN) can be built using a wide variety of
+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 infrastructure is shared more
+widely. In practice, this means that a VPN is almost always built as
+some sort of overlay on shared infrastructure.
+
+The type of VPN that we will focus on here uses
+tunneling technologies such as IPsec or SSL to provide private
+connectivity across the shared infrastructure of the Internet. We have
+already seen how encrypted tunnels can be established, but tunnels are
+just a building block for VPNs. VPN requirements vary among
+different use cases, so we begin our discussion by looking at some of
+the most common uses for VPNs.
+
+*Remote Access VPNs* are commonly used to support remote workers,
+telecommuters, or contractors who need access to corporate
+resources. :numref:`Figure %s <fig-remotevpn>` shows a simple example
+where a remote user tunnels across the Internet to connect to their
+corporate office.
+
+.. _fig-remotevpn:
+.. figure:: figures/remotevpn.png
+   :width: 600px
+   :align: center
+
+   A remote user connects via a tunnel to a corporate site.
+
+*Site-to-Site VPNs* are generally used to interconnect the sites of an
+enterprise, which could include datacenters, main corporate offices,
+and branch offices. :numref:`Figure %s <fig-sitevpn>` shows a simple
+example for three sites of difference sizes.
+
+.. _fig-sitevpn:
+.. figure:: figures/sitevpn.png
+   :width: 600px
+   :align: center
+
+   A corporate VPN connects a main office, a branch office, and a datacenter.
+
+Viewed at this level of abstraction, there are obvious similarities
+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 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 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
+
+   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.4 Web Authentication (WebAuthn) and Passkeys
+7.5 Web Authentication (WebAuthn) and Passkeys
 ----------------------------------------------------------------
 
 While public key cryptography has been well understood for decades,
@@ -531,7 +785,7 @@ sites. Those who have led their development hope that they start to
 replace the ubiquitous password for user authentication.
 
 
-7.5 Wireless Security
+7.6 Wireless Security
 --------------------------------------------
 
 Wireless links are particularly exposed to security threats due to the
@@ -550,7 +804,7 @@ redundant. Not all users are that careful, of course, but there are
 also control packets exchanged between the wireless device and the
 wired infrastructure, and that communication must be secured.
 
-7.5.1  Wi-Fi (802.11i)
+7.6.1  Wi-Fi (802.11i)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 It has long been understood how easy it is for an employee of a
@@ -648,7 +902,7 @@ is subsequently encrypted along with the plaintext in order to prevent
 birthday attacks, which depend on finding different messages with the
 same authenticator.
 
-7.5.2  Mobile Cellular Network
+7.6.2  Mobile Cellular Network
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The other widely used wireless networking technology is the Mobile