2. cnp3-ebook
3. English
4. Zen

16 ../../principles/transport.rst:59
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Trudy : `1234` 14/10000 · 14
16 ../../principles/security.rst:213
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When designing network protocols and applications that will be deployed on a large scale, it is important to take those DDoS attacks into account. Attackers use different strategies to launch DDoS attacks. Some have managed to gain control of a large number of sources by injecting malware on them. Others, and this is where protocol designers have an important role to play, simply exploit design flaws in some protocols. Consider a simple request-response protocol where the client sends a request and the server replies with a response. Often the response is larger or much larger than the request sent by the client. Consider that such a simple protocol is used over a datagram network. When Alice sends a datagram to Bob containing her request, Bob extracts both the request and Alice's address from the packet. He then sends his response in a single packet destined to Alice. Mallory would like to create a DoS attack against Alice without being identified. Since he has studied the specification of this protocol, he can send a request to Bob inside a packet having Alice's address as its source address. Bob will process the request and send his (large) response to Alice. If the response has the same size as the request, Mallory is producing a `reflection attack` since his packets are reflected by Bob. Alice would think that she is attacked by Bob. If there are many servers that operate the same service as Bob, Mallory could hide behind a large number of such reflectors. Unfortunately, the reflection attack can also become an amplification attack. This happens when the response sent by Bob is larger than the request that it has received. If the response is :math:`k` times larger than the request, then when Mallory consumes 1 Gbps of bandwidth to send requests, his victim receives :math:`k` Gbps of attack traffic. Such amplification attacks are a very important problem and protocol designers should ensure that they never send a large response before having received the proof that the request that they have received originated from the source indicated in the request. 2092/10000 · 2092
16 ../../exercises/dns.rst:50
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Assume now that you are residing in a network where there is no DNS resolver and that you need to perform your query manually starting from the DNS root. 153/10000 · 153
16 ../../exercises/http.rst:51
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The minimum command sent to a HTTP server is `GET / HTTP/1.0` followed by CRLF and a blank line. 96/10000 · 96
16 ../../exercises/ipv6.rst:91
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this network, propose the forwarding tables of ``R2`` and ``R3`` that ensure that hosts ``A`` and ``B`` can exchange packets in both directions. 147/10000 · 147
16 ../../exercises/lan.rst:115
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Testing the Spanning Tree with IPMininet 40/10000 · 40
16 ../../exercises/routing-policies.rst:155
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Propose a configuration on R1 that achieves the same objective as the one shown in the figure but also preserves the reachability of all IP addresses inside `AS456` if one of `AS456`'s interdomain links fails. 209/10000 · 209
16 ../../exercises/routing-protocols.rst:245
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Hello packet contains some parameters such as the `Hello interval` that is set to 1 second. This interval is the delay between the transmission of successive Hello packets. Since the `Router Dead Interval` is set to 3 seconds, the router will consider the link as down if it does not receive Hello packets during a period of 3 seconds. The second packet of the trace is sent by router ``r1``. 396/10000 · 396
16 ../../exercises/tcp-2.rst:88
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The description of TCP packets in packetdrill_ uses a syntax that is very close to the tcpdump_ one. The ``+0`` timing indicates that the line is executed immediately after the previous event. The ``<`` sign indicates that packetdrill_ injects a TCP segment and the ``S`` character indicates that the ``SYN`` flag must be set. Like tcpdump_, packetdrill_ uses sequence numbers that are relative to initial sequence number. The three numbers that follow are the sequence number of the first byte of the payload of the segment (``0``), the sequence number of the last byte of the payload of the segment (``0`` after the semi-column) and the length of the payload (``0`` between brackets) of the ``SYN`` segment. This segment does not contain a valid acknowledgment but advertises a window of 1000 bytes. All ``SYN`` segments must also include the ``MSS`` option. In this case, we set the MSS to 1000 bytes. The next line of the packetdrill_ script verifies the reply sent by the instrumented Linux kernel. 1003/10000 · 1003
16 ../../exercises/trace.rst:96
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — wireshark_ is very good at displaying packets, but it also contains several analysis tools that can be very useful. The first tool is `Follow TCP stream`. It is part of the `Analyze` menu and allows you to reassemble and display all the payload exchanged during a TCP connection. This tool can be useful if you need to analyze for example the commands exchanged during an HTTP or SMTP session. 393/10000 · 393
16 ../../protocols/bgp.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — over a `provider->customer` relationship, the `provider` advertises all the routes that it knows to its `customer`. 115/10000 · 115
16 ../../protocols/congestion.rst:93
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The original TCP congestion control mechanism proposed in [Jacobson1988]_ recommended that each TCP connection should begin by setting :math:`cwnd=MSS`. However, in today's higher bandwidth networks, using such a small initial congestion window severely affects the performance for short TCP connections, such as those used by web servers. In 2002, :rfc:`3390` allowed an initial congestion window of about 4 KBytes, which corresponds to 3 segments in many environments. Recently, researchers from Google proposed to further increase the initial window up to 15 KBytes [DRC+2010]_. The measurements that they collected show that this increase would not significantly increase congestion but would significantly reduce the latency of short HTTP responses. Unsurprisingly, the chosen initial window corresponds to the average size of an HTTP response from a search engine. This proposed modification has been adopted in :rfc:`6928` and TCP implementations support it. 965/10000 · 965
16 ../../protocols/dnssec.rst:171
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `DS` record contains a hash of a public key. It is used by a parent zone to certify the public key used by one of its child zones. 134/10000 · 134
16 ../../protocols/email.rst:101
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The date. This header line starts with `Date:`. :rfc:`5322` precisely defines the format used to encode a date. 111/10000 · 111
16 ../../protocols/ethernet.rst:96
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — delivers frames to their destination with a very high probability of successful delivery 88/10000 · 88
16 ../../protocols/http.rst:77
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second part of the URI is the `authority`. With retrievable URIs, this includes the DNS name or the IP address of the server where the document can be retrieved using the protocol specified via the `scheme`. This name can be preceded by some information about the user (e.g. a user name) who is requesting the information. Earlier definitions of the URI allowed the specification of a user name and a password before the `@` character (:rfc:`1738`), but this is now deprecated as placing a password inside a URI is insecure. The host name can be followed by the semicolon character and a port number. A default port number is defined for some protocols and the port number should only be included in the URI if a non-default port number is used (for other protocols, techniques like service DNS records can used). 817/10000 · 817
16 ../../protocols/http2.rst:79
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To understand the benefits of pipelining, let us consider a simple but illustrative example. A client needs to retrieve 5 web objects that are each 100 bytes. The underlying transport connection has a 1 Gbps bandwidth but a one-way delay of 100 msec. A normal HTTP/1.x client would send the first request, wait 200 msec to receive the answer, then send another request... It would need one entire second to retrieve the five web objects. This is illustrated in the figure below. 478/10000 · 478
16 ../../protocols/ipv6.rst:93
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The IETF decided to pursue the development of IPng based on the SIPP proposal. As IP version `5` was already used by the experimental ST-2 protocol defined in :rfc:`1819`, the successor of IP version 4 is IP version 6. The initial IP version 6 defined in :rfc:`1752` was designed based on the following assumptions : 316/10000 · 316
16 ../../protocols/ethernet.rst:5
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Ethernet 8/10000 · 8
16 ../../protocols/routing.rst:56
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Format of the RIP IPv6 route entries 36/10000 · 36