" ITREALMS: Steps to observe packet spoofing by ISPs (9)


Join us @2023 NDSF ... coming loaded only for 5G - ITREALMS

ITREALMS ... making leadership SENSE with digital news! The 2023 Nigeria DigitalSENSE Forum, Internet Governance, Development, IG4D, is comi...

Wednesday, May 28, 2008

Steps to observe packet spoofing by ISPs (9)

The local machine, with IP address, reported transmitting a total of five RST packets to the remote machine at (packet nos. 2340, 2342, 2346, 2350, and 2354), while it reported receiving 13 such packets from (packet nos. 2338, 2339, 2343, 2344, 2347, 2348, 2351, 2352, 2355, 2356, 2357, 2358, and 2359).

The remote machine, with IP address, reported transmitting only a single RST packet (packet no. 2560) while it believes it received 17 RST packets from (2549, 2550, 2551, 2552, 2553, 2554, 2555, 2556, 2557, 2558, 2561, 2562, 2563, 2564, 2565, 2566, 2567).

Evidently, many of the RST packets received by each machine did not actually originate from the other. 11 The result of these RST packets in this case was that the BitTorrent session stopped and did not resume for around four and a half minutes.

(A new TCP session is established with the characteristic SYN and SYN/ACK packets at local capture packet nos. 2446 and 2447, which correspond to the remote capture’s packet nos. 2578 and 2579.)

Wireshark provides the ability to view not only a packet summary list like the lists displayed above but also the sequence of bytes that comprise each individual packet, as well as a dissector view, which shows what the packet’s contents actually mean from the point of view of various Internet protocol layers.

A careful examination of this evidence could involve a byte-for-byte, packet-for-packet comparison to determine exactly which packets were spoofed. If one is performing such a comparison, it is important to appreciate that Wireshark captures more than just the IP packets that get transmitted over the Internet; each IP packet is typically captured wrapped inside a link-layer header (often referred to as an Ethernet frame header or Ethernet packet header on an Ethernet-style network, including a wired Ethernet or WiFi network).

Link-layer headers are used to communicate between computers on the same local Ethernet network and are discarded and regenerated whenever a packet is forwarded through any router. Thus, there is no reason to expect link-layer headers to correspond between two packet traces unless those packet traces were captured on the same physical local-area network. When manually performing a detailed packet comparison, packets should be considered “the same” if the Internet Protocol headers and payload match up; the link-layer headers can simply be ignored because they were never forwarded over the Internet.

ITREALMS Online ... delivering news for ICT4D

No comments: