netsec-ethz / scion Goto Github PK

Leopold has observed these errors when running bwtestclient -s 19-ffaa:1:143,[141.44.25.148]:30102 -c 17-ffaa:1:125,[10.0.2.15]:30100 -cs 10,1472,?,32Mbps -sc 10,1472,?,32Mbps:

EROR[11-21|16:47:16] Revocation failed, unable to parse signed revocation info raw=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 err="capnp panic panic=\"capnp: address out of bounds\""
EROR[11-21|16:47:16] Revocation failed, unable to parse signed revocation info raw=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 err="capnp panic panic=\"capnp: address out of bounds\""
EROR[11-21|16:47:16] Revocation failed, unable to parse signed revocation info raw=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 err="capnp panic panic=\"capnp: address out of bounds\""
EROR[11-21|16:47:16] Revocation failed, unable to parse signed revocation info raw=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 err="capnp panic panic=\"capnp: address out of bounds\""
EROR[11-21|16:47:16] Revocation failed, unable to parse signed revocation info raw=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 err="capnp panic panic=\"capnp: address out of bounds\""
EROR[11-21|16:47:16] Revocation failed, unable to parse signed revocation info raw=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 err="capnp panic panic=\"capnp: address out of bounds\""

This is what I get:
$ ./bwtestclient -s 19-ffaa:1:143,[141.44.25.148]:30102 -c 17-ffaa:1:a,[10.0.8.116]:30100 -cs 10,1472,?,32Mbps -sc 10,1472,?,32Mbps
INFO[11-21|16:46:38] Started id=34e60d76 goroutine=dispatcher_bck
Available paths to 19-ffaa:1:143
[ 0] Hops: [17-ffaa:1:a 1>147 17-ffaa:0:1107 1>4 17-ffaa:0:1102 2>2 17-ffaa:0:1103 4>8 17-ffaa:0:1101 2>1 16-ffaa:0:1002 2>2 19-ffaa:0:1301 5>1 19-ffaa:0:1303 43>1 19-ffaa:1:143] Mtu: 1472
[ 1] Hops: [17-ffaa:1:a 1>147 17-ffaa:0:1107 1>4 17-ffaa:0:1102 2>2 17-ffaa:0:1103 4>8 17-ffaa:0:1101 5>4 18-ffaa:0:1201 5>3 19-ffaa:0:1301 5>1 19-ffaa:0:1303 43>1 19-ffaa:1:143] Mtu: 1472
[ 2] Hops: [17-ffaa:1:a 1>147 17-ffaa:0:1107 1>4 17-ffaa:0:1102 2>2 17-ffaa:0:1103 4>8 17-ffaa:0:1101 1>1 16-ffaa:0:1001 2>1 19-ffaa:0:1301 5>1 19-ffaa:0:1303 43>1 19-ffaa:1:143] Mtu: 1472
[ 3] Hops: [17-ffaa:1:a 1>147 17-ffaa:0:1107 1>4 17-ffaa:0:1102 2>2 17-ffaa:0:1103 4>8 17-ffaa:0:1101 6>4 19-ffaa:0:1301 5>1 19-ffaa:0:1303 43>1 19-ffaa:1:143] Mtu: 1472
[ 4] Hops: [17-ffaa:1:a 1>147 17-ffaa:0:1107 1>4 17-ffaa:0:1102 2>2 17-ffaa:0:1103 4>8 17-ffaa:0:1101 11>2 19-ffaa:0:1302 1>7 19-ffaa:0:1301 5>1 19-ffaa:0:1303 43>1 19-ffaa:1:143] Mtu: 1472
DBUG[11-21|16:46:38] Path selection algorithm choice path="Hops: [17-ffaa:1:a 1>147 17-ffaa:0:1107 1>4 17-ffaa:0:1102 2>2 17-ffaa:0:1103 4>8 17-ffaa:0:1101 1>1 16-ffaa:0:1001 2>1 19-ffaa:0:1301 5>1 19-ffaa:0:1303 43>1 19-ffaa:1:143] Mtu: 1472" score=0.472
Using path:
Hops: [17-ffaa:1:a 1>147 17-ffaa:0:1107 1>4 17-ffaa:0:1102 2>2 17-ffaa:0:1103 4>8 17-ffaa:0:1101 1>1 16-ffaa:0:1001 2>1 19-ffaa:0:1301 5>1 19-ffaa:0:1303 43>1 19-ffaa:1:143] Mtu: 1472
INFO[11-21|16:46:38] Registered with dispatcher ia=17-ffaa:1:a host=10.0.8.116 port=30100
Client DC Next Hop 127.0.0.1 Server Host 141.44.25.148 Server Port 30103
INFO[11-21|16:46:38] Registered with dispatcher ia=17-ffaa:1:a host=10.0.8.116 port=30101
Test parameters:
clientDCAddr -> serverDCAddr 17-ffaa:1:a,[10.0.8.116]:30101 -> 19-ffaa:1:143,[141.44.25.148]:30103
client->server: 10 seconds, 1472 bytes, 27173 packets
server->client: 10 seconds, 1472 bytes, 27173 packets
S->C results
Attempted bandwidth: 31998924 bps / 32.00 Mbps
Achieved bandwidth: 11355596 bps / 11.36 Mbps
Loss rate: 64 %
Interarrival time variance: 193ms, average interarrival time: 0ms
Interarrival time min: 0ms, interarrival time max: 194ms
INFO[11-21|16:46:50] Received SCMP revocation header="Class=PATH(3) Type=REVOKED_IF(4) TotalLen=344B Checksum=4b28 Timestamp=2018-11-21 16:46:50.878976 +0100 CET" payload="Meta: Info=21 CmnHdr=1 AddrHdr=3 PathHdr=14 ExtHdrs=0 L4Hdr=1 L4Proto=UDP\nInfo: InfoF=4 HopF=5 IfID=1 Ingress=false RawSRev=101740021105a2510c0202ff100510040101750a0101aaff111102140f0fea7df55b01010fea7df55b3105420131150202ff44454641554c543a0c2049413a2031372d666661613a313a6120434841494e3a2031205452433a20314d5aa27c08d99db4cd09e305530b46f6afd737c3083cc86aefcc2bc0f365623ce84468ef59b1826c8387713344a04644af2b484f4702db0673b8d56b85e10e070000000000\nCmnHdr: 004100a912040511\nAddrHdr: 0013ffaa000101430011ffaa0001000a8d2c19940a000874\nPathHdr: 005bf57dd4001105004000100085a2ca004000109365378500400020045a1e5a00400040028c92c7014000000894aee0005bf57dbc00130301400010002a85780040002001553cb501400000019bfac7015bf57543001303014000000504c3da004000102b040e44004000100015d8fb\nExtHdrs: \nL4Hdr: 7594759600195d8e\n"
INFO[11-21|16:46:50] Received SCMP revocation header="Class=PATH(3) Type=REVOKED_IF(4) TotalLen=344B Checksum=49d0 Timestamp=2018-11-21 16:46:50.87932 +0100 CET" payload="Meta: Info=21 CmnHdr=1 AddrHdr=3 PathHdr=14 ExtHdrs=0 L4Hdr=1 L4Proto=UDP\nInfo: InfoF=4 HopF=5 IfID=1 Ingress=false RawSRev=101740021105a2510c0202ff100510040101750a0101aaff111102140f0fea7df55b01010fea7df55b3105420131150202ff44454641554c543a0c2049413a2031372d666661613a313a6120434841494e3a2031205452433a20314d5aa27c08d99db4cd09e305530b46f6afd737c3083cc86aefcc2bc0f365623ce84468ef59b1826c8387713344a04644af2b484f4702db0673b8d56b85e10e070000000000\nCmnHdr: 004100a912040511\nAddrHdr: 0013ffaa000101430011ffaa0001000a8d2c19940a000874\nPathHdr: 005bf57dd4001105004000100085a2ca004000109365378500400020045a1e5a00400040028c92c7014000000894aee0005bf57dbc00130301400010002a85780040002001553cb501400000019bfac7015bf57543001303014000000504c3da004000102b040e44004000100015d8fb\nExtHdrs: \nL4Hdr: 7594759600195d8e\n"
INFO[11-21|16:46:50] Started id=250098bb goroutine=dispatcher_bck
INFO[11-21|16:46:50] Received SCMP revocation header="Class=PATH(3) Type=REVOKED_IF(4) TotalLen=344B Checksum=48cd Timestamp=2018-11-21 16:46:50.879579 +0100 CET" payload="Meta: Info=21 CmnHdr=1 AddrHdr=3 PathHdr=14 ExtHdrs=0 L4Hdr=1 L4Proto=UDP\nInfo: InfoF=4 HopF=5 IfID=1 Ingress=false RawSRev=101740021105a2510c0202ff100510040101750a0101aaff111102140f0fea7df55b01010fea7df55b3105420131150202ff44454641554c543a0c2049413a2031372d666661613a313a6120434841494e3a2031205452433a20314d5aa27c08d99db4cd09e305530b46f6afd737c3083cc86aefcc2bc0f365623ce84468ef59b1826c8387713344a04644af2b484f4702db0673b8d56b85e10e070000000000\nCmnHdr: 004100a912040511\nAddrHdr: 0013ffaa000101430011ffaa0001000a8d2c19940a000874\nPathHdr: 005bf57dd4001105004000100085a2ca004000109365378500400020045a1e5a00400040028c92c7014000000894aee0005bf57dbc00130301400010002a85780040002001553cb501400000019bfac7015bf57543001303014000000504c3da004000102b040e44004000100015d8fb\nExtHdrs: \nL4Hdr: 7594759600195d8e\n"
INFO[11-21|16:46:50] Received SCMP revocation header="Class=PATH(3) Type=REVOKED_IF(4) TotalLen=344B Checksum=47ea Timestamp=2018-11-21 16:46:50.879806 +0100 CET" payload="Meta: Info=21 CmnHdr=1 AddrHdr=3 PathHdr=14 ExtHdrs=0 L4Hdr=1 L4Proto=UDP\nInfo: InfoF=4 HopF=5 IfID=1 Ingress=false RawSRev=101740021105a2510c0202ff100510040101750a0101aaff111102140f0fea7df55b01010fea7df55b3105420131150202ff44454641554c543a0c2049413a2031372d666661613a313a6120434841494e3a2031205452433a20314d5aa27c08d99db4cd09e305530b46f6afd737c3083cc86aefcc2bc0f365623ce84468ef59b1826c8387713344a04644af2b484f4702db0673b8d56b85e10e070000000000\nCmnHdr: 004100a912040511\nAddrHdr: 0013ffaa000101430011ffaa0001000a8d2c19940a000874\nPathHdr: 005bf57dd4001105004000100085a2ca004000109365378500400020045a1e5a00400040028c92c7014000000894aee0005bf57dbc00130301400010002a85780040002001553cb501400000019bfac7015bf57543001303014000000504c3da004000102b040e44004000100015d8fb\nExtHdrs: \nL4Hdr: 7594759600195d8e\n"
INFO[11-21|16:46:50] Received SCMP revocation header="Class=PATH(3) Type=REVOKED_IF(4) TotalLen=344B Checksum=4730 Timestamp=2018-11-21 16:46:50.879992 +0100 CET" payload="Meta: Info=21 CmnHdr=1 AddrHdr=3 PathHdr=14 ExtHdrs=0 L4Hdr=1 L4Proto=UDP\nInfo: InfoF=4 HopF=5 IfID=1 Ingress=false RawSRev=101740021105a2510c0202ff100510040101750a0101aaff111102140f0fea7df55b01010fea7df55b3105420131150202ff44454641554c543a0c2049413a2031372d666661613a313a6120434841494e3a2031205452433a20314d5aa27c08d99db4cd09e305530b46f6afd737c3083cc86aefcc2bc0f365623ce84468ef59b1826c8387713344a04644af2b484f4702db0673b8d56b85e10e070000000000\nCmnHdr: 004100a912040511\nAddrHdr: 0013ffaa000101430011ffaa0001000a8d2c19940a000874\nPathHdr: 005bf57dd4001105004000100085a2ca004000109365378500400020045a1e5a00400040028c92c7014000000894aee0005bf57dbc00130301400010002a85780040002001553cb501400000019bfac7015bf57543001303014000000504c3da004000102b040e44004000100015d8fb\nExtHdrs: \nL4Hdr: 7594759600195d8e\n"
Error, could not fetch server results, MaxTries attempted without success.

