This chapter outlines the scenarios specified for the forthcoming studies. Goals, assumptions and characteristics of each scenario are described.
5.1 Scenarios
In this subsection, we define two scenarios to be analyzed, whereas traffic models are specified in chapter 6.
Networks. We simulate 16 nodes per network (per wireless cell). All nodes share the same radio coverage area. Radio conditions are assumed to be perfect with signal levels fare above the RF background noise. Within the strategic (or deployed) network, we assume lossless infinite transmission capacity, see Figure 5.1and Figure 5.2. We assume that wired nodes are connected to the strategic network. See reference [4] for technical specification of the simulator.
Scenarios. We distinguish between scenarios by the number of ad hoc networks involved. The first scenario has one ad hoc network, whereas the second one encompasses three different networks simultaneously.
Variants and NPKI domains. For each scenario, we define three variants, distinguished by the number of NPKI domains involved. The first variant has no NPKI and is just for reference. The second one has one single NPKI domain and the third one encompasses three different NPKI domains at the same hierarchical level. In the multi domain scenario variant, we assume a root CA (trust anchor) at a hierarchical level above. This CA is, however, not an entity in our model.
NPKI CAs. We assume centralized CAs physically situated outside the ad hoc network and one CA per NPKI domain. We assume that each CA controls and maintains one repository and one status service physically situated outside the ad hoc network(s).
Validation schemes. For both scenarios, we define two alternative policies, distinguished by the validation schemes described in subsection 4.1.3: one push-based and one pull-based scheme.
− Under push scheme in the single domain scenario variant, the CA distributes CRLs to each single subscriber regularly, and subscribers are supposed to validate all certificates locally. In the multi domain variant, a CA also distributes CRLs to all other CAs. Other CAs are
supposed to forward these “foreign” CRLs to their intra domain subscribers
− Under pull scheme in the single domain variant, the CA is assumed to maintain its repository and OCSP status server dynamically, and subscribers are supposed to check all certificates online. In the multi domain variant, a CA distributes CRLs to all other CAs. Other CAs are supposed to update their status servers accordingly. Consequently, we assume it is sufficient for a subscriber to look up the intra domain OCSP status server even when “foreign”
certificates are involved.
38 FFI-rapport 2009/01546
5.2 Scenario 1 – one network
Figure 5.1 shows scenario 1 with a single NPKI domain and with multiple domains.
Characteristics are listed in Table 5.1.
Figure 5.1 Scenario 1 – one network with single domain and multi domain variants
Variant Number of NPKI domains
Validation
scheme Goal
1 0 (NA) Study the effect of increasing user traffic Obtain reference values for one network Push Same offered user traffic as above.
Study the effect of increasing user traffic under push scheme 2 1
Pull Same offered user traffic as above.
Study the effect of increasing user traffic under pull scheme Push Same offered user traffic as above.
Study the effect of adding CAs under push scheme.
Three NPKI domains within a single network.
3 3 Pull
Same offered user traffic as above.
Study the effect of adding CAs under pull scheme.
Three NPKI domains within a single network Table 5.1 Scenario 1 – one network
5.3 Scenario 2 – three networks
Figure 5.2 shows scenario 2 with a single NPKI domain and with multiple domains.
Characteristics are listed in Table 5.2.
FFI-rapport 2009/01546 39
Figure 5.2 Scenario 2 – three networks with single domain and multi domain variants
Variant Number of NPKI domains
Validation
scheme Goal
1 0 (NA) Study the effect of increasing user traffic Obtain reference values for one network Push Same offered user traffic as above.
Study the effect of increasing user traffic under push scheme 2 1
Pull Same offered user traffic as above.
Study the effect of increasing user traffic under pull scheme Push
Same offered user traffic as above.
Study the effect of adding CAs under push scheme.
Three NPKI domains, one per single network.
3 3
Pull Same offered user traffic as above.
Study the effect of adding CAs under pull scheme.
Three NPKI domains within a single network Table 5.2 Scenario 2 – three networks
40 FFI-rapport 2009/01546
5.4 Identity and Naming Plan
The identity and naming plan is shown in Table 5.3.
Identity type Name space ID Network address
NPKI CA entity ID, name]
Example: General message entity gmsg0,…, gmsgn name [Node ID,
General message entity
Sender = NPKI CA entity:
[NPKI CA entity ID, name (msg short name)]
Example:
A_CA_rp0
Sender = NPKI subscriber entity:
(NPKI subscriber ID, name (msg short name)]
Example:
A_CA_sub0_rec2
Sender = general message entity:
[General message entity ID, name (msg short name)]
Example:
0_gmsg1_BMSl_3
(NA)
*) *) msg type msg long name msg short name
Protocol messages: CMP Revocation Request rr
CMP Revocation Response rp
CMP CRL Announcement crlann
OCSP Request req
OCSP Response resp
General messages: Alarm and orders AO
Battle Management System BMS local BMSl
BMS global BMSg
Internal message exchange IME Table 5.3 Names, identities and network addresses
FFI-rapport 2009/01546 41