CommandValidatorConf » History » Version 7
Yingdi Yu, 03/17/2014 05:29 PM
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 | 6 | Yingdi Yu | The configuration file consists of **rules** that will be used in validation. |
7 | 4 | Yingdi Yu | Here is an example of configuration file containing two rules. |
8 | 3 | Yingdi Yu | |
9 | rule |
||
10 | 1 | Yingdi Yu | { |
11 | 3 | Yingdi Yu | for data |
12 | name "Simple Rule" |
||
13 | 6 | Yingdi Yu | type customized |
14 | target |
||
15 | 3 | Yingdi Yu | { |
16 | 6 | Yingdi Yu | type name |
17 | name "/localhost/example" |
||
18 | 7 | Yingdi Yu | relation isPrefixOf |
19 | 3 | Yingdi Yu | } |
20 | 6 | Yingdi Yu | signer |
21 | { |
||
22 | type name |
||
23 | 7 | Yingdi Yu | name "/ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT" |
24 | relation equal |
||
25 | 6 | Yingdi Yu | } |
26 | 1 | Yingdi Yu | } |
27 | rule |
||
28 | { |
||
29 | for data |
||
30 | name "Testbed Validation Rule" |
||
31 | type hierarchical |
||
32 | trust-anchor |
||
33 | { |
||
34 | type file |
||
35 | file-name "testbed-trust-anchor.cert" |
||
36 | } |
||
37 | } |
||
38 | |||
39 | Each rule has a unique name (which should be unique in the configuration file), e.g., "Simple Rule", "Testbed Validation Rule". |
||
40 | 6 | Yingdi Yu | The rule name is specified in the property **name**. |
41 | Each rule must be specified with a usage which is specified in the property **for**. |
||
42 | The usage indicates the type of packets to which the rule should be applied, therefore, only two usages can be specified so far: **data** and **interest**. |
||
43 | The property **type** indicates how to apply the rule to packets. |
||
44 | Some rule types (such as **hierarchical**) has been defined. |
||
45 | One can also specify its own rules by set the type property to be **customized**. |
||
46 | A particular type of rules might require some other properties. |
||
47 | Next, we will introduce the other properties for the each rule type. |
||
48 | |||
49 | 1 | Yingdi Yu | ## Customized Rule |
50 | |||
51 | Two properties are required by customized rule: **target** and **signer**. |
||
52 | 7 | Yingdi Yu | And some optional properties may be configured if necessary. |
53 | |||
54 | ### Target Property |
||
55 | |||
56 | 6 | Yingdi Yu | The **target** property defines the conditions that the packet per se must satisfy, |
57 | 1 | Yingdi Yu | thus restricting the scope of packets to which the rule can be applied. |
58 | |||
59 | A packet will be checked against the **target** property of rules in the configuration file, |
||
60 | one-by-one until the first rule whose **target** property can be satisfied by the packet. |
||
61 | 7 | Yingdi Yu | Once the packet is caught by a rule, no other rules will be applied to the packet. |
62 | Therefore, <font color='red'>**the order of rules in configuration file MATTERS!**</font> |
||
63 | If the packet cannot satisfy none of the rules, it will be treated as **unvalidated** packet. |
||
64 | 1 | Yingdi Yu | |
65 | 7 | Yingdi Yu | The **target** also has a property **type** which indicates the condition type. |
66 | Two possible types are supported so far: **name** and **regex**. |
||
67 | 1 | Yingdi Yu | |
68 | 7 | Yingdi Yu | If **type** is **name**, then the **target** has two more properties: **name** and **relation**. |
69 | A packet can satisfy the condition if the **name** and the packet name can establish the **relation**. |
||
70 | The value of **relation** could be either **isPrefixOf** or **equal**. |
||
71 | For example, a target: |
||
72 | 6 | Yingdi Yu | |
73 | 7 | Yingdi Yu | target |
74 | { |
||
75 | type name |
||
76 | name "/localhost/example" |
||
77 | relation isPrefixOf |
||
78 | } |
||
79 | 1 | Yingdi Yu | |
80 | 7 | Yingdi Yu | can catch a packet with name "/localhost/example/data" but cannot catch a packet with name "/localhost/another_example". |
81 | 1 | Yingdi Yu | |
82 | 7 | Yingdi Yu | And a target |
83 | |||
84 | target |
||
85 | { |
||
86 | type name |
||
87 | name "/localhost/example" |
||
88 | relation equal |
||
89 | } |
||
90 | |||
91 | can only catch a packet with the exact name "/localhost/example". |
||
92 | |||
93 | If **type** is **regex**, then **target** must have a property **expr** and an optional property **expand**. |
||
94 | **expr** is an NDN regular expression. |
||
95 | A packet can satisfy the **target** only if the regex can match the packet name. |
||
96 | If the regex contains back references, then the **expand** property can be specified to extract certain pattern out of the packet name. |
||
97 | For example, a target |
||
98 | |||
99 | target |
||
100 | { |
||
101 | type regex |
||
102 | expr "^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$" |
||
103 | expand "\\1\\2" |
||
104 | } |
||
105 | |||
106 | can catch all the identity certificates and extract the corresponding namespace of the certificate. |
||
107 | |||
108 | ### Signer Property |
||
109 | The **signer** property defines the conditions that the signer (or `KeyLocator`) must fulfill. |
||
110 | |||
111 | |||
112 | |||
113 | 6 | Yingdi Yu | ## Hierarchical Rule |
114 | |||
115 | As implied by its name, hierarchical rule requires the name of the target packet to be under the namespace of the packet signer. |
||
116 | Assume that the usage of the rule is for data, then it is equivalent to a customized rule: |
||
117 | |||
118 | rule |
||
119 | { |
||
120 | for data |
||
121 | name "Expanded Hierarchical Rule" |
||
122 | type customized |
||
123 | target |
||
124 | { |
||
125 | type regex |
||
126 | expr "^(<>*)$" |
||
127 | 1 | Yingdi Yu | expand "\\1" |
128 | 6 | Yingdi Yu | } |
129 | signer |
||
130 | { |
||
131 | type regex |
||
132 | expr "^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$" |
||
133 | expand "\\1\\2" |
||
134 | } |
||
135 | 7 | Yingdi Yu | relation isPrefixOf |
136 | 1 | Yingdi Yu | } |