< draft-dekater-panrg-scion-overview-00.txt   draft-dekater-panrg-scion-overview-01.txt >
PANRG C. de Kater PANRG C. de Kater
Internet-Draft N. Rustignoli Internet-Draft N. Rustignoli
Intended status: Informational A. Perrig Intended status: Informational A. Perrig
Expires: 19 November 2022 ETH Zuerich Expires: 20 November 2022 ETH Zuerich
18 May 2022 19 May 2022
SCION Overview SCION Overview
draft-dekater-panrg-scion-overview-00 draft-dekater-panrg-scion-overview-01
Abstract Abstract
The Internet has been successful beyond even the most optimistic The Internet has been successful beyond even the most optimistic
expectations and is intertwined with many aspects of our society. expectations and is intertwined with many aspects of our society.
But although the world-wide communication system guarantees global But although the world-wide communication system guarantees global
reachability, the Internet has not primarily been built with security reachability, the Internet has not primarily been built with security
and high availability in mind. The next-generation inter-network and high availability in mind. The next-generation inter-network
architecture SCION (Scalability, Control, and Isolation On Next- architecture SCION (Scalability, Control, and Isolation On Next-
generation networks) aims to address these issues. SCION was generation networks) aims to address these issues. SCION was
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 November 2022. This Internet-Draft will expire on 20 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 16, line 39 skipping to change at page 16, line 39
links_ can be added to up- or down-path segments, resulting in an links_ can be added to up- or down-path segments, resulting in an
operation similar to today's Internet. operation similar to today's Internet.
To reduce beaconing overhead and prevent possible forwarding loops, To reduce beaconing overhead and prevent possible forwarding loops,
PCBs do not traverse peering links. Instead, peering links are PCBs do not traverse peering links. Instead, peering links are
announced along with a regular path in a PCB. If the path segments announced along with a regular path in a PCB. If the path segments
of both ASes at the end of a peering link contain this peering link, of both ASes at the end of a peering link contain this peering link,
then it is possible to use the peering link to shortcut the end-to- then it is possible to use the peering link to shortcut the end-to-
end path (i.e., without going through the core). SCION also supports end path (i.e., without going through the core). SCION also supports
peering links that cross ISD boundaries, according to SCION's path peering links that cross ISD boundaries, according to SCION's path
transparency property: A source knows the exact set of ASes and ISDs transparency property.
traversed during the delivery of a packet. COMMENT: maybe last
sentence can be omitted? it is not really specific to peering links
Figure 4 shows how intra-ISD PCB propagation works, from the ISD's Figure 4 shows how intra-ISD PCB propagation works, from the ISD's
core AS down to child ASes. For the sake of illustration, the core AS down to child ASes. For the sake of illustration, the
interfaces of each AS are numbered with integer values. In practice, interfaces of each AS are numbered with integer values. In practice,
each AS can choose any encoding for its interfaces; in fact, only the each AS can choose any encoding for its interfaces; in fact, only the
AS itself needs to understand its encoding. Here, AS F receives two AS itself needs to understand its encoding. Here, AS F receives two
different PCBs via two different links from core AS X. Moreover, AS different PCBs via two different links from core AS X. Moreover, AS
F uses two different links to send two different PCBs to AS G, each F uses two different links to send two different PCBs to AS G, each
containing the respective egress interfaces. AS G extends the two containing the respective egress interfaces. AS G extends the two
PCBs and forwards both of them over a single link to a child AS. PCBs and forwards both of them over a single link to a child AS.
skipping to change at page 24, line 12 skipping to change at page 24, line 12
Figure 5: Combining three path segments into a forwarding path Figure 5: Combining three path segments into a forwarding path
2.3.2. Path Authorization 2.3.2. Path Authorization
It is crucial for the data plane that end hosts only use paths It is crucial for the data plane that end hosts only use paths
constructed and authorized by ASes in the control plane. In constructed and authorized by ASes in the control plane. In
particular, end hosts should not be able to craft HFs themselves, particular, end hosts should not be able to craft HFs themselves,
modify HFs in authorized path segments, or combine HFs of different modify HFs in authorized path segments, or combine HFs of different
path segments (path splicing). This property is called *path path segments (path splicing). This property is called *path
authorization* (see [KLENZE2021] and [LEGNER2020]. authorization* (see [KLENZE2021] and [LEGNER2020]).
SCION achieves path authorization by creating message-authentication SCION achieves path authorization by creating message-authentication
codes (MACs) during the beaconing process. Each AS calculates these codes (MACs) during the beaconing process. Each AS calculates these
MACs using a local secret key (that is only shared between SCION MACs using a local secret key (that is only shared between SCION
infrastructure elements within the AS) and chains them to the infrastructure elements within the AS) and chains them to the
previous HFs. The MACs are then included in the forwarding path as previous HFs. The MACs are then included in the forwarding path as
part of the respective HFs. part of the respective HFs.
2.3.3. Forwarding 2.3.3. Forwarding
 End of changes. 5 change blocks. 
8 lines changed or deleted 6 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/