draft-ietf-rift-rift-04.txt   draft-ietf-rift-rift-05.txt 
RIFT Working Group The RIFT Authors RIFT Working Group The RIFT Authors
Internet-Draft March 3, 2019 Internet-Draft April 23, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: September 4, 2019 Expires: October 25, 2019
RIFT: Routing in Fat Trees RIFT: Routing in Fat Trees
draft-ietf-rift-rift-04 draft-ietf-rift-rift-05
Abstract Abstract
This document outlines a specialized, dynamic routing protocol for This document outlines a specialized, dynamic routing protocol for
Clos and fat-tree network topologies. The protocol (1) deals with Clos and fat-tree network topologies. The protocol (1) deals with
fully automated construction of fat-tree topologies based on fully automated construction of fat-tree topologies based on
detection of links, (2) minimizes the amount of routing state held at detection of links, (2) minimizes the amount of routing state held at
each level, (3) automatically prunes and load balances topology each level, (3) automatically prunes and load balances topology
flooding exchanges over a sufficient subset of links, (4) supports flooding exchanges over a sufficient subset of links, (4) supports
automatic disaggregation of prefixes on link and node failures to automatic disaggregation of prefixes on link and node failures to
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 September 4, 2019. This Internet-Draft will expire on October 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 46 skipping to change at page 3, line 46
5.3.12. One-Hop Healing of Levels with East-West Links . . . 80 5.3.12. One-Hop Healing of Levels with East-West Links . . . 80
5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 80 5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4.1. Security Model . . . . . . . . . . . . . . . . . . . 80 5.4.1. Security Model . . . . . . . . . . . . . . . . . . . 80
5.4.2. Security Mechanisms . . . . . . . . . . . . . . . . . 82 5.4.2. Security Mechanisms . . . . . . . . . . . . . . . . . 82
5.4.3. Security Envelope . . . . . . . . . . . . . . . . . . 82 5.4.3. Security Envelope . . . . . . . . . . . . . . . . . . 82
5.4.4. Nonces . . . . . . . . . . . . . . . . . . . . . . . 85 5.4.4. Nonces . . . . . . . . . . . . . . . . . . . . . . . 85
5.4.5. Lifetime . . . . . . . . . . . . . . . . . . . . . . 86 5.4.5. Lifetime . . . . . . . . . . . . . . . . . . . . . . 86
5.4.6. Key Management . . . . . . . . . . . . . . . . . . . 86 5.4.6. Key Management . . . . . . . . . . . . . . . . . . . 86
5.4.7. Security Association Changes . . . . . . . . . . . . 86 5.4.7. Security Association Changes . . . . . . . . . . . . 86
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.1. Normal Operation . . . . . . . . . . . . . . . . . . . . 86 6.1. Normal Operation . . . . . . . . . . . . . . . . . . . . 87
6.2. Leaf Link Failure . . . . . . . . . . . . . . . . . . . . 88 6.2. Leaf Link Failure . . . . . . . . . . . . . . . . . . . . 88
6.3. Partitioned Fabric . . . . . . . . . . . . . . . . . . . 89 6.3. Partitioned Fabric . . . . . . . . . . . . . . . . . . . 89
6.4. Northbound Partitioned Router and Optional East-West 6.4. Northbound Partitioned Router and Optional East-West
Links . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Links . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.5. Multi-Plane Fabric and Negative Disaggregation . . . . . 91 6.5. Multi-Plane Fabric and Negative Disaggregation . . . . . 91
7. Implementation and Operation: Further Details . . . . . . . . 91 7. Implementation and Operation: Further Details . . . . . . . . 91
7.1. Considerations for Leaf-Only Implementation . . . . . . . 91 7.1. Considerations for Leaf-Only Implementation . . . . . . . 91
7.2. Considerations for Spine Implementation . . . . . . . . . 92 7.2. Considerations for Spine Implementation . . . . . . . . . 92
7.3. Adaptations to Other Proposed Data Center Topologies . . 92 7.3. Adaptations to Other Proposed Data Center Topologies . . 92
7.4. Originating Non-Default Route Southbound . . . . . . . . 93 7.4. Originating Non-Default Route Southbound . . . . . . . . 93
skipping to change at page 4, line 26 skipping to change at page 4, line 26
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
11.1. Normative References . . . . . . . . . . . . . . . . . . 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 96
11.2. Informative References . . . . . . . . . . . . . . . . . 98 11.2. Informative References . . . . . . . . . . . . . . . . . 98
Appendix A. Sequence Number Binary Arithmetic . . . . . . . . . 100 Appendix A. Sequence Number Binary Arithmetic . . . . . . . . . 100
Appendix B. Information Elements Schema . . . . . . . . . . . . 101 Appendix B. Information Elements Schema . . . . . . . . . . . . 101
B.1. common.thrift . . . . . . . . . . . . . . . . . . . . . . 102 B.1. common.thrift . . . . . . . . . . . . . . . . . . . . . . 102
B.2. encoding.thrift . . . . . . . . . . . . . . . . . . . . . 108 B.2. encoding.thrift . . . . . . . . . . . . . . . . . . . . . 108
Appendix C. Finite State Machines and Precise Operational Appendix C. Finite State Machines and Precise Operational
Specifications . . . . . . . . . . . . . . . . . . . 115 Specifications . . . . . . . . . . . . . . . . . . . 115
C.1. LIE FSM . . . . . . . . . . . . . . . . . . . . . . . . . 115 C.1. LIE FSM . . . . . . . . . . . . . . . . . . . . . . . . . 116
C.2. ZTP FSM . . . . . . . . . . . . . . . . . . . . . . . . . 121 C.2. ZTP FSM . . . . . . . . . . . . . . . . . . . . . . . . . 122
C.3. Flooding Procedures . . . . . . . . . . . . . . . . . . . 129 C.3. Flooding Procedures . . . . . . . . . . . . . . . . . . . 130
C.3.1. FloodState Structure per Adjacency . . . . . . . . . 130 C.3.1. FloodState Structure per Adjacency . . . . . . . . . 130
C.3.2. TIDEs . . . . . . . . . . . . . . . . . . . . . . . . 131 C.3.2. TIDEs . . . . . . . . . . . . . . . . . . . . . . . . 132
C.3.2.1. TIDE Generation . . . . . . . . . . . . . . . . . 132 C.3.2.1. TIDE Generation . . . . . . . . . . . . . . . . . 132
C.3.2.2. TIDE Processing . . . . . . . . . . . . . . . . . 132 C.3.2.2. TIDE Processing . . . . . . . . . . . . . . . . . 133
C.3.3. TIREs . . . . . . . . . . . . . . . . . . . . . . . . 134 C.3.3. TIREs . . . . . . . . . . . . . . . . . . . . . . . . 134
C.3.3.1. TIRE Generation . . . . . . . . . . . . . . . . . 134 C.3.3.1. TIRE Generation . . . . . . . . . . . . . . . . . 134
C.3.3.2. TIRE Processing . . . . . . . . . . . . . . . . . 134 C.3.3.2. TIRE Processing . . . . . . . . . . . . . . . . . 134
C.3.4. TIEs Processing on Flood State Adjacency . . . . . . 134 C.3.4. TIEs Processing on Flood State Adjacency . . . . . . 135
C.3.5. TIEs Processing When LSDB Received Newer Version on C.3.5. TIEs Processing When LSDB Received Newer Version on
Other Adjacencies . . . . . . . . . . . . . . . . . . 135 Other Adjacencies . . . . . . . . . . . . . . . . . . 136
C.3.6. Sending TIEs . . . . . . . . . . . . . . . . . . . . 136 C.3.6. Sending TIEs . . . . . . . . . . . . . . . . . . . . 136
Appendix D. Constants . . . . . . . . . . . . . . . . . . . . . 136 Appendix D. Constants . . . . . . . . . . . . . . . . . . . . . 136
D.1. Configurable Protocol Constants . . . . . . . . . . . . . 136 D.1. Configurable Protocol Constants . . . . . . . . . . . . . 136
Appendix E. TODO . . . . . . . . . . . . . . . . . . . . . . . . 138 Appendix E. TODO . . . . . . . . . . . . . . . . . . . . . . . . 138
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 138 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 138
1. Authors 1. Authors
This work is a product of a growing list of individuals. This work is a product of a growing list of individuals.
skipping to change at page 80, line 32 skipping to change at page 80, line 32
resulting trade-off in regard to integrity verification of the resulting trade-off in regard to integrity verification of the
information distributed through the fabric vs. necessary provisioning information distributed through the fabric vs. necessary provisioning
and auto-configuration. At a minimum, in all approaches, the and auto-configuration. At a minimum, in all approaches, the
security of an established adjacency can be ensured. The stricter security of an established adjacency can be ensured. The stricter
the security model the more provisioning must take over the role of the security model the more provisioning must take over the role of
ZTP. ZTP.
The most security conscious operators will want to have full control The most security conscious operators will want to have full control
over which port on which router/switch is connected to the respective over which port on which router/switch is connected to the respective
port on the "other side", which we will call the "port-association port on the "other side", which we will call the "port-association
model" (PAM) achievable e.g. by pairwise-key PKI. In secure data model" (PAM) achievable e.g. by configuring on each port pair a
designated shared key or pair of private/public keys. In secure data
center locations, operators may want to control which router/switch center locations, operators may want to control which router/switch
is connected to which other router/switch only or choose a "node- is connected to which other router/switch only or choose a "node-
association model" (NAM) which allows, for example, simplified port association model" (NAM) which allows, for example, simplified port
sparing. In an even more relaxed environment, an operator may only sparing. In an even more relaxed environment, an operator may only
be concerned that the router/switches share credentials ensuring that be concerned that the router/switches share credentials ensuring that
they belong to this particular data center network hence allowing the they belong to this particular data center network hence allowing the
flexible sparing of whole routers/switches. We will define that case flexible sparing of whole routers/switches. We will define that case
as the "fabric-association model" (FAM), equivalent to using a shared as the "fabric-association model" (FAM), equivalent to using a shared
secret for the whole fabric. Such flexibility may make sense for secret for the whole fabric. Such flexibility may make sense for
leaf nodes such as servers where the addition and swapping of servers leaf nodes such as servers where the addition and swapping of servers
skipping to change at page 82, line 26 skipping to change at page 82, line 26
| +----------------------+ \|/ | +----------------------+ \|/
| / Zero Configuration \ v | / Zero Configuration \ v
+--------------------------+ +--------------------------+
Figure 30: Security Model Figure 30: Security Model
5.4.2. Security Mechanisms 5.4.2. Security Mechanisms
RIFT Security goals are to ensure authentication, message integrity RIFT Security goals are to ensure authentication, message integrity
and prevention of replay attacks. Low processing overhead and and prevention of replay attacks. Low processing overhead and
efficiency messaging are also a goal. Message privacy achieved efficient messaging are also a goal. Message confidentiality is a
through full encryption is a non goal. non-goal.
The model in the previous section allows a range of security key The model in the previous section allows a range of security key
types that are analogous to the various security association models. types that are analogous to the various security association models.
PAM and NAM allow security associations at the port or node level PAM and NAM allow security associations at the port or node level
using symmetric or asymmetric keys that are pre-installed. FAM using symmetric or asymmetric keys that are pre-installed. FAM
argues for security associations to be applied only at a group level argues for security associations to be applied only at a group level
or to be refined once the topology has been established. RIFT does or to be refined once the topology has been established. RIFT does
not specify how security keys are installed or updated it specifies not specify how security keys are installed or updated it specifies
how the key can be used to achieve goals. how the key can be used to achieve goals.
skipping to change at page 83, line 14 skipping to change at page 83, line 14
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
UDP Header: UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | RIFT destination port | | Source Port | RIFT destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum | | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIFT MAGIC | Packet Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer Security Envelope Header: Outer Security Envelope Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIFT MAGIC | Packet Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | RIFT Major | Outer Key ID | Fingerprint | | Reserved | RIFT Major | Outer Key ID | Fingerprint |
| | Version | | Length | | | Version | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security Fingerprint covers all following content ~ ~ Security Fingerprint covers all following content ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Local | Nonce Remote | | Nonce Local | Nonce Remote |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remaining TIE Lifetime (all 1s in case of LIE) | | Remaining TIE Lifetime (all 1s in case of LIE) |
skipping to change at page 84, line 39 skipping to change at page 84, line 39
Outer Key ID: 24 bits. This implies key type and used algorithm. Outer Key ID: 24 bits. This implies key type and used algorithm.
Value 0 means that no valid fingerprint was computed. This key ID Value 0 means that no valid fingerprint was computed. This key ID
scope is global to the RIFT instance since it implies the scope is global to the RIFT instance since it implies the
originator of the TIE so the contained object does not have to be originator of the TIE so the contained object does not have to be
de-serialized to obtain it. de-serialized to obtain it.
Length of Fingerprint: 8 bits. Length in 32-bit multiples of the Length of Fingerprint: 8 bits. Length in 32-bit multiples of the
following fingerprint not including lifetime or nonces. It allows following fingerprint not including lifetime or nonces. It allows
to navigate the structure when an unknown key type is present. To to navigate the structure when an unknown key type is present. To
clarify a common cornercase a fingerprint with length of 0 bits is clarify a common cornercase when this value is set to 0 it
presenting this field with value of 0. signifies an empty (0 bytes long) security fingerprint.
Security Fingerprint: 32 bits * Length of Fingerprint. This is a Security Fingerprint: 32 bits * Length of Fingerprint. This is a
signature that is computed over all data following after it. If signature that is computed over all data following after it. If
the fingerprint is shorter than the signficant bits are left the signficant bits of fingerprint are fewer than the 32 bits
aligned and remaining bits are set to 0. When using PKI the padded length than the signficant bits MUST be left aligned and
remaining bits on the right padded with 0s. When using PKI the
Security fingerprint originating node uses its private key to Security fingerprint originating node uses its private key to
create the signature. The original packet can then be verified create the signature. The original packet can then be verified
provided the public key is shared and current. provided the public key is shared and current.
Remaining TIE Lifetime: 32 bits. In case of anything but TIEs this Remaining TIE Lifetime: 32 bits. In case of anything but TIEs this
field MUST be set to all ones and Origin Security Envelope Header field MUST be set to all ones and Origin Security Envelope Header
MUST NOT be present in the packet. For TIEs this field represents MUST NOT be present in the packet. For TIEs this field represents
the remaining lifetime of the TIE and Origin Security Envelope the remaining lifetime of the TIE and Origin Security Envelope
Header MUST be present in the packet. The value in the serialized Header MUST be present in the packet. The value in the serialized
model object MUST be ignored. model object MUST be ignored.
skipping to change at page 85, line 31 skipping to change at page 85, line 32
of a chain of trust). of a chain of trust).
Observe that due to the schema migration rules per Appendix B the Observe that due to the schema migration rules per Appendix B the
contained model can be always decoded if the major version matches contained model can be always decoded if the major version matches
and the envelope integrity has been validated. Consequently, and the envelope integrity has been validated. Consequently,
description of the TIE is available to flood it properly including description of the TIE is available to flood it properly including
unknown TIE types. unknown TIE types.
5.4.4. Nonces 5.4.4. Nonces
The protocol uses 16 bit Nonces to salt generated signatures as means The protocol uses two 16 bit nonces to salt generated signatures. We
of replay attack prevention. Any implementation including RIFT use the term "nonce" a bit loosely since RIFT nonces are not being
security MUST generate and wrap around local nonces properly. All changed on every packet as common in cryptography. For efficiency
implementation MUST reflect the neighbor's nonces. An implementation purposes they are changed at a frequency high enough to dwarf replay
SHOULD increment a chosen nonce on every LIE FSM transition that ends attacks attempts for all practical purposes.
up in a different state from the previous and MUST increment its
nonce at least every 5 minutes (such considerations allow for Any implementation including RIFT security MUST generate and wrap
efficient implementations without opening a significant security around local nonces properly. All implementation MUST reflect the
risk). When flooding TIEs, the implementation MUST use recent (i.e. neighbor's nonces. An implementation SHOULD increment a chosen nonce
within allowed difference) nonces reflected in the LIE exchange. The on every LIE FSM transition that ends up in a different state from
schema specifies maximum allowable nonce value difference on a packet the previous and MUST increment its nonce at least every 5 minutes
compared to reflected nonces in the LIEs. Any packet received with (such considerations allow for efficient implementations without
nonces deviating more than the allowed delta MUST be discarded opening a significant security risk). When flooding TIEs, the
without further computation of signatures to prevent computation load implementation MUST use recent (i.e. within allowed difference)
attacks. nonces reflected in the LIE exchange. The schema specifies maximum
allowable nonce value difference on a packet compared to reflected
nonces in the LIEs. Any packet received with nonces deviating more
than the allowed delta MUST be discarded without further computation
of signatures to prevent computation load attacks.
In case where a secure implementation does not receive signatures or In case where a secure implementation does not receive signatures or
receives undefined nonces from neighbor indicating that it does not receives undefined nonces from neighbor indicating that it does not
support or verify signatures, it is a matter of local policy how such support or verify signatures, it is a matter of local policy how such
packets are treated. Any secure implementation MUST discard packets packets are treated. Any secure implementation MUST discard packets
where its local nonce is not correctly mirrored but it may choose to where its local nonce is not correctly mirrored but it may choose to
either refuse forming an adjacency with an implementation not either refuse forming an adjacency with an implementation not
advertising signatures or valid nonces or simply keep on signing advertising signatures or valid nonces or simply keep on signing
local packets while accepting neighbor's packets without further local packets while accepting neighbor's packets without further
verification beside checking for proper nonce reflection. verification beside checking for proper nonce reflection.
skipping to change at page 86, line 37 skipping to change at page 86, line 43
Key roll-over while the adjacency is active is allowed and the Key roll-over while the adjacency is active is allowed and the
technique is well known and described in e.g. [RFC6518]. Key technique is well known and described in e.g. [RFC6518]. Key
distribution procedures are out of scope for RIFT. distribution procedures are out of scope for RIFT.
5.4.7. Security Association Changes 5.4.7. Security Association Changes
There in no mechanism to convert a security envelope for the same key There in no mechanism to convert a security envelope for the same key
ID from one algorithm to another once the envelope is operational. ID from one algorithm to another once the envelope is operational.
The recommended procedure to change to a new algorithm is to take the The recommended procedure to change to a new algorithm is to take the
adjacency down and make the changes and then bring the adjacency up. adjacency down and make the changes and then bring the adjacency up.
If an implementation supports disabling the security envelope Obviously, an implementation may choose to stop verifying security
requirements while sending a security envelope an implementation envelope for the duration of key change to keep the adjacency up but
could shut down the security envelope procedures while maintaining an since this introduces a security vulnerability window, such roll-over
adjacency and make changes to the algorithms on both sides then re is not recommended.
enable the security envelope procedures but that introduces security
holes during the disabled period.
6. Examples 6. Examples
6.1. Normal Operation 6.1. Normal Operation
This section describes RIFT deployment in the example topology This section describes RIFT deployment in the example topology
without any node or link failures. We disregard flooding reduction without any node or link failures. We disregard flooding reduction
for simplicity's sake. for simplicity's sake.
As first step, the following bi-directional adjacencies will be As first step, the following bi-directional adjacencies will be
created (and any other links that do not fulfill LIE rules in created (and any other links that do not fulfill LIE rules in
Section 5.2.2 disregarded): Section 5.2.2 disregarded):
skipping to change at page 94, line 48 skipping to change at page 94, line 48
lifetime behind a signature computed over it and additional nonce lifetime behind a signature computed over it and additional nonce
combination which makes even the replay attack window very small and combination which makes even the replay attack window very small and
for practical purposes irrelevant since lifetime cannot be for practical purposes irrelevant since lifetime cannot be
artificially shortened by the attacker. artificially shortened by the attacker.
8.4. Packet Number 8.4. Packet Number
Optional packet number is carried in the security envelope without Optional packet number is carried in the security envelope without
any encryption protection and is hence vulnerable to replay and any encryption protection and is hence vulnerable to replay and
modification attacks. Contrary to nonces this number must change on modification attacks. Contrary to nonces this number must change on
every packet and would present a very high cryptographic load. And every packet and would present a very high cryptographic load if
the attack vector is relatively weak since changing the packet number signed. The attack vector packet number present is relatively
in flight will only affect operational validation tools and possibly benign. Changing the packet number by a man-in-the-middle attack
some performance optimizations on flodding. It is expected that an will only affect operational validation tools and possibly some
implementation detecting too many fake losses or misorderings due to performance optimizations on flooding. It is expected that an
the attack on the number would simply suppress its further implementation detecting too many "fake losses" or "misorderings" due
to the attack on the packet number would simply suppress its further
processing. processing.
8.5. Outer Fingerprint Attacks 8.5. Outer Fingerprint Attacks
A node can try to inject LIE packets observing a conversation on the A node can try to inject LIE packets observing a conversation on the
wire by using the outer key ID albeit it cannot generate valid hashes wire by using the outer key ID albeit it cannot generate valid hashes
in case it changes the integrity of the message so the only possible in case it changes the integrity of the message so the only possible
attack is DoS due to excessive LIE validation. attack is DoS due to excessive LIE validation.
A node can try to replay previous LIEs with changed state that it A node can try to replay previous LIEs with changed state that it
skipping to change at page 102, line 19 skipping to change at page 102, line 27
10. changes any enumeration type except extending `common.TIEType` 10. changes any enumeration type except extending `common.TIEType`
(use of enumeration types is generally discouraged) (use of enumeration types is generally discouraged)
major version of the schema MUST increase. All other changes MUST major version of the schema MUST increase. All other changes MUST
increase minor version within the same major. increase minor version within the same major.
Observe however that introducing an optional field does not cause a Observe however that introducing an optional field does not cause a
major version increase even if the fields inside the structure are major version increase even if the fields inside the structure are
optional with defaults. optional with defaults.
When using security envelope all thrift encoded objects MUST NOT be
de- and re-serialized again when flooding TIEs since differences in
serializers may produce different security fingerprints.
When operating without a security envelope, thrift serializer/
deserializer MUST NOT discard optional, unknown fields but preserve
and serialize them again when re-flooding whereas missing optional
fields MAY be replaced with according default values if present.
All signed integer as forced by Thrift support must be cast for All signed integer as forced by Thrift support must be cast for
internal purposes to equivalent unsigned values without discarding internal purposes to equivalent unsigned values without discarding
the signedness bit. An implementation SHOULD try to avoid using the the signedness bit. An implementation SHOULD try to avoid using the
signedness bit when generating values. signedness bit when generating values.
The schema is normative. The schema is normative.
B.1. common.thrift B.1. common.thrift
/** /**
skipping to change at page 104, line 9 skipping to change at page 104, line 8
/** LIE FSM holdtime type */ /** LIE FSM holdtime type */
typedef i16 TimeIntervalInSecType typedef i16 TimeIntervalInSecType
/** Transaction ID type for prefix mobility as specified by RFC6550, value /** Transaction ID type for prefix mobility as specified by RFC6550, value
MUST be interpreted in implementation as unsigned */ MUST be interpreted in implementation as unsigned */
typedef i8 PrefixTransactionIDType typedef i8 PrefixTransactionIDType
/** timestamp per IEEE 802.1AS, values MUST be interpreted in implementation as unsigned */ /** timestamp per IEEE 802.1AS, values MUST be interpreted in implementation as unsigned */
struct IEEE802_1ASTimeStampType { struct IEEE802_1ASTimeStampType {
1: required i64 AS_sec; 1: required i64 AS_sec;
2: optional i32 AS_nsec; 2: optional i32 AS_nsec;
} }
/** generic counter type */
typedef i64 CounterType
/** Platform Interface Index type, i.e. index of interface on hardware */
typedef i32 PlatformInterfaceIndex
/** Flags indicating nodes behavior in case of ZTP and support /** Flags indicating nodes behavior in case of ZTP and support
for special optimization procedures. It will force level to `leaf_level` or for special optimization procedures. It will force level to `leaf_level` or
`top-of-fabric` level accordingly and enable according procedures `top-of-fabric` level accordingly and enable according procedures
*/ */
enum HierarchyIndications { enum HierarchyIndications {
leaf_only = 0, leaf_only = 0,
leaf_only_and_leaf_2_leaf_procedures = 1, leaf_only_and_leaf_2_leaf_procedures = 1,
top_of_fabric = 2, top_of_fabric = 2,
} }
skipping to change at page 106, line 19 skipping to change at page 106, line 23
struct IPv6PrefixType { struct IPv6PrefixType {
1: required IPv6Address address; 1: required IPv6Address address;
2: required PrefixLenType prefixlen; 2: required PrefixLenType prefixlen;
} }
union IPAddressType { union IPAddressType {
1: optional IPv4Address ipv4address; 1: optional IPv4Address ipv4address;
2: optional IPv6Address ipv6address; 2: optional IPv6Address ipv6address;
} }
/** Prefix representing reachablity. Observe that for interface
addresses the protocol can propagate the address part beyond
the subnet mask and on reachability computation that has to
be normalized. The non-significant bits can be used for operational
purposes.
*/
union IPPrefixType { union IPPrefixType {
1: optional IPv4PrefixType ipv4prefix; 1: optional IPv4PrefixType ipv4prefix;
2: optional IPv6PrefixType ipv6prefix; 2: optional IPv6PrefixType ipv6prefix;
} }
/** @note: Sequence of a prefix. Comparison function: /** @note: Sequence of a prefix. Comparison function:
if diff(timestamps) < 200msecs better transactionid wins if diff(timestamps) < 200msecs better transactionid wins
else better time wins else better time wins
*/ */
struct PrefixSequenceType { struct PrefixSequenceType {
skipping to change at page 108, line 15 skipping to change at page 108, line 21
/** /**
Thrift file for packet encodings for RIFT Thrift file for packet encodings for RIFT
*/ */
include "common.thrift" include "common.thrift"
/** Changes /** Changes
25.0: shorter level and major version types, clarified unsigned on nonces 25.0: shorter level and major version types, clarified unsigned on nonces
25.1: clarifications on `common.TIEType` extensions for new TIEs 25.1: clarifications on `common.TIEType` extensions for new TIEs
26.0: smaller packet sequence number and version number types 26.0: smaller packet sequence number and version number types, adding
elements to prefix and link to allow local identification, miscabling indication
*/ */
/** represents protocol encoding schema major version */ /** represents protocol encoding schema major version */
const common.VersionType protocol_major_version = 26 const common.VersionType protocol_major_version = 26
/** represents protocol encoding schema minor version */ /** represents protocol encoding schema minor version */
const common.MinorVersionType protocol_minor_version = 0 const common.MinorVersionType protocol_minor_version = 0
/** common RIFT packet header */ /** common RIFT packet header */
struct PacketHeader { struct PacketHeader {
1: required common.VersionType major_version = protocol_major_version; 1: required common.VersionType major_version = protocol_major_version;
skipping to change at page 110, line 45 skipping to change at page 111, line 6
false; false;
} }
/** LinkID pair describes one of parallel links between two nodes */ /** LinkID pair describes one of parallel links between two nodes */
struct LinkIDPair { struct LinkIDPair {
/** node-wide unique value for the local link */ /** node-wide unique value for the local link */
1: required common.LinkIDType local_id; 1: required common.LinkIDType local_id;
/** received remote link ID for this link */ /** received remote link ID for this link */
2: required common.LinkIDType remote_id; 2: required common.LinkIDType remote_id;
/** optionally describes the local interface index of the link */
10: optional common.PlatformInterfaceIndex platform_interface_index;
/** optionally describes the local interface name */
11: optional string platform_interface_name;
/** more properties of the link can go in here */ /** more properties of the link can go in here */
} }
/** ID of a TIE /** ID of a TIE
@note: TIEID space is a total order achieved by comparing the elements @note: TIEID space is a total order achieved by comparing the elements
in sequence defined and comparing each value as an in sequence defined and comparing each value as an
unsigned integer of according length. unsigned integer of according length.
*/ */
struct TIEID { struct TIEID {
skipping to change at page 113, line 15 skipping to change at page 113, line 28
1: required common.LevelType level; 1: required common.LevelType level;
/** _All_ of the node's neighbors. /** _All_ of the node's neighbors.
* If neighbor systemID repeats in other node TIEs of same node * If neighbor systemID repeats in other node TIEs of same node
the behavior is undefined. */ the behavior is undefined. */
2: required map<common.SystemIDType, 2: required map<common.SystemIDType,
NodeNeighborsTIEElement> neighbors; NodeNeighborsTIEElement> neighbors;
3: optional NodeCapabilities capabilities; 3: optional NodeCapabilities capabilities;
4: optional NodeFlags flags; 4: optional NodeFlags flags;
/** optional node name for easier operations */ /** optional node name for easier operations */
5: optional string name; 5: optional string name;
/** if any local links are miscabled, the indication
is flooded. */
10: optional set<common.LinkIDType> miscabled_links;
} }
struct PrefixAttributes { struct PrefixAttributes {
2: required common.MetricType metric = common.default_distance; 2: required common.MetricType metric = common.default_distance;
/** generic unordered set of route tags, can be redistributed to other protocols or use /** generic unordered set of route tags, can be redistributed to other protocols or use
within the context of real time analytics */ within the context of real time analytics */
3: optional set<common.RouteTagType> tags; 3: optional set<common.RouteTagType> tags;
/** optional monotonic clock for mobile addresses */ /** optional monotonic clock for mobile addresses */
4: optional common.PrefixSequenceType monotonic_clock; 4: optional common.PrefixSequenceType monotonic_clock;
/** in case of locally originated prefixes, i.e. interface addresses this can
describe which link the address belongs to. */
10: optional common.LinkIDType from_link;
} }
/** multiple prefixes */ /** multiple prefixes */
struct PrefixTIEElement { struct PrefixTIEElement {
/** prefixes with the associated attributes. /** prefixes with the associated attributes.
if the same prefix repeats in multiple TIEs of same node if the same prefix repeats in multiple TIEs of same node
behavior is unspecified */ behavior is unspecified */
1: required map<common.IPPrefixType, PrefixAttributes> prefixes; 1: required map<common.IPPrefixType, PrefixAttributes> prefixes;
} }
/** keys with their values */ /** keys with their values */
struct KeyValueTIEElement { struct KeyValueTIEElement {
/** if the same key repeats in multiple TIEs of same node /** if the same key repeats in multiple TIEs of same node
or with different values, behavior is unspecified */ or with different values, behavior is unspecified */
1: required map<common.KeyIDType,string> keyvalues; 1: required map<common.KeyIDType,string> keyvalues;
} }
skipping to change at page 132, line 21 skipping to change at page 132, line 40
TIDE_START: Begin of TIDE packet range. TIDE_START: Begin of TIDE packet range.
a. NEXT_TIDE_ID = MIN_TIEID a. NEXT_TIDE_ID = MIN_TIEID
b. while NEXT_TIDE_ID not equal to MAX_TIEID do b. while NEXT_TIDE_ID not equal to MAX_TIEID do
1. TIDE_START = NEXT_TIDE_ID 1. TIDE_START = NEXT_TIDE_ID
2. HEADERS = At most TIRDEs_PER_PKT headers in TIEDB starting at 2. HEADERS = At most TIRDEs_PER_PKT headers in TIEDB starting at
NEXT_TIDE_ID or higher that SHOULD be filtered by NEXT_TIDE_ID or higher that SHOULD be filtered by
is_tide_entry_filtered and have a lifetime left > 0 is_tide_entry_filtered and MUST either have a lifetime left >
0 or have no content
3. if HEADERS is empty then START = MIN_TIEID else START = first 3. if HEADERS is empty then START = MIN_TIEID else START = first
element in HEADERS element in HEADERS
4. if HEADERS' size less than TIRDEs_PER_PKT then END = 4. if HEADERS' size less than TIRDEs_PER_PKT then END =
MAX_TIEID else END = last element in HEADERS MAX_TIEID else END = last element in HEADERS
5. send sorted HEADERS as TIDE setting START and END as its 5. send sorted HEADERS as TIDE setting START and END as its
range range
skipping to change at page 134, line 4 skipping to change at page 134, line 24
into CLEARKEYS into CLEARKEYS
II) else put HEADER into REQKEYS II) else put HEADER into REQKEYS
c. put all TIEs in LSDB where (TIE.HEADER > LASTPROCESSED and c. put all TIEs in LSDB where (TIE.HEADER > LASTPROCESSED and
TIE.HEADER <= TIDE.end_range) into TXKEYS TIE.HEADER <= TIDE.end_range) into TXKEYS
d. for all TIEs in TXKEYS try_to_transmit_tie(TIE) d. for all TIEs in TXKEYS try_to_transmit_tie(TIE)
e. for all TIEs in REQKEYS request_tie(TIE) e. for all TIEs in REQKEYS request_tie(TIE)
f. for all TIEs in CLEARKEYS remove_from_all_queues(TIE) f. for all TIEs in CLEARKEYS remove_from_all_queues(TIE)
C.3.3. TIREs C.3.3. TIREs
C.3.3.1. TIRE Generation C.3.3.1. TIRE Generation
There is not much to say here. Elements from both TIES_REQ and There is not much to say here. Elements from both TIES_REQ and
TIES_ACK MUST be collected and sent out as fast as feasible as TIREs. TIES_ACK MUST be collected and sent out as fast as feasible as TIREs.
When sending TIREs with elements from TIES_REQ the `lifetime` field
MUST be set to 0 to force reflooding from the neighbor even if the
TIEs seem to be same.
C.3.3.2. TIRE Processing C.3.3.2. TIRE Processing
On reception of TIREs the following processing is performed: On reception of TIREs the following processing is performed:
TXKEYS: Collection of TIE Headers to be send after processing of TXKEYS: Collection of TIE Headers to be send after processing of
the packet the packet
REQKEYS: Collection of TIEIDs to be requested after processing of REQKEYS: Collection of TIEIDs to be requested after processing of
the packet the packet
 End of changes. 31 change blocks. 
60 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/