On 4/6/2012 11:21 AM, Shane Amante wrote:
a) BGP performs loop detection on the AS_PATH attribute *before* verifying any
BGPSEC_Path_Signature, in which case you drop the UPDATE, thus causing a DoS
because you're not propagating what *may* be legitimate reachability info
further downstream.
Right, I'm familiar with loop detection and K/P.
If someone has modified AS_PATH to cause another AS to drop it, then
they inserted someone else's AS. This no longer counts as "legitimate
reachability info", and therefore it should be dropped, and the sooner
the better.
It sounds like there's another issue mixed up in here (but perhaps not
in scope of the -bgpsec-threats document): you're trying to resolve the
ambiguity on what to do with AS_PATH, as Matt notes at the end of the
following section.
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5
EDITOR'S NOTE: Text will be inserted here for dealing with the
AS_PATH attribute. Note that the BGPGSEC_Path_Signatures attribute
now contains all of the information needed to construct the AS_PATH
attribute. Therefore, there seem to be two options. One option the
BGPSEC speaker checks the AS_PATH attribute against the information
in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the
two do not match. The other option is that the BGPSEC speaker
discards anything in the AS_PATH attribute and reconstructs the
AS_PATH from the data in the BGPSEC_Path_Signatures attribute. I
believe that there are no interoperability problems if the choice
between these two options is left up to the BGPSEC speaker.
b) BGP performs loop detection on the AS_PATH attribute only /after/ verifying the
BGPSEC_Path_Signature is valid, in which case there is a /potential/ for another type of
DoS, because there will always be a limited amount of crypto verifications/sec that can
be performed. There's also the concern that this will slow down propagation of
reachability information, because it first needs to be crypto-verified before it's
used/propagated. Note, this is unlikely to be a problem during "steady-state",
but is more likely to appear during some amount of churn in BGP due to link and/or router
failures, for example.
Yes, this is true -- there's always DoS by feeding garbage to your
neighbor, BGPSEC or not, but crypto lets you waste more CPU. DoS on a
BGP router is mentioned briefly at the end of 4.1 -- would you like more
text?
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