To do:

• Investigate, try to reproduce
• Does it happen with new versions of scionproto?

Some of the unit tests (make test) are now broken, possibly due to expired cryptographic material from testdata.
Four packages are being reported:

• go/pkg/ca/renewal:go_default_test
• go/pkg/cs/drkey/grpc:go_default_test
• go/pkg/cs/trust:go_default_test
• go/pkg/trust:go_default_test

The output of the failures is similar to this partial one, from go/pkg/trust :

--- FAIL: TestTLSCryptoManagerVerifyServerCertificate (0.00s)
    --- FAIL: TestTLSCryptoManagerVerifyServerCertificate/valid (0.00s)
        tls_handshake_test.go:63: 
                Error Trace:    tls_handshake_test.go:63
                Error:          Received unexpected error:
                                verifying chains: [ chain did not verify against any selected TRC {errors=[verifying chain {trc_base=1; trc_serial=1}: x509: certificate has expired or is not yet valid: current time 2022-07-01T07:41:07Z is after 2022-05-14T11:11:02Z]} ]
                Test:           TestTLSCryptoManagerVerifyServerCertificate/valid

Responses to a L1 DRKey request must always have the SrcIA field equal to the respondent's IA. Since the field doesn't add more information (and following the spirit of the L1 DRKey request, that doesn't contain the DstIA):

• Remove the SrcIA field from the L1 response.
• Check other requests / responses for superfluous redundant fields.

We have an implementation of the COLIBRI Gateway in https://github.com/netsec-ethz/scion/tree/colibri_gateway
It should land in our main branch.

The goal is to avoid that the committed crypto material will expire which will cause the DRKey tests to fail.

There exists a number of slayers paths that are necessary to express the different types of paths that the implementation supports.

We also have the snet.DataplanePath interface that is needed to synchronize values between the SCION header and the particular path header.

We also have the snet.RawPath that has the unprocessed path received in the packet. Why though?

We also have the snet.RawReplyPath, because RawPath cannot be reversed?

We should get rid of all but the slayers ones, and if we want to hide the particularities of the types behind a facade, a type that just delegates the needed functionality to the underlying slayers path.

As an operator I have a following scenario

• border router with multiple interfaces
• every interface binds to a different network interface in the underlying OS
• one of the underlying network interfaces is not available (for any reason, e.g. VPN connection not available)

What happens is

• border router refuses to start
• SCION connectivity is not working over any of the interfaces

What operator expects to happen

• border router starts correctly
• SCION connectivity works properly over interfaces which have underlying network interfaces available
• SCION connectivity not available over interfaces which have underlying network interface missing

It is currently not possible for a slow-side host to request keys to another host in the same AS due to how the key server validates these requests.
Say we have a client (slow side) C and a server (fast side) S, both in AS A. If the client requests the host-to-host key A:S->A:C from its CS, it receives an error saying the request is invalid. The issue seems to be how the CS validates such requests:

//go/pkg/cs/drkey/grpc:go_default_test is currently failing because the committed crypto material is expired since May 13:

(...) FAIL: //go/pkg/cs/drkey/grpc:go_default_test (see /home/ubuntu/.cache/bazel/_bazel_ubuntu/d590279010957ac1dca373a0e19d0c3c/execroot/com_github_scionproto_scion/bazel-out/k8-fastbuild/testlogs/go/pkg/cs/drkey/grpc/go_default_test/test.log)
(...) INFO: From Testing //go/pkg/cs/drkey/grpc:go_default_test:
==================== Test output for //go/pkg/cs/drkey/grpc:go_default_test:
--- FAIL: TestLvl1KeyFetching (0.03s)
    lvl1_exchange_test.go:117: 
        	Error Trace:	lvl1_exchange_test.go:117
        	Error:      	Received unexpected error:
        	            	rpc error: code = Unavailable desc = connection error: desc = "transport: authentication handshake failed: verifying chains\n    chain did not verify against any selected TRC errors=\"[verifying chain trc_base=\"1\" trc_serial=\"1\"\n    >       >       x509: certificate has expired or is not yet valid: current time 2021-06-01T08:17:05Z is after 2021-05-13T16:06:35Z]\""
        	Test:       	TestLvl1KeyFetching
    panic.go:617: missing call(s) to *mock_drkeystorage.MockServiceStore.DeriveLvl1(is anything, is anything) go/pkg/cs/drkey/grpc/lvl1_exchange_test.go:76
    panic.go:617: aborting test due to missing call(s)
FAIL
================================================================================

As a quick fix, we could generate and commit new crypto material as test data? In the long run, we should probably switch to regenerating the crypto material before running the tests.

Given for some time already SCION binaries are shipped into /usr/bin. This means binaries installed there are globally available on the end users' systems and should have meaningful names.

Currently we ship stuff like /usr/bin/border what by the name itself does not mean much. Also, different SCION services cannot be easily grouped, e.g. one cannot easily deduce /usr/bin/border and /usr/bin/sig are anyhow connected, even though they do belong to the same group of services, i.e. SCION services.

./scion.sh topology --sig -d is supposed to generate a SIG instance for each AS, but it returns the following error msg.

Create topology, configuration, and execution files.
Traceback (most recent call last):
File "python/topology/generator.py", line 80, in
main()
File "python/topology/generator.py", line 76, in main
confgen.generate_all()
File "/home/jkwon/scion/python/topology/config.py", line 96, in generate_all
topo_dicts, self.all_networks = self._generate_topology()
File "/home/jkwon/scion/python/topology/config.py", line 147, in _generate_topology
return topo_gen.generate()
File "/home/jkwon/scion/python/topology/topo.py", line 134, in generate
self._iterate(self._generate_as_topo)
File "/home/jkwon/scion/python/topology/topo.py", line 122, in _iterate
f(TopoID(isd_as), as_conf)
File "/home/jkwon/scion/python/topology/topo.py", line 252, in _generate_as_topo
self._gen_sig_entries(topo_id, as_conf)
File "/home/jkwon/scion/python/topology/topo.py", line 339, in _gen_sig_entries
'ctrl_addr': join_host_port(self._reg_addr(topo_id, reg_id, addr_type).ip, port),
File "/home/jkwon/scion/python/topology/common.py", line 112, in join_host_port
ip = ip_address(host)
File "/usr/lib/python3.6/ipaddress.py", line 54, in ip_address
address)
ValueError: None does not appear to be an IPv4 or IPv6 address

