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