Comp 343/443    

Fall 2011, LT 412, Tuesday 4:15-6:45
Week 6, Oct 4

Read:
    Ch 1, sections 1,2,3 and 5
    Ch 2, sections 1, 2, 3, 5, 6
    Ch 3, sections 1, 2, 3

Midterm: October 25

Homework 1

Note that the bandwidth delay + propagation delay is a per-link attribute; for multiple links you just add up the delays for each individual link (assuming store-and-forward).
17/19: basic one-way multi-hop delay problem as above
20/22: sending two half-sized packets over two links is faster than one big packet. Propagation (& switch/queuing) delays are the same, but we save 25% of the total one-big-packet bandwidth delay.
37: note the steady-state queue size of 2.
Additional problem: A-R throughput is 3 pkts / 50 ms. R-B throughput is 1 packet per 10+X ms, where 10 = 2*5 is the total propagation delay both ways and X is the bandwidth delay for the data packet (one-way).
How to type a µ (bonus question: can you get µ into an SMS message?)

Finish subnet example A: size 70

B: size 40
C: size 25
D: size 20

Give each of these a subnet so they can all share a single 200.0.0.0/24. The first three bytes of each subnet address must match 200.0.0. Only some of the bits of the fourth byte will be part of the subnet address, so we'll switch to binary for the last byte, and use both the /n notation (for total number of subnet bits) and also add a vertical bar | to mark the separation between subnet and host.

Example: 200.0.0.10 | 00 0000 / 26

Note that this means that the 0 bit following the 1 bit is "significant" in that for a subnet to match, it must match this 0-bit exactly. The remaining 0-bits are part of the host portion.

Note that subnet sizes are always powers of 2, so we start by rounding up the subnets to the appropriate size.

Note that routing is now hierarchical.

Class B example?


ARP and DHCP

How does a router (or host) find the physical address of a neighbor on the same network? The Address Resolution Protocol (ARP) is generally used. Alternatives: polling, link-layer notice, IP-layer notice
 
Basic ideas: broadcast request/unicast reply, cache
 
Timeout: used to be ~10 minutes (20 min for early linux),
now is much less (linux 2.4 arp timeout is ~60 seconds)

    see: http://www.cs.helsinki.fi/linux/linux-kernel/2002-07/0179.html
    ip -s neigh
    
finer points:
If A arps "where is B?"
        1. B always puts A in its cache
        2. All hosts with A in their cache update the entry
Self-arp, or gratuitous arp: detects duplicates, ethernet address changes send an arp request for yourself (and hope you don't get answers!)
 


 

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.

Arp failover
 

More ARP woes
Flooding: 
What if A tries to send 100 packets to B; how many ARPs are sent? Solution: queue the arp requests
Another flood scenario: A broadcasts, everyone replies & needs to ARP to get A's addr (because they failed to save it earlier).

These are pretty well resolved now

ARP and networks without broadcast [eg ATM]
Failure of ARP in the presence of looping (Ethernet, of course, fails in the presence of looping, but ARP looks like an IP protocol.)

Proxy ARP: having someone else answer for you

Detecting sniffers
To find out if host A is in promiscuous mode, send an ARP "who-has A?" query. Address it not to the broadcast Ethernet address, though, but to some nonexistent Ethernet address.

If promiscuous mode is off, A's NI will reject the packet.
If promiscuous mode is on, A's NI will pass the arp request to A itself, which will probably answer it.

Alas, linux kernels reject at the software level arp queries to physical ethernet addresses other than our own.
BUT: they do respond to faked Ethernet multicast addresses.

Windows: try Ethernet addresses ff:ff:ff:00:00:00 or ff:ff:ff:ff:ff:fe

You can ping A's actual IP address (which requires a separate ping for each host, and a prior scan to find all the hosts), or try pinging the IP b'cast address (all 1's in the host part).
        

Dynamic Host Configuration Protocol (DHCP)

DHCP was once known as Reverse ARP (RARP)
You broadcast your own Ethernet address, and hope a DHCP server finds it and sends you your IP address. The DHCP server may also include other helpful startup options!!!

DHCP and servers: who's going to update the DNS entries?

Minimal network config:
If you lose your default router, you are hosed. Here's something that sometimes happens to me:
  1. I am connected to the internet via Ethernet, and my default router is via my Ethernet interface
  2. I connect to Loyola's wireless network.
  3. Their DHCP server sends me a new default router on the wireless network. However, access is blocked, because wireless support for linux at Loyola is broken and the network registration process fails
  4. I disconnect from the wireless network, but I do not get back my Ethernet default-router entry. As a result, I now have no router at all, and have to fix it manually.


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.
or 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.

 
 

Chapter 5: transport

UDP - P&D 5.1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
UDP is unreliable and unconnected (stateless).
General uses: NFS, boot, RPC , real-time data

checksum & algorithm
        0x0000 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
 
socket programming interface (P&D 1.4)  // done in java

simpletalk client, server: TCP and UDP versions

UDP: server, client

TCP: server, client,  threaded server
Note how socket programming interface corresponds to the following high-level actions:
        
 

Routing-table algorithms (§4.2 (4th edition) or §3.3 (5th edition))

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:
  1. new node reported
  2. 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.
  3. increased distance reported by NextHop for that node (not used in Week 6 example)
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