Cisco – ICMP rate-limit on time-exceeded messages

A rate limit is not a prevention but rather an invitation to DoS - especially in the flavor presented above where packets are going to be dropped if a certain rate of unauthenticated packets without state information has been exceeded. Since everybody can forge packets (including source IP addresses) at this connection state without greater effort, a new DoS attack vector leveraging your rate limit facility will arise.

A rate limit generally will only make sense if you have

1. either a predictable hard or a soft connection limit in your configuration
2. set the rate limit for general traffic below this limit in order to be able to set up connections for priority or administrative traffic regardless of the load

While 1. often is hard enough to determine to even bother, 2. will obviously only work if you are able to reliably differentiate "priority or administrative" traffic from the rest upon connection setup - e.g. if it is coming through a different network interface.

In other cases, it would rather reduce your system's resiliency than add to it.

http://packetlife.net/blog/2008/dec/22/disabling-mpls-ttl-propagation/

http://www.ciscopress.com/articles/article.asp?p=680824&seqNum=4

Your packets are MPLS-encapsulated when the outer label's TTL is decremented to 0, but the inner packet TTL is not updated, so the TTL-expired labeled packet is forwarded on and the internal IP packet (with an apparently valid TTL) is returned to you as expired by the final MPLS router.

============================

When a labeled packet TTL expires the packet is actually forwarded on until the end of the 'tunnel' it's on, since the router that decremented the TTL field to 0 might not have a valid route back to the original sender. So the MPLS label is edited to indicate TTL expiration and eventually the final tunnel router decapsulates the 'valid but label-expired' packet and sends it back with a TTL failure message.

Disclaimer: I read through TTL-relevant sections of several RFC's but nothing was definite on this handling, so I would say that this behavior could vary from vendor to vendor.

Evidence from a captured packet:

Internet Control Message Protocol
Type: 11 (Time-to-live exceeded)
Code: 0 (Time to live exceeded in transit)
Checksum: 0xf4df [correct]
Internet Protocol, Src: 192.168.1.x (192.168.1.x), Dst: 8.8.8.8 (8.8.8.8)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00)
    Total Length: 92
    Identification: 0x6b56 (27478)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 2  <===== payload of packet entering MPLS tunnel
    Protocol: ICMP (1)
    Header checksum: 0x7abb [correct]
    Source: 192.168.1.x (192.168.1.x)
    Destination: 8.8.8.8 (8.8.8.8)
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0xf78f [correct]
    Identifier: 0x0001
    Sequence number: 111 (0x006f)
    Sequence number (LE): 28416 (0x6f00)
    Data (64 bytes)
MPLS Extensions
    Version: 2
    Reserved: 0x000
    Checksum: 0x5581 [correct]
    MPLS Stack Entry
        Length: 0x0008
        Class: 1
        C-Type: 1
        Label: 1864, Exp: 4, S: 1, TTL: 1
            0000 0000 0111 0100 1000 .... = Label: 1864
            .... .... .... .... .... 100. = Experimental: 4
            .... .... .... .... .... ...1 = Stack bit: Set
            Time to live: 1    <========== MPLS TTL