Trust Router Static Peering Performance Statistics
- Stefan Paetow
Because the ABFAB infrastructure requires each party in the transaction to have been authenticated to the infrastructure, a certain performance penalty is incurred the first time the parties engage in the infrastructure. Each party's successful authentication consists of 6-8 RADIUS authentication round-trips between themselves and the APC, as well as any intermediates.
The below performance statistics for use by NREN and Trust Router operators illustrate the penalties of these cumulative round-trips, in order to set expectations for Moonshot authentication requests for the operators of services on their trust router infrastructures.
Test Network
There are four trust routers in the test infrastructure in a tree configuration:
- L1 - The main (top level) trust router to which the APC is connected, as well as one IDP (L1-IDP) and one RP (L1-RP).
- L2 - The first level down-stream trust router, to which one IDP (L2-IDP) and one RP (L2-RP) are connected.
- L2A - Another first level down-stream trust router, to which one IDP (L2A-IDP) is connected.
- L3 - The second level down-stream trust router, to which one IDP (L3-IDP) and one RP (L3-RP) are connected.
The trust router connections are as follows:
- L1 has both L2 and L2A as down-stream trust routers
- L2 has L3 as a down-stream trust router
Methodology
Each of these timings was obtained by restarting all TID and RADIUS servers for all services to ensure that new keys are obtained for all parties in the chain. This way a maximum time in an ideal configuration was obtained.
Timings were obtained in both directions up- as well as down-stream, as well as between services on the same trust router. Additionally, timings were also obtained across two trust routers on the same level.
Timings
| From | To | Direction | Initial Timing | Comments |
|---|---|---|---|---|
| L1-RP | L1-IDP | Same TR | 4 seconds | Both parties are connecting to the same trust router |
| L1-RP | L2-IDP | Down 1 TR | 6 seconds | |
| L1-RP | L3-IDP | Down 2 TR | 8 seconds | |
| L2-RP | L1-IDP | Up 1 TR | 5 seconds | |
| L2-RP | L2-IDP | Same TR | 7 seconds | |
| L2-RP | L2A-IDP | Up 1 TR, Down 1 TR | 6 seconds | This configuration tested the TID completion across two trust routers on the same level |
| L2-RP | L3-IDP | Down 1 TR | 7 seconds | |
| L3-RP | L1-IDP | Up 2 TR | 7 seconds | |
| L3-RP | L2-IDP | Up 1 TR | 7 seconds | |
| L3-RP | L3-IDP | Same TR | 7 seconds |
Conclusion
The current static peering model for the Trust Router infrastructure expects that each down-stream trust router is listed upstream as the AAA server for all the IdPs connected to it, or connected to trust routers connected to it. As appropriate, each down-stream trust router then lists the true AAA server for IdPs directly connected to it. This way trust boundaries are respected. This does add a performance penalty in that each request needs to be passed up and down the chain to the top level trust router before being routed along to the IdP.
In the infrastructure example above, L2 would be listed as AAA server for L2-IDP and L3-IDP on L1, while L2A would be listed as AAA server for L2A-IDP. On L2, L3 would be listed as the AAA server for L3-IDP.
The timings improve when the top-level trust router has a fairly liberal key expiry policy and subsequent requests do not need to request TID keys for the APC itself.