So I recently learned about the whole IP Datagram and its headers. We learned about the TTL field that exists because sometimes a packet from a certain network id will be sent to another router, but in the other router it will be sent back to the first router, resulting in an infinite loop that puts a load on the system. so TTL is made to limit the amount of times a packet can transfer, thus ending the loop.
so what came to my mind is that you could send a router that has a loop connection with another one a Datagram with the TTL set to 256, which means that each router processes a request 256 times (sending and receiving it) for each time you process it, which makes for a super easy Dos attack because the router takes 256 times the computing power that you take, thus making it easy to send a lot of packets overloading the system.
So I figured out that someone surely thought about this before me, and wondered what stops this from happening? is there a feature that stops this? maybe some defense mechanism? I tried googling it but couldn’t find the proper way to word it. thanks!
Time to live
of 255 does not cause a message to be sent 255 times.
It only means that the datagram will be forwarded along a route whose
maximum length is 255 hops.
Each router on the route will receive the datagram once and send
it out once only, while reducing the count.
Once the 255 is exhausted or the route peters out,
an error will be sent back to the original sender.
The TTL cannot be used to create a
So I figured out that someone surely thought about this before me, and wondered what stops this from happening? is there a feature that stops this? maybe some defense mechanism?
Yes, generally it’s avoided by not creating routing loops in the first place. They’re not something that you would see in normal operation. Automatic routing protocols (such as OSPF or BGP) are built specifically to generate a loop-free network.
Loops do happen, and such DoS is a concern (especially with unused network ranges it’s very easy to create a routing loop that remains unnoticed), but the primary mitigation is to fix the configuration so that the routing loop is removed outright – not to waste resources on complex defenses.
(For example, routers often use point-to-point links between each other. One might configure the link to use a /24 or similar subnet mask, which will appear to work just fine but – as soon as a unused address from that /24 is contacted, both routers will bounce the packet from one end of the link to another. The common mitigation is to change the netmask to the smallest possible, i.e. /31 or /127, so that no addresses are unused and the routing loop disappears.
As another example, let’s say you have router A with a broad “aggregate” route of a whole /16 towards router B – but router B only recognizes a few smaller ranges, while everything else goes along the default route back to router A. In other words, the subnets in use work perfectly fine, but the ones not in use are a loop just waiting to be triggered. The mitigation again is to remove the loop completely, which can be done simply by adding a “discard” route for the entire /16 on router B.)