move DoS section to infra and update intro to chapter

firewall.rst

@@ -516,7 +516,7 @@ example, the systems related to heating and cooling don't need access
 to the systems where customer credit card details are stored. A
 default policy of no access can also be established, with explicit
 configuration then required to create precisely specified allowable
-commuincation patterns between specific devices.
+communication patterns between specific devices.
 
 The VPN example above provides motivation for a different approach to
 handling users and devices outside of the confines of a traditional
@@ -673,104 +673,3 @@ firewall, we might not require an IDS or IPS. However, knowing that
 firewalls will never block all forms of malicious traffic leads to the
 conclusion that an IDS/IPS is worth having as a second line of
 defense.
-
-9.5.2 DoS Mitigation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Sometimes unwanted traffic is simply trying to consume resources,
-rather than exploit a vulnerability. Such attacks—or as they are
-commonly known, *Denial of Service (DoS)* attacks—threaten
-availability (as opposed to confidentiality or integrity). They
-typically involve an adversary trying to overwhelm "good" resources
-(link bandwidth, packet forwarding rates, server response throughput)
-with traffic generated by "bad" resources (botnets constructed from a
-distributed collection of compromised devices). Firewalls and other
-security appliances help protect devices from being compromised in the
-first place, but because they are not perfect (a human is often the
-weakest link), we also need ways to mitigate the impact of
-*Distributed DoS (DDoS)* attacks.
-
-Keeping in mind that DDoS traffic typically looks legitimate (there's
-just too much of it), the DDoS challenge is addressed by two general
-countermeasures. Note that the best we can hope for is to mitigate the
-impact of such attacks; there is no cure-all. This is easy to
-understand at an intuitive level: an appliance defending against DoS
-attacks is itself a kind of resource that can be DoSed.
-
-The first countermeasure is to absorb potential attacks with even
-greater resources than the adversary is able to muster. For web
-content, this is done using the same mechanism as is used to absorb
-flash crowds of legitimate traffic: a *Content Distribution Network
-(CDN).* The idea is to replicate content (whether it's a movie or a
-critical piece of infrastructure metadata) across many
-widely-distributed servers. As long as the aggregate capacity of these
-servers is greater than the aggregate capacity of the botnet—and the
-CDN does a good job spreading requests across the available
-servers—content remains available. This notion of *aggregate* capacity
-generalizes beyond web servers responding to HTTP GET requests. A
-network is itself a distributed collection of forwarding and
-transmission resources, engineered to distribute those resources in a
-way that avoids vulnerable bottlenecks.
-
-The second countermeasure is to filter malicious traffic as early
-(close to the source) as possible. If a DoS attack comes from a single
-source, then it is easy to "block" traffic from that source at an
-ingress to a network you control. This is why DoS attacks are
-typically distributed.  Dropping (or rate limiting) attack packets at
-the boundary router (or firewall) for an enterprise is better than
-allowing those packets to flood the local network and reach a victim
-server(s), but the more widely distributed the periphery of your
-network, the earlier you can filter malicious packets. And drawing on
-the first countermeasure, the more widely distributed your network
-resources are, the greater your aggregate filtering capacity.  Global
-overlay networks, as provided by companies like Cloudflare and Fastly,
-offer a combination of content distribution and distributed packet
-filtering.  These are commercial products, with many proprietary
-details, but the general principles outlined here explain their
-underlying strategy.
-
-Finally, note that this brief overview of DoS attacks is heavily
-slanted towards web content, which is to say, attackers are taking
-advantage of the HTTP protocol—significant server resources are
-consumed responding to bogus GET requests. In general, all protocols
-are vulnerable to insidious combinations of packets. For example, IP
-can be attacked with a "Christmas Tree" packet, one that has multiple
-options turned on (i.e., is "lit up like a Christmas tree"), where
-each option requires IP to execute instructions it would not normally
-execute to forward a typical packet. A router with a naive
-implementation of IP would be at risk of not being able to forward
-packets at line speed if it's busy processing the options. For this
-reason, routers typically implement a "fast path" that is able to keep
-pace with line speeds and a "slow path" that processes exceptional
-packets, and most importantly, they quickly determine which path each
-packet should be assigned to. This is a variant of the second
-countermeasure—decide early to protect resources.
-
-Another well-known example is a "SYN Flood" targeting TCP, whereby an
-attacker floods a server with SYN requests without any intent to
-complete the TCP handshake and actually establish a connection.  This
-overloads TCP's connection table, potentially denying connections to
-legitimate clients. An IDS/IPS can help protect servers since a flood
-of SYN packets is anomalous behavior, but individual servers can also
-limit the impact by encoding connection state in the sequence number
-included in the SYN+ACK they send back to the client—a "SYN cookie" of
-sorts—and then allocate connection state locally only after the client
-goes to the trouble of correctly ACK'ing that packet. This is a
-variant of the first countermeasure in that it forces the attacker to
-use additional resources.
-
-These examples are just two of many illustrating the need to program
-defensively. This is especially true for protocols since they are
-purposely designed to process messages from remote sources, exposing
-them to attempts to crash, hack, or as in the case of DoS attacks,
-simply consume the system. This topic ventures outside the scope of
-the book, but the following reference explores one approach to
-addressing the challenge.
-
-.. admonition:: Further Reading
-
-   X. Qie, R. Pang, and L. Peterson. `Defensive Programming: Using an Annotation Toolkit to Build
-   DoS-Resistant Software
-   <https://www.usenix.org/conference/osdi-02/defensive-programming-using-annotation-toolkit-build-dos-resistant-software>`__.
-   Proceedings of the Fifth Symposium on Operating System Design and Implementation
-   (OSDI). Usenix. December 2002.

