proposal: encode beaconing type in beacon payload

[oncilla]

Proposal

Extend the BeaconRequest:

scion/proto/control_plane/v1/seg.proto

Lines 85 to 88 in 68db9a0

	message BeaconRequest {
	// Beacon in form of a partial path segment.
	PathSegment segment = 1;
	}

with an indication in what context the beacon is forwarded:

message BeaconRequest {
    // Defines how the beacon is meant to propagate through the topology.
    enum PropagationType {
        PROPAGATION_TYPE_UNSPECIFIED = 0;
        PROPAGATION_TYPE_CORE = 1;
        PROPAGATION_TYPE_INTRA_ISD = 2;
    }

    // Beacon in form of a partial path segment.
    PathSegment segment = 1;
    
    // The propagation rule set for this beacon.
    PropagationType propagation_type = 2;
}

Problem

Currently, the BeaconRequest simply contains the partial path segment, and there is no indication whether the beacon is being forwarded in the context of core beaconing or intra-isd beaconing.

In certain edge cases, due to misconfiguration, this can lead to valid path segments being constructed that do not adhere to the rules of SCION.

Consider the following graph:

C1 (core) - (parent) N1 (child) - (parent) N2

• C1 is misconfigured and considers N1 a core (link type is configured as core link)
• N1 is properly configured and considers C1 a parent.

1. C1 originates a beacon towards N1. To C1 it is in the context of core beaconing. To N1 it is in the context of intra-ISD beaconing.
2. N1 propagates the beacon towards N2 in the context of intra-ISD beaconing.
3. N2 can terminate the beacon and have a valid up/down segment from the data plane perspective.

On the router level, when forwarding the traffic, everything looks in order too:

• At C1, everything looks like we are traversing a core segment.
• At N1, everything looks like we are traversing a up/down segment.

Alternatives considered

Alternatively, we can use only the TRC information to check during beaconing that the link types that are configured make sense, and only propagate if they do. However, this still leaves us guessing in what context a beacon is forwarded. And we could still face edge cases if the TRC is partially known to the network.

We should probably do both. TRC information to sanity check the link types, and extending the BeaconRequest to drop beacons that do not agree with our configuration.