On Mon, Nov 24, 2014 at 3:08 PM, Smith, Donald <donald.sm...@centurylink.com> wrote: > Wouldn't GTSM and tcp-ao help with DOS attacks? >
I think this was focused only on the uplift to bgp that bgpsec is supposed to be, so the assumption was/is that you'd already be doing 'bgp best practices'. (authors are free to correct me, as always) -chris > I would recommend they be put in in the paragraph below. > > 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 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 > ________________________________ > 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 > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
