From 2cbdc27540575bbaa0e2f632207d966504912a00 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Tue, 8 Oct 2024 17:16:03 +0100 Subject: [PATCH 1/8] Deprecates draft-dekater-panrg-scion-overview --- draft-dekater-scion-pki.md | 43 ++++++-------------------------------- 1 file changed, 6 insertions(+), 37 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index e8c4a49..211e068 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -39,40 +39,9 @@ normative: RFC5652: RFC5758: RFC9217: - I-D.scion-cp: - title: SCION Control Plane - date: 2023 - target: https://datatracker.ietf.org/doc/draft-dekater-scion-controlplane/ - author: - - - ins: C. de Kater - name: Corine de Kater - org: SCION Association - - - ins: N. Rustignoli - name: Nicola Rustignoli - org: SCION Association - - - ins: S. Hitz - name: Samuel Hitz - org: Anapaya Systems - I-D.scion-dataplane: - title: SCION Data Plane - date: 2023 - target: https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane/ - author: - - - ins: C. de Kater - name: Corine de Kater - org: SCION Association - - - ins: N. Rustignoli - name: Nicola Rustignoli - org: SCION Association - - - ins: S. Hitz - name: Samuel Hitz - org: Anapaya Systems + I-D.dekater-scion-controlplane: + I-D.dekater-scion-dataplane: + I-D.dekater-panrg-scion-overview: informative: RFC5398: @@ -139,11 +108,11 @@ SCION relies on three main components: *PKI* - To achieve scalability and trust, SCION organizes existing ASes into logical groups of independent routing planes called *Isolation Domains (ISDs)*. All ASes in an ISD agree on a set of trust roots called the *Trust Root Configuration (TRC)* which is a collection of signed root certificates in X.509 v3 format {{RFC5280}}. The ISD is governed by a set of *core ASes* which typically manage the trust roots and provide connectivity to other ISDs. This is the basis of the public key infrastructure which the SCION control plane relies upon for the authentication of messages that is used for the SCION control plane. -*Control Plane* - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See {{I-D.scion-cp}} +*Control Plane* - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See {{I-D.scion-controlplace}} *Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.scion-dataplane}} -This document describes the SCION PKI component used by the Control Plane. +This document describes the SCION PKI component used by the Control Plane. It should be read in conjunction with {{I-D.dekater-scion-pki}} and {{I-D.dekater-scion-dataplane}} and deprecates {{I-D.dekater-panrg-scion-overview}}. ## Terminology @@ -1361,7 +1330,7 @@ As described in [](#substitutes-to-revocation), there is no revocation in the CP 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 control-plane messages - every AS and endpoint can verify all control-plane messages by following the certificate chain. The relying party MUST be able to discover and obtain new or updated cryptographic material. For the control plane messages, this is simplified by the observation that the sender of a message (e.g. of a path construction beacon during path exploration or a path segment during a path lookup) always has all the cryptographic material to verify it. Thus, the receiver can always immediately obtain all the cryptographic material from the message originator. -As the corresponding PKI messaging thus only occurs when the control plane is already communicating, these requests to obtain cryptographic material are not prone to additional denial of service attacks. We therefore refer to {{I-D.scion-cp}} for a more detailed description of DoS vulnerabilities of control-plane messages. +As the corresponding PKI messaging thus only occurs when the control plane is already communicating, these requests to obtain cryptographic material are not prone to additional denial of service attacks. We therefore refer to {{I-D.dekater-scion-controlplace}} for a more detailed description of DoS vulnerabilities of control-plane messages. For certificate renewal, on the other hand, this does not apply. Denial of Service on the CA infrastructure or on the communication links from the individual ASes to the CA, could be used by an attacker to prevent victim ASes from renewing their certificates, halting the path discovery process. From 0f6595a14ee5476e21491ba91aeb3a0220264313 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Tue, 8 Oct 2024 17:18:37 +0100 Subject: [PATCH 2/8] Fixed typo --- draft-dekater-scion-pki.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 211e068..5329a49 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -108,11 +108,11 @@ SCION relies on three main components: *PKI* - To achieve scalability and trust, SCION organizes existing ASes into logical groups of independent routing planes called *Isolation Domains (ISDs)*. All ASes in an ISD agree on a set of trust roots called the *Trust Root Configuration (TRC)* which is a collection of signed root certificates in X.509 v3 format {{RFC5280}}. The ISD is governed by a set of *core ASes* which typically manage the trust roots and provide connectivity to other ISDs. This is the basis of the public key infrastructure which the SCION control plane relies upon for the authentication of messages that is used for the SCION control plane. -*Control Plane* - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See {{I-D.scion-controlplace}} +*Control Plane* - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See {{I-D.scion-controlplane}} *Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.scion-dataplane}} -This document describes the SCION PKI component used by the Control Plane. It should be read in conjunction with {{I-D.dekater-scion-pki}} and {{I-D.dekater-scion-dataplane}} and deprecates {{I-D.dekater-panrg-scion-overview}}. +This document describes the SCION PKI component used by the Control Plane. It should be read in conjunction with {{I-D.dekater-scion-controlplane}} and {{I-D.dekater-scion-dataplane}} and deprecates {{I-D.dekater-panrg-scion-overview}}. ## Terminology From 8c094b0df4a9cc41016db57a7a2243d933019842 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Tue, 8 Oct 2024 17:34:14 +0100 Subject: [PATCH 3/8] Fixed references --- draft-dekater-scion-pki.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 5329a49..1564b65 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -108,9 +108,9 @@ SCION relies on three main components: *PKI* - To achieve scalability and trust, SCION organizes existing ASes into logical groups of independent routing planes called *Isolation Domains (ISDs)*. All ASes in an ISD agree on a set of trust roots called the *Trust Root Configuration (TRC)* which is a collection of signed root certificates in X.509 v3 format {{RFC5280}}. The ISD is governed by a set of *core ASes* which typically manage the trust roots and provide connectivity to other ISDs. This is the basis of the public key infrastructure which the SCION control plane relies upon for the authentication of messages that is used for the SCION control plane. -*Control Plane* - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See {{I-D.scion-controlplane}} +*Control Plane* - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See {{I-D.dekater-scion-controlplane}} -*Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.scion-dataplane}} +*Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.dekater-scion-dataplane}} This document describes the SCION PKI component used by the Control Plane. It should be read in conjunction with {{I-D.dekater-scion-controlplane}} and {{I-D.dekater-scion-dataplane}} and deprecates {{I-D.dekater-panrg-scion-overview}}. @@ -1330,7 +1330,7 @@ As described in [](#substitutes-to-revocation), there is no revocation in the CP 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 control-plane messages - every AS and endpoint can verify all control-plane messages by following the certificate chain. The relying party MUST be able to discover and obtain new or updated cryptographic material. For the control plane messages, this is simplified by the observation that the sender of a message (e.g. of a path construction beacon during path exploration or a path segment during a path lookup) always has all the cryptographic material to verify it. Thus, the receiver can always immediately obtain all the cryptographic material from the message originator. -As the corresponding PKI messaging thus only occurs when the control plane is already communicating, these requests to obtain cryptographic material are not prone to additional denial of service attacks. We therefore refer to {{I-D.dekater-scion-controlplace}} for a more detailed description of DoS vulnerabilities of control-plane messages. +As the corresponding PKI messaging thus only occurs when the control plane is already communicating, these requests to obtain cryptographic material are not prone to additional denial of service attacks. We therefore refer to {{.dekater-scion-controlplace}} for a more detailed description of DoS vulnerabilities of control-plane messages. For certificate renewal, on the other hand, this does not apply. Denial of Service on the CA infrastructure or on the communication links from the individual ASes to the CA, could be used by an attacker to prevent victim ASes from renewing their certificates, halting the path discovery process. From 7a916bc5ee356720e51396fc55151948021454c5 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Tue, 8 Oct 2024 17:36:48 +0100 Subject: [PATCH 4/8] Fixed typo --- draft-dekater-scion-pki.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 1564b65..6de508e 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -1330,7 +1330,7 @@ As described in [](#substitutes-to-revocation), there is no revocation in the CP 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 control-plane messages - every AS and endpoint can verify all control-plane messages by following the certificate chain. The relying party MUST be able to discover and obtain new or updated cryptographic material. For the control plane messages, this is simplified by the observation that the sender of a message (e.g. of a path construction beacon during path exploration or a path segment during a path lookup) always has all the cryptographic material to verify it. Thus, the receiver can always immediately obtain all the cryptographic material from the message originator. -As the corresponding PKI messaging thus only occurs when the control plane is already communicating, these requests to obtain cryptographic material are not prone to additional denial of service attacks. We therefore refer to {{.dekater-scion-controlplace}} for a more detailed description of DoS vulnerabilities of control-plane messages. +As the corresponding PKI messaging thus only occurs when the control plane is already communicating, these requests to obtain cryptographic material are not prone to additional denial of service attacks. We therefore refer to {{I-D.dekater-scion-controlplane}} for a more detailed description of DoS vulnerabilities of control-plane messages. For certificate renewal, on the other hand, this does not apply. Denial of Service on the CA infrastructure or on the communication links from the individual ASes to the CA, could be used by an attacker to prevent victim ASes from renewing their certificates, halting the path discovery process. From fc525c244b532775c76d3bbe6212e8a84a963117 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Wed, 9 Oct 2024 11:27:58 +0100 Subject: [PATCH 5/8] Add note to remove text before publication Moved I-D references from normative to informative. --- draft-dekater-scion-pki.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 6de508e..f58ca70 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -39,11 +39,11 @@ normative: RFC5652: RFC5758: RFC9217: + +informative: I-D.dekater-scion-controlplane: I-D.dekater-scion-dataplane: I-D.dekater-panrg-scion-overview: - -informative: RFC5398: RFC6996: BARRERA17: DOI.10.1145/3085591 @@ -112,7 +112,14 @@ SCION relies on three main components: *Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.dekater-scion-dataplane}} -This document describes the SCION PKI component used by the Control Plane. It should be read in conjunction with {{I-D.dekater-scion-controlplane}} and {{I-D.dekater-scion-dataplane}} and deprecates {{I-D.dekater-panrg-scion-overview}}. +This document describes the SCION PKI component used by the Control Plane. + +The SCION architecture was initially developed outside of the IETF by ETH Zurich with significant contributions from Anapaya Systems. It is deployed in the Swiss finance sector to provide resilient connectivity between financial institutions. The aim of this document is to document the existing protocol specification as deployed, and to introduce new concepts that can potentially be further improved to address particular problems with the current Internet architecture. + +The following text is to be removed before publication: + +This document should be read in conjunction with {{I-D.dekater-scion-controlplane}} and {{I-D.dekater-scion-dataplane}} and deprecates {{I-D.dekater-panrg-scion-overview}}. + ## Terminology From 1b59bf8bde2a5a50b8fd4e330a4ee13f43fcf747 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Wed, 9 Oct 2024 15:05:15 +0100 Subject: [PATCH 6/8] Added Appendix on SCIONLab --- draft-dekater-scion-pki.md | 41 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index f58ca70..9cb596f 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -82,6 +82,39 @@ informative: ins: A. Perrig name: Adrian Perrig org: ETH Zuerich + SCIONLAB: + title: SCIONLAB - A Next-Generation Internet Testbed + date: 2020 + target: https://ieeexplore.ieee.org/abstract/document/9259355 + author: + - + ins: J. Kown + name: Jonghoon Kwon + org: ETH Zuerich + - + ins: J. García-Pardo + name: Juan A. García-Pardo + org: ETH Zuerich + - + ins: M. Legner + name: Markus Legner + org: ETH Zuerich + - + ins: F. Wirz + name: François Wirz + org: ETH Zuerich + - + ins: M. Frei + name: Matthias Frei + org: ETH Zuerich + - + ins: D. Hausheer + name: David Hausheer + org: Otto von Guericke University Magdeburg + - + ins: A. Perrig + name: Adrian Perrig + org: ETH Zuerich --- abstract @@ -1364,6 +1397,14 @@ The SCION AS and ISD number are SCION-specific numbers. They are currently alloc Many thanks go to Fritz Steinmann (SIX Group AG), Juan A. Garcia Prado (ETH Zurich) and Russ Housley (IETF) for reviewing this document. We are also very grateful to Adrian Perrig (ETH Zurich), for providing guidance and feedback about each aspect of SCION. Finally, we are indebted to the SCION development teams of Anapaya and ETH Zurich, for their practical knowledge and for the documentation about the CP PKI, as well as to the authors of {{CHUAT22}} - the book is an important source of input and inspiration for this draft. +# Deployment Testing: SCIONLab +{:numbered="false"} + +SCIONLab is a global research network that is available to test the SCION architecture. You can create and use your ASes using your own computation resources which allows you to gain real-world experience of deploying and managing a SCION network. + +More information can be found on the SCIONLab website and in the {{SCIONLAB}} paper. + + # Appendix A. Signing Ceremony Initial TRC {#initial-ceremony} {:numbered="false"} From e7c57172dfee985bf9081ac14cf78a76e536e156 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Wed, 9 Oct 2024 15:11:42 +0100 Subject: [PATCH 7/8] Controlplane and Dataplane I-D references moved back to Normative --- draft-dekater-scion-pki.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index 9cb596f..aebdc54 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -34,6 +34,8 @@ author: email: hitz@anapaya.net normative: + I-D.dekater-scion-controlplane: + I-D.dekater-scion-dataplane: RFC5280: RFC5480: RFC5652: @@ -41,8 +43,6 @@ normative: RFC9217: informative: - I-D.dekater-scion-controlplane: - I-D.dekater-scion-dataplane: I-D.dekater-panrg-scion-overview: RFC5398: RFC6996: From 7911a79d7813f76d86b7b69bee3b013b6d4bbe68 Mon Sep 17 00:00:00 2001 From: knmeynell Date: Wed, 9 Oct 2024 19:55:14 +0100 Subject: [PATCH 8/8] Aligned text in Intro --- draft-dekater-scion-pki.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/draft-dekater-scion-pki.md b/draft-dekater-scion-pki.md index aebdc54..0e3eba4 100644 --- a/draft-dekater-scion-pki.md +++ b/draft-dekater-scion-pki.md @@ -145,13 +145,11 @@ SCION relies on three main components: *Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.dekater-scion-dataplane}} -This document describes the SCION PKI component used by the Control Plane. +This document describes the SCION PKI component used by the Control Plane. It should be read in conjunction with the other components {{I-D.dekater-scion-controlplane}} and {{I-D.dekater-scion-dataplane}}. The SCION architecture was initially developed outside of the IETF by ETH Zurich with significant contributions from Anapaya Systems. It is deployed in the Swiss finance sector to provide resilient connectivity between financial institutions. The aim of this document is to document the existing protocol specification as deployed, and to introduce new concepts that can potentially be further improved to address particular problems with the current Internet architecture. -The following text is to be removed before publication: - -This document should be read in conjunction with {{I-D.dekater-scion-controlplane}} and {{I-D.dekater-scion-dataplane}} and deprecates {{I-D.dekater-panrg-scion-overview}}. +Note (to be removed before publication): this document, together with the other components {{I-D.dekater-scion-controlplane}} and {{I-D.dekater-scion-dataplane}}, deprecates {{I-D.dekater-panrg-scion-overview}}. ## Terminology