7/8/2003
CSCE 590
Summer 2003

• Open Systems Interconnection Model
– End to End Layers:
• 7 – Application: interfaces directly with the user
• 6 – Presentation: provides data independence (different representation of numbers, network byte order)
• 5 – Session: establishes, manages and terminates connections between applications
• 4 – Transport: end-to-end error recovery and flow control
– Point to Point Layers:
• 3 – Network: creating logical paths for transmitting data from node to node; i.e. routing, switching
• 2 – Link: logical organization of data bits transmitted on a particular medium
• 1 – Physical: physical properties of communications media

• IP is older than OSI Model, so IP doesn’t exactly fit it
– Application – SSH, DNS
– Transport – TCP, UDP
– Network - IP
– Link/Physical – device drivers/wires and electricity

• Like envelopes within envelopes
• Frames = hardware layers
– Ethernet
– ATM
– Tokenring
• Packets = software layers
– IP
– IPX

• Has header and trailer
– Trailer 4 bytes
– Cyclic Redundancy Check (CRC)
• Frame header used for synchronization
– Tells NIC where frame begins so it can start pulling data
– 14 bytes
• Frame data is packet for next layer
• Max 1518 bytes, min 64 bytes

• IEEE 802.3
Ethernet frame
• Layer 2 MAC
Header
Preamble
101010…
7 bytes
1 byte
6 bytes
6 bytes
2 bytes
Start
Delimiter
Destination
MAC
Address
Source
MAC
Address
Length
Data
Field
10101011
Min: 64 bytes
Max: 1518 bytes
Layer 3+
4 bytes
Pad
Field
Frame CRC

• Alternating 0’s and 1’s in preamble to synchronize
• Start delimiter has last 2 bits as 11
• Length of data field does not include any padding to get minimum size
– In Ethernet II, is the Type field, value > 1500
• represents which memory buffer on dst it stored in = protocol of data field (IP = hex 0800)
• MAC addresses
– 48 bit hardware address of Network Interface Card
– First 3 bytes are the Organizationally Unique Identifier
(OUI) of NIC manufacturer
– All ones signifies broadcast address
• CRC does not include preamble and start delimiter

• tcpdump –en –XX –s 1518 –i eth0 |more
Ethernet II:
Protocol=IP;
Not packet length

• One layer’s header is part of another layer’s data
DATA
TCP
Header
DATA
IP
Header
DATA
Frame
Footer
Frame
Header
Frame
Header
IP
Header
TCP
Header
DATA
DATA

• How do we get from hardware MAC address at Layer 2 to IP address at Layer 3?
• Address Resolution Protocol (ARP)
– We don’t want a permanent mapping between
MAC address and IP address, needs to be dynamic
– ARP allows us, given an IP address, to find the physical address of the host with that IP address

• IP addresses are used to route a packet to its final destination
• MAC addresses are used to travel from intermediate hop to intermediate hop
• MAC Addresses are stripped and replaced from the frame at each hop.
– Next hop becomes new destination
– Current hop becomes new source
• IP routing provides which hop is next, MAC addresses and ARP get the frame there

0 1 2 3
Hardware Type
4 5
Hardware Length Protocl Addr Len
8 9
6
Protocol Type
Opcode
7
Source Protocol Address (cont)
20 21
10 11
12
Source Hardware Address
13 14
Source Hardware Address (cont)
16 17
15
Source Protocol Address
18 19
Target Hardware Address
22 23
24
Target Hardware Address (cont)
25 26 27
Target Protocol Address
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

• Hardware Type:
– Ethernet = 1
– ATM = 16
• Protocol Address Type
– IP = 0x0800
• Hardware Address Length: length of hardware address in bytes
• Protocol Address Length: length of hardware address in bytes
• Operation Code: 1 = Request, 2 = Reply

• Each machine keeps a local ARP cache of IP address-MAC address mappings for about 120 seconds each
• If an IP address is not in its cache, it broadcasts an
ARP Request to all machines on the local network
• Non-target machines receiving broadcast may cache sender’s MAC and IP addresses to help reduce broadcast traffic
• Destination MAC address is all 1’s
• arp who-has 10.252.49.4 tell 10.252.49.5

• The machine that has that IP address, issues an ARP Reply
• It also caches the requestor’s IP and MAC addresses
• Requestor gets response and caches it
• arp reply 10.252.49.5 is-at 00:06:de:ad:be:ef
• Many machines will cache an unsolicited arp reply which can enable ARP spoofing and sniffing on switched networks

• Unsolicited ARP reply Man-in-the-Middle
10.10.32.200
10.10.32.100
ARP Cache Contents Afterwards:
10.10.32.100 = 00:00:de:ad:be:ef arp reply 10.10.32.100 is-at 00:00:de:ad:be:ef
10.10.32.50
00:00:de:ad:be:ef