infra.rst

@@ -12,6 +12,21 @@ systems routinely come under attack. There are efforts underway to
 make them more resistant to attacks, as we discuss in the following
 sections.
 
+This following discussion builds on some of the concepts introduced in previous
+chapters. Notably, the concept of public key infrastructure (PKI),
+which we introduced in Chapter 4 and which underpins the operation of TLS,
+plays an important role in securing infrastructure as well. While the
+principles of certificates and chains of trust apply in any PKI, the
+specifics of how certificates are distributed and what they refer to
+are different in each application. We describe the different
+approaches to PKI for infrastructure services in the following sections.
+
+Availability of infrastructure, including resistance to
+denial-of-service (DoS) attacks, is clearly important to the operation
+of the Internet. Mitigation of such attacks is increasingly handled by
+distributed infrastructure like content distribution networks (CDNs),
+as we discuss in the final section of this chapter.
+
 
 8.1 BGP and Routing Security
 ----------------------------
@@ -841,8 +856,8 @@ the key used to verify the signature. That's a significant increase in
 the number of bytes returned for a single query. The mitigation
 techniques outlined above—source address filtering and DoS
 prevention—can still be applied. Additionally, there is an advantage
-to using crytographic algorithms that use relatively short keys. For
-this reason the EDCSA algorithm may be preferred to RSA, since EDCSA
+to using cryptographic algorithms that use relatively short keys. For
+this reason the ECDSA algorithm may be preferred to RSA, since ECDSA
 keys are considerably shorter than RSA keys for comparable levels of
 security.
 
@@ -949,10 +964,114 @@ for the target function.
    <https://doi.org/10.1145/3340301.3341128>`__. Proc. 2019 Applied
    Networking Research Workshop, 2019.
 
-.. notes
 
