Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address Til's comments. #80

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Address Til's comments. #80

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c1b092b
Address Til's comments.
jiceatscion Dec 20, 2024
e1f3f2d
Fix typoe.
jiceatscion Dec 20, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 25 additions & 8 deletions draft-dekater-scion-controlplane.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -385,7 +385,7 @@ The text representation of SCION addresses MUST be `<ISD>-<AS>`, where `<ISD>` i

For example, the text representation of AS number 65551 (0x1000f) in ISD number 4 is `4-0000:1:f`.

## Avoiding Circular Dependencies and Partitioning
## Bootstrapping ablity

A secure and reliable routing architecture has to be designed specifically to avoid circular dependencies during network initialization. One goal of SCION is that the Internet can start up even after large outages or attacks, in addition to avoiding cascades of outages caused by fragile interdependencies. This section lists the concepts SCION uses to prevent circular dependencies.

Expand All @@ -396,7 +396,9 @@ A secure and reliable routing architecture has to be designed specifically to av

**Note:** For a detailed description of a TRC and more information on the availability of certificates and TRCs, see the SCION Control-Plane PKI Internet-Draft {{I-D.dekater-scion-pki}}.

Besides inter-dependencies, another threat to the Internet is network partition which occurs when one network is split into two because of a link failure. However, partition of the global SCION inter-domain network is much less likely to happen as during normal operation the full network fabric is available, offering multiple paths between all ASes. Even during failures there is no special failure mode required as SCION-enabled ASes can always switch to otherwise unused links.
## Resistance to partitioning

Besides inter-dependencies, another threat to the Internet is network partitionig which occurs when one network is split into two because of a link failure. Partitioning of the global SCION inter-domain network is much less likely to happen as during normal operation the full network fabric is available, offering multiple paths between all ASes. Even during failures there is no special failure mode required as SCION-enabled ASes can always switch to already known paths that use other links.

