Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10

Chris,

You are correct that was the thinking that went into Section 7.3. That is,
Section 7.3 focuses on mitigating any new denial of service possibilities
that are introduced by the BGPsec extensions to BGP.

I am happy to make this more clear in the text.

- Matt Lepinski

On Mon, Jan 12, 2015 at 1:25 PM, Christopher Morrow <morrowc.lists@gmail.com
> wrote:

> On Mon, Nov 24, 2014 at 3:08 PM, Smith, Donald
> <Donald.Smith@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.Smith@centurylink.com
> > ________________________________
> > From: sidr [sidr-bounces@ietf.org] on behalf of Stephen Kent [
> kent@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
>