Subject: [v6ops] ICMP rate-limiting in draft-ietf-v6ops-ipv6rtr-reqs-00

From: "Alvarez, Pablo" <[email-masked]>
Date: Sun, 30 Jul 2017 21:36:31 -0400

I presented data at IETF-99 maprg showing that traceroutes work less 
well in IPv6 than in IPv4, and that this is likely due to rate limits 
required by RFC 4443, which are set to very restrictive values on some 
routers. Moreover, the data suggest that many rate limits may be left at 
router manufacturer defaults.

Slides: 
https://www.ietf.org/proceedings/99/slides/slides-99-maprg-rate-limiting-of-ipv6-traceroutes-is-widespread-measurements-and-mitigations-02.pdf 

Video: 
https://www.youtube.com/watch?v=qYtaKuzXaiM&list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h, 
minute 37:20

Accordingly, I suggest amending the language regarding ICMP filtering in 
the draft as follows:

1. Paragraph 5.4, third bullet

Proposed:
o  SHOULD rate limit the generation of ICMP error messages
    with a token bucket method as described in [RFC 4443].
    Rate limits SHOULD be narrow enough to (a) protect the
    device's ability to generate packets and (b) reduce the
    usefulness of ICMP error packets as part of a distributed
    denial of service attack. Limits SHOULD be generous enough to
    allow successful path MTU discovery and traceroute. For
    example, in a small/mid-size device, the possible defaults
    could be bucket size=100, refill rate=100/s. Larger devices
    can afford more generous rate limits.

Current draft:

oSHOULD rate limit the generation of ICMP messages relative to 
theability of the device to generate packets and to block the use ofICMP 
packets being used as part of a distributed denial of serviceattack

The example refill rate and bucket size suggested here are 10x higher 
than the similar example in RFC4443, which was published in 2006. 
Internet traffic has grown 30x since 2006, single CPU speeds have grown 
9x, and devices usually have many more CPUs, so this increase in the 
suggested rate limits seems reasonably prudent.

I would also like to suggest the following revisions to the first 
bullet, to clarify what types of packets should not be filtered:

Proposed:
o  SHOULD NOT filter Destination Unreachable or Packet Too Big
    ICMP error messages by default, as this has negative impacts
    on many aspects of IPv6 operation, particularly path MTU discovery.

Current draft:

oSHOULD NOT filter ICMP unreachables by default, as this has
negative impacts on many aspects of IPv6 operation, particularly
path MTU

Finally, I have a concern about the second bullet in paragraph 5.4. The 
current draft states:

o  SHOULD filter ICMP echo and echo response by default, to prevent    
the discovery of reachable hosts and topology.

This recommendation is quite strong, and is presented without further 
discussion or justification. I am interested in the justification for 
this, and its value as compared to the cost to researchers, CDNs, 
network operators and others who benefit from being able to better 
understand network topology (and who can provide better service to end 
users with that understanding). In fact, paragraph 4.2 of the current 
draft emphasizes the importance of being able to visualize and 
understand network topology.

Pablo Alvarez

Akamai Technologies

---

From: Simon Hobson <[email-masked]>
Date: Mon, 31 Jul 2017 11:31:11 +0100

"Alvarez, Pablo" <[email-masked]> wrote:

> Finally, I have a concern about the second bullet in paragraph 5.4. The current draft states:
> 
> This recommendation is quite strong, and is presented without further discussion or justification. I am interested in the justification for this, and its value as compared to the cost to researchers, CDNs, network operators and others who benefit from being able to better understand network topology (and who can provide better service to end users with that understanding). In fact, paragraph 4.2 of the current draft emphasizes the importance of being able to visualize and understand network topology.

It does seem odd, and it's been a bugbear of mine (with my work hat on) that basic troubleshooting should be so hampered by people who think that filtering ICMP Echo endows some sort of security. I liken it to someone removing the house number from the front of the house as though not having it visible somehow protects from burglars.