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