Wormhole attacks

[nicorusti]

I feel that the wormhole paragraph is not mature enough for this submission. Some issues:

• several parts of the content is a duplicate of 5.2.4. Manipulation of the Path-Selection Process in draft-dekater-scion-controlplane-04
• some of the mitigations proposed are quite vague
• it does not clearly mention proof of transit as a solution

This is the text I removed in #23 , to be reworked for a later submission

## Wormhole attack

### Set up

Scenario: attackers create two core ASes that are geographically far apart. They then announce a link (effectively a shortcut) between these two ASes with
very appealing properties (low latency, few hops, ...).

### Impact
The attacker can now perform blackhole attacks (DoS), greyhole attacks, delay traffic, or similarily impact traffic.

Critically, there is currently no clear way to recover from this situation. In order to recover, ASes that are connected to the
wormhole ASes would need to learn of the problem and stop forwarding the wormhole beacons.

Mitigations:

- Introduce a way for ASes to verify path properties. This would make it harder to install wormholes.
  This could include measuring latency or sense-checking of geolocation information.
- Introduce a way for endpoints to discover path problems.
- Introduce a way for endpoints to report path problems.
- Introduce a way to recover from malicious segments, see {{signalling-faulty-segments}}.
- Adapt the path discovery and dissemination algorithm to allow ASes to have many more than five paths to
  a given remote destination. The attack would then require an (unreasonably) large number of compromised ASes.

A related question is discussed in {{signalling-faulty-segments}}.

[tzaeschke]

Apologies, apparently I wasn't quite finished when I committed it. Just in case we decide to add this again, here is a slightly improved version of the text:

## Wormhole attack

The wormhole attack is described in {{I-D.scion-cp}}.

### Set up

Scenario: attackers create two core ASes that are geographically far apart. They then announce a link (effectively a shortcut) between these two ASes with
very appealing properties (low latency, few hops, ...).

### Impact

The attacker can now perform blackhole attacks (DoS), greyhole attacks, delay traffic, or similarly impact traffic.

Critically, there is currently no clear way to recover from this situation. In order to recover, ASes that are connected to the
wormhole ASes would need to learn of the problem and stop forwarding the wormhole beacons.

### Mitigations

- Prevention: Introduce a way for ASes to verify path properties. This would make it harder to install wormholes.
  This could include measuring latency (per path or per link) or sense-checking of geolocation information.
- Recovery: Introduce a way to endpoints to detect, report and recover from path problems. This is discussed in {{signalling-faulty-segments}}.
  - Endpoints need (a standardized? way) to detect path problems, such as high latency or packet loss.
  - Endpoints need a way to report path problems to ASes.
  - ASes need a way to report path problems to other ASes (leaf to core, core to core).
  - ASes need a way to recover from reported or detected malicious segments.

I'm not sure how proof of transit would help. I think if the two malicious ASes are connected via VPN, it is impossible to proof that the packets had to go through other ASes...?

[nicorusti]

Thank you!

I'm not sure how proof of transit would help. I think if the two malicious ASes are connected via VPN, it is impossible to proof that the packets had to go through other ASes...?

If traffic is "swallowed" via a wormhole shortcut, then packets will skip some of the ASes on path. If there is proof of transit, then the proof for the skipped ASes would be missing, revealing the attack. On the other hand, it is impossible to prove that packets went though other ASes.. PoT can only prove that traffic did NOT go through the intended ASes. Does it make sense?

[tzaeschke]

If traffic is "swallowed" via a wormhole shortcut, then packets will skip some of the ASes on path.

I probably misunderstand how wormholes work, but why would there be ASes on the path that need to be skipped? I assumed the idea is that two colluding malicious ASes announce a route that is attractive simply because it doesn't have other ASes on the path? I.e. it is attractive because it announces a direct connection or peering link to a remote AS?

I am happy to take this offline and discuss some other time if you like :)

[nicorusti]

You are right, we had some internal slides about proof of transit that mentioned it as a solution to a "wormhole" in the dataplane. This is something that we already mention in the DP draft (and that we are making clearer in https://github.com/scionassociation/scion-dp_I-D/pull/34 ).

Here you are referring to a wormhole in the control plane, for this one I agree proof of transit cannot do anything. I also discussed this with JC in https://github.com/scionassociation/scion-cp_I-D/pull/53 Sorry for the confusion here! I think wit the two PRs above it should be clear.

[tzaeschke]

@nicorusti Ah, that makes it clearer, thanks for the explanation! :)