blob: 69edc452aedd4dc6b0b1309ef82978184025e842 [file] [log] [blame]
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -07001Validator Configuration File Format
2===================================
3
Yingdi Yu4e99f532014-08-25 19:40:57 -07004.. contents::
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -07005
Yingdi Yu4e99f532014-08-25 19:40:57 -07006You can set up a ``Validator`` via a configuration file. Next, we will show you how to
7write a configuration file.
8
9The configuration file consists of **rules** and **trust-anchors** that will be used in
10validation. **Rules** tell the validator how to validate a packet, while **trust-anchors**
11tell the validator which certificates are valid immediately. Here is an example of
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -080012configuration file containing two rules and a trust anchor.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -070013
14::
15
16 rule
17 {
18 id "Simple Rule"
19 for data
20 filter
21 {
22 type name
23 name /localhost/example
24 relation is-prefix-of
25 }
26 checker
27 {
28 type customized
29 sig-type rsa-sha256
30 key-locator
31 {
32 type name
Alexander Afanasyevc381bca2017-10-15 14:51:49 -040033 name /ndn/edu/ucla/yingdi/KEY/1234
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -070034 relation equal
35 }
36 }
37 }
38 rule
39 {
40 id "Testbed Validation Rule"
41 for data
42 checker
43 {
44 type hierarchical
45 sig-type rsa-sha256
46 }
47 }
48 trust-anchor
49 {
50 type file
51 file-name "testbed-trust-anchor.cert"
52 }
53
Davide Pesavento933a5672020-07-03 22:32:43 -040054.. attention:: **The order of rules MATTERS!**
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -070055
56A rule can be broken into two parts:
57
58- The first part is to qualify packets to which the rule can be
59 applied;
60- The second part is to check whether further validation process is
61 necessary.
62
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -080063When a packet is presented for validation, the validator will check the rules one-by-one
64in the configuration file using **for** and **filter** conditions against the packet,
65until finding a rule for which the packet qualifies. After that, the **checker**
66conditions of the matched rule will be used to check the validity of the packet. If the
67packet does not match any rules, it is treated as an invalid packet. Once a packet has
68been matched by a rule, the remaining rules are not applied to the packet (i.e., the
69matched rule "captures" the packet). Therefore, you should always put the most specific
70rule first.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -070071
Yingdi Yu4e99f532014-08-25 19:40:57 -070072In the example configuration, the first rule indicates that all the data packets under the
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -080073name prefix ``/localhost/example`` must be signed by a certificate whose name (the key
Alexander Afanasyevc381bca2017-10-15 14:51:49 -040074part) is ``/ndn/edu/ucla/yingdi/KEY/1234``. If a packet does not have a name under
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -080075prefix ``/localhost/example``, the validator will skip the first rule and apply the second
76rule. The second rule indicates that all other data packets must be validated using the
77hierarchical policy (data name should be prefix or equal to the identity part of the
78certificate name). The example configuration defines that all certificate chains must be
79rooted in the certificate defined in the file "testbed-trust-anchor.cert".
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -070080
81Rules in general
82----------------
83
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -080084A rule has four properties: **id**, **for**, **filter**, and **checker**.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -070085
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -080086The **id** property uniquely identifies the rule in the configuration file. As long as
Yingdi Yu4e99f532014-08-25 19:40:57 -070087being unique, any name can be given to a rule, e.g., "Simple Rule", "Testbed Validation
88Rule". A rule must have one and only one **id** property.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -070089
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -080090A rule is either used to validate a data packet or an interest packet. This information
91is specified in the **for** property, which can be either **data** or **interest**. A
92rule must have exactly one **for** property.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -070093
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -080094The **filter** property further constrains the packets that can be checked by the
95rule. The filter property is not required in a rule; if omitted, the rule will capture all
96packets passed to it. A rule may contain multiple filters, in this case, a packet
97is captured by the rule only if all filters are satisfied.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -070098
Davide Pesavento933a5672020-07-03 22:32:43 -040099.. attention:: **A packet that satisfies all the filters may not be valid.**
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700100
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800101The **checker** property defines the conditions that a matched packet must fulfill to be
Zhiyi Zhang044bb7e2016-06-10 00:02:37 -0700102treated as a valid packet. A rule must have at least one **checker** property. A packet is
103treated as valid if it can pass at least one of the checkers and as invalid when it cannot
104pass any checkers.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700105
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700106Filter Property
107---------------
108
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800109Filter has a **type** property and type-specific properties. Although a rule can contain
110more than one filters, there can be at most one filter of each type.
111
112Currently, only the packet name filter is defined.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700113
114Name Filter
115~~~~~~~~~~~
116
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800117There are two ways to express the conditions on packet name:
118
119- relationship between the packet name and the specified name
120- :doc:`NDN regular expression <utils-ndn-regex>` match.
121
122Name and Relation
123^^^^^^^^^^^^^^^^^
124
125In the first case, two more properties are required: **name** and **relation**. A packet
126can fulfill the condition if the **name** has a **relation** to the packet's name. Three
127types of **relation** has been defined: **equal**, **is-prefix-of**,
128**is-strict-prefix-of**. For example, the filter
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700129
130::
131
132 filter
133 {
134 type name
135 name /localhost/example
136 relation equal
137 }
138
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800139will capture only a packet with the exact name ``/localhost/example``.
140
141The filter
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700142
143::
144
145 filter
146 {
147 type name
148 name /localhost/example
149 relation is-prefix-of
150 }
151
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800152will capture a packet with name ``/localhost/example`` or ``/localhost/example/data``, but
153will not capture a packet with name ``/localhost/another_example``. And the filter
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700154
155::
156
157 filter
158 {
159 type name
160 name /localhost/example
161 relation is-strict-prefix-of
162 }
163
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800164will capture a packet with name ``/localhost/example/data``, but will not capture a packet
Yingdi Yu4e99f532014-08-25 19:40:57 -0700165with name ``/localhost/example``.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700166
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800167NDN Regular Expression Match
168^^^^^^^^^^^^^^^^^^^^^^^^^^^^
169
Yingdi Yu4e99f532014-08-25 19:40:57 -0700170The second way is to specify an :doc:`utils-ndn-regex` that can match the packet. In this
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800171case, only one property **regex** is required. For example, the filter
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700172
173::
174
175 filter
176 {
177 type name
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800178 regex ^<>*<KEY><><><>$
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700179 }
180
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800181will capture all certificates.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700182
183Checker Property
184----------------
185
Yingdi Yu4e99f532014-08-25 19:40:57 -0700186Passing all the filters in a rule only indicates that a packet can be checked using the
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800187rule, and it does not necessarily imply that the packet is valid. The validity of a
Yingdi Yu4e99f532014-08-25 19:40:57 -0700188packet is determined by the property **checker**, which defines the conditions that a
189valid packet must fulfill.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700190
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800191Same as **filter**, **checker** has a property **type**. We have defined two types of
192checkers:
193
194- **customized** is a checker that allows customization of the conditions according to specific
195 requirements;
196
197- **hierarchical** is a checker with pre-defined hierarchical trust model.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700198
199Customized Checker
200~~~~~~~~~~~~~~~~~~
201
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800202The customized checker requires two properties: **sig-type**, **key-locator**. Both must
203appear exactly once and are related to the ``SignatureInfo`` of a packet.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700204
205::
206
207 checker
208 {
209 type customized
210 sig-type ...
211 key-locator
212 {
213 ...
214 }
215 }
216
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800217The property **sig-type** specifies the acceptable signature type and can be
218**rsa-sha256**, **ecdsa-sha256** (strong signature types), or **sha256** (weak signature
219type). If sig-type is sha256, **key-locator** is ignored, and the validator will simply
220calculate the digest of a packet and compare it with the one in ``SignatureValue``. If
221sig-type is rsa-sha256 or ecdsa-sha256, you have to further customize the checker with
222**key-locator**.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700223
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800224The property **key-locator** specifies the conditions on ``KeyLocator``. If the
Yingdi Yu4e99f532014-08-25 19:40:57 -0700225**key-locator** property is specified, it requires the existence of the ``KeyLocator``
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800226field in ``SignatureInfo``. **key-locator** property only supports one type: **name**:
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700227
228::
229
230 key-locator
231 {
232 type name
233 ...
234 }
235
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800236This key-locator property specifies the conditions on the certificate name of the signing
237key. Since the conditions are about name, they can be specified in the same way as the
238name filter. For example, a checker can be:
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700239
240::
241
242 checker
243 {
244 type customized
245 sig-type rsa-sha256
246 key-locator
247 {
248 type name
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400249 name /ndn/edu/ucla/yingdi/KEY/1234
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700250 relation equal
251 }
252 }
253
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800254This checker property requires that the packet must have a ``rsa-sha256`` signature that
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400255can be verified with ``/ndn/edu/ucla/yingdi/KEY/1234`` key.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700256
Yingdi Yu4e99f532014-08-25 19:40:57 -0700257Besides the two ways to express conditions on the ``KeyLocator`` name (name and regex),
258you can further constrain the ``KeyLocator`` name using the information extracted from the
259packet name. This third type of condition is expressed via a property
260**hyper-relation**. The **hyper-relation** property consists of three parts:
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700261
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800262- an NDN regular expression that extracts information from the packet name
263- an NDN regular expression that extracts information from the ``KeyLocator`` name
264- relation from the part extracted from the ``KeyLocator`` name to the one extracted from
265 the packet name
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700266
267For example, a checker:
268
269::
270
271 checker
272 {
273 type customized
274 sig-type rsa-sha256
275 key-locator
276 {
277 type name
278 hyper-relation
279 {
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800280 k-regex ^(<>*)<KEY><>$
281 k-expand \\1
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700282 h-relation is-prefix-of
283 p-regex ^(<>*)$
284 p-expand \\1
285
286 }
287 }
288 }
289
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800290requires the packet name must be under the corresponding namespace (identity part) of the
291``KeyLocator`` name.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700292
293Hierarchical Checker
294~~~~~~~~~~~~~~~~~~~~
295
Yingdi Yu4e99f532014-08-25 19:40:57 -0700296As implied by its name, hierarchical checker requires that the packet name must be under
297the namespace of the packet signer. A hierarchical checker:
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700298
299::
300
301 checker
302 {
303 type hierarchical
304 sig-type rsa-sha256
305 }
306
307is equivalent to a customized checker:
308
309::
310
311 checker
312 {
313 type customized
314 sig-type rsa-sha256
315 key-locator
316 {
317 type name
318 hyper-relation
319 {
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800320 k-regex ^(<>*)<KEY><>$
321 k-expand \\1
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700322 h-relation is-prefix-of
323 p-regex ^(<>*)$
324 p-expand \\1
325 }
326 }
327 }
328
Alexander Afanasyevd36dd552014-06-30 12:42:46 -0700329.. _validator-conf-trust-anchors:
330
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700331Trust Anchors
332-------------
333
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800334**trust-anchor** is a necessary option in order to properly validate packets. A
335configuration file may contain more than one trust anchors and the order of trust anchors
336does not matter. The structure of trust-anchor is as follows:
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700337
338::
339
340 trust-anchor
341 {
342 type file
343 file-name "trusted-signer.cert"
344 }
345 trust-anchor
346 {
347 type base64
348 base64-string "Bv0DGwdG...amHFvHIMDw=="
349 }
350
Yingdi Yu4e99f532014-08-25 19:40:57 -0700351You may also specify a trust-anchor directory. All certificates under this directory are
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800352taken as static trust anchors. For example, if all trust anchors are put into
Yingdi Yu4e99f532014-08-25 19:40:57 -0700353``/usr/local/etc/ndn/keys``.
Yingdi Yub4650652014-04-17 10:19:59 -0700354
355::
356
357 trust-anchor
358 {
359 type dir
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800360 dir /usr/local/etc/ndn/keys
Yingdi Yub4650652014-04-17 10:19:59 -0700361 }
362
Yingdi Yu4e99f532014-08-25 19:40:57 -0700363If certificates under the directory might be changed during runtime, you can set a refresh
364period, such as
Yingdi Yub4650652014-04-17 10:19:59 -0700365
366::
367
368 trust-anchor
369 {
370 type dir
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800371 dir /usr/local/etc/ndn/keys
Yingdi Yub4650652014-04-17 10:19:59 -0700372 refresh 1h ; refresh certificates every hour, other units include m (for minutes) and s (for seconds)
373 }
374
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800375There is also a special trust anchor **any**. As long as such a trust-anchor is defined
Yingdi Yu4e99f532014-08-25 19:40:57 -0700376in config file, packet validation will be turned off.
Yingdi Yu44d190c2014-04-16 17:05:46 -0700377
Davide Pesavento933a5672020-07-03 22:32:43 -0400378.. danger::
379 This type of trust anchor is dangerous. You should used it only when you
380 want to disable packet validation temporarily (e.g., debugging code, building a demo).
Yingdi Yu44d190c2014-04-16 17:05:46 -0700381
382::
383
384 trust-anchor
385 {
386 type any
387 }
388
Yingdi Yub4650652014-04-17 10:19:59 -0700389
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700390Example Configuration For NLSR
391------------------------------
392
Yingdi Yu4e99f532014-08-25 19:40:57 -0700393The trust model of NLSR is semi-hierarchical. An example certificate signing hierarchy is:
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700394
395::
396
397 root
398 |
399 +--------------+---------------+
400 site1 site2
401 | |
402 +---------+---------+ +
403 operator1 operator2 operator3
404 | | |
405 +-----+-----+ +----+-----+ +-----+-----+--------+
406 router1 router2 router3 router4 router5 router6 router7
407 | | | | | | |
408 + + + + + + +
409 NLSR NSLR NSLR NSLR NSLR NSLR NSLR
410
411However, entities name may not follow the signing hierarchy, for
412example:
413
Alexander Afanasyev3aeeaeb2014-04-22 23:34:23 -0700414+------------+-------------------------------------------------------------------------------------+
415| Entity | Identity name and examples |
416+============+=====================================================================================+
417| root | ``/<network>`` |
418| | |
419| | Identity example: ``/ndn`` |
420| | |
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400421| | Certificate name example: ``/ndn/KEY/1/%00/%01`` |
Alexander Afanasyev3aeeaeb2014-04-22 23:34:23 -0700422+------------+-------------------------------------------------------------------------------------+
423| site | ``/<network>/<site>`` |
424| | |
425| | Identity example: ``/ndn/edu/ucla`` |
426| | |
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400427| | Certificate name example: ``/ndn/edu/ucla/KEY/2/%00/%01`` |
Alexander Afanasyev3aeeaeb2014-04-22 23:34:23 -0700428+------------+-------------------------------------------------------------------------------------+
429| operator | ``/<network>/<site>/%C1.O.N./<operator-id>`` |
430| | |
431| | Identity example: ``/ndn/edu/ucla/%C1.O.N./op1`` |
432| | |
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400433| | Certificate name example: ``/ndn/edu/ucla/%C1.O.N./op1/KEY/3/%00/%01`` |
Alexander Afanasyev3aeeaeb2014-04-22 23:34:23 -0700434+------------+-------------------------------------------------------------------------------------+
435| router | ``/<network>/<site>/%C1.O.R./<router-id>`` |
436| | |
437| | Identity example: ``/ndn/edu/ucla/%C1.O.R./rt1`` |
438| | |
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400439| | Certificate name example: ``/ndn/edu/ucla/%C1.O.R./rt1/KEY/4/%00/%01`` |
Alexander Afanasyev3aeeaeb2014-04-22 23:34:23 -0700440+------------+-------------------------------------------------------------------------------------+
441| NLSR | ``/<network>/<site>/%C1.O.R./<router-id>/NLSR`` |
442| | |
443| | Identity example: ``/ndn/edu/ucla/%C1.O.R./rt1/NLSR`` |
444| | |
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400445| | Certificate name example: ``/ndn/edu/ucla/%C1.O.R./rt1/NLSR/KEY/5/%00/%01`` |
Alexander Afanasyev3aeeaeb2014-04-22 23:34:23 -0700446+------------+-------------------------------------------------------------------------------------+
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700447
448Assume that a typical NLSR data name is
Yingdi Yu4e99f532014-08-25 19:40:57 -0700449``/ndn/edu/ucla/%C1.O.R./rt1/NLSR/LSA/LSType.1/%01``. Then, the exception of naming
450hierarchy is "operator-router". So we can write a configuration file with three rules. The
451first one is a customized rule that capture the normal NLSR data. The second one is a
452customized rule that handles the exception case of the hierarchy (operator->router). And
453the last one is a hierarchical rule that handles the normal cases of the hierarchy.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700454
Yingdi Yu4e99f532014-08-25 19:40:57 -0700455We put the NLSR data rule to the first place, because NLSR data packets are the most
456frequently checked. The hierarchical exception rule is put to the second, because it is
457more specific than the last one.
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700458
459And here is the configuration file:
460
461::
462
463 rule
464 {
465 id "NSLR LSA Rule"
466 for data
467 filter
468 {
469 type name
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400470 regex ^<>*<NLSR><LSA><><>$
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700471 }
472 checker
473 {
474 type customized
475 sig-type rsa-sha256
476 key-locator
477 {
478 type name
479 hyper-relation
480 {
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400481 k-regex ^(<>*)<KEY><>$
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700482 k-expand \\1
483 h-relation equal
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400484 p-regex ^(<>*)<NLSR><LSA><><>$
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700485 p-expand \\1
486 }
487 }
488 }
489 }
490 rule
491 {
492 id "NSLR Hierarchy Exception Rule"
493 for data
494 filter
495 {
496 type name
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400497 regex ^<>*<%C1.O.R.><><KEY><><><>$
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700498 }
499 checker
500 {
501 type customized
502 sig-type rsa-sha256
503 key-locator
504 {
505 type name
506 hyper-relation
507 {
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400508 k-regex ^(<>*)<%C1.O.N.><><KEY><>$
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700509 k-expand \\1
510 h-relation equal
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400511 p-regex ^(<>*)<%C1.O.R.><><KEY><><><>$
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700512 p-expand \\1
513 }
514 }
515 }
516 }
517 rule
518 {
519 id "NSLR Hierarchical Rule"
520 for data
521 filter
522 {
523 type name
Alexander Afanasyevc381bca2017-10-15 14:51:49 -0400524 regex ^<>*<KEY><><><>$
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700525 }
526 checker
527 {
528 type hierarchical
529 sig-type rsa-sha256
530 }
531 }
532 trust-anchor
533 {
534 type file
535 file-name "testbed-trust-anchor.cert"
536 }
537
Yingdi Yu4e99f532014-08-25 19:40:57 -0700538Example Configuration For NFD RIB Management
539--------------------------------------------
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700540
Davide Pesavento0530b5b2016-11-07 03:23:58 +0100541Assume `NFD RIB Management <https://redmine.named-data.net/projects/nfd/wiki/RibMgmt>`_
Yingdi Yu4e99f532014-08-25 19:40:57 -0700542allows any valid testbed certificate to register prefix, the configuration file could be
543written as:
Alexander Afanasyev7c6aeb02014-04-10 19:59:19 -0700544
545::
546
Alexander Afanasyeve5a19b82017-01-30 22:30:46 -0800547 rule
548 {
549 id "RIB Prefix Registration Command Rule"
550 for interest ; rule for Interests (to validate CommandInterests)
551 filter
552 {
553 type name ; condition on interest name (w/o signature)
554 regex ^[<localhop><localhost>]<nfd><rib>[<register><unregister>]<><><>$ ; prefix before
555 ; SigInfo & SigValue
556 }
557 checker
558 {
559 type customized
560 sig-type rsa-sha256 ; interest must have a rsa-sha256 signature
561 key-locator
562 {
563 type name ; key locator must be the certificate name of the
564 ; signing key
565 regex ^<>*<KEY><><><>$
566 }
567 }
568 checker
569 {
570 type customized
571 sig-type ecdsa-sha256 ; interest must have a ecdsa-sha256 signature
572 key-locator
573 {
574 type name ; key locator must be the certificate name of the
575 ; signing key
576 regex ^<>*<KEY><><><>$
577 }
578 }
579 }
580 rule
581 {
582 id "NDN Testbed Hierarchy Rule"
583 for data ; rule for Data (to validate NDN certificates)
584 filter
585 {
586 type name ; condition on data name
587 regex ^<>*<KEY><><><>$
588 }
589 checker
590 {
591 type hierarchical ; the certificate name of the signing key and
592 ; the data name must follow the hierarchical model
593 sig-type rsa-sha256 ; data must have a rsa-sha256 signature
594 }
595 checker
596 {
597 type hierarchical ; the certificate name of the signing key and
598 ; the data name must follow the hierarchical model
599 sig-type ecdsa-sha256 ; data must have a ecdsa-sha256 signature
600 }
601 }
602 trust-anchor
603 {
604 type file
605 file-name keys/ndn-testbed-root.ndncert.base64
606 }