Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021

[Ben Maddison <[e-mail]>]

Hi Alexander,

On 12/10, Alexander Azimov wrote:
> > > [...]
> > >
> > > Let's elaborate what kind of events we are facing at the moment.
> > > The majority of hijacks and route leaks are mistakes. We can assume that
> > > the difference between accidental and malicious hijacks is absence of
> > > forged as path in case of accidental events.
> > > So, ROA with ANY prefix length is good enough to limit the blast radius
> > of
> > > accidental hijacks.
> >
> > Only if the origin AS of the hijack route is that of the hijacker. That
> > is not the case for all mistakes (Noction-leaks, for example).
> >
> > Minimal ROAs are the best current initial line of defense to such
> > incidents.
> >
> I agree with your point about Noction. At the very moment, we don't have
> any other technique if forged disaggregated routes are leaked.
> Though it is mixing up route leaks and hijack problems, and there might be
> more suitable solutions for route leaks in the long term.
> 
> My point and my main concern grow from the fact that Noction-like incidents
> don't present all the scope.
> The incidents that I witnessed were results of redistribution of static
> routes with Invalid origin AS. I hope we can agree that for this kind of
> incident the length of ROA doesn't matter.
> 
Yes. We can certainly agree there.
However a substantial proportion of the wide scale incidents that I have
seen in recent months have been such events.
We really don't have a good defense to these other than the ROV
length-check.

> >
> > > Unfortunately ROV deployment isn't at the level when we are no longer
> > > affected by accidental hijacks. And the best option is instant prefix
> > > deaggregation, if it is possible.
> > > And I hope you will agree - the time is precious.
> > >
> > > Now let's discuss how the recommendations from this document may
> > complicate
> > > things that already got nasty due to the fact that your address space was
> > > hijacked.
> > >
> > > *Scenario 1:*
> > > Being a proactive and BCP aware autonomous system holder, one may add
> > > egress ROV with strict policy to drop Invalid routes with an exception to
> > > blackhole routes.
> > > In case of a hijack this good citizen will have to relax it's routing
> > > policy/turn off ROV on egress. It is still not that bad, but in huge
> > > companies with complicated access rules to devices, it may still take
> > time.
> > >
> > If your neighbors drop invalids, turning off egress ROV doesn't make any
> > difference: the update gets dropped on the other end of the wire.
> >
> > If your neighbors don't drop invalids then this can be done in local
> > policy using SLURM, in close to real time.
> >
> > In either case, this is a red-herring.
> >
> In this scenario, I was supposing that ROV is done on egress and is absent
> at the ingress of the neighbor.
> And, yes, it can be done using local policy, but it may take time if this
> scenario is not thought out in advance.
> I wonder if you want to cite it in your document. I don't see any
> references to rfc8893 at the moment.
> 
I'm hesitant to add any more length to an already lengthy document.
I kinda think this should be fairly obvious to an educated reader.
What do others think here?

> > *Scenario 2:*
> > [...]
> >
> I think you missed my point in this scenario.
> 
Yes, Sriram pointed out to me that you were considering competition for
path selection inside the intersection of Y and Z's customer cones. I
missed that previously. Apologies for making you repeat yourself.

Viewed from this perspective, this scenario is simply a variation on the
one that lead to us adding section 5.2.

In this case the defensive routes are hidden because of differences
between local-pref in Y, but the effect is the same as if there is no
adjacency between X and Y.

I stand by my view that, in the general case, solving for this creates
more risk than it removes. But I also appreciate that this general
guidance is "general", and isn't necessarily true for your employer, or
those with similar topologies...

> [...]
> 
> I can imagine that for access providers the list of 'important' targets may
> be quite small these days.
> But this view can be very different from the content provider sude. Last
> time I made this math I had 1000AS to cover 80% of egress traffic and
> another 1000 AS to cover 95%.

Yes, the same distinction occurred to me.
This phenomenon only occurs when the networks that one cares about are
not directly adjacent to the hijack victim.
Most content networks with which I am familiar have very high external
interconnection density, and are usually only one AS away from the other
end of a TCP connection.
This would make the above much less of a problem, and perhaps explains
why other CDN ops people here seem less concerned about it?

I wonder if you have looked at how many of those ~2k networks you are
directly adjacent to?

> I hope you admit that makes 'some' networks care about the customer cones
> of their peers. And as far as I know, these networks are primary targets
> for Noction-like systems.
> 
> [...]
> I hope you reconsider. Let's try to find the golden mean between our
> positions.

I think that we can resolve this by explicitly noting that the "general"
recommendation of section 5.2 will not apply to everyone.

Something like (section 5.2):

    447,451c447,452
    <    victim and hijacker filters ROV invalid prefixes, it may be the case
    <    that the existence of a minimal ROA issued by the victim prevents the
    <    defensive more- specific prefixes being propagated to the networks
    <    topologically close to the attacker, thus hampering the effectiveness
    <    of this response.
    ---
    >    victim and hijacker filters ROV invalid prefixes (or where path
    >    selection policy within intermediate ASs prefers paths learned from
    >    the attack source) it may be the case that the existence of a minimal
    >    ROA issued by the victim prevents the defensive more-specific
    >    prefixes being propagated to the networks topologically close to the
    >    attacker, thus hampering the effectiveness of this response.
    453,455c454,456
    <    Nevertheless, this document recommends that where possible, network
    <    operators publish minimal ROAs even in the face of this risk.  This
    <    is because:
    ---
    >    Nevertheless, this document recommends that in general, network
    >    operators SHOULD publish minimal ROAs even in the face of this risk.
    >    This is because:
    468a470,480
    > 
    >    Some operators, however, especially those that are topologically
    >    distant from traffic sources that they consider "important", MAY
    >    legitimately prioritise the ability to defensively de-aggregate above
    >    the protection that minimal ROAs afford.  Operators making such a
    >    decision SHOULD carefully evaluate (insofar as they are able) the
    >    filtering and path selection behaviour of ASs in their vicinity to
    >    determine the extent to which the aforementioned risks apply to their
    >    situation.  Furthermore, operators SHOULD continue to re-evaluate
    >    this decision periodically in the face of continuing deployment of
    >    route origin validation by other ASs.

Let me know if this works for you?

Cheers,

Ben