If I change the time-to-live (TTL) field in an IP packet, should I also recompute the IP checksum?
And what about the checksum at the transport layer ? Will that have to change too?
Yes. If you change any field in the IP header, the checksum must be updated.
As for the checksum at the transport layer, it theoretically depends what the transport protocol is... however in practice I do not believe there exist any transport protocols whose checksums cover the IP TTL field. Certainly the pseudo headers for both TCP and UDP don't cover it.
Yes, if you change the TTL field, then you have to change the checksum also because checksum is related to TTL field.
Also, TTL will be changed at every hop. Since TTL is changing at every hop, so checksum will also be changed.
Related
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.
When a packet is sent from source to destination,it has to pass by through several routers and each router decreases the value of TTL of packet by 1. So header checksum is to be recomputed at each router since one of the header field i.e. TTL surely changes. Then how does the destination verifies the presence of error by calculating the checksum ,though the checksum it got has changed than that of checksum of source side?
When the packet leaves the source, it has some initial TTL and (hopefully) a valid checksum.
When the packet arrives at a router, the router checks only the IPv4 header checksum. If it is incorrect, it drops the packet. If it is correct, it (1) decrements the TTL; (2) checks that the TTL is higher than zero (otherwise the packet is dropped) and (3) computes and fills in the new IP header checksum.
Interestingly, the new checksum can be computed directly from the old checksum and the old and new value of the TTL, with some clever math: https://www.rfc-editor.org/rfc/rfc1624 so reading the whole IPv4 header again is not necessary.
Note that IPv6 has a hop limit (which works like the TTL) but no header checksum.
Every router calculates and verifies the checksum before routing, if there is a mismatch the router drops the datagram.
I'm dealing with IP packets which might contain UDP or TCP payloads.
If we only consider IP-level and transport-level headers, what could be a set of representative fields for one packet? That is, which header fields, considered as a whole, would make that packet unique? (in absence of duplicates, of course)
If we didn't consider the IP and TCP or UDP chksum fields, would a subset of the other fields be enough?
IP and UDP don't have a concept of "uniqueness". TCP does, implied by the sequence-number field. There aren't enough fields to make it clear when a packet gets duplicated or dropped in transit.
Update based on comments:
If you're writing both the sending and receiving code, you could include an IP option that identifies the packet uniquely. I'd recommend using the SATNET StreamId option (#8, see RFC 791, section 3.1) - it gives you 16 bits to work with and it's been around for over 30 years.
If you're not writing the sending code, I don't think you can do this - there just aren't any fields to base the comparison on in IP, ICMP, or UDP.
You can use the optional field of IP Header to append data for uniqueness (if you're sending) but you need to modify IHL to greater than 5.
What is the need for having checksum at various layers ? For eg, there is a checksum in TCP layer and again in IP layer and also Ethernet layer has it.
Is not it sufficient to have checksum at one layer ?
All three layers are needed, for multiple reasons:
IP does not always run over ethernet (imagine IP over RS-232 serial, something every Cisco and Unix box can do)
IP does not checksum the data
TCP packets can be reassembled incorrectly from IP packets and fragments that each have perfect checksums
Even if reassembled correctly, software or other errors could be introduced in the layers between IP and TCP
Even if all software functions correctly, and TCP/IP is over ethernet, the limited size of the checksums can be accidently correct (and will be at some point, given enough packets) in the face of persistent errors, so having more than one checksum is helpful.
Every time a new header is introduced there is more to checksum, and the new layer can't see the header bits of the layer below.
Ethernet checksum is a hop to hop checksum - meaning that it is recomputed everytime the Ethernet header fields change. TCP/UDP checksum is a end-to-end checksum meaning it is computed by the sender and verified by the receiver. TCP/UDP checksums cover the entire segment. IP checksum covers only the header. Ethernet CRC covers the entire frame.
The designers of IPv6 decided it's not necessary at all those layers and removed it in favor of checksums at other layers (such as those you mentioned).
Why is the Pseudo header prepended to the UDP datagram for the computation of the UDP checksum? What's the rational behind this?
The nearest you will get to an answer "straight from the horse's mouth", is from David P. Reed at the following link.
http://www.postel.org/pipermail/end2end-interest/2005-February/004616.html
The short version of the answer is, "the pseudo header exists for historical reasons".
Originally, TCP/IP was a single monolithic protocol (called just TCP). When they decided to split it up into TCP and IP (and others), they didn't separate the two all that cleanly: the IP addresses were still thought of as part of TCP, but they were just "inherited" from the IP layer rather than repeated in the TCP header. The reason why the TCP checksum operates over parts of the IP header (including the IP addresses) is because they intended to use cryptography to encrypt and authenticate the TCP payload, and they wanted the IP addresses and other TCP parameters in the pseudo header to be protected by the authentication code. That would make it infeasible for a man in the middle to tamper with the IP source and destination addresses: intermediate routers wouldn't notice the tampering, but the TCP end-point would when it attempted to verify the signature.
For various reasons, none of that grand cryptographic plan came to pass, but the TCP checksum which took its place still operates over the pseudo header as though it were a useful thing to do. Yes, it gives you a teensy bit of extra protection against random errors, but that's not why it exists. Frankly, we'd be better off without it: the coupling between TCP and IP means that you have to redefine TCP when you change IP. Thus, the definition of IPv6 includes a new definition for the TCP and UDP pseudo header (see RFC 2460, s8.1). Why the IPv6 designers chose to perpetuate this coupling rather than take the chance to abolish it is beyond me.
From the TCP or UDP point of view, the packet does not contain IP addresses. (IP being the layer beneath them.)
Thus, to do a proper checksum, a "pseudo header" is included. It's "pseudo", because it is not actaully part of the UDP datagram. It contains the most important parts of the IP header, that is, source and destination address, protocol number and data length.
This is to ensure that the UDP checksum takes into account these fields.
When these protocols were being designed, a serious concern of theirs was a host receiving a packet thinking it was theirs when it was not. If a few bits were flipped in the IP header during transit and a packet changed course (but the IP checksum was still correct), the TCP/UDP stack of the redirected receiver can still know to reject the packet.
Though the pseudo-header broke the separation of layers idiom, it was deemed acceptable for the increased reliability.
"The purpose of using a pseudo-header is to verify that the UDP
datagram has reached its correct destination. The key to
understanding the pseudo-header lies in realizing that the correct
destination consists of a specific machine and a specific protocol
port within that machine. The UDP header itself specifies only the
protocol port number. Thus, to verify the destination, UDP on the
sending machine computes a checksum that covers the destination IP
address as well as the UDP datagram. The pseudo-header is not
transmitted with the UDP datagram, nor is it included in the length."
E. Comer - Internetworking with TCP/IP 4th edition.
Pseudo IP header contains the source IP, destination IP, protocol and Total length fields. Now, by including these fields in TCP checksum, we are verifying the checksum for these fields both at Network layer and Transport layer, thus doing a double check to ensure that the data is delivered to the correct host.