Martin, Apologies for the delayed response. Got busy with too many other things.
The only thing remaining is the security issue. Would the following text added to the security section address your concern? >>> It is possible for a sophisticated attacker with knowledge of the details of large flow recognition algorithm (packet fields used and parameters of the algorithm) and the network topology to launch an attack in which sufficient traffic is generated so as to result in the flow being recognized as a large flow resulting the the installation of a PBR rule. Subsequently, the attacker can generate traffic for other such flows resulting in consuming entries in the PBR table until the older, inactive flows are removed. >>> Thanks, Anoop On Wed, May 7, 2014 at 1:25 PM, Martin Thomson <[email protected]> wrote: > Inline... > > On 6 May 2014 19:16, Anoop Ghanwani <[email protected]> wrote: > >> There's not a lot of discussion about the costs of maintaining an > >> exception list for rebalanced flows. A hash-based distribution is > >> going to cost essentially zero state because the outbound path can be > >> determined on a per-packet basis, but as soon as you start > >> redistributing, there is an added state cost (and potential increase > >> in lookup times). That probably needs some discussion. > >> > > > > We could probably add another subsection to Section 6 which discusses > > operational considerations. Would the following address this concern? > > > > 6.3 Forwarding Resources > > > > Hash-based techniques used for load balancing with LAG/ECMP > > are usually stateless. The mechanisms described in this document > > require additional resources in the forwarding plane of routers for > creating > > PBR rules that are capable of overriding the forwarding decision from > > the hash-based approach. These resources may limit the number of > > flows that can be rebalanced and may also impact the latency experienced > > by packets due to the additional lookups that are required. > > Yep, that's perfect. > > >> This plays into the security considerations, which I think need to > >> highlight this as a potential DoS vector. Implementing automatic > >> redistribution on top of a hash-based stateless distribution is > >> vulnerable to attack if the hash function used is predictable. > >> > > > > Can you say something more about this attack? Is it that an attacker > > would send large flows that map to the same link in order to consume > > resources in the PBR table? > > That's exactly the concern. Similar concerns arise in hash tables > that are predictable. If an attacker wants to mount a DoS attack, one > vector they have open to them is to overload a single bucket, forcing > lookup times to increase from O(1) to O(N). There's some research on > the matter, http://cr.yp.to/papers/surf.pdf for example. > > > Yes, we have had issues with this when converting from Word and > > keep forgetting to adjust the .txt before submitting. > > It's probably too late for this, but you might find this useful in > future: https://github.com/cabo/kramdown-rfc2629 (see it in action > here: https://github.com/tlswg/tls13-spec) >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
