Skip to content

Commit

Permalink
Update Sec Considerations - V
Browse files Browse the repository at this point in the history
  • Loading branch information
Corine de Kater committed Dec 6, 2023
1 parent 85b7585 commit 823c564
Showing 1 changed file with 6 additions and 12 deletions.
18 changes: 6 additions & 12 deletions draft-dekater-scion-pki.md
Original file line number Diff line number Diff line change
Expand Up @@ -1335,7 +1335,7 @@ The steps required to create a new AS certificate are the following:

# Security Considerations

This section describes the possible security risks and attacks that SCION's control-plane PKI may be prone to, and how these may be mitigated. As SCION is an inter-domain network architecture, the focus lies on *inter*-AS routing.
This section describes the possible security risks and attacks that SCION's control-plane PKI may be prone to, and how these may be mitigated. As SCION is an inter-domain network architecture, the focus lies on *inter*-AS trust issues. All *intra*-AS trust- and security aspects are out of scope.

**Note:** This section only discusses security considerations related to SCION's control-plane PKI. For SCION control plane- and routing-specific security considerations, see {{I-D.scion-cp}}. {{I-D.scion-dp}} includes security considerations that concern the SCION data plane and data forwarding.

Expand All @@ -1347,27 +1347,23 @@ SCION’s trust architecture fundamentally differs from a global monopolistic tr

### Local ISD Kill Switch

As in the case of DNSSEC and BGPsec, executing a kill switch inside a local ISD can be done at different levels of the AS-level hierarchy. One difference in SCION is that core ASes cannot be switched off by a parent authority since they manage their own cryptographic trust roots. Another difference is that the attack vector of intra-ISD kill switches has only two entry levels; all ASes obtain certificates directly from the CAs included in the TRC.
Executing a kill switch inside a local ISD can be done at different levels of the AS-level hierarchy. Compared to DNSSEC and BGPsec, however, SCION core ASes cannot be switched off by a parent authority as they manage their own cryptographic trust roots. Another difference is that the attack vector of intra-ISD kill switches has only two entry levels; all ASes within an ISD obtain certificates directly from the CAs included in the ISD's TRC. If one of the core’s root keys is compromised, an adversary could issue illegitimate AS certificates, which may be used in further attacks. However, multiple different voting keys (defined by the voting quorum in the TRC) would be required to maliciously change the TRC through a TRC update.

If one of the core’s root keys is compromised, an adversary could issue illegitimate AS certificates, which may be used in further attacks. However, multiple different voting keys (defined by the voting quorum) would be required to maliciously change the TRC through a TRC update.
Another possible attack is when a core AS stops propagating PCBs, thus frustrating the discovery of new paths. In this case, downstream ASes will notice that PCBs are no longer being propagated, but all previously discovered (and still valid) paths are still usable for data-plane forwarding until they expire.

Moreover, the core might stop propagating PCBs, precluding the discovery of new paths. In this case, downstream ASes will notice that PCBs are no longer being propagated, but all previously discovered (and still valid) paths are still usable for data-plane forwarding until they expire.

Perhaps a more stealthy kill switch would be to shut down path services in victim ASes. While this cannot be done remotely, an adversarial entity controlling an ISD (e.g., a government) might compel core and non-core ASes to stop replying to path requests. Alternatively, the compelled ASes might return only a subset of all available paths. If this attack were used in conjunction with blackholing, senders in the ISD would have difficulty getting traffic out of the ISD. However, note that in SCION, existing paths can continue to be used in the data plane as long as the traversed ASes allow the forwarding.
Perhaps a more stealthy kill switch would be to shut down control services in victim ASes. While this cannot be done remotely, an adversarial entity controlling an ISD (e.g., a government) might compel core and non-core ASes to stop replying to path requests. Alternatively, the compelled ASes might return only a subset of all available paths. If this attack were used in conjunction with blackholing, where traffic is redirected to a non-existent resource, senders in the ISD would have difficulty getting traffic out of the ISD. However, note that in SCION, existing paths can continue to be used in the data plane as long as the traversed ASes allow the forwarding.


### Remote ISD/AS Kill Switch

SCION ISDs independently manage their own cryptographic keys and namespace. This prevents a remote attacker who is outside the victim's ISD from causing a kill switch in the victim ISD. That is, without access to the private keys forming the trust root in the remote ISD, the attacker is limited to data-plane attacks. Even if private keys became available to a remote attacker, they would need access to an AS inside the remote ISD to inject faulty information.
SCION ISDs independently manage their own cryptographic keys and namespace. This prevents a remote attacker who is outside the victim's ISD from causing a kill switch in the victim ISD. That is, without access to the private keys forming the trust root in the victim ISD, the remote attacker is limited to data-plane attacks. Even if private keys became available to a remote attacker, they would need access to an AS inside the remote ISD to inject faulty information.


### Recovery from Kill Switches

In the event of a key compromise of a non-core AS, the impacted AS needs to obtain a new certificate from the core. This process will vary depending on internal issuance protocols. If any of the root keys or voting keys contained in the TRC are compromised, the TRC must be updated as described in [](#update). Only in the case of a catastrophic compromise of multiple voting keys at the same time must a trust reset be triggered.

If the core AS has not been compromised, but is instead acting maliciously (e.g., by not propagating PCBs downstream or tampering with responses for paths or certificates), one way to recover is for downstream ASes to self- organize and form a new ISD. By now operating autonomously, the new ISD can begin path discovery and traffic forwarding.

SCION, unlike BGP, has no notion of routing convergence. Instead, the flooding of PCBs disseminates topology information. This means that in the worst case, if all paths must be re-created, fresh paths are established after a single flood has reached all ASes.
If the core AS has not been compromised, but is instead acting maliciously (e.g., by not propagating PCBs downstream or tampering with responses for paths or certificates), one way to recover is for downstream ASes to self-organize and form a new ISD. By now operating autonomously, the new ISD can begin path discovery and traffic forwarding. SCION, unlike BGP, has no notion of routing convergence. Instead, the flooding of PCBs disseminates topology information. This means that in the worst case, if all paths must be re-created, fresh paths are established after a single flood has reached all ASes.


## Denial of Service Attacks
Expand All @@ -1376,8 +1372,6 @@ As described previously, the SCION's control-plane PKI lays the foundation for t

DoS attacks, where attackers overload different parts of the IT infrastructure, may impede this process of retrieving missing cryptographic material. SCION offers protection against volumetric DoS attacks, which aim to exhaust network bandwidth on links; in this case, ASes can switch to alternative paths that do not contain the congested links. Transport protocol attacks however, where the attacker tries to exhaust the resources on a target server by opening a large number of connections, may be more difficult to avoid. Possible means to mitigate this kind of DoS attacks are basically the same as for the current Internet, e.g., geo-blocking or using cookies.

**Note:** It is almost impossible for an outside attacker to launch DoS attacks in an entirely SCION-enabled ecosystem. However, DoS attacks coming from a malicious element within the system may be a conceivable scenario.


# IANA Considerations

Expand Down

0 comments on commit 823c564

Please sign in to comment.