I have a question that I encountered in my Operating Systems exam today.
Given a process that "forges" the IP address in every sent packet (gives the wrong IP address), does the ARP work correctly?
I maintain that it doesn't, since the packet wouldn't know where to return the "ack".
Would love to hear your opinions.
I maintain that it doesn't, since the packet wouldn't know where to return the "ack".
It is returned to the sender's MAC address, not IP address.
From RFC 826:
When an address resolution packet is received, the receiving Ethernet
module gives the packet to the Address Resolution module which goes
through an algorithm similar to the following. Negative conditionals
indicate an end of processing and a discarding of the packet.
?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.
What this means?
ARP is return addressed using MACs, although IP addresses can also be included in the Sender protocol address (SPA) field of the packet. This means that although the sender IP address (SPA) is spoofed, there is no mention of the Sender hardware address (SHA) being spoofed in your question.
This means that the sender will receive the ARP replies and ARP will function (from the point of view of the sending machine). However, as the ARP packets contain a spoofed SPA, the target machines (and possibly other devices on the network) will associate the sender as having that IP address, enabling a successful ARP poisoning attack:
e.g. Linux ignores unsolicited replies, but on the other hand uses seen requests from other machines to update its cache.
I think it will know where to return the ack to, because the sender sends his MAC address and this what matters. Yet I think it won't work because the receiver will change his ARP table according to the MAC&IP he got from the sender. (this is a trivial optimization).
Related
I think at L2 it will be ether type and destination MAC address.
at L3 it can be protocol field and Destination IP Address.
I want to know what are the other fields by which we can differentiate between control and data packet.
#Anupam Thakur: In pure L2 infrastructure, on receiving frame, node does the bridge-table/l2-table/cam lookup based on destination mac address. For different BPDUs (almost always reserved multicast mac dst addresses, few exceptions beyond the scope of this question) wherever required cam table is programmed with punt path to control-plane module (/also). Note, punt path doesn't distinguish between different protocols. It's job is to just push the packet in Q towards control-plane module. When cp module receives such packet, based on ethertype or LLC content it determines the further protocol processing of the packet.
"Router Alert Option" in IP header can also force packet to be punted to Control Plane, even though it is not destined for recipient device. (i.e. transit node)
Inside an IP network IPv4 protocol is being used. When a datagram is being transported through the network (TTL=2), an error occurs inside the field which contains TCP-segment with the address of a web page. What will be the reaction of the router when reading such datagram?
I'm battling with this question for two days now.
What I know:
the router only reads the header of the datagram and if the checksum fails the datagram is being discarded by the router,
TTL is always decremented by one by the router if the header checksum is OK, after the -1, the datagram is being forwarded to the next router in the network
Based on this two points I conclude that the datagram will go further and TTL will be 1 and new checksum will be calculated by the router.
However there are three other possible answers to the questions:
The router sends ICMP to source with the error
the router repairs the mistake based on the header checksum and then forward the datagram
the router sends the datagram out of the network (discards the datagram)
Any help with clearing this problem?
The exact algorithms that must be implemented by IPv4 routers is described in RFC 1812 - Requirements for IP Version 4 Routers. According to the IETF RFC Index it still applies ("Status: BEST CURRENT PRACTICE").
The forwarding algorithm can be found in Section 5.2.1. The constraints determining the dependencies between the steps are (quoting):
(1) A router MUST verify the IP header, as described in section
[5.2.2], before performing any actions based on the contents of
the header. This allows the router to detect and discard bad
packets before the expenditure of other resources.
(2) Processing of certain IP options requires that the router
insert
its IP address into the option. [...]
(3) The router cannot check and decrement the TTL before checking
whether the packet should be delivered to the router itself, for
reasons mentioned in Section [4.2.2.9].
(4) More generally, when a packet is delivered locally to the
router,
its IP header MUST NOT be modified in any way [...].
The actual steps performed when receiving a packet are (quoting):
(1) The router receives the IP packet (plus additional information
about it, as described in Section [3.1]) from the Link Layer.
(2) The router validates the IP header, as described in Section
[5.2.2]. Note that IP reassembly is not done, except on IP
fragments to be queued for local delivery in step (4).
(3) The router performs most of the processing of any IP options.
As
described in Section [5.2.4], some IP options require additional
processing after the routing decision has been made.
(4) The router examines the destination IP address of the IP
datagram, as described in Section [5.2.3], to determine how it
should continue to process the IP datagram. There are three
possibilities:
o The IP datagram is destined for the router, and should be
queued for local delivery, doing reassembly if needed.
o The IP datagram is not destined for the router, and should be
queued for forwarding.
o The IP datagram should be queued for forwarding, but (a copy)
must also be queued for local delivery.
So it is clear that checksum verification of the IPv4 header is performed first. The exact steps are described in Section 5.2.2 IP Header Validation, but they are not important here. What matters is that only the IP header is checked, not the content. Therefore the router cannot detect the error.
Based on this two points I conclude that the datagram will go further and TTL will be 1 and new checksum will be calculated by the router.
Correct.
As for the other options:
The router sends ICMP to source with the error
No, there is no Time Exceeded error. As for other ICMP errors, there are none that signal to the sender packet corruption. So even if the router could detect packet corruption (say if the corrupted bit was in the IP header), it would still not send an ICMP message.
The router repairs the mistake based on the header checksum and then forward the datagram
No, the checksumming performed in IPv4 and TCP only allows error detection, not correction.
The router sends the datagram out of the network (discards the datagram)
It does not discard it because it does not detect the error.
Regarding what I said in the comment about link layer error detection, there are usually two sources of errors in transit: (1) from the transmission medium (interference, damaged cable, improperly connected plug etc.) and (2) from forwarding devices themselves (defective memory chips, firmware bugs, cosmic rays hitting a chip etc.). The link layer can usually detect and may even correct errors from (1), but obviously not from (2). So the scenario described in the question is indeed possible if a device malfunction corrupted the packet contents.
packet switching is a protocol, where a message received from tcp layer is divided into packets only at sender machine ip layer and each packet is sent individually on different routes with an identification field set in ip header to help use re-assemble at destination machine.
Where as
fragmentation at ip layer is done on sender machine or any of the, on the way layer 3 device ip layer and fragmentation field is set in ip header to help use re-assemble at destination machine only.
My question:
is my understanding correct?
In packet switching, If message could not be re-assembled due to missing packet at destination, based on identification field, that message is discarded at ip layer of destination machine and tcp layer of sender machine will take care of retransmission of that message, am i correct?
packet switching is a protocol
No. Packet switching is an alternative to circuit switching at the physical layer.
where a message received from tcp layer is divided into packets only at sender machine ip layer and each packet is sent individually on different routes with an identification field set in ip header to help use re-assemble at destination machine.
None of this is correct as a description of packet switching. Packet switching implies the existence of packets, period. It doesn't impose any of these constraints.
Whereas fragmentation at ip layer is done on sender machine or any of the
... intermediate nodes
on the way layer 3 device ip layer
Layer 2
and fragmentation field is set in ip header to help use re-assemble at destination machine only.
My question:
is my understanding correct?
No. You seem to think that packet switching and fragmentation are in some kind of opposition. They aren't. Fragmentation is an extension of packet switching if anything, not an alternative to it.
In packet switching, If message could not be re-assembled due to missing packet at destination, based on identification field, that message is discarded at ip layer of destination machine and tcp layer of sender machine will take care of retransmission of that message, am i correct?
No. Again you're confused about what packet switching is. Your remark applies pretty well to TCP, but that's because of the semantics of TCP, not because of packet switching.
Is it possible to push all packets received at NIC to the TCP/IP stack even if their ethernet address doesn't match my ethernet address? In other words I want to process all incoming packets at my NIC.
Can anyone mention a possible scenario for changing network interface driver code?how could I check the operation of driver code?
In the typical system, this already happens. That is, all you have to do is put the interface into promiscuous mode. The driver then sends all packets it receives to the TCP/IP stack. Check any ordinary network driver, you'll see that in processing received packets, there is no comparison of the MAC (or ethernet) address with the device's MAC address.
Simplifying considerably:
What normally happens is that when you don't have promiscuous mode enabled, the driver configures the device such that it filters on a specific MAC address, only delivering frames that have a matching address or a broadcast address (or occasionally a multicast address, which may or may not also be filtered). When you enable promiscuous mode, the driver simply tells the device not to filter on MAC address but to deliver all frames. The driver then will receive all frames and deliver them to the stack. In linux, this typically happens through a call to netif_receive_skb() or a variant thereof.
The TCP/IP stack itself doesn't care about the MAC address. It will instead look for packets that have an IP address matching one of its own. Any packets received that don't have an IP address belonging to this box are simply discarded -- unless there's a user-mode program trying to receive raw packets (such as tcpdump). [In the latter case, it's still discarded after being delivered to tcpdump.]
If it matches on the IP address, it's then passed up the stack to TCP or UDP [etc] -- where it could also be discarded if it doesn't correspond to a session / port that anything on the box cares about.
But typically packets destined for a MAC address not matching one assigned to this device will not be packets that this machine cares about. Hence, promiscuous mode is usually only enabled for debugging, troubleshooting, forensics (i.e. tcpdump, wireshark, etc). The rest of the time, it's a waste of processing resources since the packets will just be discarded.
I have a router1-switch-router2 connection. My problem is if I send a packet from router1 to router2, it is not received at router2. I am sure the ipaddress/subnet address are correct. And am also sure that packets are going out the router1. And I am also sure of the internal port connections of the switch. I have access to the onpath switch. Is there any specific command that can be used in the switch to check whether the packet is received or not? ARP itself not getting resolved
You can have a packet capture app running on both the sender and receiver that would tell the incoming and outgoing packets on both boxes.
In this case probably your packet is getting dropped either on the sender or receiver side. There can be million reasons for a packet drop. But this is a good step to start with.