Skip to content

Commit

Permalink
Script updating gh-pages from 823c564. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Dec 6, 2023
1 parent cb9338b commit ca23f3e
Show file tree
Hide file tree
Showing 2 changed files with 50 additions and 57 deletions.
25 changes: 11 additions & 14 deletions cdk-security-considerations/draft-dekater-scion-pki.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@
intervaltree 3.1.0
Jinja2 3.1.2
lxml 4.9.3
platformdirs 4.0.0
platformdirs 4.1.0
pycountry 22.3.5
PyYAML 6.0
requests 2.31.0
Expand Down Expand Up @@ -1031,7 +1031,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">de Kater &amp; Rustignoli</td>
<td class="center">Expires 7 June 2024</td>
<td class="center">Expires 8 June 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1044,12 +1044,12 @@
<dd class="internet-draft">draft-dekater-scion-pki-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2023-12-05" class="published">5 December 2023</time>
<time datetime="2023-12-06" class="published">6 December 2023</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2024-06-07">7 June 2024</time></dd>
<dd class="expires"><time datetime="2024-06-08">8 June 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1099,7 +1099,7 @@ <h2 id="name-status-of-this-memo">
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 7 June 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 8 June 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -3445,7 +3445,7 @@ <h3 id="name-creating-a-new-control-plan">
<h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
</h2>
<p id="section-5-1">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 <em>inter</em>-AS routing.<a href="#section-5-1" class="pilcrow"></a></p>
<p id="section-5-1">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 <em>inter</em>-AS trust issues. All <em>intra</em>-AS trust- and security aspects are out of scope.<a href="#section-5-1" class="pilcrow"></a></p>
<p id="section-5-2"><strong>Note:</strong> This section only discusses security considerations related to SCION's control-plane PKI. For SCION control plane- and routing-specific security considerations, see <span>[<a href="#I-D.scion-cp" class="cite xref">I-D.scion-cp</a>]</span>. <span>[<a href="#I-D.scion-dp" class="cite xref">I-D.scion-dp</a>]</span> includes security considerations that concern the SCION data plane and data forwarding.<a href="#section-5-2" class="pilcrow"></a></p>
<div id="kill-switches">
<section id="section-5.1">
Expand All @@ -3458,18 +3458,17 @@ <h3 id="name-kill-switches">
<h4 id="name-local-isd-kill-switch">
<a href="#section-5.1.1" class="section-number selfRef">5.1.1. </a><a href="#name-local-isd-kill-switch" class="section-name selfRef">Local ISD Kill Switch</a>
</h4>
<p id="section-5.1.1-1">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.<a href="#section-5.1.1-1" class="pilcrow"></a></p>
<p id="section-5.1.1-2">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.<a href="#section-5.1.1-2" class="pilcrow"></a></p>
<p id="section-5.1.1-3">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.<a href="#section-5.1.1-3" class="pilcrow"></a></p>
<p id="section-5.1.1-4">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.<a href="#section-5.1.1-4" class="pilcrow"></a></p>
<p id="section-5.1.1-1">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.<a href="#section-5.1.1-1" class="pilcrow"></a></p>
<p id="section-5.1.1-2">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.<a href="#section-5.1.1-2" class="pilcrow"></a></p>
<p id="section-5.1.1-3">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.<a href="#section-5.1.1-3" class="pilcrow"></a></p>
</section>
</div>
<div id="remote-isdas-kill-switch">
<section id="section-5.1.2">
<h4 id="name-remote-isd-as-kill-switch">
<a href="#section-5.1.2" class="section-number selfRef">5.1.2. </a><a href="#name-remote-isd-as-kill-switch" class="section-name selfRef">Remote ISD/AS Kill Switch</a>
</h4>
<p id="section-5.1.2-1">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.<a href="#section-5.1.2-1" class="pilcrow"></a></p>
<p id="section-5.1.2-1">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.<a href="#section-5.1.2-1" class="pilcrow"></a></p>
</section>
</div>
<div id="recovery-from-kill-switches">
Expand All @@ -3478,8 +3477,7 @@ <h4 id="name-recovery-from-kill-switches">
<a href="#section-5.1.3" class="section-number selfRef">5.1.3. </a><a href="#name-recovery-from-kill-switches" class="section-name selfRef">Recovery from Kill Switches</a>
</h4>
<p id="section-5.1.3-1">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 <a href="#update" class="auto internal xref">Section 3.1.5</a>. Only in the case of a catastrophic compromise of multiple voting keys at the same time must a trust reset be triggered.<a href="#section-5.1.3-1" class="pilcrow"></a></p>
<p id="section-5.1.3-2">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.<a href="#section-5.1.3-2" class="pilcrow"></a></p>
<p id="section-5.1.3-3">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.<a href="#section-5.1.3-3" class="pilcrow"></a></p>
<p id="section-5.1.3-2">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.<a href="#section-5.1.3-2" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand All @@ -3491,7 +3489,6 @@ <h3 id="name-denial-of-service-attacks">
</h3>
<p id="section-5.2-1">As described previously, the SCION's control-plane PKI lays the foundation for the authentication procedures in SCION. It provides each AS within a specific ISD with a certified key pair. These keys enable the authentication of all routing messages - every AS and end host can verify all routing messages by following the certificate chain. If an AS realizes that it misses any cryptographic material, it must query the originator of the message for it. This implies that the AS can reach the originating AS of the message, that is, that paths to the originator are available and that the relevant services at the originating AS are accessible.<a href="#section-5.2-1" class="pilcrow"></a></p>
<p id="section-5.2-2">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.<a href="#section-5.2-2" class="pilcrow"></a></p>
<p id="section-5.2-3"><strong>Note:</strong> 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.<a href="#section-5.2-3" class="pilcrow"></a></p>
</section>
</div>
</section>
Expand Down
82 changes: 39 additions & 43 deletions cdk-security-considerations/draft-dekater-scion-pki.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
Network Working Group C. de Kater
Internet-Draft N. Rustignoli
Intended status: Informational SCION Association
Expires: 7 June 2024 5 December 2023
Expires: 8 June 2024 6 December 2023


SCION Control-Plane PKI
Expand Down Expand Up @@ -56,7 +56,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 7 June 2024.
This Internet-Draft will expire on 8 June 2024.

Copyright Notice

Expand Down Expand Up @@ -2392,7 +2392,8 @@ Table of Contents
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.
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-
Expand All @@ -2413,46 +2414,47 @@ Table of Contents

5.1.1. 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.

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.

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
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.

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.

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, 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.
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.

5.1.2. 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.
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.

5.1.3. Recovery from Kill Switches

Expand All @@ -2467,14 +2469,13 @@ Table of Contents
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
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.
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.

5.2. Denial of Service Attacks

Expand All @@ -2501,11 +2502,6 @@ Table of Contents
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.

6. IANA Considerations

Future iterations of this draft will comprise more detailed IANA
Expand Down

0 comments on commit ca23f3e

Please sign in to comment.