Suspect that the IP address to be assigned to the last SIG instance is None.
(i.e., self._reg_addr(topo_id, reg_id, addr_type).ip in /home/jkwon/scion/python/topology/topo.py.

When the COLIBRI service sends packets with the service address as source, the corresponding ACK packets can't be delivered by the dispatcher to the socket. This is because the dispatcher will send the ACK to the listening service socket (the one listening for new requests, etc), instead of the socket that sent the initial packets. This is in turn because the listening socket is the one registered as the service socket, and the ACK comes with that service address in its destination.

This happens when the SvcCOL initiates control plane communication, or when the SvcCOL receives control plane communication because of packets with C=1.

The TestProcessColibriPkt test in //go/pkg/router:go_default_test fails with the following output:

==================== Test output for //go/pkg/router:go_default_test:
--- FAIL: TestProcessColibriPkt (0.00s)
    --- FAIL: TestProcessColibriPkt/controlplane_onpath_AS_inbound_to_colibri_service (0.00s)
        dataplane_test.go:1733: 
            	Error Trace:	dataplane_test.go:1733
            	Error:      	Not equal: 
            	            	expected: &socket.Message{Buffers:[][]uint8{[]uint8{0xb, 0x80, 0xde, 0xad, 0x11, 0x1b, 0x0, 0x12, 0x4, 0x0, 0x0, 0x0, 0x0, 0x4, 0xff, 0x0, 0x0, 0x0, 0x4, 0x11, 0x0, 0x2, 0xff, 0x0, 0x0, 0x0, 0x2, 0x22, 0xa, 0x0, 0x0, 0x3, 0xc, 0x0, 0x0, 0x4, 0x40, 0x25, 0x49, 0x5, 0x0, 0x0, 0x11, 0xed, 0x80, 0x2, 0x2, 0x5, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0x18, 0xaf, 0x6e, 0x29, 0x34, 0x56, 0x0, 0x12, 0x0, 0x0, 0x0, 0x1, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0x54, 0xde, 0xa5, 0x7f, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x0, 0xff, 0xff, 0xff, 0xff, 0x61, 0x63, 0x74, 0x75, 0x61, 0x6c, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64, 0x62, 0x79, 0x74, 0x65, 0x73}}, OOB:[]uint8(nil), Addr:(*net.UDPAddr)(0xc0001519b0), N:0, NN:0, Flags:0}
            	            	actual  : &socket.Message{Buffers:[][]uint8{[]uint8{0xb, 0x80, 0xde, 0xad, 0x11, 0x1b, 0x0, 0x12, 0x4, 0x0, 0x0, 0x0, 0x0, 0x4, 0xff, 0x0, 0x0, 0x0, 0x4, 0x11, 0x0, 0x2, 0xff, 0x0, 0x0, 0x0, 0x2, 0x22, 0xa, 0x0, 0x0, 0x3, 0xc, 0x0, 0x0, 0x4, 0x0, 0x1, 0xff, 0x0, 0x0, 0x0, 0x1, 0x10, 0x80, 0x2, 0x2, 0x5, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0x18, 0xaf, 0x6e, 0x29, 0x34, 0x56, 0x0, 0x12, 0x0, 0x0, 0x0, 0x1, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0x54, 0xde, 0xa5, 0x7f, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x0, 0xff, 0xff, 0xff, 0xff, 0x61, 0x63, 0x74, 0x75, 0x61, 0x6c, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64, 0x62, 0x79, 0x74, 0x65, 0x73}}, OOB:[]uint8(nil), Addr:(*net.UDPAddr)(0xc0003acc00), N:0, NN:0, Flags:0}
            	            	
            	            	Diff:
            	            	--- Expected
            	            	+++ Actual
            	            	@@ -5,3 +5,3 @@
            	            	    00000010  00 00 04 11 00 02 ff 00  00 00 02 22 0a 00 00 03  |..........."....|
            	            	-   00000020  0c 00 00 04 40 25 49 05  00 00 11 ed 80 02 02 05  |....@%I.........|
            	            	+   00000020  0c 00 00 04 00 01 ff 00  00 00 01 10 80 02 02 05  |................|
            	            	    00000030  01 02 03 04 05 06 07 08  09 0a 0b 0c 18 af 6e 29  |..............n)|
            	Test:       	TestProcessColibriPkt/controlplane_onpath_AS_inbound_to_colibri_service
    --- FAIL: TestProcessColibriPkt/reversed_controlplane_onpath_AS_inbound_to_colibri_service (0.00s)
        dataplane_test.go:1733: 
            	Error Trace:	dataplane_test.go:1733
            	Error:      	Not equal: 
            	            	expected: &socket.Message{Buffers:[][]uint8{[]uint8{0xb, 0x80, 0xde, 0xad, 0x11, 0x1b, 0x0, 0x12, 0x4, 0x0, 0x0, 0x0, 0x0, 0x2, 0xff, 0x0, 0x0, 0x0, 0x2, 0x22, 0x0, 0x4, 0xff, 0x0, 0x0, 0x0, 0x4, 0x11, 0xc, 0x0, 0x0, 0x4, 0xa, 0x0, 0x0, 0x3, 0x40, 0x25, 0x42, 0x3, 0x0, 0x0, 0x11, 0xed, 0xc0, 0x2, 0x2, 0x5, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0x18, 0xaf, 0x6e, 0x29, 0x34, 0x56, 0x0, 0x12, 0x0, 0x1, 0x0, 0x0, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0x54, 0xde, 0xa5, 0x7f, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x1, 0xff, 0xff, 0xff, 0xff, 0x61, 0x63, 0x74, 0x75, 0x61, 0x6c, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64, 0x62, 0x79, 0x74, 0x65, 0x73}}, OOB:[]uint8(nil), Addr:(*net.UDPAddr)(0xc0002422a0), N:0, NN:0, Flags:0}
            	            	actual  : &socket.Message{Buffers:[][]uint8{[]uint8{0xb, 0x80, 0xde, 0xad, 0x11, 0x1b, 0x0, 0x12, 0x4, 0x0, 0x0, 0x0, 0x0, 0x2, 0xff, 0x0, 0x0, 0x0, 0x2, 0x22, 0x0, 0x4, 0xff, 0x0, 0x0, 0x0, 0x4, 0x11, 0xc, 0x0, 0x0, 0x4, 0xa, 0x0, 0x0, 0x3, 0x0, 0x1, 0xff, 0x0, 0x0, 0x0, 0x1, 0x10, 0xc0, 0x2, 0x2, 0x5, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0x18, 0xaf, 0x6e, 0x29, 0x34, 0x56, 0x0, 0x12, 0x0, 0x1, 0x0, 0x0, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0x54, 0xde, 0xa5, 0x7f, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x1, 0xff, 0xff, 0xff, 0xff, 0x61, 0x63, 0x74, 0x75, 0x61, 0x6c, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64, 0x62, 0x79, 0x74, 0x65, 0x73}}, OOB:[]uint8(nil), Addr:(*net.UDPAddr)(0xc000150f00), N:0, NN:0, Flags:0}
            	            	
            	            	Diff:
            	            	--- Expected
            	            	+++ Actual
            	            	@@ -5,3 +5,3 @@
            	            	    00000010  00 00 02 22 00 04 ff 00  00 00 04 11 0c 00 00 04  |..."............|
            	            	-   00000020  0a 00 00 03 40 25 42 03  00 00 11 ed c0 02 02 05  |....@%B.........|
            	            	+   00000020  0a 00 00 03 00 01 ff 00  00 00 01 10 c0 02 02 05  |................|
            	            	    00000030  01 02 03 04 05 06 07 08  09 0a 0b 0c 18 af 6e 29  |..............n)|
            	Test:       	TestProcessColibriPkt/reversed_controlplane_onpath_AS_inbound_to_colibri_service
    --- FAIL: TestProcessColibriPkt/controlplane_last_AS_inbound (0.00s)
        dataplane_test.go:1733: 
            	Error Trace:	dataplane_test.go:1733
            	Error:      	Not equal: 
            	            	expected: &socket.Message{Buffers:[][]uint8{[]uint8{0xb, 0x80, 0xde, 0xad, 0x11, 0x1b, 0x0, 0x12, 0x4, 0x0, 0x0, 0x0, 0x0, 0x4, 0xff, 0x0, 0x0, 0x0, 0x4, 0x11, 0x0, 0x2, 0xff, 0x0, 0x0, 0x0, 0x2, 0x22, 0xa, 0x0, 0x0, 0x3, 0xc, 0x0, 0x0, 0x4, 0x40, 0x25, 0x26, 0xd2, 0x0, 0x0, 0x11, 0xed, 0x80, 0x2, 0x4, 0x5, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0x18, 0xaf, 0x6e, 0x29, 0x34, 0x56, 0x0, 0x12, 0x0, 0x0, 0x0, 0x1, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x0, 0x91, 0xef, 0x9f, 0x68, 0x61, 0x63, 0x74, 0x75, 0x61, 0x6c, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64, 0x62, 0x79, 0x74, 0x65, 0x73}}, OOB:[]uint8(nil), Addr:(*net.UDPAddr)(0xc000492fc0), N:0, NN:0, Flags:0}
            	            	actual  : &socket.Message{Buffers:[][]uint8{[]uint8{0xb, 0x80, 0xde, 0xad, 0x11, 0x1b, 0x0, 0x12, 0x4, 0x0, 0x0, 0x0, 0x0, 0x4, 0xff, 0x0, 0x0, 0x0, 0x4, 0x11, 0x0, 0x2, 0xff, 0x0, 0x0, 0x0, 0x2, 0x22, 0xa, 0x0, 0x0, 0x3, 0xc, 0x0, 0x0, 0x4, 0x0, 0x4, 0xff, 0x0, 0x0, 0x0, 0x4, 0x11, 0x80, 0x2, 0x4, 0x5, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0x18, 0xaf, 0x6e, 0x29, 0x34, 0x56, 0x0, 0x12, 0x0, 0x0, 0x0, 0x1, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x0, 0x91, 0xef, 0x9f, 0x68, 0x61, 0x63, 0x74, 0x75, 0x61, 0x6c, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64, 0x62, 0x79, 0x74, 0x65, 0x73}}, OOB:[]uint8(nil), Addr:(*net.UDPAddr)(0xc000492c00), N:0, NN:0, Flags:0}
            	            	
            	            	Diff:
            	            	--- Expected
            	            	+++ Actual
            	            	@@ -5,3 +5,3 @@
            	            	    00000010  00 00 04 11 00 02 ff 00  00 00 02 22 0a 00 00 03  |..........."....|
            	            	-   00000020  0c 00 00 04 40 25 26 d2  00 00 11 ed 80 02 04 05  |....@%&.........|
            	            	+   00000020  0c 00 00 04 00 04 ff 00  00 00 04 11 80 02 04 05  |................|
            	            	    00000030  01 02 03 04 05 06 07 08  09 0a 0b 0c 18 af 6e 29  |..............n)|
            	Test:       	TestProcessColibriPkt/controlplane_last_AS_inbound
    --- FAIL: TestProcessColibriPkt/reversed_controlplane_first_AS_inbound (0.00s)
        dataplane_test.go:1733: 
            	Error Trace:	dataplane_test.go:1733
            	Error:      	Not equal: 
            	            	expected: &socket.Message{Buffers:[][]uint8{[]uint8{0xb, 0x80, 0xde, 0xad, 0x11, 0x1b, 0x0, 0x12, 0x4, 0x0, 0x0, 0x0, 0x0, 0x2, 0xff, 0x0, 0x0, 0x0, 0x2, 0x22, 0x0, 0x4, 0xff, 0x0, 0x0, 0x0, 0x4, 0x11, 0xc, 0x0, 0x0, 0x4, 0xa, 0x0, 0x0, 0x3, 0x40, 0x25, 0x38, 0x1a, 0x0, 0x0, 0x11, 0xed, 0xc0, 0x2, 0x4, 0x5, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0x18, 0xaf, 0x6e, 0x29, 0x34, 0x56, 0x0, 0x12, 0x0, 0x1, 0x0, 0x0, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x1, 0xd0, 0x50, 0x9a, 0x7a, 0x61, 0x63, 0x74, 0x75, 0x61, 0x6c, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64, 0x62, 0x79, 0x74, 0x65, 0x73}}, OOB:[]uint8(nil), Addr:(*net.UDPAddr)(0xc0005043f0), N:0, NN:0, Flags:0}
            	            	actual  : &socket.Message{Buffers:[][]uint8{[]uint8{0xb, 0x80, 0xde, 0xad, 0x11, 0x1b, 0x0, 0x12, 0x4, 0x0, 0x0, 0x0, 0x0, 0x2, 0xff, 0x0, 0x0, 0x0, 0x2, 0x22, 0x0, 0x4, 0xff, 0x0, 0x0, 0x0, 0x4, 0x11, 0xc, 0x0, 0x0, 0x4, 0xa, 0x0, 0x0, 0x3, 0x0, 0x2, 0xff, 0x0, 0x0, 0x0, 0x2, 0x22, 0xc0, 0x2, 0x4, 0x5, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0x18, 0xaf, 0x6e, 0x29, 0x34, 0x56, 0x0, 0x12, 0x0, 0x1, 0x0, 0x0, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x1, 0x0, 0x2, 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x1, 0xd0, 0x50, 0x9a, 0x7a, 0x61, 0x63, 0x74, 0x75, 0x61, 0x6c, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64, 0x62, 0x79, 0x74, 0x65, 0x73}}, OOB:[]uint8(nil), Addr:(*net.UDPAddr)(0xc000504030), N:0, NN:0, Flags:0}
            	            	
            	            	Diff:
            	            	--- Expected
            	            	+++ Actual
            	            	@@ -5,3 +5,3 @@
            	            	    00000010  00 00 02 22 00 04 ff 00  00 00 04 11 0c 00 00 04  |..."............|
            	            	-   00000020  0a 00 00 03 40 25 38 1a  00 00 11 ed c0 02 04 05  |....@%8.........|
            	            	+   00000020  0a 00 00 03 00 02 ff 00  00 00 02 22 c0 02 04 05  |..........."....|
            	            	    00000030  01 02 03 04 05 06 07 08  09 0a 0b 0c 18 af 6e 29  |..............n)|
            	Test:       	TestProcessColibriPkt/reversed_controlplane_first_AS_inbound
