You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SCMP "specification" document described support for SCMP as
mandatory. Furthermore, it mandates the use of SPAO+DRKey authentication
for SCMPs. This does not correspond to what is currently implemented.
SCMP support has been treated as at least semi-optional e.g. in
discussions around the dispatcher-less end host stack.
Regarding the authentication, there is no full implementation of this
neither in router (support in "our" router is experimental/demo-level,
no other router implementation supports it at all) nor in end hosts
(currently, nothing at all). There is not sufficiently clear consensus
around this to pretend that we'll realize this ambition shortly.
Update the documentation specs to reflect this reality. Move the SCMP
authentication description into a design document.
Closesscionproto#4528
- On hold. No clear consensus that this is the right approach. See "Discussion" section.
11
+
- Experimental support in router, added in :issue:`4255`.
12
+
13
+
14
+
Abstract
15
+
========
16
+
:doc:`SCMP </protocols/scmp>` error messages can potentially be abused by an attacker to signal spurious network errors, attempting to degrade or deny a victim's use of a service or network path.
17
+
Employ cryptographic validation to check authenticity and authorization of the sender of an SCMP message.
18
+
19
+
Background
20
+
==========
21
+
22
+
SCMP error messages can potentially be abused by an attacker to signal spurious network errors.
23
+
Implementations of TCP/IP, face a similar challenge with ICMP error messages; in order to avoid acting on fraudulent errors, they carefully validate ICMP messages using their internal state machine and ignore errors that appear unlikely to happen e.g. after the connection has already been established RFC 5927.
24
+
QUIC goes even further and simply ignores all ICMP errors, except those related to MTU discovery.
25
+
26
+
This approach can only mitigate the problem.
27
+
Furthermore, this approach is not sufficient in SCION as the applications/transport layer on end hosts are expected to react to events in the network, e.g. path failures, by changing to a different path.
28
+
The occurrence of such events is independent of the transport's internal state machine.
29
+
This aspect does not exist in IP based internet, where the network will transparently adapt the routing (or not) on faults.
30
+
31
+
To address this, we use :doc:`/cryptography/drkey` and the :doc:`/protocols/authenticator-option` to authenticate SCMP messages.
32
+
33
+
Proposal
34
+
========
35
+
36
+
As noted in the :doc:`/protocols/scmp`, support for the SCMP protocol is optional for SCION nodes.
37
+
This proposal *mandates* authentication for most SCMP messages.
38
+
Should this proposal be adopted, it extends the SCMP specification, and terms MUST/MUST NOT/MAY used below will apply to all SCION nodes with an SCMP implementations.
39
+
In other words, SCION nodes either need to implement the additional processing rules for SCMP messages described in this document, or remove SCMP support altogether.
40
+
41
+
.. _scmp-spao:
42
+
43
+
SCMP with SCION Packet Authenticator Option
44
+
-------------------------------------------
45
+
46
+
SCMP messages can be authenticated with a MAC based on a symmetric key established with the :ref:`DRKey infrastructure <drkey>`.
47
+
The MAC is transported in the :ref:`authenticator-option` End-to-End extension header.
48
+
49
+
The Authenticator MAC algorithm is AES-CMAC (identifier :code:`0`).
50
+
51
+
SCMP error messages MUST always be authenticated.
52
+
SCMP informational messages MAY optionally be authenticated; a response message
53
+
MUST be authenticated if and only if the corresponding request message was
54
+
authenticated.
55
+
56
+
All DRKey keys used here are derived with :ref:`protocol identifier <drkey-protocol-identifiers>` :code:`SCMP`, decimal :code:`1`.
57
+
58
+
SCMP messages from (and to) routers are authenticated with :ref:`AS-host keys <drkey-as-host>`.
59
+
SCMP response messages from a router in AS :math:`D` to a node :math:`H_s` in
60
+
AS :math:`S` are authenticated with the DRKey :math:`K_{D,S:H_s}`.
61
+
SCMP requests (specifically, :ref:`traceroute-request`) processed by a router
62
+
are authenticated with the same key.
63
+
64
+
SCMP messages between two end-hosts are authenticated with :ref:`host-host keys <drkey-host-host>`.
65
+
An SCMP response message from a node :math:`H_d` in AS :math:`D` to a node
66
+
:math:`H_s` in AS :math:`S` is authenticated with the key
67
+
:math:`K_{D:H_d,S:H_s}`.
68
+
SCMP requests and data packets from :math:`H_s` to :math:`H_d` are
69
+
authenticated with this same key.
70
+
71
+
For packets addressed to a router directly (specifically for
72
+
:ref:`echo-request` and :ref:`echo-reply`) it is treated like an end-host and
73
+
the corresponding host-host keys are used.
74
+
75
+
.. note::
76
+
Recall that :ref:`traceroute-request`\s are *not* addressed to the router.
77
+
Instead, the router processes the request if its router alert flag is set.
78
+
79
+
Processing Rules
80
+
----------------
81
+
The processing rules for SCMP messages are extended with the following points:
82
+
83
+
- Every SCMP error message MUST be authenticated.
84
+
85
+
Every SCMP informational reply message MUST be authenticated if and only if
86
+
the corresponding request was authenticated.
87
+
88
+
.. note::
89
+
Consequentially, an implementation without support for SCMP
90
+
authentication MUST never send SCMP error messages and MUST NOT reply to
- When an SCMP message is received, the receiver MUST check the
94
+
authentication header.
95
+
96
+
- SCMP error messages without or with an invalid authentication header and
97
+
SCMP informational messages with an invalid authentication header MUST
98
+
be silently dropped.
99
+
100
+
- The receiver checks that the :ref:`DRKey identified by the SPI <spao-spi-drkey>`
101
+
is appropriate for the SCMP message type and code, as described above in
102
+
the section :ref:`scmp-spao`.
103
+
104
+
- The receiver derives or fetches the relevant key for validation of the MAC.
105
+
106
+
- Before checking the authentication, and in particular before fetching a
107
+
key, the receiver SHOULD check whether the quoted message was possibly
108
+
recently sent via/to the originator of the error message.
109
+
110
+
- The receiver MUST limit the traffic to the control service to fetch keys
111
+
for verifying the authentication of an SCMP message.
112
+
At most one packet SHOULD be sent to fetch the key for a received SCMP
113
+
message. If this fails or is not possible (e.g. because there is no
114
+
existing TCP session to the control service), the message SHOULD be
115
+
silently dropped.
116
+
117
+
Compatibility
118
+
=============
119
+
As SCMP authentication is a new addition, there will be a transition period during which receivers
120
+
may accept SCMP error messages without authentication.
121
+
122
+
Discussion
123
+
==========
124
+
125
+
Even though this proposal had been accepted, it later turned out that there is no strong consensus
126
+
to implement this in all routers and end points. For now, this has been put on hold.
127
+
Alternative options that can be considered:
128
+
129
+
- No authentication, expand the heuristics that end hosts apply to detect fraudulent SCMP messages.
130
+
- Authenticate only :ref:`external-interface-down` and :ref:`internal-connectivity-down` messages.
131
+
If we authenticate only the information about the link that is down (ISD, AS, interface IDs) and a coarse timestamp, we can reuse the same signed message body for link down notifications for some time period, e.g. a few seconds.
132
+
Protection against message replay is not a concern for these messages types, as receivers can naturally consider them less and less relevant the longer ago they were created.
133
+
This allows authenticating these message body with relatively slow asymmetric cryptographic signatures with the CP-PKI, removing the dependency on DRKey.
134
+
The signature would be part of the SCMP message format for these specific messages and thus no longer requires the SPAO header.
135
+
Overall, this approach is very similar to the "Path revocation" messages that we historically used to have.
0 commit comments