CommandValidatorConf » History » Revision 7
Revision 6 (Yingdi Yu, 03/17/2014 04:52 PM) → Revision 7/55 (Yingdi Yu, 03/17/2014 05:29 PM)
# Validator Configuration File Format
You can set up a `Validator` via a configuration file.
Next, we will show you how to write a configuration file.
The configuration file consists of **rules** that will be used in validation.
Here is an example of configuration file containing two rules.
rule
{
for data
name "Simple Rule"
type customized
target
{
type name
name "/localhost/example"
relation condition isPrefixOf
}
signer
{
type name
name rule "/ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT"
relation condition equal
}
}
rule
{
for data
name "Testbed Validation Rule"
type hierarchical
trust-anchor
{
type file
file-name "testbed-trust-anchor.cert"
}
}
Each rule has a unique name (which should be unique in the configuration file), e.g., "Simple Rule", "Testbed Validation Rule".
The rule name is specified in the property **name**.
Each rule must be specified with a usage which is specified in the property **for**.
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**.
The property **type** indicates how to apply the rule to packets.
Some rule types (such as **hierarchical**) has been defined.
One can also specify its own rules by set the type property to be **customized**.
A particular type of rules might require some other properties.
Next, we will introduce the other properties for the each rule type.
## Customized Rule
Two properties are required by customized rule: **target** and **signer**.
And some optional properties may be configured if necessary.
### Target Property
The **target** property defines the conditions that the packet per se must satisfy,
thus restricting the scope of packets to which the rule can be applied.
A packet will be checked against the **target** property of rules in the configuration file,
one-by-one until the first rule whose **target** property can be satisfied by the packet.
Once the packet is caught by a rule, no other rules will be applied to the packet.
Therefore, <font color='red'>**the **the order of rules in configuration file MATTERS!**</font>
If the packet cannot satisfy none of the rules, it will be treated as **unvalidated** packet. MATTERS!**
The **target** also has a property **type** which indicates the condition type.
Two with two possible types are supported so far: value **name** and **regex**.
If **type** is **name**, then the **target** has two more properties: **name**
and **relation**.
A packet can satisfy the condition if the **name** and the packet name can establish the **relation**.
The value of **relation** could be either **isPrefixOf** or **equal**.
For example, a target:
target
{
type name
name "/localhost/example"
relation isPrefixOf
}
can catch a packet with name "/localhost/example/data" but cannot catch a packet with name "/localhost/another_example".
And a target
target
{
type name
name "/localhost/example"
relation equal
}
can only catch a packet with the exact name "/localhost/example".
If **type** is **regex**, then **target** must have a property **expr** and an optional property **expand**.
**expr** is an NDN regular expression.
A packet can satisfy the **target** only if the regex can match the packet name.
If the regex contains back references, then the **expand** property can be specified to extract certain pattern out of the packet name.
For example, a target
target
{
type regex
expr "^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$"
expand "\\1\\2"
}
can catch all the identity certificates and extract the corresponding namespace of the certificate.
### Signer Property
The **signer** property defines the conditions requirements that the signer (or `KeyLocator`) must fulfill.
## Hierarchical Rule
As implied by its name, hierarchical rule requires the name of the target packet to be under the namespace of the packet signer.
Assume that the usage of the rule is for data, then it is equivalent to a customized rule:
rule
{
for data
name "Expanded Hierarchical Rule"
type customized
target
{
type regex
expr "^(<>*)$"
expand "\\1"
}
signer
{
type regex
expr "^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$"
expand "\\1\\2"
}
relation isPrefixOf additional-condition >
}