2. cnp3-ebook
3. English
4. Zen

54 ../../protocols/tls.rst:283
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The client sends the ``ChangeCipherSpec`` message followed by the ``Finished`` message. The ``ChangeCipherSpec`` message indicates that the client has received all the information required to generate the security keys for this TLS session. This messages can also appear later in the session to indicate a change in the encryption algorithms that are used, but this usage is outside the scope of this book. The ``Finished`` message is more important. It confirms to the server that the TLS handshake has been performed correctly and that no attacker has been able to modify the data sent by the client or the server. This is the first message that is encrypted with the selected security keys. It contains a hash of all the messages that were exchanged during the handshake. 774/10000 · 774
54 ../../protocols/wifi.rst:154
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second important utilization of the management frames is to allow a WiFi station to be associated with an access point. When a WiFi station starts, it listens to beacon frames to find the available SSIDs. To be allowed to send and receive frames via an access point, a WiFi station must be associated to this access point. If the access point does not use any security mechanism to secure the wireless transmission, the WiFi station simply sends an `Association request` frame to its preferred access point (usually the access point that it receives with the strongest radio signal). This frame contains some parameters chosen by the WiFi station and the SSID that it requests to join. The access point replies with an `Association response frame` if it accepts the WiFI station. 783/10000 · 783
54 ../../exercises/sockets.rst:372
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As an example, here is what you could have to invoke your programs. 67/10000 · 67
54 ../../bibliography.rst:74
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Freier, A., Karlton, P., Kocher, C., `The SSL Protocol Version 3.0`, Internet draft, November 1996, https://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00 159/10000 · 159
54 ../../principles/sharing.rst:359
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — There is another solution that allows spreading the load among many sources without relying on the name service. The popular `bittorent <https://www.bittorrent.com>`_ service is an example of this approach. With this solution, each file is divided in blocks of fixed size. To retrieve a file, a client needs to retrieve all the blocks that compose the file. However, nothing forces the client to retrieve all the blocks in sequence and from the same server. Each file is associated with metadata that indicates for each block a list of addresses of hosts that store this block. To retrieve a complete file, a client first downloads the metadata. Then, it tries to retrieve each block from one of the hosts that store the block. In practice, implementations often try to download several blocks in parallel. Once one block has been successfully downloaded, the next block can be requested. If a host is slow to provide one block or becomes unavailable, the client can contact another host listed in the metadata. Most deployments of bittorrent allow the clients to participate to the distribution of blocks. Once a client has downloaded one block, it contacts the server which stores the metadata to indicate that it can also provide this block. With this scheme, when a file is popular, its blocks are downloaded by many hosts that automatically participate in the distribution of the blocks. Thus, the number of `servers` that are capable of providing blocks from a popular file automatically increases with the file's popularity. 1531/10000 · 1531
55 ../../bibliography.rst:76
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Fortz, B. Rexford, J. ,Thorup, M., `Traffic engineering with traditional IP routing protocols <https://dx.doi.org/10.1109/MCOM.2002.1039866>`_, IEEE Communication Magazine, October 2002 185/10000 · 185
55 ../../exercises/network.rst:373 • ../../exercises/network.rst:375
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 2 via C 7/10000 · 7
55 ../../glossary.rst:185
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The HyperText Transport Protocol is defined in :rfc:`2616` 58/10000 · 58
55 ../../principles/reliability.rst:231
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 01111110000100100100100100100001101111110 41/10000 · 41
55 ../../principles/sharing.rst:363
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Now that we have provided a broad overview of the techniques that can be used to spread the load and allocate resources in the network, let us analyze two techniques in more details : Medium Access Control and Congestion control. 229/10000 · 229
55 ../../principles/transport.rst:200
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A second imperfection that may affect an `unreliable connectionless service` is that it may duplicate SDUs. Some packets may be duplicated in a network and be delivered twice to their destination. This is illustrated by the time-sequence diagram below. 252/10000 · 252
55 ../../principles/security.rst:571
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A better approach would be to authenticate Alice without storing her password in clear on Bob's computer. For this, Alice computes a `hash chain` as proposed by Lamport in [Lamport1981]_. A hash chain is a sequence of applications of a hash function (`H`) on an input string. If Alice's password is `P`, then her 10 steps hash chain is : :math:`H(H(H(H(H(H(H(H(H(H(P))))))))))`. The result of this hash chain will be stored on Bob's computer together with the value `10`. This number is the maximum number of remaining authentications for Alice on Bob's computer. To authenticate Alice, Bob sends the remaining number of authentications, i.e. `10` in this example. Since Alice knows her password, `P`, she can compute :math:`H^9(P)=H(H(H(H(H(H(H(H(H(P)))))))))` and send this information to Bob. Bob computes the hash of the value received from Alice (:math:`H(H^9(P))`) and verifies that this value is equal to the value stored in his database. It then decrements the number of authorized authentications and stores :math:`H^9(P)` in his database. Bob is now ready for the next authentication of Alice. When the number of authorized authentications reaches zero, the hash chain needs to be reinitialized. If Eve captures :math:`(H^n(P))`, she cannot use it to authenticate herself as Alice on Bob's computer because Bob will have decremented its number of authorized authentications. Furthermore, given that hash functions are not invertible, Eve cannot compute :math:`H^{n-1}(P)` from :math:`H^{n}(P)`. 1504/10000 · 1504
55 ../../exercises/ipv6.rst:527
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Configuring IPv6 Networks 25/10000 · 25
55 ../../exercises/routing-protocols.rst:812
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We can now observe the BGP-Loc-RIB of the router with the ``show bgp ipv6 command`` command. 92/10000 · 92
55 ../../exercises/tcp-2.rst:688
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — How long does it take for the sender to deliver 3 KBytes to the receiver ? 74/10000 · 74
55 ../../protocols/bgp.rst:166
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a BGP session starts, the routers first exchange `OPEN` messages to negotiate the options that apply throughout the entire session. Then, each router extracts from its FIB the routes to be advertised to the peer. It is important to note that, for each known destination prefix, a BGP router can only advertise to a peer the route that it has itself installed inside its `FIB`. The routes that are advertised to a peer must pass the peer's `export filter`. The `export filter` is a set of rules that define which routes can be advertised over the corresponding session, possibly after having modified some of its attributes. One `export filter` is associated to each BGP session. For example, on a `shared-cost peering`, the `export filter` only selects the internal routes and the routes that have been learned from a `customer`. The pseudo-code below shows the initialization of a BGP session. 899/10000 · 899
55 ../../protocols/congestion.rst:238
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In enterprise networks or datacenters, the situation is different since a single company typically controls all the sources and all the routers. In such networks it is possible to ensure that all hosts and routers have been upgraded before turning on ECN on the routers. 270/10000 · 270
55 ../../protocols/email.rst:232
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 34 2/10000 · 2
55 ../../protocols/ethernet.rst:207
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Ethernet Switches 17/10000 · 17
55 ../../protocols/http.rst:188
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — All status codes starting with digit `3` indicate that the requested document is no longer available on the server. `301 Moved Permanently` indicates that the requested document is no longer available on this server. A `Location:` header containing the new URI of the requested document is inserted in the HTTP response. `304 Not Modified` is used in response to an HTTP request containing the `If-Modified-Since:` header. This status line is used by the server if the document stored on the server is not more recent than the date indicated in the `If-Modified-Since:` header. 577/10000 · 577