CommandValidatorConf » History » Revision 13
Revision 12 (Yingdi Yu, 03/18/2014 03:43 PM) → Revision 13/55 (Yingdi Yu, 03/18/2014 03:49 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
{
id "Simple Rule"
for data
type customized
filter
{
type name
name "/localhost/example"
relation isPrefixOf
}
signer
{
type name
name "/ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT"
relation equal
}
}
rule
{
id "Testbed Validation Rule"
for data
type hierarchical
trust-anchor
{
type file
file-name "testbed-trust-anchor.cert"
}
}
<font color='red'>**ATTENTION: The order of rules MATTERS!**</font>
A rule can be broken into two parts:
* The first part is to qualify packets to which the rule can be applied;
* The second part is to decide whether further validation process is necessary.
When receiving a packet, the validator will check it against rules in the configuration file one-by-one,
until reaching a rule that the packet qualifies for.
And the second part of the matching rule will be used to check the validity of the packet.
If the packet cannot qualify any rules, it is treated as an invalid packet.
In the example configuration,
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".
If a packet does not have a name under prefix "/localhost/example", validator will skip the first rule and check the second rule.
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".
## Rules in general
Before we go into the details of specific rules, we need to introduce several general properties of a rule.
A rule must have a **id** property which uniquely identify the rule in the configuration file, e.g., "Simple Rule", "Testbed Validation Rule".
A rule is either used to validate an interest packet or a data packet.
This information is specified in the property **for**.
Only two value can be specified: **data** and **interest**.
The property **type** indicates the type of rules.
There are some pre-defined rule types, such as **hierarchical**.
People can also customize their own rules by setting the type property to be **customized**.
A rule may have some other properties depending on the rule type.
Next, we will introduce the other properties for the each rule type.
## Customized Rule
Two properties are required by customized rule: **filter** and **signer**.
And some optional properties may be needed, such as **relation**, **trust-anchor**, etc..
### Filter Property
The **filter** property specifies the condition that a packet must satisfy.
A rule may contain more than one filters.
A packet can be captured by a rule only if the packet satisfies all the filters.
Filter has its own property **type**.
Although a rule may contain more than one filters, there is at most one filter of each type.
So far, we defined only one filter type: **name**.
In other word, only one filter can be specified for now.
There are two ways to express the restrictions restriction on name.
The first way is to specify a relationship between the packet name and a particular name.
In this case, two more properties are required: **name** and **relation**.
A packet can satisfy the condition if the **name** and the packet name can establish the **relation**.
The value of **relation** property could be either **isPrefixOf** or **equal**.
For example, a filter: target:
filter target
{
type name
name "/localhost/example"
relation isPrefixOf
}
can capture catch a packet with name "/localhost/example/data" but cannot catch a packet with name "/localhost/another_example".
And a filter target
filter target
{
type name
name "/localhost/example"
relation equal
}
can only catch a packet with the exact name "/localhost/example".
The second way is to specify an NDN regular expression that the packet name must match.
In this case, only one property **regex** is required.
The value of **regex** is an NDN regular expression.
A packet can satisfy the filter **target** only if the regex can match the packet name.
If regex **regex** is used, an optional property **expand** may be specified if back reference is need to extract certain pattern out of the packet name.
For example, a filter target
filter target
{
type name
regex "^([^<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 that the signer (or `KeyLocator`) must fulfill.
The structure of the **signer** property is the same as the **target** property.
And same as **target** property, a rule may contain more than one **signer** properties.
However, as long as one of the **signer** properties is satisfied, the packet validation can proceed without treating the packet as invalid.
### Relation Property
The **relation** property is optional.
If the **relation** property is set, then
## 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
anchor
{
type file
file-name "trust-anchor.cert"
}
}
## The Order Of Rules