Project

General

Profile

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
    }