CommandValidatorConf » History » Version 10
Yingdi Yu, 03/18/2014 02:42 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 | 9 | Yingdi Yu | id "Simple Rule" |
12 | 3 | Yingdi Yu | for data |
13 | 6 | Yingdi Yu | type customized |
14 | 9 | Yingdi Yu | filter |
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 | 9 | Yingdi Yu | id "Testbed Validation Rule" |
30 | 1 | Yingdi Yu | for data |
31 | type hierarchical |
||
32 | trust-anchor |
||
33 | { |
||
34 | type file |
||
35 | file-name "testbed-trust-anchor.cert" |
||
36 | } |
||
37 | } |
||
38 | |||
39 | 9 | Yingdi Yu | |
40 | <font color='red'>**ATTENTION: The order of rules MATTERS!**</font> |
||
41 | |||
42 | 10 | Yingdi Yu | A rule can be broken into two parts: |
43 | 9 | Yingdi Yu | |
44 | * The first part is to qualify packets to which the rule can be applied; |
||
45 | * The second part is to decide whether further validation process is necessary. |
||
46 | 1 | Yingdi Yu | |
47 | 10 | Yingdi Yu | When receiving a packet, the validator will check it against rules in the configuration file one-by-one, |
48 | until reaching a rule that the packet qualifies for. |
||
49 | And the second part of the matching rule will be used to check the validity of the packet. |
||
50 | If the packet cannot qualify any rules, it is treated as an invalid packet. |
||
51 | 1 | Yingdi Yu | |
52 | 10 | Yingdi Yu | |
53 | In the example configuration, |
||
54 | 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". |
||
55 | If a packet does not have a name under prefix "/localhost/example", validator will skip the first rule and check the second rule. |
||
56 | The second rule indicates that any data packets must be validated recursively back along a hierarchy with a trust anchor stored in a file called "testbed-trust-anchor.cert". |
||
57 | |||
58 | 9 | Yingdi Yu | |
59 | 1 | Yingdi Yu | Each rule has a unique name (which should be unique in the configuration file), e.g., "Simple Rule", "Testbed Validation Rule". |
60 | The rule name is specified in the property **name**. |
||
61 | 6 | Yingdi Yu | Each rule must be specified with a usage which is specified in the property **for**. |
62 | 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**. |
||
63 | 1 | Yingdi Yu | The property **type** indicates how to apply the rule to packets. |
64 | 9 | Yingdi Yu | Some rule types (such as **hierarchical**) has been pre-defined. |
65 | One can also customize its own rules by setting the type property to be **customized**. |
||
66 | Some other properties are required depending on the rule type. |
||
67 | 1 | Yingdi Yu | Next, we will introduce the other properties for the each rule type. |
68 | |||
69 | ## Customized Rule |
||
70 | 7 | Yingdi Yu | |
71 | 9 | Yingdi Yu | Two properties are required by **customized rule**: **filter** and **signer**. |
72 | 7 | Yingdi Yu | And some optional properties may be configured if necessary. |
73 | |||
74 | 9 | Yingdi Yu | ### Filter Property |
75 | 1 | Yingdi Yu | |
76 | 9 | Yingdi Yu | The **filter** property specifies which packets to which the rule can be applied. |
77 | A rule may contain more than one **filter** properties, a packet can be caught by a rule only if the packet satisfy all the **filter** properties. |
||
78 | 8 | Yingdi Yu | |
79 | 9 | Yingdi Yu | A packet will be checked against the **filter** properties of rules in the configuration file, |
80 | 1 | Yingdi Yu | one-by-one until the first rule whose **target** property can be satisfied by the packet. |
81 | Once the packet is caught by a rule, no other rules will be applied to the packet. |
||
82 | 8 | Yingdi Yu | Therefore, <font color='red'>**the order of rules in configuration file MATTERS!**</font> |
83 | 1 | Yingdi Yu | If the packet cannot satisfy any rules, it will be treated as **invalid** packet. |
84 | 8 | Yingdi Yu | |
85 | The **target** has its own property **type** which indicates the type of condition. |
||
86 | Although a rule may contain more than one **target** properties, there is at most one **target** property for each type. |
||
87 | So far, only one target type is supported: **name**. |
||
88 | 7 | Yingdi Yu | In other word, only one **target** property can be specified for now. |
89 | 8 | Yingdi Yu | |
90 | There are two ways to express the restriction on name. |
||
91 | The first way is to specify a relationship between the packet name and a particular name. |
||
92 | 7 | Yingdi Yu | In this case, two more properties are required: **name** and **relation**. |
93 | A packet can satisfy the condition if the **name** and the packet name can establish the **relation**. |
||
94 | The value of **relation** could be either **isPrefixOf** or **equal**. |
||
95 | 6 | Yingdi Yu | For example, a target: |
96 | 7 | Yingdi Yu | |
97 | target |
||
98 | { |
||
99 | type name |
||
100 | name "/localhost/example" |
||
101 | relation isPrefixOf |
||
102 | 1 | Yingdi Yu | } |
103 | 7 | Yingdi Yu | |
104 | 1 | Yingdi Yu | can catch a packet with name "/localhost/example/data" but cannot catch a packet with name "/localhost/another_example". |
105 | 7 | Yingdi Yu | |
106 | And a target |
||
107 | |||
108 | 1 | Yingdi Yu | target |
109 | { |
||
110 | type name |
||
111 | name "/localhost/example" |
||
112 | 7 | Yingdi Yu | relation equal |
113 | } |
||
114 | 1 | Yingdi Yu | |
115 | can only catch a packet with the exact name "/localhost/example". |
||
116 | 8 | Yingdi Yu | |
117 | The second way is to specify an NDN regular expression that the packet name must match. |
||
118 | In this case, only one property **regex** is required. |
||
119 | 7 | Yingdi Yu | The value of **regex** is an NDN regular expression. |
120 | 8 | Yingdi Yu | A packet can satisfy the **target** only if the regex can match the packet name. |
121 | 7 | Yingdi Yu | If **regex** is used, an optional property **expand** may be specified if back reference is need to extract certain pattern out of the packet name. |
122 | 1 | Yingdi Yu | For example, a target |
123 | 7 | Yingdi Yu | |
124 | 1 | Yingdi Yu | target |
125 | 8 | Yingdi Yu | { |
126 | type name |
||
127 | 7 | Yingdi Yu | regex "^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$" |
128 | 1 | Yingdi Yu | expand "\\1\\2" |
129 | 7 | Yingdi Yu | } |
130 | 1 | Yingdi Yu | |
131 | can catch all the identity certificates and extract the corresponding namespace of the certificate. |
||
132 | 7 | Yingdi Yu | |
133 | 8 | Yingdi Yu | ### Signer Property |
134 | 1 | Yingdi Yu | |
135 | 8 | Yingdi Yu | The **signer** property defines the conditions that the signer (or `KeyLocator`) must fulfill. |
136 | The structure of the **signer** property is the same as the **target** property. |
||
137 | And same as **target** property, a rule may contain more than one **signer** properties. |
||
138 | 7 | Yingdi Yu | However, as long as one of the **signer** properties is satisfied, the packet validation can proceed without treating the packet as invalid. |
139 | 8 | Yingdi Yu | |
140 | 7 | Yingdi Yu | ### Relation Property |
141 | 8 | Yingdi Yu | |
142 | The **relation** property is optional. |
||
143 | 7 | Yingdi Yu | If the **relation** property is set, then |
144 | 8 | Yingdi Yu | |
145 | |||
146 | |||
147 | 6 | Yingdi Yu | |
148 | ## Hierarchical Rule |
||
149 | |||
150 | As implied by its name, hierarchical rule requires the name of the target packet to be under the namespace of the packet signer. |
||
151 | Assume that the usage of the rule is for data, then it is equivalent to a customized rule: |
||
152 | |||
153 | rule |
||
154 | { |
||
155 | for data |
||
156 | name "Expanded Hierarchical Rule" |
||
157 | type customized |
||
158 | target |
||
159 | 1 | Yingdi Yu | { |
160 | type regex |
||
161 | expr "^(<>*)$" |
||
162 | expand "\\1" |
||
163 | } |
||
164 | 6 | Yingdi Yu | signer |
165 | 1 | Yingdi Yu | { |
166 | type regex |
||
167 | 6 | Yingdi Yu | expr "^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$" |
168 | 1 | Yingdi Yu | expand "\\1\\2" |
169 | 6 | Yingdi Yu | } |
170 | 8 | Yingdi Yu | relation isPrefixOf |
171 | anchor |
||
172 | { |
||
173 | type file |
||
174 | file-name "trust-anchor.cert" |
||
175 | 6 | Yingdi Yu | } |
176 | 8 | Yingdi Yu | } |
177 | |||
178 | 1 | Yingdi Yu | ## The Order Of Rules |