[Sidrops] draft-sidrops-maxlen - questions from 110 session

[Ben Maddison <[e-mail]>]

Hi all,

During my presentation yesterday, I indicated that the authors believed
this document was ready for WGLC.

However, I believe that the question raised by Alexander at the mic
deserves some further discussion first (although I'm yet sure that this
document is the place to deal with the issue that he pointed out).

I will attempt to demonstrate the issue that Alexander was describing
(@Alexander, please will you speak up if I have mis-interpreted your
description?).

Description
===========

Consider the following topology:

             +-------+     +-------+
             | 65020 |-----| 65021 |
             +-------+     +-------+
                 |    \   /    |
                 |     \ /     |
                 |      X      |
                 |     / \     |
                 |    /   \    |
             +-------+     +-------+
             | 65010 |-----| 65011 |
             +-------+     +-------+
              /                   \
             /                     \
            /                       \
    +-------+                       +-------+
    | 65000 |                       | 65666 |
    +-------+                       +-------+

65000 is a customer of 65010
65666 is a customer of 65011
65010, 65011, 65020, and 65021 peer with each other in a full mesh. The
business relationships amongst them are unimportant.

65010 and 65020 perform ROV and drop Invalids on import
65020 and 65021 do not.

Assume that ROV is the only possible form of import filtering in place
at any AS border. This is not a good assumption in practise, but
simplifies the analysis.

Every AS has policy do discard prefixes of length > k (for some k common
to them all - in the IPv4 DFZ today, this is almost universally 24-bits)

65000 has an IP allocation P/m from its RIR, for some m < k. 65000
announces only this aggregate.

65666 is attempting to hijack traffic for the sub-prefix P/k.
65666 injects a route for P/k into BGP, and advertises it to 65011.

65666 is a relatively sophisticated adversary, and will inspect the
global RPKI to determine whether a ROA matching P/k exists:
- If a matching ROA exists authorising asID X, then 65011 will announce
  P/k with AS_PATH 65666_X;
- If no matching ROA exists, it will announce P/k with AS_PATH 65666.

Consider the following scenarios:
A.  65000 has not created any ROA covering P/m
B.  65000 has created ROA(prefix: P/m, asID: 65000)
C.  65000 has created ROA(prefix: P/m, asID: 65000, maxLength: k)

Scenario A
==========

The route for P/k originated at 65666 will initialling become best-path
in all ASes (possibly even 65000, if their import policy doesn't filter
their own prefixes). The attack will initially succeed almost
universally.

65000 may respond by dis-aggregating, and announcing their own route for
P/k. As a result of this response, the steady state outcome is:
- 65010 will forward towards 65000
- 65011 will forward towards 65666
- 65020 and 65020 may prefer either (or even load-share between both)

The attack will be ~50% successful (from the AS-level perspective)

Scenario B
==========

Any route for P/k will be dropped at the border of an AS performing ROV.
This includes the hijack announcement or a defensive route announced by
65000.

Thus, there is no opportunity for 65000 to announce a defensive more
specific, since it will not propagate to or past 65010. (This, I
believe, is the crux of Alexander's point).

The steady state outcome is:
- 65010 and 65020 will forward towards 65000 (based on the Valid P/m
  route)
- 65011 and 65021 will forward towards 65666 (based on the Invalid P/k
  route)

Scenario C
==========

As described above, 65666 will forge the AS_PATH such that the
originator appears to be 65000. The hijack route will therefore be ROV
Valid.

As in scenario A, the initial attack will be nearly universally
successful.

Also as in scenario A, 65000 may respond by defensively announcing P/k.
However, 65000 does not need to artificially increase the AS_PATH length
in order to make the announcement ROV Valid.

As a result, the steady state becomes:
- 65010, 65020 and 65021 forward towards 65000 (due to the shorter
  AS_PATH)
- 65011 may prefer either one (depending on its relationships with the
  other networks)

Conclusions
===========

The initial impact of the attack is minimised through the creation of
a "minimal" ROA.
However, depending on the (ROV policy) behaviour of the ASes in between
the victim and the attacker, the "minimal" ROA may impede the ability of
the victim to defensively de-aggregate. In such a scenario, and in the
face of a persistent attack, the long-run impact in the presence of a
"minimal" ROA may be worse than the long-run impact in the presence of a
"non-minimal" ROA.

Both cases are still better (or at least no worse) than the impact if no
ROA exists at all.

Generalising
============

Where there is partial deployment of ROV (with discard-Invalid) it is
possible that a sub-prefix hijack may originate within a neighborhood N of
the AS-connectivity topology, such that
- no member of N has policy to discard ROV Invalids; and
- there exists no possible BGP update propagation path from the victim
  AS to N without traversing an intermediate AS that does discard ROV
  Invalids.

In such a case, a minimal ROA may make it impossible for the victim to
defensively originate a more-specific prefix to "compete" with the
hijack announcement for bestpath selection within N.

However, a "minimal" ROA is still the best way for the victim to
minimise the immediate impact (i.e. before any defensive measures can be
taken) of the attack, and to guarantee that the impact of the attack is
limited to traffic originating in N.

It is not possible to provide general recommendations in this case:
- The existence of such neighborhoods can only be determined with
  reference to the topological location of a potential victim, and with
  detailed information of the routing policies of the networks in their
  vicinity;
- For any such neighborhood that does exist, the victim must weigh up
  the relative importance of:
  - Minimising the initial impact of the attack Internet-wide
  - Guaranteeing that an attack will not succeed in attracting traffic
    outside N (including in the attackers immediate vicinity)
  Versus:
  - Losing the ability to mitigate the attack within N.
In practise this will likely come down to the traffic that the would-be
victim expects to receive from any such N, that could be put at risk.

Cheers,

Ben