Wouldn't GTSM and tcp-ao help with DOS attacks? I would recommend they be put in in the paragraph below.
7.3<https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-10#section-7.3> Mitigation of Denial of Service Attacks BGPSEC speakers should implement an update validation algorithm that performs expensive checks (e.g., signature verification) after performing less expensive checks (e.g., syntax checks). The validation algorithm specified in Section 5.2<https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-10#section-5.2> was chosen so as to perform checks which are likely to be expensive after checks that are likely to be inexpensive. https://tools.ietf.org/html/rfc5082 https://tools.ietf.org/html/rfc5925 As examples or recommendations for the "less expensive" checks. In fact it should be GTSM, tcp-ao THEN bgpsec validation. (coffee != sleep) & (!coffee == sleep) donald.sm...@centurylink.com<mailto:donald.sm...@centurylink.com> ________________________________ From: sidr [sidr-boun...@ietf.org] on behalf of Stephen Kent [k...@bbn.com] Sent: Monday, November 24, 2014 12:35 PM To: sidr@ietf.org Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10 Wes, To first order I agree with your concern of this DoS vulnerability, but with some minor clarifications. 1. BGPsec-signed updates are sent only between ASes that agree to send and receive (separate choices) this signed data. So, an attack of this sort is perpetrated only against an immediate neighbor that agrees to accept BGPsec traffic from you. You cannot send a BGPsec route to an arbitrary AS that it not configured for you as a neighbor. 2. As you noted, an AS can generate a path only for ASes that it holds, and thus, for which it holds private keys. So, a long path of the sort you describe is directly traceable to the resources holder, creating a "smoking gun" effect, for forensic purposes. If we can agree on a max path length, based on real world data, and RECOMMEND that routers enforce this limit, we can mitigate the ability of an AS to Dos it's neighbor (and others). That, combined with the ability to identify who added all of the questionable AS entries, might provide a deterrent to this behavior. Still, even with a max path length, there is the potential to add just a few, unnecessary ASes to every signed route that traverses an evil AS, to add to the burden of neighbors and those beyond. Given all the folks who track routing updates, this too will probably be noted by a bunch of folks, and because of the signatures, there will be no doubt about the source(s). So, here too, that may prove to be a deterrent. I believe someone at the meeting observed that smart implementations will try to address this sort of concern by postponing BGPsec crypto processing when resources get scarce. While I agree that this represents another attack vector, the ability to identify the perpetrators may diminish the attraction of this attack strategy. In any case, this is a good topic to address, perhaps in the BGPsec security considerations section, plus a separate document that suggests implementation notes. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
