not authorized for accessing this policy’ (0x0345).
Then the middlebox checks the contained address tuple attributes.
If the first one does not have the location parameter field set to
’internal’ (0x00) or if the second one does not have the location
parameter field set to ’external’ (0x03), then the middlebox returns
a negative reply message of type ’inconsistent request’ (0x034B).
If the transport protocol parameter field does not have the same
value in both address tuple attributes, then the middlebox returns a
negative reply message of type ’inconsistent request’ (0x034B).
If both address tuple attributes contain a port range parameter
field, if both port range parameter fields have values not equal to
0xFFFF, and if the values of both port range parameter fields are
different, then the middlebox returns a negative reply message of
type ’inconsistent request’ (0x034B).
Then the agent checks if wildcarding is requested and if the
requested wildcarding is supported by the middlebox. Wildcarding
support may be different for internal address tuples and external
address tuples. The following parameter fields of the address tuple
attribute can indicate wildcarding:
- the first parameter field
If it is set to ’protocols only’ (0x1), then IP addresses and
port numbers are completely wildcarded.
- the transport protocol field
If it is set to 0x00, then IP the transport protocol is
completely wildcarded. Please note that a completely wildcarded
transport protocol might still support only a limited set of
transport protocols according to the capabilities of the
middlebox. For example, a typical NAT implementation may apply
transport wildcarding to UDP and TCP transport only.
- the prefix length field
If the IP version number field indicates IPv4 and the value of
this field is less than 0x20, then IP addresses are wildcarding
according to this prefix length. If the IP version number field
indicates IPv6 and the value of this field is less than 0x80,
then IP addresses are wildcarding according to this prefix
length. If the first parameter field is set to ’protocols only’
(0x1), then the value of the prefix length field is irrelevant.
- the port number field
If it is set to zero, then port numbers are completely
wildcarded.
- the port range field
If it is set to a value greater than one, then port numbers are
wildcarded within an interval starting with the specified port
number and containing as many consecutive port numbers as
specified by the parameter.
If any of these kinds of wildcarding is used, and if this is in
conflict with wildcarding support for internal or external addresses
of the middlebox, then the middlebox returns a negative reply message
of type ’requested wildcarding not supported’ (0x034C).
If the PEA request conflicts with any policy disable rule (see
Section 8.8.1), then the middlebox returns a negative reply message
of type ’conflict with existing rule’ (0x0350).
After checking the address tuple attributes, the middlebox chooses a
lifetime value for the new policy enable rule to be created, which is
greater than or equal to zero and less than or equal to the minimum
of the requested value and the maximum lifetime specified by the
middlebox capabilities attribute at session setup. Formally, the
lifetime is chosen such that
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where ’lt_granted’ is the actual lifetime chosen by the
middlebox, ’lt_requested’ is the lifetime requested by the agent, and
’lt_maximum’ is the maximum lifetime specified during capability
exchange at session setup.
If there are further sessions in state OPEN with authenticated agents
authorized to access the policy rule, then to each of these agents a
corresponding ARE notification with lifetime set to lt_granted is
sent.
If the chosen lifetime is zero, the middlebox sends a negative reply
of type ’middlebox configuration failed’ (0x034A) to the agent.
8.4.2. Processing on Pure Firewalls
If the middlebox is configured as a pure firewall, then it tries to
configure the requested pinhole. The firewall configuration ignores
the port parity parameter field in the PER parameter set attribute,
but it considers the direction parameter field in this attribute.
The pinhole is configured such that communication between the
specified internal and external address tuples is enabled in the
specified direction and covering the specified wildcarding. If the
configuration fails, then the middlebox returns a negative reply
message of type ’middlebox configuration failed’ (0x034A).
If the configuration was successful, the middlebox replaces the
policy reserve rule referenced by the policy rule identifier
attribute in the PEA request message with a new policy enable rule.
The policy enable rule re-uses the policy rule identifier of the
replaced policy reserve rule. The state of the policy rule
identifier changes from RESERVED to ENABLED. The policy reserve rule
is a member of the same group as the replaced policy reserve rule
was.
Then the middlebox generates a positive PER reply and sets the
attributes as specified below.
The identifier chosen for the new policy rule is reported in the
policy rule identifier attribute of the PER reply.
The group identifier is reported in the group identifier attribute of
the PER reply.
The chosen lifetime is reported in the lifetime attribute of the PER
reply.
The address tuple (internal) attribute of the PER request is reported
as the address tuple (outside) attribute of the PER reply. The
address tuple (external) attribute of the PER request is reported as
the address tuple (inside) attribute of the PER reply.
8.4.3. Processing on Network Address Translators
If the middlebox is configured as a NAT, then it tries to configure
the requested NAT binding, i.e., enabling the already reserved
binding. The already reserved NAT binding from the PRR request is
now enabled in the middlebox.
If the enable configuration was successful, the middlebox replaces
the policy reserve rule referenced by the policy rule identifier
attribute in the PEA request message with a new policy enable rule.
The policy enable rule re-uses the policy rule identifier of the
replaced policy reserve rule. The state of the policy rule
identifier changes from RESERVED to ENABLED. The policy reserve rule
is a member of the same group as the replaced policy reserve rule
was.
Then the middlebox generates a positive PER reply and sets the
attributes as specified below.
The reserved outside address tuple is reported as the address tuple
(outside) attribute of the PER reply. The reserved inside address
tuple is reported as the address tuple (inside) attribute of the PER
reply. Both reserved outside and inside address tuples are taken
from the reserve policy rule generated during the PRR transaction.
8.5. Processing PLC Requests
When a middlebox receives a PLC request message, it first checks if
the authenticated agent is authorized for requesting policy rule
lifetime changes. If not, it returns a negative reply message of
type ’agent not authorized for this transaction’ (0x0341).
Then the middlebox checks the policy rule identifier attribute
contained in the PLC message. If no policy rule with this identifier
exists, then the middlebox returns a negative reply message of type
’specified policy rule does not exist’ (0x0343).
If a policy rule with this identifier exists, but the authenticated
agent is not authorized for changing the lifetime of this policy
rule, then the middlebox returns a negative reply message of type
’agent not authorized for accessing this policy’ (0x0345).
Then the middlebox chooses a lifetime value for the new policy rule,
which is greater than zero and less than or equal to the minimum of
the requested value and the maximum lifetime specified by the
middlebox capabilities attribute at session setup. Formally, the
lifetime is chosen such that
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where ’lt_granted’ is the actual lifetime chosen by the
middlebox, ’lt_requested’ is the lifetime requested by the agent, and
’lt_maximum’ is the maximum lifetime specified during capability
exchange at session setup. This procedure implies that the chosen
lifetime is zero if the requested lifetime is zero.
If the chosen lifetime is greater than zero, the middlebox changes
the lifetime of the policy rule to the chosen value and generates a
PLC reply message. The chosen lifetime is reported in the lifetime
attribute of the message.
If otherwise (the chosen lifetime is zero), then the middlebox
terminates the policy rule and changes the PID state from ENABLED or
RESERVED, respectively, to UNUSED.
The middlebox generates a PRD reply message and sends it to the
requesting agent. If there are further sessions in state OPEN with
authenticated agents authorized to access the policy rule, then to
each of these agents a corresponding ARE notification with lifetime
set to zero is sent.
8.6. Processing PRS Requests
When a middlebox receives a PRS request message, it first checks if
the authenticated agent is authorized for receiving policy status
information. If not, it returns a negative reply message of type
’agent not authorized for this transaction’ (0x0341).
Then the middlebox checks the policy rule identifier attribute
contained in the PRS message. If no policy rule with this identifier
exists in state RESERVED or ENABLED, then the middlebox returns a
negative reply message of type ’specified policy rule does not exist’
(0x0343).
If a policy rule with this identifier exists, but the authenticated
agent is not authorized to receive status information for this policy
rule, then the middlebox returns a negative reply message of type
’agent not authorized for accessing this policy’ (0x0345).
If the checks described above are passed, the middlebox accepts the
requests and generates a reply. If the policy rule for which status
information is requested is in state RESERVED, then a PRS reply is
generated and sent to the agent. If otherwise (the policy rule is in
state ENABLED), then a PES reply is generated and sent to the agent.
For policy disable rules, a PDS reply is generated and sent to the
agent.
In both message formats, the lifetime attribute reports the current
remaining lifetime of the policy rule, and the owner attribute
reports the owner of the policy rule for which status information is
requested.
The PRS reply message format is identical to the PRR reply message
format except for an appended owner attribute. In the PRS reply, the
attributes that are common with the PRR reply (except for the
lifetime attribute) have exactly the same values as the corresponding
attributes of the PRR reply that was sent as part of the PRR
transaction that established the policy reserve rule.
In the PES reply message, the PER parameter set attribute, the
address tuple (internal) attribute, and the address tuple (external)
attribute have exactly the same values as the corresponding
attributes of the PER or PEA request that were sent as part of the
corresponding transaction that established the policy enable rule.
In the PES reply message, the policy rule identifier attribute, the
group identifier attribute, the address tuple (inside) attribute, and
the address tuple (outside) attribute have exactly the same values as
the corresponding attributes of the PER reply that was sent as part
of the PER or PEA transaction that established the policy enable
rule.
In the PDS reply message, the policy rule identifier attribute, the
address tuple (internal) attribute, and the address tuple (external)
attribute have exactly the same values as the corresponding
attributes of the PDR request message.
This transaction does not change the state of any policy rule.
8.7. Processing PRL Requests
When a middlebox receives a PRL request message, it first checks if
the authenticated agent is authorized for receiving policy
information. If not, it returns a negative reply message of type
’agent not authorized for this transaction’ (0x0341).
Then the middlebox generates a PRL reply message. For each policy
rule at the middlebox in state RESERVED or ENABLED that the
authenticated agent can access, a policy rule identifier attribute is
generated and added to the PRL reply message before the message is
sent to the agent. A negative reply message of type ’reply message
too big’ (0x0313) is generated if the number of policy rule
attributes to be returned exceeds the maximum transport unit size of
the underlying network connection or the maximum length of a SIMCO
message. The total size of a SIMCO message is limited to 65,536
octets in total (see Section 4.2 for the SIMCO header).
This transaction does not change the state of any policy rule.
8.8. Processing PDR requests
Processing of PDR requests is structured into five sub-sections. The
first one describes the general extension of the MIDCOM protocol
semantics by PDR. The second sub-section describes the initial
checks that are performed in any case. The third sub-section
describes the processing of PDR requests on pure firewalls. The
fourth one describes processing on devices with NATs, and the fifth
describes processing of devices with combined firewall and NAT
functions.
8.8.1. Extending the MIDCOM semantics
The Policy Disable Rule (PDR) extends the MIDCOM protocol semantics
[RFC3989] by another policy rule type. The PDR is intended to be
used for dynamically blocking unwanted traffic, particularly in case
of an attack, for example, a distributed denial of service attack.
PDR requests follow the same ownership concept as all other
transactions do (see [RFC3989], Section 2.1.5). However, PDR
prioritization over PERs is independent of ownership. A PDR always
overrules a conflicting PER, even if the respective owners are
different. Typically, only a highly privileged agent will be allowed
to issue PDR requests.
A PDR rule and PER rule conflict with each other if their address
tuples overlap such that there exists at least one IP packet that
matches address tuple A0 of both rules in the internal network and
that matches address tuple A3 of both rules in the external network.
Note that the packet may be translated from the internal to external
network, or vice versa.
Let’s assume, for instance, that a policy enable rule (PER) enables
all traffic from any external host using any UDP port to a certain
UDP port of a certain internal host:
PER A3={ any external IP address, UDP, any port }
PER A0={ internal IP address 10.1.8.3, UDP, port 12345 }
Then this conflicts with a policy disable rule (PDR) blocking all UDP
traffic from a potentially attacking host:
PDR A3={ external IP address 192.0.2.100, UDP, any port }
PDR A0={ any internal IP address, UDP, any port }
If a new PDR is established, then all conflicting PERS are terminated
immediately. A new PER can only be established if it does not
conflict with any already existing PDR.
8.8.2. Initial Checks
When a middlebox receives a PDR request message, it first checks if
the authenticated agent is authorized for requesting middlebox
configurations for disabling communication. If not, it returns a
negative reply message of type ’agent not authorized for this
transaction’ (0x0341).
Then the middlebox checks the contained address tuple attributes.
If the first one does not have the location parameter field set to
’internal’ (0x00), or if the second one does not have the location
parameter field set to ’external’ (0x03), then the middlebox returns
a negative reply message of type ’inconsistent request’ (0x034B).
If the transport protocol parameter field does not have the same
value in both address tuple attributes, then the middlebox returns a
negative reply message of type ’inconsistent request’ (0x034B).
If both address tuple attributes contain a port range parameter
field, if both port range parameter fields have values not equal to
0xFFFF, and if the values of both port range parameter fields are
different, then the middlebox returns a negative reply message of
type ’inconsistent request’ (0x034B).
Then the agent checks if wildcarding is requested and if the
requested wildcarding is supported by the middlebox. Wildcarding
support may be different for internal address tuples and external
address tuples. The following parameter fields of the address tuple
attribute can indicate wildcarding:
- the first parameter field
If it is set to ’protocols only’ (0x1), then IP addresses and
port numbers are completely wildcarded.
- the transport protocol field
If it is set to 0x00, then the transport protocol is completely
wildcarded. Please note that a completely wildcarded transport
protocol might still support only a limited set of transport
protocols according to the capabilities of the middlebox. For
example, a typical NAT implementation may apply transport
wildcarding to UDP and TCP transport only. Wildcarding the
transport protocol implies wildcarding of port numbers. If this
field is set to 0x00, then the values of the port number field
and the port range field are irrelevant.
- the prefix length field
If the IP version number field indicates IPv4 and the value of
this field is less than 0x20, then IP addresses are wildcarding
according to this prefix length. If the IP version number field
indicates IPv6 and the value of this field is less than 0x80,
then IP addresses are wildcarding according to this prefix
length. If the first parameter field is set to ’protocols only’
(0x1), then the value of the prefix length field is irrelevant.
- the port number field
If it is set to zero, then port numbers are completely
wildcarded. In this case, the value of the port range field is
irrelevant.
If any of these kinds of wildcarding is used, and if this is in
conflict with wildcarding support for internal or external addresses
of the middlebox, then the middlebox returns a negative reply message
of type ’requested wildcarding not supported’ (0x034C).
Please note that the port range field cannot be used for wildcarding.
If it is set to a value greater than one, then middlebox
configuration is requested for all port numbers in the interval
starting with the specified port number and containing as many
consecutive port numbers as specified by the parameter.
The specified policy disable rule is activated, and the middlebox
will terminate any conflicting policy enable rule immediately.
Conflicts are defined in Section 8.8.1. Agents with open sessions
that have access to the policy rules to be terminated are notified
via the ARE notification.
The middlebox will reject all requests for new policy enable rules
that conflict with the just established PDR as long as the PDR is not
terminated. In such a case, a negative ’conflict with existing rule’
(0x0350) reply will be generated.
After checking the address tuple attributes, the middlebox chooses a
lifetime value for the new policy rule to be created, which is
greater than or equal to zero and less than or equal to the minimum
of the requested value and the maximum lifetime specified by the
middlebox capabilities attribute at session setup. Formally, the
lifetime is chosen such that
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where ’lt_granted’ is the actual lifetime chosen by the
middlebox, ’lt_requested’ is the lifetime requested by the agent, and
’lt_maximum’ is the maximum lifetime specified during capability
exchange at session setup.
If there are further sessions in state OPEN with authenticated agents
authorized to access the policy rule, then to each of these agents a
corresponding ARE notification with lifetime set to lt_granted is
sent.
If the chosen lifetime is zero, the middlebox sends a negative reply
of type ’middlebox configuration failed’ (0x034A) to the agent.
8.8.3. Processing on Pure Firewalls
If the middlebox is acting as a pure firewall, then it tries to
configure the requested disable rule, i.e., configuring a blocking
rule at the firewall. The disable rule is configured such that
communication between the specified internal and external address
tuples is blocked, covering the specified wildcarding. If the
configuration fails (for example, because the blocking rule would
conflict with high-level firewall policies), then the middlebox
returns a negative reply message of type ’middlebox configuration
failed’ (0x034A).
If the configuration was successful, the middlebox establishes a new
policy disable rule and assigns to it a policy rule identifier in
state ENABLED. It generates a positive PDR reply and sets the
attributes as specified below.
The identifier chosen for the new policy rule is reported in the
policy rule identifier attribute of the PDR reply.
The chosen lifetime is reported in the lifetime attribute of the PDR
reply.
8.8.4. Processing on Network Address Translators
If the middlebox is configured as a NAT, then it tries to block the
specified address tuple in the NAT. The mechanisms used for this
depend on the implementation and capabilities of the NAT.
Should the configuration fail in either NAT case, a negative reply
’middlebox configuration failed’ (0x034A) is returned.
If the configuration was successful, the middlebox establishes a new
policy disable rule and assigns to it a policy rule identifier in
state ENABLED. It generates a positive PDR reply and sets the
attributes as specified below.
The identifier chosen for the new policy rule is reported in the
policy rule identifier attribute of the PDR reply.
The chosen lifetime is reported in the lifetime attribute of the PDR
reply.
8.8.5. Processing on Combined Firewalls and NATs
Middleboxes that are combinations of firewall and NAT are configured
in such a way that first the firewall is configured with the blocking
rule and afterwards the NAT is configured to block the address tuple.
This aspect of middlebox operation may be irrelevant to SIMCO, since
some NATs already do firewall configuration on their own.
8.9 Generating ARE Notifications
At any time, the middlebox may terminate a policy rule by deleting
the configuration of the rule and by changing the corresponding PID
state from ENABLED or from RESERVED, respectively, to UNUSED.
For each session in state OPEN with authenticated agents authorized
to access the policy rule, the middlebox generates a corresponding
ARE notification with the lifetime attribute set to zero and sends it
to the respective agent. The identifier of the terminated policy
rule is reported in the policy rule identifier attribute of the ARE
notification.
After sending the notification, the middlebox will consider the
policy rule non-existent. It will not process any further
transaction on this policy rule.
In the case of PRR, PER, PEA, and PLC (reserving and enabling policy
rules and changes of the lifetime), the middlebox generates an ARE
notification after processing the request. This ARE notification is
generated for each session in state OPEN with authenticated agents
(other than the requesting agent) who are authorized to access the
policy rule. Through this ARE notification all other agents are kept
synchronized with the latest state of the policy rules.
9. Security Considerations
9.1. Possible Threats to SIMCO
Middleboxes, such as firewalls and NATs, are usually operated for
improving the network security and for extending the IP address space
(note that stand-alone NATs are not considered to improve security;
see [RFC2663]). The configuration of middleboxes from an external