+8.3 DoS Mitigation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In much of this book we have focused on attacks against the
+confidentiality or integrity of information, but we also need to
+concern ourselves with availability of both the end systems (such as
+web sites) and the infrastructure of the network itself.  Commonly
+known as *Denial of Service (DoS)* attacks, such attacks typically
+involve an adversary trying to overwhelm "good" resources (link
+bandwidth, packet forwarding rates, server response throughput) with
+traffic generated by "bad" resources (such as botnets constructed from
+a distributed collection of compromised devices). Patching of
+vulnerabilities and the deployment of security appliances such as
+firewalls can help protect devices from being compromised in the first
+place, but they are not perfect—new vulnerabilities appear constantly
+and a human is often the weakest link. Hence we also need ways to
+mitigate the impact of *Distributed DoS (DDoS)* attacks. This is
+another example of defense in depth: protect devices against being
+compromised, and also protect against the attacks launched by
+compromised devices.
+
+Keeping in mind that DDoS traffic typically looks legitimate (there's
+just too much of it), the DDoS challenge is addressed by two general
+countermeasures. Note that the best we can hope for is to mitigate the
+impact of such attacks; there is no cure-all. This is easy to
+understand at an intuitive level: any systems that we deploy to defend against DoS
+attacks represent a kind of resource that can itself be DoSed. Thus DoS
+mitigation solutions tend to be distributed themselves.
+
+The first countermeasure is to absorb potential attacks with even
+greater resources than the adversary is able to muster. For web
+content, this is done using the same mechanism as is used to absorb
+flash crowds of legitimate traffic: a *Content Distribution Network
+(CDN).* The idea is to replicate content (whether it's a movie or a
+critical piece of infrastructure metadata) across many
+widely-distributed servers. As long as the aggregate capacity of these
+servers is greater than the aggregate capacity of the botnet—and the
+CDN does a good job spreading requests across the available
+servers—content remains available. This notion of *aggregate* capacity
+generalizes beyond web servers responding to HTTP GET requests. A
+network is itself a distributed collection of forwarding and
+transmission resources, engineered to distribute those resources in a
+way that avoids vulnerable bottlenecks. The DNS, for example, is
+itself a highly distributed system designed to avoid single points of
+failure with redundancy at all levels of the hierarchy.
+
+The second countermeasure is to filter malicious traffic as early
+(close to the source) as possible. If a DoS attack comes from a single
+source, then it is easy to "block" traffic from that source at an
+ingress to a network you control. This is why DoS attacks are
+typically distributed.  Dropping (or rate limiting) attack packets at
+the boundary router (or firewall) for an enterprise or service
+provider is better than allowing those packets to flood the core of
+the network and reach a victim server(s), but the more widely
+distributed the periphery of your network, the earlier you can filter
+malicious packets. And drawing on the first countermeasure, the more
+widely distributed your network resources are, the greater your
+aggregate filtering capacity.  Global overlay networks, as provided by
+companies like Cloudflare and Fastly, offer a combination of content
+distribution and distributed packet filtering.  These are commercial
+products, with many proprietary details, but the general principles
+outlined here explain their underlying strategy.
+
+Finally, note that DoS attacks highlight the never-ending nature of
+tackling security. Almost any protocol or system can by a target of a
+DoS attack. We discussed the role of DNS in amplification of DoS attacks in the
+preceding section. When attacks are launched against web sites,
+attackers are often taking advantage of the HTTP protocol—significant server
+resources are consumed responding to bogus GET requests. As a very
+different example, the forwarding of IP packets can be attacked with a
+"Christmas Tree" packet, one that has multiple options turned on
+(i.e., is "lit up like a Christmas tree"), where each option requires
+IP to execute instructions it would not normally execute to forward a
+typical packet. A router with a naive implementation of IP would be at
+risk of not being able to forward packets at line speed if it's busy
+processing the options. For this reason, routers typically implement a
+"fast path" that is able to keep pace with line speeds and a "slow
+path" that processes exceptional packets, and most importantly, they
+quickly determine which path each packet should be assigned to. This
+is a variant of the second countermeasure—decide early to protect
+resources.
+
+Another well-known example is a "SYN Flood" targeting TCP, whereby an
+attacker floods a server with SYN requests without any intent to
+complete the TCP handshake and actually establish a connection.  This
+overloads TCP's connection table, potentially denying connections to
+legitimate clients. An IDS/IPS can help protect servers since a flood
+of SYN packets is anomalous behavior, but individual servers can also
+limit the impact by encoding connection state in the sequence number
+included in the SYN+ACK they send back to the client—a "SYN cookie" of
+sorts—and then allocate connection state locally only after the client
+goes to the trouble of correctly ACK'ing that packet. This is a
+variant of the first countermeasure in that it forces the attacker to
+use additional resources.
+
+These examples are just a few of many illustrating the need to program
+defensively. This is especially true for protocols since they are
+purposely designed to process messages from remote sources, exposing
+them to attempts to crash, hack, or as in the case of DoS attacks,
+simply consume the system. This topic ventures outside the scope of
+the book, but the following reference explores one approach to
+addressing the challenge.
 
-   adoption of RPKI vs DNSSEC - the difference between detecting
-   corrupt info vs. preventing spread of corrupt info
+.. admonition:: Further Reading
 
-   compare infra mechanisms vs e2e, notably TLS
+   X. Qie, R. Pang, and L. Peterson. `Defensive Programming: Using an Annotation Toolkit to Build
+   DoS-Resistant Software
+   <https://www.usenix.org/conference/osdi-02/defensive-programming-using-annotation-toolkit-build-dos-resistant-software>`__.
+   Proceedings of the Fifth Symposium on Operating System Design and Implementation
+   (OSDI). Usenix. December 2002.