Subject: [Rift] RIFT Security Models

From: Don Fedyk <[email-masked]>
Date: Sun, 18 Nov 2018 09:56:12 -0500

Hi

The following text and diagram are for inclusion in the RIFT draft spec.
This text was generated from discussions in a RIFT core team meeting.  (It
goes with the first doodles that Tony posted last week.)
Comments/Questions welcome.

Thanks,
Don
-------- Begin Text------
An inherent property of any security and ZTP architecture is the
resulting trade-off in regard to integrity verification of the
information distributed through the fabric vs. necessary provisioning
and auto-configuration.  At a minimum, in all approaches, the security of
an established but adjacency can be ensured. The stricter the security
model the more provisioning must take over the role of mis-cabling
detection.

The most security conscious operators will want to have full control
over which port on which router/switch is connected to which other
port on which other router/switch, which we will call the
"port-association model" (PAM) achievable e.g. by pair-key PKI. In
secure data center locations, operators may want to control which
router/switch is connected to which other router/switch only or choose
a "node-association model" (NAM) which allows, for example, simplified
port sparing. In an even more relaxed environment, an operator may
only be concerned that the router/switches share credentials ensuring
that they belong in this particular data center network allowing the
flexible sparing of whole routers/switches. We will define that case
as the "fabric-association model" (FAM), equivalent to using a shared
secret for the whole fabric.  Such flexibility may make sense for leaf
nodes such as servers where the addition and swapping of servers is
more frequent than the rest of the data center network.  Generally,
leafs of the fabric are less trusted than switches. The models could
be mixed throughout the fabric if the benefits outweigh the cost of
increased complexity in provisioning.

In each of the above cases, some configuration mechanism is needed to
allow the operator to specify which connections are allowed, and some
mechanism is needed to:
(a) discover and report missing connections,
(b) discover and report unexpected connections, and prevent such
adjacencies from forming.

On the more relaxed configuration side of the spectrum, operators
might only configure the level of each switch, but don't explicitly
configure which connections are allowed. In this case, RIFT will
only allow adjacencies to come up between nodes are that in
adjacent levels. The  operators with lowest security
requirements may not use any configuration to specify which
connections are allowed. Such fabrics could rely fully on ZTP for each
router/switch to discover its level and would only allow adjacencies
between adjacent levels to come up.

Ultimately, some level of verification of the link quality may be
required before an adjacency is allowed to be used for forwarding. For
example, an implementation may require that a BFD session comes up
before advertising the adjacency.

For the above outlined cases, RIFT has two approaches to enforce that
a local port is connected to the correct port on the correct remote
router/switch.  One approach is to piggy-back on RIFT’s authentication
mechanism. Assuming the provisioning model (e.g. the YANG model) is
flexible enough, operators can choose to provision a unique
authentication key for:
(a) each pair of ports in "port-association model" or
(b) each pair of switches in "node-association model" or
(c) each pair of levels or
(d) for the entire fabric in "fabric-association model".
The other approach is to rely on the system-id, port-id and level
fields in the LIE message to validate an adjacency against the
configured expected cabling topology, and optionally introduce some
new rules in the FSM to allow the adjacency to come up if the
expectations are violated.

         ^                 /\                  |
        /|\               /  \                 |
         |               /    \                |
         |              / PAM  \               |
     Increasing        /        \          Increasing
     Integrity        +----------+         Flexibility
         &           /    NAM     \            &
    Increasing      +--------------+         Less
    Provisioning   /      FAM       \     Configuration
         |        +------------------+         |
         |       / Level Provisioning \        |
         |      +----------------------+      \|/
         |     /    Zero Configuration  \      v
              +--------------------------+