Re: [Sidrops] Clarification of draft-ietf-sidrops-aspa-verification-03

[Alexander Azimov <[e-mail]>]

Hi Luuk,

Thank you for another good question.
Your understanding is correct: with the ASPA technique, you can detect only
mistakes when the route is received from a provider or RS.

It is explicitly stated in the security considerations (Sec. 8):

   While the ASPA is capable to detect both mistake and malicious
   activity for routes received from customers, RS-clients or peers, it
   provides only detection of mistakes for routes that are received from
   upstream providers and RS(s).


While this is limiting your opportunity to detect malicious activity, the
only attack scenario is when a provider sends malformed routes to its
customer. At the same time, IMO the opportunity to detect even mistake
leaks coming from providers is great. I recently modeled the work of ASPA
algorithms on top of BMP data in Yandex - it worked and already showed
valuable results.

вт, 21 янв. 2020 г. в 11:05, Luuk Hendriks <[e-mail]>:

> Hi Alexander, all,
>
> On Tue 14 Jan 2020, 18:04, Alexander Azimov wrote:
> > In the terms of the draft AS0->AS1->AS2 is an upstream path, while
> AS3->AS4
> > is a downstream path.
> > The invalid state of (AS2, AS3) pair triggers the change of the
> > 'direction', but the following downstream path verification procedure is
> > not applicable to (AS3, AS2) since it can be a peering link, that's why
> I++
> > is used.
>
> Thanks for clarifying, it seems that we did interpret those parts of the
> draft
> correctly then. But we are still wondering whether skipping the check
> after the
> direction change is introducing a problem. (Again, this might be us not
> having
> much operational experience with actual routing, so please bear with me..)
>
>
> What if a bad actor, AS9, inserts itself in the path like this:
>
>                              +-----+
>                     +--------> AS2 +--------+
>                     |        +--+--+        |
>                  +-----+        |        +--v--+
>         +------->+ AS1 |        | +----->| AS3 +--------+
>         |        +-----+        | |      +--^--+        |
>      +-----+                  +-v-+-+                +--v--+
>      | AS0 |                  | AS9 |                | AS4 |
>      +-----+                  +-----+                +-----+
>                                                         |
>                                                      +--v--+
>                                                      | AS5 |
>                                                      +-----+
>
> No valid (AS2, AS9) ASPA is found, so we assume it is a peering link (the
> I++). Direction is changed, so continuing, (AS3, AS9) and (AS4, AS3) are
> checked. Now, if and only if any of these yield Invalid, the final result
> will
> be Invalid. Otherwise, the result will be Valid or Unknown, even though
> there is
> a malicious AS in the path. In other words, is the draft in its current
> revision
> beneficial without (close to) 100% adoption?
> Or, is this situation not considered a problem in reality due to the longer
> AS_PATH and thus a lower preference anyway?
>
>
> Thanks,
>  luuk
>


-- 
Best regards,
Alexander Azimov