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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
