ignore max length as an argument of roa_check

[Ondrej Zajicek]

On Tue, Mar 30, 2021 at 09:31:32PM +0200, Pier Carlo Chiodi wrote:
> Hi,
> 
> > Let's assume an IXP has member A who has customer B, who propagates some
> address range. Who is responsible for originating blackhole route for IP
> addres from such range propagated to the IXP?
> 
> FWIW, my understanding of "Local Scope of Blackholes" from
> https://tools.ietf.org/html/rfc7999#section-3.2 is that it's allowed to
> cautiously propagate a route tagged with BLACKHOLE when policies are
> explicitly in place between adjacent networks to treat those routes
> according to RFC7999.
> 
> If I got your example right, B originates the BLACKHOLE prefix to ask A to
> mitigate an attack that they are receiving. B announces it to A. A is a
> member of IXP, and it has peering relationships with peer n (n could be
> either another member or a route server). If there is an agreement between
> A and IXPn to treat BLACKHOLE routes according to RFC7999, in that case
> (according to my understanding) A could propagate that route to IXPn as it
> is, with AS_PATH "A, B". The origin AS would still be B. IXPn would be the
> one in charge of implementing the sanity checks to verify that the route is
> valid.

That is pretty clear, but i thought more about the other case - /32 address
from B is DDoSed, link from IXP to A is saturated, and A does not wait for B
to originate BLACKHOLE route, and originates it themselves and propagates
it to IXP. Such blackhole route would have AS_PATH just 'A', so RPKI check
would fail (as RPKI registered origin is B).

Not sure if this is considered appropriate, but i would say that it is
both intentionally valid (provider A says which traffic want and do not
want to accept) and allowed by RFC 7999:

  o  The announced prefix is covered by an equal or shorter prefix that
      the neighboring network is authorized to advertise.

(A is authorized to advertise, but not originate such prefix)

So my point/idea is that if this case is valid, then using RPKI-style
checking for BLACKHOLE is broken idea anyway, and perhaops we should
instead focus on implementing (IMHO) proper checking for BLACKHOLE
routes, similar to one for flowspec validation:

  BLACKHOLE route received from A is valid if i have (RPKI-valid)
  regular route from A for network N covering the BLACKHOLE route
  and (optionally) such route is best route for network N.

I am interested in opinions about this criterion of blackhole validity vs
loose/ignore_max_length-RPKI criterion of blackhole validity. But that is
probably more a question for SIDROPS mailing list.


> The point I wanted to raise with my original message is that I believe the
> current implementation of 'ignore max length' might be a bit too loose.
> 
> That knob de-facto goes against the way RFC6811 works, and if I understand
> it correctly, it does it at a very global level, for all the ROAs inside
> the table. Having a ROA table where the maxLength of all the ROAs is

Yes, it is intended for creating separate ROA table just for loose RPKI OV.


> On the basis of my experience, sometimes, having a handy solution to
> quickly solve reachability issues could be seen as the way to go,
> especially while under pressure, but that would cause more damage than it
> solves ;-)
> I believe that turning 'ignore max length' on, seeing that it "solves" the
> issue, and then forgetting about it could be a very easy and likely path in
> certain circumstances, and that it could undermine the benefits given by
> the whole global RPKI/OV deployment effort.

That is a possibility, and probably more likely than using per-roa_check()
knob improperly.


> To your point, I also believe that RPKI OV as per RFC6811 is not
> appropriate to handle blackhole requests. In a recent message to Sidrops we
> can read:
> 
> > Work in under way to harmonize RPKI & BGP blackholing. The IETF's draft
> submission window currently is closed, but as soon as it opens, I will
> upload a document detailing a possible way forward. (1 or 2 weeks from now)
> 
> (https://mailarchive.ietf.org/arch/msg/sidrops/v0tVaVcT2WHe9vW2x_GKg52KX-E/)
> 
> It will probably take a bit of time before a solution based on the above
> will be ready for production, but I believe that in the meantime it could
> be worth exploring other less intrusive methods to satisfy the request you
> received, without weakening RPKI OV "too much".
> 
> If the desire is to really tweak OV in a way that it could deal with such
> blackhole routes, I'd suggest rethinking the way that config knob is used
> today.
> 
> We just heard feedback on this list where the author mentioned the need of
> dealing with multiple ROAs tables. This seems very suboptimal to me. What
> do you think about moving that knob to roa_check?

Could be done, but adding optional arguments is problematic due to
limitations of scripting language, so perhaps just add another operation
called roa_loose_check().


> Another more drastic proposal could be to just drop the config knob
> completely and keep the OV implementation secure, leaving it up to other
> forums to come up with a solution, agreed upon by the community.

I am interested in alternate solutions (like flowspec-style validation
as i suggested above).

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."