2. cnp3-ebook
3. English
4. Zen

23 ../../principles/security.rst:301
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Unfortunately, it is difficult to use this cipher in practice since the key must be as long as the message that needs to be transmitted. If the key is smaller than the message and the message is divided into blocks that have the same length as the key, then the scheme becomes less secure since the same key is used to decrypt different parts of the message. In practice, `XOR` is often one of the basic operations used by encryption schemes. To be usable, the deployed encryption schemes use keys that are composed of a small number of bits, typically 56, 64, 128, 256, ... 574/10000 · 574
23 ../../exercises/dns.rst:61
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When `dig` is run, the header section in its output indicates the `id` the DNS identifier used to send the query. Does your implementation of `dig` generates random identifiers ? 178/10000 · 178
23 ../../exercises/ipv6.rst:195
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Consider a slightly different network than in the previous question. 68/10000 · 68
23 ../../exercises/lan.rst:248
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second part of the output provides the state of each switch port. Port ``s3-eth1`` is active and forwards data frames (state is set to `forwarding`). This port is a `designated` port. The cost of ``1`` is the cost associated to this interface. The same information is found for port ``s3-eth2``. 299/10000 · 299
23 ../../exercises/routing-policies.rst:195
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Section 3.1 <https://tools.ietf.org/html/rfc4443#section-3.1>`_ of :rfc:`4443` seven different Codes for the ICMPv6 Destination Unreachable Message. Under which circumstances would a router generate such an ICMPv6 message with : 229/10000 · 229
23 ../../exercises/routing-protocols.rst:272
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Exploring RIP 13/10000 · 13
23 ../../exercises/tcp-2.rst:125
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We can now close the connection gracefully. Let us first issue inject a segment with the ``FIN`` flag set. 106/10000 · 106
23 ../../exercises/trace.rst:114
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — You can now use your understanding of wireshark_ and tcpdump_ to analyze a 2-minutes long packet trace. 103/10000 · 103
23 ../../protocols/bgp.rst:78
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `import filter` that specifies, for each peering relationship, the routes that can be accepted from the neighboring domain (the non-acceptable routes are ignored and the domain never uses them to forward packets) 216/10000 · 216
23 ../../protocols/congestion.rst:118
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The third difficulty is to allow an ECN-capable sender to detect whether the remote host also supports ECN. This is a classical negotiation of extensions to a transport protocol. In TCP, this could have been solved by defining a new TCP option used during the three-way handshake. To avoid wasting space in the TCP options, the designers of ECN opted in :rfc:`3168` for using the `ECN-Echo` and `CWR` bits in the TCP header to perform this negotiation. In the end, the result is the same with fewer bits exchanged. 514/10000 · 514
23 ../../protocols/dnssec.rst:220
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — There are several details of the operation of DNSSEC that are worth being discussed. First, a server that supports DNSSEC must have a public-private key pair. The public key is distributed with the `DNSKEY` record. The private key is never distributed and it does not even need to be stored on the server that uses the public key. DNSSEC does not require the DNSSEC servers to perform any operation that requires a private key in real time. All the `RRSIG` records can be computed offline, possibly on a different server than the server that returns the DNSSEC replies. The initial motivation for this design choice was the CPU complexity of computing the `RRSIG` signatures for zones that contain millions of records. In the early days of DNSSEC, this was an operational constraint. Today, this is less an issue, but avoiding costly signature operations in real time has two important benefits. First, this reduces the risk of denial of service attacks since an attacker cannot force a DNSSEC server to perform computationally intensive signing operations. Second, the private key can be stored offline, which means that even if an attacker gains access to the DNSSEC server, it cannot retrieve its private key. Using offline signatures for the `RRSIG` records has some practical implications that are reflected in the content of this record. First, each `RRSIG` record contains the original TTL of the signed record. When DNS resolvers cache records, they change the value of the TTL of these cached records and then return the modified records to their clients. When a resolver receives a signed DNS record, it must replace the received TTL of the record with the original TTL (and check that the received TTL is smaller than the original one) before checking the signature. Second, the `RRSIG` records contain a validity period, i.e. a starting time and an ending time for the validity of the signature. This period is specified as two timestamps. This period is only the validity of the signature. It does not affect the TTL of the signed record and is independent from the TTL. In practice, the validity period is important to allow DNS server operators to update their public/private keys. When such a key is changed, e.g. because the private could have been compromised, there is some period of time during which records signed with the two keys coexist in the network. The validity period allows ensuring that old signatures do not remain in DNS caches for ever. 2471/10000 · 2471
23 ../../protocols/email.rst:124
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Several other optional header lines are defined in :rfc:`5322` and elsewhere [#femailheaders]_. Furthermore, many email clients and servers define their own header lines starting from `X-`. Several of the optional header lines defined in :rfc:`5322` are worth being discussed here : 282/10000 · 282
23 ../../protocols/ethernet.rst:156
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A hierarchical Ethernet network composed of hubs 48/10000 · 48
23 ../../protocols/http.rst:110
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A simple HTML page 18/10000 · 18
23 ../../protocols/http2.rst:155
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The information exchanged over an HTTP/2.0 session is composed of frames. A frame starts with a 9 bytes-long header that carries several types of information. The HTTP/2.0 frames have a variable length. The `Length` field of the header contains the length of the frame payload in bytes. As this field is encoded as a 24 bits field, an HTTP/2.0 frame cannot be longer than :math:`2^{24} -1` bytes. It should be noted that :rfc:`7540` assumes a maximum size of :math:`2^{14}` bytes, i.e. 16,384 bytes for the HTTP/2.0 frame payload unless a longer maximum frame length has been negotiated at the beginning of the session using the HTTP/2.0 `Settings` frame that will be described later. The next field of the frames header indicates the frame type. The first frame types are `Data` which contains data from web objects and `Headers` containing HTTP/2.0 headers. When a client retrieves a web object from a server, it always receives an HTTP/2.0 `Headers` frame followed by an HTTP/2.0 `Data` frame. The `Headers` frame information contains essentially the same HTTP headers as the ones supported by HTTP/1.1, but those are encoded by leveraging a data compression technique that minimizes the number of bytes required to transmit them. 1233/10000 · 1233
23 ../../protocols/ipv6.rst:105
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — IPv6 addressing architecture 28/10000 · 28
23 ../../protocols/ethernet.rst:59
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The last field of the Ethernet frame is a 32 bit Cyclical Redundancy Check (CRC). This CRC is able to catch a much larger number of transmission errors than the Internet checksum used by IP, UDP and TCP [SGP98]_. The format of the Ethernet frame is shown below. 261/10000 · 261
23 ../../protocols/routing.rst:75
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Internal router : A router whose directly connected networks belong to the area 79/10000 · 79
23 ../../protocols/rpc.rst:100
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second sub-problem is how to reach the callee. A simple solution to this problem is to make sure that the callee listens on a specific port on the remote machine and then exchange information with this server process. This is the solution chosen for JSON-RPC [JSON-RPC2]_. JSON-RPC can be used over the connectionless or the connection-oriented transport service. A JSON-RPC request contains the following fields: 417/10000 · 417
23 ../../protocols/ssh.rst:204
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a key used by the client (resp. server) to encrypt the data that it sends 73/10000 · 73