Member Avatar for scottyscotty19

Question: Highlight the part of the algorithm detailed in RFC826 which makes Arp Poison Routing (APR) possible and briefly explain your reasoning.

I am not 100% sure on this question, what is it asking for? I have read the document RFC826 but still confused.

Does it mean this this algorithm?

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
?Am I the target protocol address?
Yes:
If Merge_flag is false, add the triplet <protocol type,
sender protocol address, sender hardware address> to
the translation table.
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.

Source: http://www.faqs.org/rfcs/rfc826.html

Thanks

  • 1 Contributor
  • 1 Reply
  • 179 Views
  • 21 Hours Discussion Span
  • Latest Post Latest Post by scottyscotty19

Dani AI

Generated

Short answer: the packet‑reception part of RFC 826 that instructs the ARP handler to merge the sender’s <protocol, sender‑protocol‑address, sender‑hardware‑address> into the local translation table before the code even checks the opcode — and the clause that says a new hardware address “supersedes the old one.” In plain terms, the spec tells hosts to accept and update an IP→MAC mapping from any received ARP packet (request or reply) and to overwrite existing entries. (rfc-editor.org)

Why that enables APR/ARP‑poisoning: because ARP has no built‑in authentication and the RFC’s algorithm trusts the sender fields it receives. An attacker on the same LAN can send forged ARP packets (including unsolicited replies or gratuitous ARPs) that other hosts will accept and install, so traffic gets redirected to the attacker (MITM, sniffing or DoS). This is the classic ARP‑spoofing/poisoning vector documented in security literature. (sans.org)

What to write/highlight in an answer: point to the lines in the “Packet Reception” algorithm that (a) say “merge the <protocol, sender‑protocol, sender‑hardware> into the table” before opcode handling and (b) say the new hardware address replaces the old. Then add one sentence of reasoning: because the update happens unconditionally and without authentication, an attacker can inject forged mappings. That succinctly links the RFC text to the APR vulnerability. (rfc-editor.org)

Practical note (detection/mitigation): on real networks use monitoring (arpwatch/host tools) and network enforcement — static ARP for critical hosts, switch features like Dynamic ARP Inspection (DAI), and end‑to‑end encryption (TLS/IPsec) so MITM gains less value. Quick checks: list ARP entries and watch for rapid MAC changes. Example commands:

# Linux
ip neigh show
sudo ip neigh flush all

# Windows (cmd)
arp -a
arp -d *
# Live monitor
sudo tcpdump -n -i eth0 arp

DAI and ARP‑monitoring capabilities are standard vendor responses to this class of attack. (cisco.com)

Member Avatar for scottyscotty19

Anybody have any ideas?

I have done all the other 19 questions, but I am still stuck on this one.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.