Merge branch 'master' of github.com:cnp3/ebook

AUTHORS

@@ -44,6 +44,6 @@ The first and second versions of the e-book were developed on github. A lot of t
 
 If you send a pull request to the third edition of the e-book, please add your name below:
 
- -
+ - Greg Skinner
 
 

README.md

@@ -31,7 +31,7 @@ This is the simplest way to contribute. If you spot a small error, a typo or wou
 
  - We use American English spelling. There are automated travis tests that will automatically verify that your pull-request passes the spell check. If not, update your pull request. If you introduce a new word that is not recognized by the standard directory, you can either add it as a spelling directive in the file where is appears (see e.g. the bottom of the `bibliography.rst` file) or include it in the `wordlist.dict` file which contains the new words that are used in different files.
  - When citing references, please update the file `bibliography.rst`. Please use the same style as the one used in the file and add an hyperlink to the paper title that points to a stable URL, e.g. a DOI
- - Make sure that your update builds correctly using sphinx. You can check the result of the travis tests of your pull request on github.
+ - Make sure that your update builds correctly using sphinx. There are now github actions that check the spelling and then build the pdf, epub and HTML versions of the ebook automatically. 
 
 ### Proposing new sections
 

bibliography.rst

@@ -325,6 +325,7 @@ Whenever possible, the bibliography includes stable hypertext links to the refer
 .. [Russel06] Russell A., `Rough Consensus and Running Code and the Internet-OSI Standards War <https://dx.doi.org/10.1109/MAHC.2006.42>`_, IEEE Annals of the History of Computing, July-September 2006 
 .. .. [SAO1990] Sidhu, G., Andrews, R., Oppenheimer, A., `Inside AppleTalk <ftp://ftp.turingbirds.com/electronics/books/buses_networks/apple_localtalk.pdf>`_, Addison-Wesley, 1990 
 .. [SARK2002] Subramanian, L., Agarwal, S., Rexford, J., Katz, R.. .. `Characterizing the Internet hierarchy from multiple vantage points <https://dx.doi.org/10.1109/INFCOM.2002.1019307>`_. In IEEE INFOCOM, 2002 
+.. [Schneier1996] Schneier, B., `Applied Cryptography: Protocols, Algorithms, and Source Code in C`_, Second Edition, Wiley, 1996
 .. [Sechrest] Sechrest, S., `An Introductory 4.4BSD Interprocess Communication Tutorial <http://docs.freebsd.org/44doc/psd/20.ipctut/paper.pdf>`_, 4.4BSD Programmer's Supplementary Documentation 
 .. [SG1990] Scheifler, R., Gettys, J., `X Window System: The Complete Reference to Xlib <https://www.x.org/releases/current/doc/xproto/x11protocol.html>`_, X Protocol, ICCCM, XLFD, X Version 11, Release 4, Digital Press
 .. [SGP98] Stone, J., Greenwald, M., Partridge, C., and Hughes, J., `Performance of checksums and CRC's over real data <https://dx.doi.org/10.1109/90.731187>`_. IEEE/ACM Transactions Networking 6, 5 (Oct. 1998), 529-543. 
@@ -671,6 +672,7 @@ Whenever possible, the bibliography includes stable hypertext links to the refer
    Savola
    Scharf
    Scheifler
+   Schneier
    Schulzrinne
    Scudder
    Sechrest

preface.rst

@@ -113,6 +113,8 @@ The `first edition <https://www.computer-networking.info/firstedition.html>`_ of
     Saylor
     Stephane
     Bortzmeyer
+    Greg
+    Skinner
 
 Over the years, students and colleagues contributed to parts of the text, including:
 
@@ -169,6 +171,7 @@ The main contributors to the third edition were `Olivier Bonaventure`_ and `Quen
  - Nicolas Rosar
  - Gauthier de Moffarts
  - Marcin Wilk
+ - Greg Skinner
 
 
 The entire source code for the ebook is available on `https://github.com/CNP3/ebook <https://github.com/CNP3/ebook>`_ If you spot any error, typo or want to improve the ebook, please add issues or suggest pull requests.

protocols/ssh.rst

@@ -132,8 +132,11 @@ Once the cryptographic algorithms have been negotiated, the key exchange algorit
 used to negotiate a secret key that will be shared by the client and the server.
 These key exchange algorithms include some variations over
 the basic algorithms. As an example, let us analyze how the
-Diffie Hellman key exchange algorithm is used within the
-``ssh`` protocol. In this case, each host has both a private and a public key.
+Diffie-Hellman key exchange algorithm is used within the
+``ssh`` protocol. In this case, each host has both a private and a public key.  (Note that
+:math:`g` is a generator for the subgroup of the Galois field of order :math:`p`, where
+:math:`p` is a prime number, and || is the concatenation operator.  For additional background
+information, see [Schneier1996]_.)
 
  - the client generates the random number :math:`a` and sends
    :math:`A=g^{a} \mod p` to the server
@@ -144,11 +147,11 @@ Diffie Hellman key exchange algorithm is used within the
    messages sent by the client (resp. server), :math:`KEX\_INIT_{Client}`
    (resp.  :math:`KEX\_INIT_{Server}`) is the key exchange message sent by
    the client (resp. server) and :math:`A`, :math:`B` and :math:`K` are the
-   messages of the Diffie Hellman key exchange
+   messages of the Diffie-Hellman key exchange
  - the client can recompute :math:`K=A^{b} \mod p` and verify the
    signature provided by the server
 
-This is a slightly modified authenticated Diffie Hellman key exchange
+This is a slightly modified authenticated Diffie-Hellman key exchange
 with two interesting points. The first point is that
 when the server authenticates the key exchange it does not provide a
 certificate. This is because ``ssh`` assumes that the client will store
@@ -171,7 +174,7 @@ has been upgraded and that a new key has been generated during this upgrade.
 .. index:: downgrade attack
 
 The second point is that the server authenticates not only the result
-of the Diffie Hellman exchange but also a hash of all the information
+of the Diffie-Hellman exchange but also a hash of all the information
 sent and received during the exchange. This is important to prevent
 `downgrade attacks`. A `downgrade attack` is an attack where an
 active attacker modifies the messages sent by the communicating hosts
@@ -192,7 +195,7 @@ is a technique that is frequently used to prevent downgrade attacks.
 
 .. note:: Single use keys
 
-   Thanks to the Diffie Hellman key exchange, the client and the
+   Thanks to the Diffie-Hellman key exchange, the client and the
    servers share key :math:`K`. A naive implementation would probably
    directly use this key for all the cryptographic algorithms that
    have been negotiated for this session. Like most security protocols,
@@ -285,7 +288,7 @@ command on ``computer2``, she can create an ``ssh`` session on this computer
 and type (again) her password. With the host-based authentication scheme,
 ``computer1`` signs a message with its private key to confirm that
 it has already authenticated Alice. ``computer2`` would then accept
-Alice's session without asking her credentials.
+Alice's session without asking for her credentials.
 
 The ``ssh`` protocol includes other features that are beyond the
 scope of this book. Additional details may be found in [BS2005]_.

protocols/tcp.rst

@@ -54,7 +54,7 @@ A TCP header contains the following fields :
 
  - the `checksum` field contains the value of the Internet checksum computed over the entire TCP segment and a pseudo-header as with UDP
  - the `Reserved` field was initially reserved for future utilization. It is now used by :rfc:`3168`.
- - the `TCP Header Length` (THL) or `Data Offset` field is a four bits field that indicates the size of the TCP header in 32 bit words. The maximum size of the TCP header is thus 64 bytes.
+ - the `TCP Header Length` (THL) or `Data Offset` field is a four-bit field that indicates the size of the TCP header in 32 bit words. The maximum size of the TCP header is thus 64 bytes.
  - the `Optional header extension` is used to add optional information to the TCP header. Thanks to this header extension, it is possible to add new fields to the TCP header that were not planned in the original specification. This allowed TCP to evolve since the early eighties. The details of the TCP header extension are explained in sections :ref:`TCPOpen` and :ref:`TCPReliable`.
 
     .. _fig-tcpports:
@@ -108,15 +108,15 @@ TCP connection establishment
 
 .. index:: TCP Connection establishment, TCP SYN, TCP SYN+ACK
 
