--- 1/draft-ietf-v6ops-pmtud-ecmp-problem-05.txt 2015-10-18 20:15:13.134427791 -0700 +++ 2/draft-ietf-v6ops-pmtud-ecmp-problem-06.txt 2015-10-18 20:15:13.162428466 -0700 @@ -1,21 +1,21 @@ v6ops M. Byerly Internet-Draft Fastly Intended status: Informational M. Hite Expires: April 20, 2016 Evernote J. Jaeggli Fastly October 18, 2015 Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB) - draft-ietf-v6ops-pmtud-ecmp-problem-05 + draft-ietf-v6ops-pmtud-ecmp-problem-06 Abstract This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination (typically the server) in ECMP load balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures. Status of This Memo @@ -69,30 +69,30 @@ Operators of popular Internet services face complex challenges associated with scaling their infrastructure. One scaling approach is to utilize equal-cost multi-path (ECMP) routing to perform stateless distribution of incoming TCP or UDP sessions to multiple servers or to middle boxes such as load balancers. Distribution of traffic in this manner presents a problem when dealing with ICMP signaling. Specifically, an ICMP error is not guaranteed to hash via ECMP to the same destination as its corresponding TCP or UDP session. A case where this is particularly problematic operationally is path - MTU discovery RFC 1981 PMTUD [RFC1981]. + MTU discovery [RFC1981]. 2. Problem A common application for stateless load balancing of TCP or UDP flows is to perform an initial subdivision of flows in front of a stateful load balancer tier or multiple servers so that the workload becomes divided into manageable fractions of the total number of flows. The flow division is performed using ECMP forwarding and a stateless but - sticky algorithm for hashing across the available paths (see RFC 2991 + sticky algorithm for hashing across the available paths (see [RFC2991] for background on ECMP routing). This nexthop selection for the purposes of flow distribution is a constrained form of anycast topology, where all anycast destinations are equidistant from the upstream router responsible for making the last next-hop forwarding decision before the flow arrives on the destination device. In this approach, the hash is performed across some set of available protocol headers. Typically, these headers may include all or a subset of (IPv6) Flow-Label, IP-source, IP-destination, protocol, source-port, destination-port and potentially others such as ingress interface. @@ -316,27 +316,28 @@ 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations The employed mitigation has the potential to greatly amplify the impact of a deliberately malicious sending of ICMPv6 PTB messages. Sensible ingress rate limiting can reduce the potential for impact; however, legitimate PMTUD messages may be lost once the rate limit is - reached; analogous to other cases where DOS traffic can crowd out - legitimate traffic. + reached; the scenario is analogous to other cases where DOS traffic + can crowd out legitimate traffic, however with a limited subset of + overall traffic. The proxy replication results in devices on the subnet not associated with the flow that generated the PTB, being recipients of the ICMPv6 PTB message; which contains a large fragment of the packet that - exceeded the allowable MTU. This replication of the packet freagment + exceeded the allowable MTU. This replication of the packet fragment could arguably result in information disclosure. Recipient machines should be in a common administrative domain. 8. Informative References [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, . [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and