Matt- Per discussion during IDR/SIDR meeting Friday, there may need to be some text in the security considerations around the attack vector of sending many updates with long (but valid) AS_Paths, since the analysis Sriram provided indicated a correlation between the length of the AS Path to be validated and CPU impact or convergence time impact. Sounds like we don't have a problem with long paths comprised of multiple prepends because Pcount means that there aren't multiple signatures, but validly signed strings of unique ASNs could still trigger this problem, whether they are generated accidentally or maliciously. We may also need to make the observation that rapid route churn with these sorts of prefixes are likely to make the impact even higher, such that it may be advisable to implement route flap dampening to provide additional protection against route churn.
That said, I'm not sure that this is strictly a security considerations addition, because we may need to make some suggestions in the design to protect against these sorts of scaling problems. I'm not sure if we can use analysis of existing routing table data to identify an 80/20 threshold of the longest credible AS Path and put a recommendation on a max_as_length value for the limit for protection against this attack, or whether we cannot recommend a value, and have to simply acknowledge that this is a problem and recommend that implementers provide a knob for setting a limit on AS Path such that implementations can intercept and drop long AS_Paths before the BGPSec machinery tries to validate them. Perhaps both, i.e. A reasonable default limit that can be raised or lowered if a user sees fit. Alternatively, we could suggest a fall-back method whereby excessively long-path BGPSec updates are deprioritized or throttled to avoid causing adverse performance impacts, perhaps in conjunction with existing RFD implementations for routes that are both long-path and churning. I can try to contribute some text once the WG weighs in on what direction they want to take to address this, but I wanted to at least get the discussion started. Thanks, Wes George On 10/27/14, 7:40 PM, "Matthew Lepinski" <[email protected]> wrote: >Just posted the -10 revision of the document. > >The only normative change was to decouple BGPsec validation from >Origin Validation. (This is a normative change to the validation >algorithm in Section 5.) This is based on working group discussions at >IETF 90 and confirmed on the list in September. > >Additionally, there were some text changes made, including a reference >to the AS-Migration document (and an accompanying text change >regarding pCount=0). > >I have a couple of improvements to the security considerations text >that I wasn't able to fold into this version of the document. > >Other than improving the security considerations, I am not aware of >any open issues in this particular document. > >- Matt Lepinski > >_______________________________________________ >sidr mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
