Computer Networks Week 6 Feb 25 Corboy Law 522
Read:
Chapter 3:
3.1
3.2.1 (Learning Bridges)
Chapter 4:
4.1.1-4.1.6
4.2.1
4.2.2 (Distance-Vector)
Chapter 5:
5.1: UDP
5.2.1: End-to-End
5.2.2: Segment format
5.2.3: connection establishment and termination
Midterm: March 18
ARP security
Suppose A wants to log in to secure server S, using a password. How can B (for Bad) impersonate S?
Here is an ARP-based strategy. First, B makes sure the real S is down,
either by waiting until scheduled downtime or by launching a
denial-of-service attack against S.
When A tries to connect, it will begin with an ARP WHO-HAS S. All B has to do is answer, I am S. This is trivial; all B has to do is set its own IP address to that of S.
A will connect, and give its password to B. B now simply responds with something like backup in progress; try later, and use A's credentials against the real S.
This works even if the communications channel A uses is encrypted! If A is using the ssh
protocol, then A will get a message that the other side's key has
changed (B will present its own ssh key, not S's), but how many people
really recognize that as a problem? And if you use a Loyola-labs-style
dataless configuration, you always get that message.
DHCP and routers
It is often desired (for Loyola-sized networks, for example) to
have only one or two DHCP servers, but to have multiple subnets.
Classical DHCP relies on broadcast, which isn't forwarded by routers,
and even if it were, the DHCP server would have no way of knowing what
subnet the computer in question was actually located on.
This is generally addressed by DHCP Relay
(sometimes known by the older name BOOTP Relay). The router (or,
sometimes, some other host on the subnet) receives the DHCP broadcast
message, and relays it to the
designated DHCP Server. The relayed message is sent directly (unicast),
not broadcast, and the network part of the IP address is included so
that the DHCP Server can assign an IP address on the correct subnet.
This feature has to be specially enabled on the router.
4.3.1: subnets
What if our site has more than one physical LAN? Or is really too big
for one physical LAN? The latter is Loyola's situation. It did not take
long for the IP world to run into this problem.
Getting a separate IP network number for each subnet is bad for routers, and bad politically.
Subnets support further routing within the IPnet site. "Site" may mean different things, but once the packet has been delivered to the IPnet border router, further routing within the subnet should NOT involve the outside Internet!
Subnets introduce hierarchical routing: first we route to the primary network, then inside that site we route to the subnet, and finally the last hop delivers to the host.
Routing and subnets involves in effect moving the IPnet division line RIGHTWARD.
subnets versus:
- bridging
- multiple IP networks
Basic example: divide a class-B into 256 "class-C subnets", on byte boundaries.
If a node doesn't know it is on a subnet, and a packet arrives destined
for another subnet, it will assume it can deliver the packet locally
and this will fail. Nodes know they
are on subnets by virtue of having a SUBNET MASK. They then use the
mask to decide where to divide IP addresses into net and host parts, rather than the classA-B-C rule. Each interface (each subnet) can have its own subnet mask.
The (common) net portion of the IP addresses on a subnet is called the subnet address or subnet number.
A subnet mask (of length n) is really a 32-bit word, consisting of n
1-bits followed by 0-bits. If M is such a mask and A is an IP address,
then we can use the bitwise AND of A and M, A & M, to in effect
truncate A after n bits (more precisely, to zero out A after n bits).
Comparing A & M to B&M is to compare the first n bits of A and
B.
The class-based IP-address strategy allowed any host anywhere on the
internet to properly separate any address into its net and host
portions. With subnets, this division point is now allowed to vary; for example, the address 147.126.65.47 divides into 147.126 | 65.47 outside of Loyola, but into 147.126.65 |
47 inside. This means that the net-host division is no longer an
absolute property of addresses, but rather something that depends on
where the packet is on its journey.
As a result, division into net versus host on subnets cannot be done for arbitrary packets (eg outbound packets). Howver, that division is not in fact what we need. What is
needed is a way to tell if a given address A belongs to the current
subnet, say B; that is, we need to compare the first n bits of A and B,
where n is the length of the subnet mask. We do this by comparing
A&M to B&M, where M is the mask corresponding to n. A&M is not necessarily the same as Anet, for arbitrary A. However, if A&M == B&M, then A also belongs to the subnet, and then A&M is in fact Anet.
Technically, we also need the requirement that given any two subnet
numbers of disjoint subnets, neither is a proper prefix of the other.
This guarantees that if A is an address and B is a subnet number with
mask M (so B = B&M), then if A&M = B then A does not match any other subnet. Regardless of the net/host division rules, we cannot possibly have subnet 147.126 with host 65.47 and subnet 147.126.65 with different host 47.) (I specify that the subnets are disjoint because 147.126.65/24 is in some sense a proper subset of 147.126/16.)
- Subnets and local delivery
- consequences of misconfigured masks
- variable-sized subnet mask
4.3.1: Division of a class-C into subnets of size 70, 40, 25, and 20.
Routing-table algorithms (§4.2)
Ethernet bridges can always fall back on broadcast, so they can afford
to build the routing tables "incrementally". For IP, there is no
fallback delivery mechanism: router tables must be built before
delivery can succeed. While manual table construction is possible, it
is not practical.
4.2.2: distance vector routing (Routing Information Protocol, RIP)
Distance-Vector is used by the Routing Information Protocol, or RIP, on
unix systems this is often called "routed" (pronounced route-d). It is
the simplest routing-table protocol.
Routers identify their router neighbors, and add a third cost (or distance)
column to their tables. The simplest case is when we assign a cost of 1
to each link (the "hopcount" metric); it is also possible to assign
more complex numbers. Neighbors exchange the (destination,cost)
portions of their tables. When a neighbor's (dest,cost) pair arrives,
the router updates its own table in three cases:
-
new node reported
- decreased distance to existing node reported
. NOTE: these are the "no-bad-news" cases for which convergence happens
because the distances are monotonically decreasing (or the
same). If all hopcounts are 1, shortest path is the first discovered.
- increased distance reported by NextHop for that node
For the moment, let us ignore the third case. Then every cost is
(non-monotonically) decreasing, and thus must converge. The first two
cases are the "no-bad-news" cases.
Simple example:
B
/ \
/ \
A -------- C
| |
| |
D -------- E
First example: use the first two rules to generate basic tables for everyone
Second example: have the D--E link break, and have the third rule come
into play. This is the "bad-news" case: a link has broken, and is no
longer available. Costs may now rise as well as fall.
Third example: link weights other than 1.
A-----2-----C
| |
8 1
| |
B-----3-----D
Distance-Vector slow-convergence problem
A and B have table entries for destination D as shown underneath.
D-------A----------B
<D,dir,1>
<D,A,2> ;; "dir": directly
connected
Now the D--A link breaks:
D---x---A----------B
<D,dir,∞>
<D,A,2> ;; "dir": directly
connected
If A immediately notifies B that D is no longer reachable (distance
= ∞), then all is well. However, it is possible that, just before A
begins to do this, B notifies A first that it has a route to D, with cost 2. This will lead to "slow convergence to infinity" (demo).
slow-convergence fixes
The simplest is using a small value for infinity.
RIP: infinity=16, updates every 30 sec
Cisco IGRP: infinity <= 256; default = 100
Other fixes (covered week 7):
split horizon:
Don't report reachability to your own
NextHop for a node; in the example above, B would never report
D-reachability to A because A is B's NextHop to D.
poison reverse:
claim a node to be at distance infinity, when reporting to your own NextHop for that node
Poison reverse is a stronger form of split horizon.
triggered updates: send report
immediately on any change
for the worse. This is generally intuitive, except that it can lead to
notification storms, and there is still the possibility that the other
end will send first.
hold down: sort of a receiver-side version of triggered updates: the receiver doesn't use new alternate routes for ~60 sec following discovery of unreachability. This gives time for bad news to arrive.
route poisoning: hold down only for changes that increase hop count
Chapter 5: transport
UDP - P&D 5.1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source
Port
| Destination
Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Length
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
unreliable, unconnected (stateless). General uses: NFS, boot, RPC
, real-time data
checksum & algorithm
0000 checksum never occurs naturally, and is used in UDP as "checksum not used"
pseudo-header: include some IP header fields in UDP checksum
ports & final destinations
lost packets due to queue overflow (skipped)
at router
at host
socket programming interface (P&D 1.3) // done in java
udpclient/udpserver
simpletalk client, server: TCP and UDP versions
socket, bind, sockaddr_in, gethostbyname,
Note how socket programming interface corresponds to the following high-level actions:
- create a socket
- ask for a specific port number (server only)
- send or receive