CommandValidatorConf » History » Version 51
Yingdi Yu, 06/13/2014 11:06 AM
1 | 3 | Yingdi Yu | # Validator Configuration File Format |
---|---|---|---|
2 | 1 | Yingdi Yu | |
3 | 3 | Yingdi Yu | You can set up a `Validator` via a configuration file. |
4 | Next, we will show you how to write a configuration file. |
||
5 | 1 | Yingdi Yu | |
6 | 32 | Yingdi Yu | The configuration file consists of **rules** and **trust-anchors** that will be used in validation. |
7 | **Rules** tell the validator how to validate a packet, while **trust-anchors** tell the validator which certificates are valid immediately. |
||
8 | 4 | Yingdi Yu | Here is an example of configuration file containing two rules. |
9 | 3 | Yingdi Yu | |
10 | rule |
||
11 | 1 | Yingdi Yu | { |
12 | 9 | Yingdi Yu | id "Simple Rule" |
13 | 3 | Yingdi Yu | for data |
14 | 9 | Yingdi Yu | filter |
15 | 3 | Yingdi Yu | { |
16 | 6 | Yingdi Yu | type name |
17 | 22 | Yingdi Yu | name /localhost/example |
18 | 48 | Yingdi Yu | relation is-prefix-of |
19 | 3 | Yingdi Yu | } |
20 | 26 | Yingdi Yu | checker |
21 | 1 | Yingdi Yu | { |
22 | 27 | Yingdi Yu | type customized |
23 | 14 | Yingdi Yu | sig-type rsa-sha256 |
24 | key-locator |
||
25 | { |
||
26 | type name |
||
27 | 22 | Yingdi Yu | name /ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT |
28 | 14 | Yingdi Yu | relation equal |
29 | } |
||
30 | 6 | Yingdi Yu | } |
31 | 1 | Yingdi Yu | } |
32 | rule |
||
33 | { |
||
34 | 9 | Yingdi Yu | id "Testbed Validation Rule" |
35 | 1 | Yingdi Yu | for data |
36 | checker |
||
37 | 27 | Yingdi Yu | { |
38 | 1 | Yingdi Yu | type hierarchical |
39 | sig-type rsa-sha256 |
||
40 | } |
||
41 | 27 | Yingdi Yu | } |
42 | 32 | Yingdi Yu | trust-anchor |
43 | { |
||
44 | type file |
||
45 | file-name "testbed-trust-anchor.cert" |
||
46 | } |
||
47 | 1 | Yingdi Yu | |
48 | 29 | Yingdi Yu | * <font color='red'>**ATTENTION: The order of rules MATTERS!**</font> |
49 | 10 | Yingdi Yu | |
50 | 1 | Yingdi Yu | A rule can be broken into two parts: |
51 | |||
52 | 9 | Yingdi Yu | * The first part is to qualify packets to which the rule can be applied; |
53 | 27 | Yingdi Yu | * The second part is to check whether further validation process is necessary. |
54 | 1 | Yingdi Yu | |
55 | 27 | Yingdi Yu | When receiving a packet, the validator will apply rules in the configuration file one-by-one against the packet, |
56 | until finding a rule that the packet qualifies for. |
||
57 | And the second part of the matched rule will be used to check the validity of the packet. |
||
58 | 1 | Yingdi Yu | If the packet cannot qualify for any rules, it is treated as an invalid packet. |
59 | Once a packet has been matched by a rule, the rest rules will not be applied against the packet. |
||
60 | 27 | Yingdi Yu | Therefore, you should always put the most specific rule to the top, otherwise it will become useless. |
61 | 1 | Yingdi Yu | |
62 | In the example configuration, |
||
63 | the first rule indicates that all the data packets under the name prefix "/localhost/example" must be signed by a key whose certificate name is "/ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT". |
||
64 | If a packet does not have a name under prefix "/localhost/example", validator will skip the first rule and apply the second rule. |
||
65 | 32 | Yingdi Yu | The second rule indicates that any data packets must be validated along a hierarchy. |
66 | And a certificate stored in a file "testbed-trust-anchor.cert" is valid. |
||
67 | 27 | Yingdi Yu | |
68 | 11 | Yingdi Yu | ## Rules in general |
69 | 1 | Yingdi Yu | |
70 | 29 | Yingdi Yu | A rule has four types of properties: **id**, **for**, **filter**, and **checker**. |
71 | 1 | Yingdi Yu | |
72 | 27 | Yingdi Yu | The property **id** uniquely identifies the rule in the configuration file. |
73 | 11 | Yingdi Yu | As long as being unique, any name can be given to a rule, e.g., "Simple Rule", "Testbed Validation Rule". |
74 | 29 | Yingdi Yu | A rule must have one and only one **id** property. |
75 | 1 | Yingdi Yu | |
76 | 27 | Yingdi Yu | A rule is either used to validate an interest packet or a data packet. |
77 | 1 | Yingdi Yu | This information is specified in the property **for**. |
78 | Only two value can be specified: **data** and **interest**. |
||
79 | 29 | Yingdi Yu | A rule must have one and only one **for** property. |
80 | 1 | Yingdi Yu | |
81 | 51 | Yingdi Yu | * <font color='red'>**ATTENTION: For [signed interest](http://redmine.named-data.net/projects/nfd/wiki/Signed_Interests), rules should cover the prefix before the ``timestamp``**</font>. |
82 | |||
83 | 1 | Yingdi Yu | The property **filter** further constrains the packets that can be checked by the rule. |
84 | 29 | Yingdi Yu | Filter property is not required in a rule, in this case, the rule will capture all the packets passed to it. |
85 | A rule may contain more than one filters, in this case, a packet can be checked by a rule only if the packet satisfies all the filters. |
||
86 | 27 | Yingdi Yu | |
87 | 29 | Yingdi Yu | * <font color='red'>**ATTENTION: A packet that satisfies all the filters may not be valid**</font>. |
88 | 1 | Yingdi Yu | |
89 | 29 | Yingdi Yu | The property **checker** defines the conditions that a matched packet must fulfill to be treated as a valid packet. |
90 | 44 | Yingdi Yu | A rule must have at least one **checker** property, a packet is treated as invalid if it cannot pass none of the checkers. |
91 | 29 | Yingdi Yu | |
92 | 27 | Yingdi Yu | **filter** and **checker** have their own properties. |
93 | 29 | Yingdi Yu | Next, we will introduce them separately. |
94 | 12 | Yingdi Yu | |
95 | 27 | Yingdi Yu | ## Filter Property |
96 | 12 | Yingdi Yu | |
97 | 29 | Yingdi Yu | Filter has its own **type** property. |
98 | 13 | Yingdi Yu | Although a rule may contain more than one filters, there is at most one filter of each type. |
99 | 29 | Yingdi Yu | So far, only one type of filter is defined: **name**. |
100 | 27 | Yingdi Yu | In other word, only one filter can be specified in a rule for now. |
101 | 1 | Yingdi Yu | |
102 | 28 | Yingdi Yu | ### Name Filter |
103 | |||
104 | 27 | Yingdi Yu | There are two ways to express the conditions on name. |
105 | 21 | Yingdi Yu | The first way is to specify a relationship between the packet name and a particular name. |
106 | 7 | Yingdi Yu | In this case, two more properties are required: **name** and **relation**. |
107 | 27 | Yingdi Yu | A packet can fulfill the condition if the **name** has a **relation* to the packet name. |
108 | 48 | Yingdi Yu | Three types of **relation** has been defined: **equal**, **is-prefix-of**, **is-strict-prefix-of**. |
109 | 1 | Yingdi Yu | For example, a filter |
110 | 22 | Yingdi Yu | |
111 | 21 | Yingdi Yu | filter |
112 | 1 | Yingdi Yu | { |
113 | type name |
||
114 | name /localhost/example |
||
115 | relation equal |
||
116 | } |
||
117 | 21 | Yingdi Yu | |
118 | 27 | Yingdi Yu | shall only capture a packet with the exact name "/localhost/example". |
119 | 21 | Yingdi Yu | And a filter |
120 | 22 | Yingdi Yu | |
121 | 21 | Yingdi Yu | filter |
122 | { |
||
123 | 1 | Yingdi Yu | type name |
124 | 21 | Yingdi Yu | name /localhost/example |
125 | 48 | Yingdi Yu | relation is-prefix-of |
126 | 21 | Yingdi Yu | } |
127 | 1 | Yingdi Yu | |
128 | 27 | Yingdi Yu | shall capture a packet with name "/localhost/example" or "/localhost/example/data", but cannot catch a packet with name "/localhost/another_example". |
129 | 1 | Yingdi Yu | And a filter |
130 | 22 | Yingdi Yu | |
131 | 21 | Yingdi Yu | filter |
132 | 8 | Yingdi Yu | { |
133 | 7 | Yingdi Yu | type name |
134 | 21 | Yingdi Yu | name /localhost/example |
135 | 48 | Yingdi Yu | relation is-strict-prefix-of |
136 | 21 | Yingdi Yu | } |
137 | 7 | Yingdi Yu | |
138 | 27 | Yingdi Yu | shall capture a packet with name "/localhost/example/data", but cannot catch a packet with name "/localhost/example". |
139 | 1 | Yingdi Yu | |
140 | The second way is to specify an [[Regex|NDN Regular Expression]] that can match the packet. |
||
141 | In this case, only one property **regex** is required. |
||
142 | For example, a filter |
||
143 | |||
144 | filter |
||
145 | { |
||
146 | type name |
||
147 | regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$ |
||
148 | } |
||
149 | |||
150 | shall capture all the identity certificates. |
||
151 | |||
152 | ## Checker Property |
||
153 | |||
154 | 29 | Yingdi Yu | Passing all the filters in a rule only indicates that a packet can be checked using the rule, |
155 | and it does not necessarily implies that the packet is valid. |
||
156 | 1 | Yingdi Yu | The validity of a packet is determined by the property **checker**, which defines the conditions that a valid packet must fulfill. |
157 | |||
158 | 29 | Yingdi Yu | Same as **filter**, **checker** has a property **type**. |
159 | 37 | Yingdi Yu | We have defined three types of checkers: **customized**, and **hierarchical**, and **fixed-signer**. |
160 | 29 | Yingdi Yu | As suggested by its name, **customized** checker allows you to customize the conditions according to specific requirements. |
161 | 37 | Yingdi Yu | **hierarchical** checker and **fixed-signer** checker are pre-defined shortcuts, which specify specific trust models separately. |
162 | 1 | Yingdi Yu | |
163 | 29 | Yingdi Yu | ### Customized Checker |
164 | |||
165 | 32 | Yingdi Yu | So far, we only allow three customized properties in a customized checker: **sig-type**, **key-locator**. |
166 | 29 | Yingdi Yu | All of them are related to the `SignatureInfo` of a packet. |
167 | |||
168 | 1 | Yingdi Yu | checker |
169 | 29 | Yingdi Yu | { |
170 | type customized |
||
171 | sig-type ... |
||
172 | key-locator |
||
173 | { |
||
174 | ... |
||
175 | } |
||
176 | } |
||
177 | |||
178 | The property **sig-type** specifies the acceptable signature type. |
||
179 | Right now two signature types have been defined: **rsa-sha256** (which is a strong signature type) and **sha256** (which is a weak signature type). |
||
180 | 32 | Yingdi Yu | If sig-type is sha256, then **key-locator** will be ignored. |
181 | 29 | Yingdi Yu | Validator will simply calculate the digest of a packet and compare it with the one in `SignatureValue`. |
182 | 32 | Yingdi Yu | If sig-type is rsa-sha256, you have to further customize the checker with **key-locator**. |
183 | 29 | Yingdi Yu | |
184 | The property **key-locator** which specifies the conditions on `KeyLocator`. |
||
185 | If the **key-locator** property is specified, it requires the existence of the `KeyLocator` field in `SignatureInfo`. |
||
186 | Although there are more than one types of `KeyLocator` defined in the [Packet Format](http://named-data.net/doc/ndn-tlv/signature.html), |
||
187 | **key-locator** property only supports one type: **name**: |
||
188 | |||
189 | key-locator |
||
190 | { |
||
191 | type name |
||
192 | ... |
||
193 | } |
||
194 | |||
195 | Such a key-locator property specifies the conditions on the certificate name of the signing key. |
||
196 | Since the conditions are about name, they can be specified in the same way as the name filter. |
||
197 | 1 | Yingdi Yu | For example, a checker could be: |
198 | |||
199 | checker |
||
200 | 21 | Yingdi Yu | { |
201 | 29 | Yingdi Yu | type customized |
202 | 21 | Yingdi Yu | sig-type rsa-sha256 |
203 | key-locator |
||
204 | { |
||
205 | type name |
||
206 | 1 | Yingdi Yu | name /ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT |
207 | relation equal |
||
208 | } |
||
209 | 15 | Yingdi Yu | } |
210 | |||
211 | This checker property requires that the packet must have a rsa-sha256 signature generated by a key whose certificate name is "/ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT". |
||
212 | 1 | Yingdi Yu | |
213 | 29 | Yingdi Yu | Besides the two ways to express conditions on the `KeyLocator` name (name and regex), |
214 | you can further constrain the `KeyLocator` name using the information extracted from the packet name. |
||
215 | 15 | Yingdi Yu | This third type of condition is expressed via a property **hyper-relation**. |
216 | 21 | Yingdi Yu | The **hyper-relation** property consists of three parts: |
217 | 1 | Yingdi Yu | |
218 | 21 | Yingdi Yu | * an NDN regular expression that can extract information from packet name |
219 | 29 | Yingdi Yu | * an NDN regular expression that can extract information from `KeyLocator` name |
220 | * relation from the part extracted from `KeyLocator` name to the one extracted from the packet name |
||
221 | 22 | Yingdi Yu | |
222 | For example, a checker: |
||
223 | 21 | Yingdi Yu | |
224 | checker |
||
225 | 1 | Yingdi Yu | { |
226 | 29 | Yingdi Yu | type customized |
227 | 15 | Yingdi Yu | sig-type rsa-sha256 |
228 | 6 | Yingdi Yu | key-locator |
229 | 1 | Yingdi Yu | { |
230 | type name |
||
231 | hyper-relation |
||
232 | { |
||
233 | k-regex ^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$ |
||
234 | 41 | Yingdi Yu | k-expand \\1\\2 |
235 | 48 | Yingdi Yu | h-relation is-prefix-of |
236 | 29 | Yingdi Yu | p-regex ^(<>*)$ |
237 | 41 | Yingdi Yu | p-expand \\1 |
238 | 29 | Yingdi Yu | |
239 | 1 | Yingdi Yu | } |
240 | } |
||
241 | } |
||
242 | |||
243 | 29 | Yingdi Yu | requires the packet name must be under the corresponding namespace of the `KeyLocator` name. |
244 | 1 | Yingdi Yu | |
245 | 32 | Yingdi Yu | In some cases, you can even customize checker with another property |
246 | 29 | Yingdi Yu | For example: |
247 | 1 | Yingdi Yu | |
248 | checker |
||
249 | { |
||
250 | 29 | Yingdi Yu | type customized |
251 | 1 | Yingdi Yu | sig-type rsa-sha256 |
252 | key-locator |
||
253 | { |
||
254 | 29 | Yingdi Yu | type name |
255 | 1 | Yingdi Yu | hyper-relation |
256 | { |
||
257 | k-regex ^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$ |
||
258 | 41 | Yingdi Yu | k-expand \\1\\2 |
259 | 48 | Yingdi Yu | h-relation is-prefix-of |
260 | 1 | Yingdi Yu | p-regex ^(<>*)$ |
261 | 41 | Yingdi Yu | p-expand \\1 |
262 | 1 | Yingdi Yu | } |
263 | 29 | Yingdi Yu | } |
264 | } |
||
265 | 16 | Yingdi Yu | |
266 | 29 | Yingdi Yu | ### Hierarchical Checker |
267 | |||
268 | As implied by its name, hierarchical checker requires that the packet name must be under the namespace of the packet signer. |
||
269 | 32 | Yingdi Yu | A hierarchical checker: |
270 | 29 | Yingdi Yu | |
271 | 37 | Yingdi Yu | checker |
272 | 29 | Yingdi Yu | { |
273 | type hierarchical |
||
274 | sig-type rsa-sha256 |
||
275 | } |
||
276 | 1 | Yingdi Yu | |
277 | 32 | Yingdi Yu | is equivalent to a customized checker: |
278 | 1 | Yingdi Yu | |
279 | 29 | Yingdi Yu | checker |
280 | 1 | Yingdi Yu | { |
281 | 26 | Yingdi Yu | type customized |
282 | 29 | Yingdi Yu | sig-type rsa-sha256 |
283 | key-locator |
||
284 | 1 | Yingdi Yu | { |
285 | 21 | Yingdi Yu | type name |
286 | 29 | Yingdi Yu | hyper-relation |
287 | 22 | Yingdi Yu | { |
288 | 29 | Yingdi Yu | k-regex ^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$ |
289 | 42 | Yingdi Yu | k-expand \\1\\2 |
290 | 48 | Yingdi Yu | h-relation is-prefix-of |
291 | 29 | Yingdi Yu | p-regex ^(<>*)$ |
292 | 42 | Yingdi Yu | p-expand \\1 |
293 | 29 | Yingdi Yu | } |
294 | 33 | Yingdi Yu | } |
295 | 29 | Yingdi Yu | } |
296 | |||
297 | 37 | Yingdi Yu | ### Fixed-Signer Checker |
298 | 29 | Yingdi Yu | |
299 | In some cases, you only accept packets signed with pre-trusted certificates, i.e. "one-step validation". |
||
300 | 37 | Yingdi Yu | Such a trust model can be expressed with **fixed-signer** checker. |
301 | 39 | Yingdi Yu | And you only need to specify the trusted certificate via property **signer**. |
302 | The definition of **signer** is the same as **trust-anchor**. |
||
303 | 29 | Yingdi Yu | For example: |
304 | |||
305 | 36 | Yingdi Yu | checker |
306 | 29 | Yingdi Yu | { |
307 | 1 | Yingdi Yu | type fixed-signer |
308 | sig-type rsa-sha256 |
||
309 | 39 | Yingdi Yu | signer |
310 | { |
||
311 | type file |
||
312 | file-name "trusted-signer.cert" |
||
313 | } |
||
314 | signer |
||
315 | { |
||
316 | 40 | Yingdi Yu | type base64 |
317 | base64-string "Bv0DGwdG...amHFvHIMDw==" |
||
318 | 39 | Yingdi Yu | } |
319 | 29 | Yingdi Yu | } |
320 | |||
321 | 32 | Yingdi Yu | ## Trust Anchors |
322 | |||
323 | 45 | Yingdi Yu | Although **trust-anchor** is always not required in the configuration file (for example, if fixed-signer checker is used), |
324 | it is very common to have a few trust-anchors in the configuration file, otherwise most packets cannot be validated. |
||
325 | 1 | Yingdi Yu | A configuration file may contain more than one trust anchors, but the order of trust anchors does not matter. |
326 | 45 | Yingdi Yu | The structure of trust-anchor is same as the **signer** in fixed-signer checker, for example: |
327 | |||
328 | trust-anchor |
||
329 | { |
||
330 | type file |
||
331 | file-name "trusted-signer.cert" |
||
332 | } |
||
333 | trust-anchor |
||
334 | { |
||
335 | type base64 |
||
336 | base64-string "Bv0DGwdG...amHFvHIMDw==" |
||
337 | } |
||
338 | 32 | Yingdi Yu | |
339 | 50 | Yingdi Yu | You may also specify a trust anchor directory as following: |
340 | |||
341 | trust-anchor |
||
342 | { |
||
343 | type dir |
||
344 | dir /usr/local/ndn/keys |
||
345 | } |
||
346 | |||
347 | Validator will load every file as a trust anchor from the directory. |
||
348 | If the content in the directory will change during the runtime, |
||
349 | you can specify **refresh** property to ask Validator to periodically reload trust anchors. |
||
350 | For example: |
||
351 | |||
352 | trust-anchor |
||
353 | { |
||
354 | type dir |
||
355 | dir /usr/local/ndn/keys |
||
356 | refresh 1h |
||
357 | } |
||
358 | |||
359 | indicates that validator should reload trust anchors from this directory every hour. |
||
360 | There three options of time units: `h` for hour, `m` for minutes, and `s` for seconds. |
||
361 | If the refresh period is set to `0`, then the default refresh period (`1h`) will be used. |
||
362 | If the refresh property is not specified, then trust anchors will be loaded for only one time. |
||
363 | |||
364 | 49 | Yingdi Yu | There is another special trust anchor **any**. |
365 | As long as such a trust-anchor is defined in config file, packet validation will be turned off. |
||
366 | |||
367 | <font color=red>**ATTENTION!! Such a type of trust anchor is dangerous. |
||
368 | You should used it only when you want to disable packet validation temporarily (e.g, debugging code, building a demo).**</font> |
||
369 | |||
370 | trust-anchor |
||
371 | { |
||
372 | type any |
||
373 | } |
||
374 | |||
375 | 21 | Yingdi Yu | ## Example Configuration For NLSR |
376 | 25 | Yingdi Yu | |
377 | 24 | Yingdi Yu | The trust model of NLSR is semi-hierarchical. |
378 | 17 | Yingdi Yu | An example certificate signing hierarchy is: |
379 | 1 | Yingdi Yu | |
380 | 17 | Yingdi Yu | root |
381 | | |
||
382 | +--------------+---------------+ |
||
383 | site1 site2 |
||
384 | | | |
||
385 | 1 | Yingdi Yu | +---------+---------+ + |
386 | operator1 operator2 operator3 |
||
387 | | | | |
||
388 | +-----+-----+ +----+-----+ +-----+-----+--------+ |
||
389 | router1 router2 router3 router4 router5 router6 router7 |
||
390 | | | | | | | | |
||
391 | 22 | Yingdi Yu | + + + + + + + |
392 | 17 | Yingdi Yu | NLSR NSLR NSLR NSLR NSLR NSLR NSLR |
393 | 1 | Yingdi Yu | |
394 | However, entities name may not follow the signing hierarchy, for example: |
||
395 | 17 | Yingdi Yu | |
396 | Entity | Identity Name | Example | Certificate Name Example |
||
397 | -------- | ------------------------------------------------- | ------------------------------- | ------------------------------------------------ |
||
398 | root | /\<network\> | /ndn | /ndn/KEY/ksk-1/ID-CERT/%01 |
||
399 | 22 | Yingdi Yu | site | /\<network\>/\<site\> | /ndn/edu/ucla | /ndn/edu/ucla/KEY/ksk-2/ID-CERT/%01 |
400 | 17 | Yingdi Yu | operator | /\<network\>/\<site\>/%C1.O.N./\<operator-id\> | /ndn/edu/ucla/%C1.O.N./op1 | /ndn/edu/ucla/%C1.O.N./op1/KEY/ksk-3/ID-CERT/%01 |
401 | 26 | Yingdi Yu | router | /\<network\>/\<site\>/%C1.O.R./\<router-id\> | /ndn/edu/ucla/%C1.O.R./rt1 | /ndn/edu/ucla/%C1.O.R./rt1/KEY/ksk-4/ID-CERT/%01 |
402 | 17 | Yingdi Yu | NLSR | /\<network\>/\<site\>/%C1.O.R./\<router-id\>/NLSR | /ndn/edu/ucla/%C1.O.R./rt1/NLSR | /ndn/edu/ucla/%C1.O.R./rt1/NLSR/KEY/ksk-5/ID-CERT/%01 |
403 | 1 | Yingdi Yu | |
404 | 17 | Yingdi Yu | |
405 | 1 | Yingdi Yu | Assume that a typical NLSR data name is "/ndn/edu/ucla/%C1.O.R./rt1/NLSR/LSA/LSType.1/%01". |
406 | Then, the exception of naming hierarchy is "operator-router". |
||
407 | So we can write a configuration file with three rules. |
||
408 | The first one is a customized rule that capture the normal NLSR data. |
||
409 | The second one is a customized rule that handles the exception case of the hierarchy (operator->router). |
||
410 | And the last one is a hierarchical rule that handles the normal cases of the hierarchy. |
||
411 | |||
412 | We put the NLSR data rule to the first place, because NLSR data packets are the most frequently checked. |
||
413 | 17 | Yingdi Yu | The hierarchical exception rule is put to the second, because it is more specific than the last one. |
414 | 22 | Yingdi Yu | |
415 | And here is the configuration file: |
||
416 | |||
417 | rule |
||
418 | { |
||
419 | id "NSLR LSA Rule" |
||
420 | for data |
||
421 | filter |
||
422 | 17 | Yingdi Yu | { |
423 | type name |
||
424 | regex ^[^<NLSR><LSA>]*<NLSR><LSA> |
||
425 | } |
||
426 | checker |
||
427 | { |
||
428 | 29 | Yingdi Yu | type customized |
429 | 17 | Yingdi Yu | sig-type rsa-sha256 |
430 | key-locator |
||
431 | { |
||
432 | type name |
||
433 | 23 | Yingdi Yu | hyper-relation |
434 | 17 | Yingdi Yu | { |
435 | 1 | Yingdi Yu | k-regex ^([^<KEY>]*)<KEY><ksk-.*><ID-CERT>$ |
436 | 43 | Yingdi Yu | k-expand \\1 |
437 | 1 | Yingdi Yu | h-relation equal |
438 | 29 | Yingdi Yu | p-regex ^([^<NLSR><LSA>]*)<NLSR><LSA><LSType\.\d><>$ |
439 | 43 | Yingdi Yu | p-expand \\1 |
440 | 17 | Yingdi Yu | } |
441 | 22 | Yingdi Yu | } |
442 | } |
||
443 | } |
||
444 | rule |
||
445 | { |
||
446 | id "NSLR Hierarchy Exception Rule" |
||
447 | for data |
||
448 | filter |
||
449 | 17 | Yingdi Yu | { |
450 | type name |
||
451 | regex ^[^<KEY><%C1.O.R.>]*<%C1.O.R.><><KEY><ksk-.*><ID-CERT><>$ |
||
452 | } |
||
453 | checker |
||
454 | { |
||
455 | 29 | Yingdi Yu | type customized |
456 | 17 | Yingdi Yu | sig-type rsa-sha256 |
457 | key-locator |
||
458 | { |
||
459 | 19 | Yingdi Yu | type name |
460 | 1 | Yingdi Yu | hyper-relation |
461 | 18 | Yingdi Yu | { |
462 | 1 | Yingdi Yu | k-regex ^([^<KEY><%C1.O.N.>]*)<%C1.O.N.><><KEY><ksk-.*><ID-CERT>$ |
463 | 43 | Yingdi Yu | k-expand \\1 |
464 | 35 | Yingdi Yu | h-relation equal |
465 | 29 | Yingdi Yu | p-regex ^([^<KEY><%C1.O.R.>]*)<%C1.O.R.><><KEY><ksk-.*><ID-CERT><>$ |
466 | 43 | Yingdi Yu | p-expand \\1 |
467 | 1 | Yingdi Yu | } |
468 | } |
||
469 | } |
||
470 | } |
||
471 | rule |
||
472 | { |
||
473 | id "NSLR Hierarchical Rule" |
||
474 | for data |
||
475 | 30 | Yingdi Yu | filter |
476 | 1 | Yingdi Yu | { |
477 | type name |
||
478 | 46 | Yingdi Yu | regex ^[^<KEY>]*<KEY><ksk-.*><ID-CERT><>$ |
479 | } |
||
480 | checker |
||
481 | { |
||
482 | type hierarchical |
||
483 | sig-type rsa-sha256 |
||
484 | } |
||
485 | } |
||
486 | trust-anchor |
||
487 | { |
||
488 | type file |
||
489 | file-name "testbed-trust-anchor.cert" |
||
490 | } |
||
491 | |||
492 | ## Example Configuration For NRD |
||
493 | |||
494 | Assume NRD allows any valid testbed certificate to register prefix, the configuration file could be written as: |
||
495 | |||
496 | rule |
||
497 | { |
||
498 | id "NRD Prefix Registration Command Rule" |
||
499 | for interest |
||
500 | filter |
||
501 | { |
||
502 | type name |
||
503 | regex ^<localhost><nrd>[<register><unregister><advertise><withdraw>] |
||
504 | } |
||
505 | checker |
||
506 | { |
||
507 | type customized |
||
508 | sig-type rsa-sha256 |
||
509 | key-locator |
||
510 | { |
||
511 | type name |
||
512 | 47 | Yingdi Yu | regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$ |
513 | 46 | Yingdi Yu | } |
514 | } |
||
515 | } |
||
516 | rule |
||
517 | { |
||
518 | id "Testbed Hierarchy Rule" |
||
519 | for data |
||
520 | filter |
||
521 | { |
||
522 | type name |
||
523 | regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT><>$ |
||
524 | 1 | Yingdi Yu | } |
525 | 29 | Yingdi Yu | checker |
526 | 1 | Yingdi Yu | { |
527 | 29 | Yingdi Yu | type hierarchical |
528 | 1 | Yingdi Yu | sig-type rsa-sha256 |
529 | } |
||
530 | 33 | Yingdi Yu | } |
531 | trust-anchor |
||
532 | { |
||
533 | type file |
||
534 | file-name "testbed-trust-anchor.cert" |
||
535 | 1 | Yingdi Yu | } |