FAIL

When running ./scion.sh topology in the nextversion branch on commit 6684764 I receive the following error:

./scion.sh topology
Shutting down: Terminating this run of the SCION infrastructure
Shut down
Create topology, configuration, and execution files.
Traceback (most recent call last):
  File "python/topology/generator.py", line 28, in <module>
    from topology.config import (
  File "/home/ubuntu/go/src/github.com/scionproto/scion/python/topology/config.py", line 47, in <module>
    from lib.path_store import PathPolicy
  File "/home/ubuntu/go/src/github.com/scionproto/scion/python/lib/path_store.py", line 28, in <module>
    from lib.packet.pcb import PathSegment
  File "/home/ubuntu/go/src/github.com/scionproto/scion/python/lib/packet/pcb.py", line 27, in <module>
    import proto.path_seg_capnp as P
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
  File "capnp/lib/capnp.pyx", line 3949, in capnp.lib.capnp._Loader.load_module (capnp/lib/capnp.cpp:75560)
  File "capnp/lib/capnp.pyx", line 3928, in capnp.lib.capnp.load (capnp/lib/capnp.cpp:75048)
  File "capnp/lib/capnp.pyx", line 3251, in capnp.lib.capnp.SchemaParser.load (capnp/lib/capnp.cpp:65949)
capnp.lib.capnp.KjException: /home/ubuntu/go/src/github.com/scionproto/scion/proto/path_seg.capnp:1: failed: Import failed: go.capnp
stack: 0x7f281ab26d98 0x7f281b53bb1b 0x7f281b53c055 0x7f281b514481 0x7f281b515fdc 0x7f281b52f04c 0x7f281b534b15 0x7f281b5309ae 0x7f281b514df2 0x7f281b5145aa 0x7f281b5157d3 0x7f281b51b502 0x7f281b521cd5 0x7f281b522635 0x7f281b5338cd 0x7f281b534b7f

Maybe I have to do some more steps aside from checking out and installing the new version?

Furthermore, I am not totally aware of future plans of the local topology in the next version but thought this is noteworthy for the upcoming release.

Adapt from these ones:
https://github.com/scionproto/scion/blob/master/topology/PathPolicy.yml

Also review as.yml.

Things to do:

• Ideally cherry pick the commit(s) to us.
• Set the values to all nodes in all ASes in SCIONLab infrastructure
• Use this new change in Coordinator
• Propagate changes to existing user ASes via the "upgrade mechanism"

What has been observed is the following scenario

• arbitrary interface of a border router goes down
• beacon server issues a revocation and marks the interface as down
• other border routers are informed about the interface/router being down

The steps described above are happening pretty quickly, in the order of a few seconds. At this moment as a user I would expect paths containing the faulty/down interface not to be returned any more. However, if a SCION connection to an arbitrary target was previously made, the available paths are cached and are available for the next 6 hours, also the paths containing the faulty interface.

A simple solution would be to request every application running over SCION to be able to handle a scenario when connection over a selected path can fail and do a failover themselves, however as an end user I would expect the first path returned to be always available one - covering a simple scenario where I do not care about path awareness, but want just to run over SCION.

Also, working under assumption "I always select a first path returned", it is very easy to take the SCIONLab down - disabling one arbitrary interface in a core AS can break down ~30% of the network. What's more important, neighbouring ISDs are also affected. A very simple scenario to reproduce it can be putting down a br-1 in AWS Tokyo.

There seems to be a performance issue with the DRKey key derivation. (Already mentioned to @juagargi)

The function deriveKey calls initAESCBC, which in turn calls aes.NewCipher and cipher.NewCBCEncrypter.

COLIBRI packets with S=0 and C=1 are created when doing a traceroute with an EER ID, or when using an EER to do a renewal, etc.
These packets cannot be delivered by the current dispatcher, as the host address is picked from the packet SCION header, that contains the destination of the final end-host, and not that of the COLIBRI service.

In SCIONLab we issue many revocations against infrastructure links . This should not happen, e.g. from logs/bs19-ffaa_0_1301-1.DEBUG:

2018-10-16 13:44:42.667414+0000 [INFO] (BS._handle_if_timeouts) Issuing revocation: RevInfo: 19-ffaa:0:1301 IF: 3 Link type: CORE Timestamp: 2018-10-16 13:44:42+00:00 TTL: 10s

Typically the connection between border routers is just fine. Tasks:

• Investigate why this happens
• Get a metric to know how many / where they happen
• Add said metric to our monitoring
• Fix the issue / create ticket to fix it, with specific proposals

Depends on #152 and #153
After they are fixed, re-visit the traceroute command and in its first step (the CmdTraceroute function of the debug server) we must obtain the transport path for that EER using S=0,C=1.

When shutting down the CS, all DBs should flush and close orderly. The DRKey DB seems not to do so, as there are -wal and -shm files for the CSs that have DRKey configured.
E.g. for the tiny topology, with 111 and 112 configured with DRKey:

$ ls gen-cache/*wal
gen-cache/cs1-ff00_0_111-1.drkey.db-wal  gen-cache/cs1-ff00_0_112-1.drkey.db-wal

$ ls gen-cache/*shm
gen-cache/cs1-ff00_0_111-1.drkey.db-shm  gen-cache/cs1-ff00_0_112-1.drkey.db-shm

So far nothing else seems broken, but the WAL and SHM files should not be there when cleanly closing the DB.

It seems sciond may have some sort of problem with the path store. We saw a problem in ffaa:0:1309 Valencia where scmp echo was not working at all.
From the sciond log file:

2019-07-31 09:22:24.764539+0000 [EROR] Unable to get paths debug_id=c2279b8c err=
>  Error looking up path segment q="SELECT DISTINCT s.RowID, s.Segment, s.LastUpdated, h.IsdID, h.AsID, h.CfgID FROM Segments s
>      >   JOIN HpCfgIds h ON h.SegRowID=s.RowID
>      >   JOIN SegTypes t ON t.SegRowID=s.RowID
>      >   WHERE (t.Type=?) AND
>      >   ((s.StartIsdID=? AND s.StartAsID=?) OR (s.StartIsdID=? AND s.StartAsID=?)) AND
>      >   ((s.EndIsdID=? AND s.EndAsID=?))
>      >    ORDER BY s.LastUpdated"
>      no such table: Segments

There was a change at 09:20 UTC where both machines at GEANT were shut down. The machine at ffaa:0:1305 SIDN works perfectly fine.

Some log files here:
https://gist.github.com/juagargi/91101ea0b29cb60ed1762dc92935c11d#file-sciond-issue-tgz

Late note: restarting sciond was enough to have it working again. But look at the two first paths:

$ ./bin/scmp echo -local 19-ffaa:0:1309,[127.0.0.1] -remote 19-ffaa:0:1303,[127.0.0.1] -i
Available paths to 19-ffaa:0:1303
[ 0] Hops: [19-ffaa:0:1309 1>128 19-ffaa:0:1303] Mtu: 1472
[ 1] Hops: [19-ffaa:0:1309 1>128 19-ffaa:0:1303] Mtu: 1472
[ 2] Hops: [19-ffaa:0:1309 2>3 19-ffaa:0:1304 1>6 19-ffaa:0:1301 5>1 19-ffaa:0:1303] Mtu: 1472
Choose path: 0
Using path:
  Hops: [19-ffaa:0:1309 1>128 19-ffaa:0:1303] Mtu: 1472
104 bytes from 19-ffaa:0:1303,[127.0.0.1] scmp_seq=0 time=43.854ms
104 bytes from 19-ffaa:0:1303,[127.0.0.1] scmp_seq=1 time=44.209ms
^C
--- 19-ffaa:0:1303,[[127.0.0.1]] statistics ---

The look the same.

Consider introducing an additional error type in the level 1 key fetching protocol which enables a given AS to report that it will no longer provide level 1 keys to the requesting AS. I.e., introduce some kind of "permanent error" in the protocol so that client ASes can adapt their behavior accordingly.

This issue should mainly serve as a reminder to think again about the possible error scenarios in the DRKey protocol. It's not clear yet, whether the suggestion above is really needed.

At the moment the COLIBRI service returns the tokens to construct packets that are S=0,C=0. This works
It must return the tokens to build packets like these:

• S=0,C=0
• S=0,C=1
  These two types are all that the client end-host would need to use. Any packet with R=1 can be constructed by reversing the path.

The particular case for S=1,C=1 is already taken into account in the activation of SegRs, and needs not to be taken into account here in the EER scenario.

Note: While looking at this, also modify the EER to store those tokens, so that the traceroute case for EER will work by picking the correct set of tokens.

As an operator I have a following scenario occurring in the network

• border routers on both sides of the link are up and running
• beacon servers on both sides detect link as up
• a network interface which serves a SCION interface goes down on one side (let's assume it's a tun interface and OpenVPN has died)
• after some time VPN connection is restored and tun interface reappears with the same IP as before

At this moment what happens is

• border router on the side of restored connection is confused and is not sending IFIDs anymore
• connectivity is not restored
• restart of the border router (only on this one side) is required
• no error messages in any of the logs appear indicating the issue

What operator expects to happen

• either: border router crashes when underlying network interface where it binds to disappears
• or: border router automatically binds to the interface once it reappears

What requires a further investigation

• Create a user AS connected over VPN to the AP. Restart VPN server on the AP's side. Check status of the border router on both AS' and AP's side.
• Create a user AS connected over VPN to the AP. Stop VPN server on the AP's side. After 5 minutes start VPN server on the AP's side. Check status of the border router on both AS' and AP's side.
• Create a user AS connected over VPN to the AP. Restart VPN client on the AS' side. Check status of the border router on the AS' side.
• Create a user AS connected over VPN to the AP. Stop VPN client on the AS' side. After 5 minutes start VPN client on the AS' side. Check status of the border router on the AS' side.

Due to the nature of SCIONLab, we mainly expect modifications to the source upstream in these two forms:

1. Change existing behavior.
2. New features.

The first one, changing an existing piece of code, can be tackled quite well with the use of gopatch (link), which has been tested already by @juagargi and works quite well.

On the other hand, adding new features usually involves only modifying a small amount of existing code from upstream,
while much more often (in number of changes) adding code where there was none.
This has been done in the past in these instances:

• Adding a COLIBRI service.
• Adding a COLIBRI data-plane forwarding routine.
• Adding carbon impact as a new meta-information variable.

We do propose the use of Go plugins (link) in those entry points that we find out will be relevant for these types of endeavors. So far we have:

1. Path Type: Allow forwarding of new path types
2. Meta-information variables: allow the addition of new variables.
3. (maybe) Useful for beacon selection and propagation (each AS could have their own function)

The use of plugins has to be first tested to ensure that:

• They correctly link to the existing upstream version. Do we need a versioning system, or is that taken care by Go?
• Performance is not impacted, where performance is important. Namely, data-plane forwarding.
• Wrong configuration of the plugin preventing it to load properly will not affect the rest of the process. E.g. a wrong version of the plugin is loaded, whose symbols are incompatible with the main e.g. control service, forces an entry in the log as an error, but the control service resumes initializing and continues as usual.

To do:

• Study the questions above.
• Create a plugin system for e.g. the border router data-plane.
• Create gopatch patches for this plugin system.
• Contact the SCION Association to study the possibility of using our plugin system in general.
• Merge to upstream whenever possible, and remove the corresponding gopatch.
• Simultaneously proceed with the rest of the plugin systems (e.g. meta-information variables).

When upgrading SCIONLab, it will be the case that PCBs arriving to a BS with a clock in the past will be rejected (the verifier will return an error).

@oncilla has a PR about this:
scionproto#3003

we can call truststore.NewVerifier().WithSignatureTimstampRange() , @oncilla dixit

The tolerant verifier would have to be used in:

• BS
• PS
• sciond

Relates to #7

We will need to set a longer revocation TTL, as we did in the patch for the previous SCIONLab version.

Note: it would be nicer if we can set a configuration value for the tolerance and use it in the verification call.

After merging #7 we will also need to extend the life of the revocations to e.g. 20s.

In our COLIBRI service we forgot to add code in the end to end reservation setup to check for segment types when stitching.
Not all combinations of segments are valid when stitching. These are the allowed ones:

• up, core, down
• up, down
• core, down

Note that with these combinations, whenever a core segment appears, the stitching point must ensure that the EER will follow the direction of the reservation. I.e. a core SegR A->B cannot be used to stitch C->B->A at stitching point B

TODO:

• Check segment type before stitching.
• Ensure that the segments are followed only in the order of the reservation, at any AS during the EER setup (not only stitching).
• When stitching, and as a particular case of the above point, ensure that the next segment is followed in the direction of the reservation.

@JordiSubira has used this linter and discovered some errors in our code in scionlab:
https://github.com/jingyugao/rowserrcheck

It seems useful. Should we use it in our linting steps? What about scionproto's?

For new contributors to SCION, it can be confusing what the purpose of this repository is, and how it is distinguished from scionproto/scion.
This could be simply addressed by changing the README and explaining that this repository represents the current SCION version deployed at SCIONLab (if I understand correctly, at least).

Similarly, the purposes of the branches, such as scionlab_previousversion and scionlab_nextversion could be elaborated.
Also, the releases page does not clarify the relationship between the currently deployed SCIONLab version and SCION v0.5.0. Is it (basically) the same or not?

Finally, maybe the issue tracker should be disabled, as all issues should probably rather be directed at scionproto/scion (or netsec-ethz/scionlab for SCIONLab-specific issues in particular).