An introductory presentation of a short paper with same name in the ICUFN2022: The 13th International Conference on Ubiquitous and Future Networks in Barcelona, Spain. The presentation and paper describes our (Karri Huhtanen, Antti Kolehmainen) initial proposal for distributed multi-factor AAA architecture capable of surviving connectivity disruptions. Together with Tampere University we intend to design, implement and deploy the proposed architecture in practice to ensure its validity.

1. FAULT-TOLERANT, DISTRIBUTED AAA
ARCHITECTURE SUPPORTING
CONNECTIVITY DISRUPTION
Karri Huhtanen (Radiator Software), Antti Kolehmainen (Tampere University)

2. Introduction
● Trend in services is to move from on-premise deployments to service
provider or cloud environments.
● Authentication, authorisation and accounting (AAA) is not an exception as
a service.
● While it may be true for some or most organisations that the local network
services access does not matter if Internet connectivity is down, there are
still organisations, which require access to their on-premise network and
services even without Internet access => need for fault-tolerant,
distributed AAA
● In this short paper, we examine initial design, implementation and
deployment issues related to our proposed hybrid architecture model for
fault-tolerant distributed AAA architecture

3. Proposed architecture

4. Phase 1: Normal situation
Centralised AAA is
accessible by all the
onsite AAA replicas.

5. Phase 2: Connectivity loss
The connectivity
between the
centralised AAA and
onsite AAAs is lost.
The onsite AAAs
start to operate
independently.
Log data is
buffered on onsite
AAAs, but what if
there are needs to
modify AAA site
data?

6. Phase 3: Divergence of AAA data
If the disruption
continues longer,
the need for local
AAA data
modifications
increases =>
divergence of AAA
data
Centralised AAA
and onsite AAAs
are then
out-of-sync
between each
other.

7. Phase 4: Connectivity restored:
Re-synchronisation of data
What happens or
should happen
when connectivity
is restored after a
longer disruption is
one of the key
issues for us to
research further.
There are different options
for AAA data
synchronisation:
● DBMS features
● Custom sync. Scripts
● One direction sync.
(Centralised AAA
overwrites Onsite
AAA data)
● etc.

8. In addition to AAA data re-synchronisation
there are research questions like …
● How the Centralised AAA <-> Site AAA communication is
secured and authenticated?
● How the site AAA replicas are deployed and provisioned?
● What AAA technologies work in situations like these and
with which limitations?
● Do we need additional components, e.g. PKI?
● What is the best way to deploy this kind of architecture? Is it
for example possible to utilise software containers deployed
in network switches instead of servers?

9. Most importantly does it work in practice?
● Our approach to solving the research questions is to try
to design, implement and deploy the proposed
architecture to practice.
● The iterative design based on the empirical research
ensured that the found solutions are improved and
validated during the process.
● This short paper/presentation is an introduction to the
research work and architecture we are developing and
we will publish more detailed results later.

10. Please, feel free to contact authors if interested in this research for
further discussion.
Any questions from the audience?
Karri Huhtanen (Radiator Software)
Antti Kolehmainen (Tampere University)

11. Technologies, protocols, standards being
currently considered…
Area / Status Confirmed Under consideration To be evaluated / researched
AAA Two/Multi-Factor
Authentication, TOTP (RFC
6328), RADIUS (RFC 2865),
Radius over TLS (RadSec,
RFC 6614)
TACACS+ (RFC 8907) HOTP (RFC 4226)
Communications
security
TLS, Radius over TLS
(RadSec, RFC 6614)
OpenVPN, Wireguard IPSEC
Database and
synchronisation
MariaDB (DBMS) sync, one
direction sync
SQLite sync, custom sync
scripts
Onsite network security RADIUS, RadSec TACACS+ (RFC 8907) EAP-TLS (RFC 5216)
Platforms Linux, containers Cisco industrial switches with
container support