-A TCP connection is established by using a three-way handshake. The connection establishment phase uses the `sequence number`, the `acknowledgment number` and the `SYN` flag. When a TCP connection is established, the two communicating hosts negotiate the initial sequence number to be used in both directions of the connection. For this, each TCP entity maintains a 32 bits counter, which is supposed to be incremented by one at least every 4 microseconds and after each connection establishment [#ftcpclock]_. When a client host wants to open a TCP connection with a server host, it creates a TCP segment with :
+A TCP connection is established by using a three-way handshake. The connection establishment phase uses the `sequence number`, the `acknowledgment number` and the `SYN` flag. When a TCP connection is established, the two communicating hosts negotiate the initial sequence number to be used in both directions of the connection. For this, each TCP entity maintains a 32-bit counter, which is supposed to be incremented by one at least every 4 microseconds and after each connection establishment [#ftcpclock]_. When a client host wants to open a TCP connection with a server host, it creates a TCP segment with :
 
  - the `SYN` flag set
- - the `sequence number` set to the current value of the 32 bits counter of the client host's TCP entity
+ - the `sequence number` set to the current value of the 32-bit counter of the client host's TCP entity
 
 Upon reception of this segment (which is often called a `SYN segment`), the server host replies with a segment containing :
 
  - the `SYN` flag set
- - the `sequence number` set to the current value of the 32 bits counter of the server host's TCP entity
+ - the `sequence number` set to the current value of the 32-bit counter of the server host's TCP entity
  - the `ACK` flag set
  - the `acknowledgment number` set to the `sequence number` of the received `SYN` segment incremented by 1 :math:`\pmod{2^{32}}`. When a TCP entity sends a segment having `x+1` as acknowledgment number, this indicates that it has received all data up to and including sequence number `x` and that it is expecting data having sequence number `x+1`. As the `SYN` flag was set in a segment having sequence number `x`, this implies that setting the `SYN` flag in a segment consumes one sequence number.
 
@@ -144,7 +144,7 @@ In the figure above, the connection is considered to be established by the clien
 
   ISN = M + H(localhost, localport, remotehost, remoteport, secret).
 
- where `M` is the current value of the TCP clock and `H` is a cryptographic hash function. `localhost` and `remotehost` (resp. `localport` and `remoteport` ) are the IP addresses (port numbers) of the local and remote host and `secret` is a random number only known by the server. This method allows the server to use different ISNs for different clients at the same time. `Measurements <http://lcamtuf.coredump.cx/newtcp/>`_ performed with the first implementations of this technique showed that it was difficult to implement it correctly, but today's TCP implementation now generate good ISNs.
+ where `M` is the current value of the TCP clock and `H` is a cryptographic hash function. `localhost` and `remotehost` (resp. `localport` and `remoteport` ) are the IP addresses (port numbers) of the local and remote host and `secret` is a random number only known by the server. This method allows the server to use different ISNs for different clients at the same time. `Measurements <http://lcamtuf.coredump.cx/newtcp/>`_ performed with the first implementations of this technique showed that it was difficult to implement it correctly, but today's TCP implementations now generate good ISNs.
 
 .. index:: TCP RST
 
@@ -189,13 +189,13 @@ Apart from these two paths in the TCP connection establishment FSM, there is a t
 
 .. topic:: Denial of Service attacks
 
- When a TCP entity opens a TCP connection, it creates a Transmission Control Block (:term:`TCB`). The TCB contains the entire state that is maintained by the TCP entity for each TCP connection. During connection establishment, the TCB contains the local IP address, the remote IP address, the local port number, the remote port number, the current local sequence number and the last sequence number received from the remote entity. Until the mid 1990s, TCP implementations had a limit on the number of TCP connections that could be in the `SYN RCVD` state at a given time. Many implementations set this limit to about 100 TCBs. This limit was considered sufficient even for heavily load http servers given the small delay between the reception of a `SYN` segment and the reception of the `ACK` segment that terminates the establishment of the TCP connection. When the limit of 100 TCBs in the `SYN Rcvd` state is reached, the TCP entity discards all received TCP `SYN` segments that do not correspond to an existing TCB.
+ When a TCP entity opens a TCP connection, it creates a Transmission Control Block (:term:`TCB`). The TCB contains the entire state that is maintained by the TCP entity for each TCP connection. During connection establishment, the TCB contains the local IP address, the remote IP address, the local port number, the remote port number, the current local sequence number and the last sequence number received from the remote entity. Until the mid-1990s, TCP implementations had a limit on the number of TCP connections that could be in the `SYN RCVD` state at a given time. Many implementations set this limit to about 100 TCBs. This limit was considered sufficient even for heavily loaded HTTP servers given the small delay between the reception of a `SYN` segment and the reception of the `ACK` segment that terminates the establishment of the TCP connection. When the limit of 100 TCBs in the `SYN Rcvd` state is reached, the TCP entity discards all received TCP `SYN` segments that do not correspond to an existing TCB.
 
- This limit of 100 TCBs in the `SYN Rcvd` state was chosen to protect the TCP entity from the risk of overloading its memory with too many TCBs in the `SYN Rcvd` state. However, it was also the reason for a new type of Denial of Service (DoS) attack :rfc:`4987`. A DoS attack is defined as an attack where an attacker can render a resource unavailable in the network. For example, an attacker may cause a DoS attack on a 2 Mbps link used by a company by sending more than 2 Mbps of packets through this link. In this case, the DoS attack was more subtle. As a TCP entity discards all received `SYN` segments as soon as it has 100 TCBs in the `SYN Rcvd` state, an attacker simply had to send a few 100 `SYN` segments every second to a server and never reply to the received `SYN+ACK` segments. To avoid being caught, attackers were of course sending these `SYN` segments with a different address than their own IP address [#fspoofing]_. On most TCP implementations, once a TCB entered the `SYN Rcvd` state, it remained in this state for several seconds, waiting for a retransmission of the initial `SYN` segment. This attack was later called a `SYN flood` attack and the servers of the ISP named panix were among the first to `be affected <http://memex.org/meme2-12.html>`_ by this attack.
+ This limit of 100 TCBs in the `SYN Rcvd` state was chosen to protect the TCP entity from the risk of overloading its memory with too many TCBs in the `SYN Rcvd` state. However, it was also the reason for a new type of Denial of Service (DoS) attack :rfc:`4987`. A DoS attack is defined as an attack where an attacker can render a resource unavailable in the network. For example, an attacker may cause a DoS attack on a 2 Mbps link used by a company by sending more than 2 Mbps of packets through this link. In this case, the DoS attack was more subtle. As a TCP entity discards all received `SYN` segments as soon as it has 100 TCBs in the `SYN Rcvd` state, an attacker simply had to send a few 100 `SYN` segments every second to a server and never reply to the received `SYN+ACK` segments. To avoid being caught, attackers were of course sending these `SYN` segments with a different address than their own IP address [#fspoofing]_. On most TCP implementations, once a TCB entered the `SYN Rcvd` state, it remained in this state for several seconds, waiting for a retransmission of the initial `SYN` segment. This attack was later called a `SYN flood` attack and the servers of the ISP named Panix were among the first to `be affected <http://memex.org/meme2-12.html>`_ by this attack.
 
  .. spelling::
 
-   panix
+   Panix
 
  To avoid the `SYN flood` attacks, recent TCP implementations no longer enter the `SYN Rcvd` state upon reception of a `SYN segment`. Instead, they reply directly with a `SYN+ACK` segment and wait until the reception of a valid `ACK`. This implementation trick is only possible if the TCP implementation is able to verify that the received `ACK` segment acknowledges the `SYN+ACK` segment sent earlier without storing the initial sequence number of this `SYN+ACK` segment in a TCB. The solution to solve this problem, which is known as `SYN cookies <http://cr.yp.to/syncookies.html>`_ is to compute the 32 bits of the `ISN` as follows :
 
@@ -224,11 +224,11 @@ The TCP options are encoded by using a Type Length Value format where :
 
  - the first byte indicates the `type` of the option.
  - the second byte indicates the total length of the option (including the first two bytes) in bytes
- - the last bytes are specific for each type of option
+ - the remaining bytes are specific for each type of option
 
-:rfc:`793` defines the Maximum Segment Size (MSS) TCP option that must be understood by all TCP implementations. This option (type 2) has a length of 4 bytes and contains a 16 bits word that indicates the MSS supported by the sender of the `SYN` segment. The MSS option can only be used in TCP segments having the `SYN` flag set.
+:rfc:`793` defines the Maximum Segment Size (MSS) TCP option that must be understood by all TCP implementations. This option (type 2) has a length of 4 bytes and contains a 16-bit word that indicates the MSS supported by the sender of the `SYN` segment. The MSS option can only be used in TCP segments having the `SYN` flag set.
 
-:rfc:`793` also defines two special options that must be supported by all TCP implementations. The first option is `End of option`. It is encoded as a single byte having value `0x00` and can be used to ensure that the TCP header extension ends on a 32 bits boundary. The `No-Operation` option, encoded as a single byte having value `0x01`, can be used when the TCP header extension contains several TCP options that should be aligned on 32 bit boundaries. All other options [#ftcpoptions]_ are encoded using the TLV format.
+:rfc:`793` also defines two special options that must be supported by all TCP implementations. The first option is `End of option`. It is encoded as a single byte having value `0x00` and can be used to ensure that the TCP header extension ends on a 32-bit boundary. The `No-Operation` option, encoded as a single byte having value `0x01`, can be used when the TCP header extension contains several TCP options that should be aligned on 32-bit boundaries. All other options [#ftcpoptions]_ are encoded using the TLV format.
 
 .. note:: The robustness principle
 
@@ -635,7 +635,7 @@ The `TIME\_WAIT` state is different from the other states of the TCP FSM. A TCP
 
 .. [#fspoofing] Sending a packet with a different source IP address than the address allocated to the host is called sending a :term:`spoofed packet`.
 
-.. [#ftcpoptions] The full list of all TCP options may be found at http://www.iana.org/assignments/tcp-parameters/
+.. [#ftcpoptions] The full list of all TCP options may be found at https://www.iana.org/assignments/tcp-parameters/
 
 .. [#fackflag] In practice, only the `SYN` segment do not have their `ACK` flag set.