CommandValidatorConf » History » Version 6
Yingdi Yu, 03/17/2014 04:52 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 | condition isPrefixOf |
||
| 19 | 3 | Yingdi Yu | } |
| 20 | 6 | Yingdi Yu | signer |
| 21 | { |
||
| 22 | type name |
||
| 23 | rule "/ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT" |
||
| 24 | condition equal |
||
| 25 | } |
||
| 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 | ## Customized Rule |
||
| 50 | |||
| 51 | Two properties are required by customized rule: **target** and **signer**. |
||
| 52 | The **target** property defines the conditions that the packet per se must satisfy, |
||
| 53 | thus restricting the scope of packets to which the rule can be applied. |
||
| 54 | |||
| 55 | A packet will be checked against the **target** property of rules in the configuration file, |
||
| 56 | one-by-one until the first rule whose **target** property can be satisfied by the packet. |
||
| 57 | Therefore, **the order of rules in configuration file MATTERS!** |
||
| 58 | |||
| 59 | **target** also has a property **type** with two possible value **name** and **regex**. |
||
| 60 | If **type** is **name**, then |
||
| 61 | |||
| 62 | and **signer** defines the requirements that the signer (or `KeyLocator`) must fulfill. |
||
| 63 | |||
| 64 | |||
| 65 | |||
| 66 | ## Hierarchical Rule |
||
| 67 | |||
| 68 | As implied by its name, hierarchical rule requires the name of the target packet to be under the namespace of the packet signer. |
||
| 69 | Assume that the usage of the rule is for data, then it is equivalent to a customized rule: |
||
| 70 | |||
| 71 | rule |
||
| 72 | { |
||
| 73 | for data |
||
| 74 | name "Expanded Hierarchical Rule" |
||
| 75 | type customized |
||
| 76 | target |
||
| 77 | { |
||
| 78 | type regex |
||
| 79 | expr "^(<>*)$" |
||
| 80 | expand "\\1" |
||
| 81 | } |
||
| 82 | signer |
||
| 83 | { |
||
| 84 | type regex |
||
| 85 | expr "^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$" |
||
| 86 | expand "\\1\\2" |
||
| 87 | } |
||
| 88 | additional-condition > |
||
| 89 | } |