Exit Zen
67
../../protocols/tcp.rst:225
English
the first byte indicates the `type` of the option.
0/500 · 50
67
../../protocols/tls.rst:361
English
MAC-then-encrypt or Encrypt-then-MAC
0/360 · 36
68
../../glossary.rst:147
English
IGP
0/100 · 3
68
../../exercises/network.rst:380
English
Router `B` will flood its updated link state packet through the entire network and all routers will recompute their forwarding table. Upon reception of a link state packet, routers usually first flood the received link-state packet and then recompute their forwarding table. Assume that `B` is the first to recompute its forwarding table, followed by `D`, `A`, `C` and finally `E`.
396/3810 · 381
68
../../principles/network.rst:304
English
Sometimes, the network layer needs to deal with heterogeneous datalink layers. For example, two hosts connected to different datalink layers exchange packets via routers that are using other types of datalink layers. Thanks to the network layer, this exchange of packets is possible provided that each packet can be placed inside a datalink layer frame before being transmitted. If all datalink layers support the same frame size, this is simple. When a node receives a frame, it decapsulates the packet that it contains, checks the header and forwards it, encapsulated inside another frame, to the outgoing interface. Unfortunately, the encapsulation operation is not always possible. Each datalink layer is characterized by the maximum frame size that it supports. Datalink layers typically support frames containing up to a few hundreds or a few thousands of bytes. The maximum frame size that a given datalink layer supports depends on its underlying technology. Unfortunately, most datalink layers support a different maximum frame size. This implies that when a host sends a large packet inside a frame to its nexthop router, there is a risk that this packet will have to traverse a link that is not capable of forwarding the packet inside a single frame. In principle, there are three possibilities to solve this problem. To discuss them, we consider a simple scenario with two hosts connected to a router as shown in the figure below.
0/14420 · 1442
68
../../principles/reliability.rst:242
English
`space` : `0100000` b
0/210 · 21
68
../../principles/transport.rst:226
English
the `request-response service`
0/300 · 30
68
../../principles/sharing.rst:277
English
Static allocation methods
0/250 · 25
68
../../principles/security.rst:837
English
To cope with some of the above mentioned problems, public-key cryptography is usually combined with certificates. A `certificate` is a data structure that includes a signature from a trusted third party. A simple explanation of the utilization of certificates is to consider that Alice and Bob both know Ted. Ted is trusted by these two users and both have stored Ted's public key : :math:`Ted_{pub}`. Since they both know Ted's key, he can issue certificates. A certificate is mainly a cryptographic link between the identity of a user and his/her public key. Such a certificate can be computed in different ways. A simple solution is for Ted to generate a file that contains the following information for each certified user :
0/7280 · 728
68
../../exercises/ipv6.rst:615
English
``2001:db8:1341:1::/64`` on the link between ``b`` and ``r3``
0/610 · 61
68
../../exercises/routing-protocols.rst:930
English
Without a BGP session between ``AS2`` and ``AS3``, there are reachability problems in this simple Internet.
0/1070 · 107
68
../../exercises/tcp-2.rst:887
English
The `Push` flag is one of the TCP flags defined in :rfc:`793`. TCP stacks usually set this flag when transmitting a segment that empties the send buffer. This is the reason why we observe this push flag in our example.
0/2180 · 218
68
../../protocols/bgp.rst:283
English
the attributes including the AS-Path
0/360 · 36
68
../../protocols/email.rst:236
English
19
0/100 · 2
68
../../protocols/ethernet.rst:314
English
The Spanning Tree Protocol (802.1d)
0/350 · 35
68
../../protocols/http.rst:321
English
The server replies with the `Connection: Keep-Alive` header and indicates that it accepts a maximum of 100 HTTP requests over this connection and that it will close the connection if it remains idle for 15 seconds.
0/2140 · 214
68
../../protocols/ipv6.rst:234
English
Furthermore, the IETF has reserved some IPv6 addresses for a special usage. The two most important ones are :
0/1090 · 109
68
../../protocols/ethernet.rst:203
English
Fortunately, IEEE was able to define the [IEEE802.3]_ frame format while maintaining backward compatibility with the Ethernet [DIX]_ frame format. The trick was to only assign values above 1500 as `EtherType` values. When a host receives a frame, it can determine whether the frame's format by checking its `EtherType/Length` field. A value lower smaller than `1501` is clearly a length indicator and thus an [IEEE802.3]_ frame. A value larger than `1501` can only be type and thus a [DIX]_ frame.
0/4970 · 497
68
../../protocols/tcp.rst:226
English
the second byte indicates the total length of the option (including the first two bytes) in bytes
0/970 · 97
68
../../protocols/tls.rst:363
English
When secure protocols use Message Authentication and Encryption, they need to specify how these two algorithms are combined. A first solution, which is used by the current version of TLS, is to compute the authentication code and then encrypt both the data and the authentication code. A drawback of this approach is that the receiver of an encrypted TLS record must first attempt to decrypt data that has potentially been modified by an attacker before being able to verify the authenticity of the record. A better approach is for the sender to first encrypt the data and then compute the authentication code over the encrypted data. This is the encrypt-then-MAC approach proposed in :rfc:`7366`. With encrypt-then-MAC, the receiver first checks the authentication code before attempting to decrypt the record.
0/8110 · 811