Exit Zen
84
../../protocols/bgp.rst:327
English
As BGP routers always prefer the routes with the highest `local-pref` attribute, this policy can be implemented using the following import filter on `R1`
0/1530 · 153
84
../../protocols/email.rst:240
English
38
0/100 · 2
84
../../protocols/ethernet.rst:356
English
100 Mbps
0/100 · 8
84
../../protocols/ipv6.rst:334
English
`Traffic class` : this 8 bits field indicates the type of service expected by this packet and contains the ``CE`` and ``ECT`` flags that are used by `Explicit Congestion Notification`
0/1830 · 183
84
../../protocols/ethernet.rst:324
English
Spanning tree computed in a switched Ethernet network
0/530 · 53
84
../../protocols/tcp.rst:260
English
the remote IP address
0/210 · 21
84
../../protocols/tls.rst:417
English
The TLS 1.3 handshake differs from the TLS 1.2 handshake in several ways. First, the TLS 1.3 handshake requires a single round-trip-time when the client connects for the first time to a server. To achieve this, the TLS designers look at the TLS 1.2 handshake in details and found that the first round-trip-time is mainly used to select the set of cryptographic algorithms and the cryptographic exchange scheme that will be used over the TLS session. TLS 1.3 drastically simplifies this negotiation by requiring to use the Diffie Hellman exchange with a small set of possible parameters. This means that the client can guess the parameters used by the server (i.e. the modulus, p and the base g) and immediately start the Diffie Hellman exchange. A simplified version of the TLS 1.3 handshake is shown in the figure below.
0/8210 · 821
85
../../glossary.rst:81
English
IPv6
0/100 · 4
85
../../principles/transport.rst:500
English
The `request-response service` allows to efficiently exchange small amounts of information in a request and associate it with the corresponding response. This service can be depicted by using the time-sequence diagram below.
0/2240 · 224
85
../../principles/sharing.rst:356
English
ALOHA and slotted ALOHA can easily be implemented, but unfortunately, they can only be used in networks that are very lightly loaded. Designing a network for a very low utilization is possible, but it clearly increases the cost of the network. To overcome the problems of ALOHA, many Medium Access Control mechanisms have been proposed which improve channel utilization. Carrier Sense Multiple Access (CSMA) is a significant improvement compared to ALOHA. CSMA requires all nodes to listen to the transmission channel to verify that it is free before transmitting a frame [KT1975]_. When a node senses the channel to be busy, it defers its transmission until the channel becomes free again. The pseudo-code below provides a more detailed description of the operation of CSMA.
0/7750 · 775
85
../../principles/security.rst:940
English
The security of this protocol relies on the difficulty of computing discrete logarithms, i.e. from the knowledge of :math:`A` (resp. :math:`B`), it is very difficult to extract :math:`\log(A)=\log(g^{a} \mod p)=a` (resp. :math:`\log(B)=\log(g^{b} \mod p)=b`).
0/2590 · 259
85
../../exercises/ipv6.rst:794
English
There are three routes in this table. The first two correspond to the two prefixes that are used over the ``a-eth0`` interface. These routes are automatically created when an IPv6 address is configured on an interface. The last route is the default route (``::/0``) which points towards ``2001:db8:1341:1::1``, i.e. router ``r1``.
0/3300 · 330
85
../../exercises/routing-protocols.rst:1265
English
What is the Loc-RIB of ``AS6`` for prefix `p1` ? Indicate which is the best route towards this prefix.
0/1020 · 102
85
../../protocols/bgp.rst:335
English
With this import filter, all the BGP routes learned from `RB` over the high bandwidth links are preferred over the routes learned over the backup link. If the primary link fails, the corresponding routes are removed from `R1`'s RIB and `R1` uses the route learned from `RA`. `R1` reuses the routes via `RB` as soon as they are advertised by `RB` once the `R1-RB` link comes back.
0/3790 · 379
85
../../protocols/email.rst:240
English
m
0/100 · 1
85
../../protocols/ethernet.rst:356
English
200000
0/100 · 6
85
../../protocols/ipv6.rst:335
English
`Flow Label` : this field was initially intended to be used to tag packets belonging to the same `flow`. A recent document, :rfc:`6437` describes some possible usages of this field, but it is too early to tell whether it will be really used.
0/2410 · 241
85
../../protocols/ethernet.rst:327
English
In this network, the STP will compute the following spanning tree. `Switch1` will be the root of the tree. All the interfaces of `Switch1`, `Switch2` and `Switch7` are part of the spanning tree. Only the interface connected to `LAN B` will be active on `Switch9`. `LAN H` will only be served by `Switch7` and the port of `Switch44` on `LAN G` will be disabled. A frame originating on `LAN B` and destined for `LAN A` will be forwarded by `Switch7` on `LAN C`, then by `Switch1` on `LAN E`, then by `Switch44` on `LAN F` and eventually by `Switch2` on `LAN A`.
0/5590 · 559
85
../../protocols/tcp.rst:261
English
the local TCP port number
0/250 · 25
85
../../protocols/tls.rst:447
English
There are several important differences with the TLS 1.2 handshake. First, the Diffie Hellman key exchange is required in TLS 1.3 and this exchange is initiated by the client (before having validated the server identity). To initiate the Diffie Hellman key exchange, the client needs to guess the modulus and the base that can be accepted by the server. Either the client uses standard parameters that most server supports or the client remembers the last modulus/base that it used with this particular server. If the client guessed incorrectly, the server replies with the parameters that it expects and one round-trip-time is lost. When the server sends its `ServerHello`, it already knows the session key. This implies that the server can encrypt all subsequent messages. After one round-trip-time, all data exchanged over the TLS 1.3 session is encrypted and authenticated. In TLS 1.3, the server certificate is encrypted with the session key, as well as the `Finished` message. The server signs the handshake to confirm that it owns the public key of its certificate. If the server wants to send application data, it can already encrypt it and send it to the client. Upon reception of the server Certificate, the client verifies it and checks the signature of the handshake and the `Finished` message. The client confirms the end of the handshake by sending its own `Finished` message. At that time, the client can send encrypted data. This means that the client only had to wait one round-trip-time before sending encrypted data. This is much faster than with TLS 1.2.
0/15740 · 1574