• Sniffing on Switched Networks
• ARP spoof the default gateway of the subnet sending to the switch
• Switch will have 2 entries for default gateway in cache, and will send each packet to both
• Or on older switches, you could flood ARP cache with bogus entries, causing the switch to fail open, like a hub. Sends each packet to all ports

ARP Cache Contents Afterwards:
10.10.32.1 = 00:00:da:da:be:ee
10.10.32.1 = 11:11:de:ad:be:ef
11:11:da:da:be:ee
10.10.32.1
10.10.32.200
arp reply 10.10.32.1 is-at 00:00:de:ad:be:ef
10.10.32.50
00:00:de:ad:be:ef

• Packets have positional fields
• Predefined number of bits allocated to each field
• Some optional fields vary in size
– Other fields describe their length
– Example is data field
• No footers like with frames

Version
0
Hdr Len
1
Type of Service
5 4
IP Identification Number (Frag ID)
8 9
TTL
12
16
IP Protocol
13
R D
F
M
F
2 3
Total Length in Bytes
6 7
17
Source IP Address
18
10
Fragment Offset (13 bits)
11
14
Header Checksum
15
19
20
Destination IP Address
21 22 23
Options (Variable Length 0-40 bytes, padded with 0’s)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

• Version: 4 bits, version of IP, usually 4, but 6 is becoming more common
• Header Length: 4 bits, Length of IP header in 32bit (4 byte) words
– Maximum of 60 words
– Commonly 5 words (with no IP options)
• Type of Service (TOS): 8 bits, nominally the type of service the packet should receive
• Total Length: 16 bits, total length of IP packets in bytes. Max possible 65535 bytes

• Need fragmentation because not all networks’ MTUs (Maximum Transition
Units) are the same
• Occurs when MTU is smaller than datagram
• Reassembled at destination host
• Each fragment in encapsulated in an IP datagram
• Can be used to bypass routers and IDS

• IP fragmentation fields:
– Fragmentation ID, Offset, and Flags
– Fragments must share a common fragment identification number
– Must tell the offset of this data fragment in original unfragmented datagram
– Must tell length of data in this fragment
– Must tell whether more fragments are to follow

• Each IP packet has a unique IP Identification number
• Increments by 1 for each datagram in a session
• In a fragmented packet, each datagram fragment retains the original IP ID Number as a Fragment
ID Number.
• This identifies a fragment as belonging to an original datagram to the reassembling host

• Three bit flag field
• Bit 0 is reserved and not used
• Bit 1: DF – Don’t Fragment when set to 1
– What if fragmentation is needed? A router will send back an ICMP unreachable – need to fragment packet to the source with the size of the maximum MTU
• Bit 2: MF – More Fragments when set to 1

• 13 bit field
• Tells the receiving system where the datagram belongs in the original datagram so that it can be reconstructed
• From the perspective of IP data field: TCP,
ICMP, UDP fields are included in the offset

• On Windows:
– ping –n 1 –l 3300 10.10.33.1

• Ethernet = 1500 bytes
• Each IP header takes 20 bytes
• So 1480 bytes of data in each fragment
• The total packet size we have to break up is 3300 data bytes + 20 bytes IP header + 8 bytes ICMP header = 3328 bytes
• First fragment gets IP header and ICMP header and (1500-20-8) 1472 bytes data
• The rest of the fragments do not have the ICMP header

1.
20 bytes IP, 8 bytes ICMP, 1472 bytes data fragment ID = 4620, length = 1480 offset = 0, MF = 1
3300 – 1472 = 1828 bytes remaining
2.
20 bytes IP, 1480 bytes data fragment ID = 4620, length = 1480 offset = 1480, MF = 1
1828 – 1480 = 348 bytes remaining
3.
20 bytes IP, 348 bytes data fragment ID = 4620, length = 348 offset = 2960, MF = 0
0 bytes remaining

• Fragmenting to blind IDS
– Never sends final piece
– Or piece missing in middle
– Some IDS reconstruct fragmented packets to
‘normalize’ them and check against signatures
– Only so much memory assigned to it
– Or a limited number of fragmented packets can be reconstructed at once
• If IDS does not normalize, split attack up into frags and it won’t match signatures

• Denial of Service
• Very large datagram crafted using fragments
• When reassembled by victim, the maximum
IP datagram size of 65535 is exceeded
• Causes crashes, system hangs, BSOD
• Is *OLD*, all vendors should have a patch

• What’s wrong with this picture?
1.
evilfragger.org.139 > target.edu.139: udp 28 (frag 242:36@0+)
2.
evilfragger.org > target.edu: (frag 242:4@24)
•
Remember (frag fragID:length@offset)
•
It reboots or crashes some unpatched machines

1.
evilfragger.org.139 > target.edu.139: udp 28 (frag 242:36@0+)
2.
evilfragger.org > target.edu: (frag 242:4@24)
Byte 0 Byte 24
(frag 242:4@24)
Byte 27
Fragment 2
Fragment 1
(frag 242:36@0+)
Byte 35

• Read Chapter 6