Recovering from a partitioned network is also seamless as only coarse time synchronization between the partitions is required to resume normal operation and move forward with updates of the cryptographic material. [](#clock-inaccuracy) further describes the impact of time synchronization.

Expand All @@ -423,10 +425,12 @@ In SCION, the *Control Service* of each AS is responsible for the beaconing proc
PCBs contain topology and authentication information, and can also include additional metadata that helps with path management and selection. The beaconing process itself is divided into routing processes on two levels, where *inter-ISD* or core beaconing is based on the (selective) sending of PCBs without a defined direction, and *intra-ISD* beaconing on top-to-bottom propagation.

- *Inter-ISD or core beaconing* is the process of constructing path segments between core ASes in the same or in different ISDs. During core beaconing, the Control Service of a core AS either initiates PCBs or propagates PCBs received from neighboring core ASes to other neighboring core ASes. PCBs are periodically sent over policy compliant paths to discover multiple paths between any pair of core ASes.
- *Intra-ISD beaconing* creates path segments from core ASes to non-core ASes. For this, the Control Services of core ASes create PCBs and sends them to the non-core child ASes (typically customer ASes) at regular intervals. The Control Service of a non-core child AS receives these PCBs and forwards them to its child ASes, and so on until the PCB reaches an AS without any customer (leaf AS). As a result, all ASes within an ISD receive path segments to reach the core ASes of their ISD.
- *Intra-ISD beaconing* creates path segments from core ASes to non-core ASes. For this, the Control Services of core ASes create PCBs and sends them to the non-core child ASes (typically customer ASes) at regular intervals. The Control Service of a non-core child AS receives these PCBs and forwards them to its child ASes, and so on until the PCB reaches an AS without any customer (leaf AS). As a result, all ASes within an ISD receive path segments to reach the core ASes of their ISD and register reciprocal segments with the Control Service of the associated core ASes.

On its way, a PCB accumulates cryptographically protected path and forwarding information per traversed AS. At every AS, metadata as well as information about the AS's ingress and egress interfaces is added to the PCB. The full PCB message format is described in [](#pcbs).

The process of using PCBs to construct segments is described in details in [](#path-segment-reg)

### Peering Links

PCBs do not traverse peering links. Instead, peering links are announced along with a regular path in a PCB. If both ASes at either end of a peering link have registered path segments that include this specific peering link, then it is possible to use this peering link during segment combination to create the end-to-end path.
Expand Down Expand Up @@ -1088,7 +1092,7 @@ To be valid (that is, usable to construct a valid path), a PCB MUST:
* Have a timestamp ([](#seginfo)) that is not in the future.
* Contain only unexpired hops ([](#hopfield)).

For the purpose of validation, a timestamp is considered "future" if it is later than the current time at the point of validation plus the minimum expiration time of a Hop Field (337.5 seconds, see [](#hopfield)).
For the purpose of validation, a timestamp is considered "future" if it is later than the current time at the point of validation plus an allowance for differences between local and origination clock. As an allowance, it is suggested to use the granularity of the hopfield expiration time (that is 337.5 seconds, see [](#hopfield)).

For the purpose of validation, a hop is considered expired if its absolute expiration time, calculated as defined in [](#hopfield), is later than the current time at the point of validation.

Expand Down Expand Up @@ -1119,11 +1123,16 @@ The goal of the AS SHOULD be to propagate those candidate PCBs with the highest

#### Storing and Selecting Candidate PCBs

When receiving a PCB, an AS first stores the PCB in a temporary storage for candidate PCBs called the *Beacon Store*.
When receiving a PCB, an AS first stores the PCB in a temporary storage for candidate PCBs called the *Beacon Store*. The management of this storage is implementation defined. Current practice is to retain all PCBs until expired or replaced by one describing the same path with a later origination time.

PCBs are propagated in batches to each connected AS at a fixed frequency known as the *propagation interval*. At each propagation event, each AS selects a set of the best PCBs from the candidates in the Beacon Store, according to the AS's selection policy. This set SHOULD have a fixed size, the *best PCBs set size*.

- The *best PCBs set size* SHOULD be at most "50" (PCBs) for intra-ISD beaconing and at most "5" (PCBs) for core beaconing (i.e. propagation between all core ASes). These are RECOMMENDED maxima; in current practice the intra-ISD set size is typically 20.
The *best PCBs set size* SHOULD be:
- For intra-AS beaconing (i.e. propgating to children ASes): at most 50.
- For core beaconing (i.e. propagation between core ASes): at most 5 per immediate neighbor core AS. (Current
practice is that each set of 5 is chosen among the BCPs received from each neighbor).

These are RECOMMENDED maxima; in current practice the intra-ISD set size is typically 20.

Depending on the selection criteria, it may be necessary to keep more candidate PCBs than the *best PCBs set size* in the Beacon Store, to be able to determine the best set of PCBs. If this is the case, an AS SHOULD have a suitable pre-selection of candidate PCBs in place in order to keep the Beacon Store capacity limited.

Expand Down Expand Up @@ -2510,17 +2519,25 @@ To illustrate how the path lookup works, we show two path-lookup examples in seq

Changes made to drafts since ISE submission. This section is to be removed before publication.

## draft-dekater-scion-controlplane-08
{:numbered="false"}

- Split "Circular dependencies and partitioning" into two sections: bootstrapping and partitioning.
- Added some details about PCBs propagation and storage.
- Qualified better the choice of time allowance in the definition of "segment from the future".

## draft-dekater-scion-controlplane-07
{:numbered="false"}
- Moved SCMP specification from draft-dekater-scion-dataplane-03 to this document

- Moved SCMP specification from draft-dekater-scion-dataplane-03 to this document

## draft-dekater-scion-controlplane-06
{:numbered="false"}

Major changes:

- New section: Path MTU
-New section: Monitoring Considerations
- New section: Monitoring Considerations
- Completed description of Control Services gRPC API in appendix

Minor changes:
Expand Down
Loading