available inside and/or outside IP address(es) only. The reserved
address(es) are returned to the agent. In this case, the
request-parameters "port range" and "port parity" as well as
reply-parameters "inside port number" and "outside port number",
are irrelevant.
If the protocol identifier is ’UDP’ or ’TCP’, then a combination
of an IP address and a consecutive sequence of port numbers,
starting with the specified parity, is reserved, on neither side,
one side, or both sides of the middlebox, as appropriate. The IP
address(es) and the first (lowest) reserved port number(s) of the
consecutive sequence are returned to the agent. (This also
applies to other protocols supporting ports or the equivalent.)
After a new policy reserve rule is successfully established and
the reply message has been sent to the requesting agent, the
middlebox checks whether there are other authenticated agents
participating in open sessions, which can access the new policy
rule. If the middlebox finds one or more of these agents, then it
sends a REN message reporting the new policy rule to each of them.
MIDCOM agents use the policy enable rule (PER) transaction to enable
policy reserve rules that have been established beforehand by a
policy reserve rule (PRR) transaction. See also section 2.3.2.
2.3.9. Policy Enable Rule (PER)
transaction-name: policy enable rule
transaction-type: configuration
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
- policy reserve rule identifier: A reference to an already
existing policy reserve rule created by a PRR transaction. The
reference may be empty, in which case the middlebox must assign
any necessary addresses and port numbers within this PER
transaction. If it is not empty, then the following request
parameters are irrelevant: group identifier, transport protocol,
port range, port parity, internal IP version, external IP
version.
- group identifier: A reference to the group of which the policy
enable rule should be a member. As indicated in section 2.3.3,
if this value is not supplied, the middlebox assigns a new group
for this policy reserve rule.
- transport protocol: See section 2.3.5.
- port range: The number of consecutive port numbers to be
reserved; see section 2.3.5.
- port parity: The requested parity of the port number(s) to be
mapped. Allowed values of this parameter are ’same’ and ’any’.
See also section 2.3.5.
- direction of flow: This parameter specifies the direction of
enabled communication, either ’inbound’, ’outbound’, or ’bi-
directional’.
- internal IP version: Requested IP version at the inside of the
middlebox; see section 2.3.5.
- internal IP address: The IP address of the internal
communication endpoint (A0 in Figure 3); see section 2.3.5.
- internal port number: The port number of the internal
communication endpoint (A0 in Figure 3); see section 2.3.5.
- inside interface (optional): Interface at the inside of the
middlebox; see section 2.3.7.
- external IP version: Requested IP version at the outside of the
middlebox; see section 2.3.5.
- external IP address: The IP address of the external
communication endpoint (A3 in Figure 3); see section 2.3.5.
- external port number: The port number of the external
communication endpoint (A3 in Figure 4), see section 2.3.5.
- outside interface (optional): Interface at the outside of the
middlebox; see section 2.3.7.
- policy rule lifetime: A lifetime proposal to the middlebox for
the requested policy rule.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- policy rule identifier: A middlebox-unique policy rule
identifier. It is assigned by the middlebox and used as policy
rule handle in further policy rule transactions. If a policy
reserve rule identifier was provided in the request, then the
returned policy rule identifier has the same value.
- group identifier: A reference to the group of which the policy
enable rule is a member. If a policy reserve rule identifier
was provided in the request, then this parameter identifies the
group of which the policy reserve rule was a member.
- inside IP address: The IP address provided at the inside of the
middlebox (A1 in Figure 3). In case of a twice-NAT, this
parameter will be an internal IP address reserved at the inside
of the middlebox. In all other cases, this reply-parameter will
be identical with the external IP address passed with the
request. If the policy reserve rule identifier parameter was
supplied in the request and the respective PRR transaction
reserved an inside IP address, then the inside IP address
provided in the PER response will be the identical value to that
returned by the response to the PRR request. See also section
2.3.5.
- inside port number: The internal port number provided at the
inside of the middlebox (A1 in Figure 3); see also section
2.3.5.
- outside IP address: The external IP address provided at the
outside of the middlebox (A2 in Figure 4). In case of a pure
firewall, this parameter will be identical with the internal IP
address passed with the request. In all other cases, this
reply-parameter will be an external IP address reserved at the
outside of the middlebox. See also section 2.3.5.
- outside port number: The external port number provided at the
outside of the NAT (A2 in Figure 3); see section 2.3.5..
- policy rule lifetime: The policy rule lifetime granted by the
middlebox.
failure reason:
- agent not authorized for this transaction
- agent not authorized to add members to this group
- no such policy reserve rule
- agent not authorized to replace this policy reserve rule
- conflict with already existing policy rule (e.g., the same
internal address-port is being mapped to different outside
address-port pairs)
- lack of IP addresses
- lack of port numbers
- lack of resources
- no internal IP wildcarding allowed
- no external IP wildcarding allowed
- specified inside/outside interface does not exist
- specified inside/outside interface not available for specified
service
- reserved A0 to requested A0 mismatch
notification message type: Policy Rule Event Notification (REN)
semantics:
This transaction can be used by an agent to enable communication
between an internal endpoint and an external endpoint
independently of the type of middlebox (NAT, NAPT, firewall, NAT-
PT, combined devices), for unidirectional or bi-directional
traffic.
The agent sends an enable request specifying the endpoints
(optionally including wildcards) and the direction of
communication (inbound, outbound, bi-directional). The
communication endpoints are displayed in Figure 3. The basic
operation of the PER transaction can be described by
1. the agent sending A0 and A3 to the middlebox,
2. the middlebox reserving A1 and A2 or using A1 and A2 from a
previous PRR transaction,
3. the middlebox enabling packet transfer between A0 and A3 by
binding A0-A2 and A1-A3 and/or by opening the corresponding
pinholes, both according to the specified direction, and
4. the middlebox returning A1 and A2 to the agent.
In case of a pure packet filtering firewall, the returned address
tuples are the same as those in the request: A2=A0 and A1=A3.
Each partner uses the other’s real address. In case of a
traditional NAT, the internal endpoint may use the real address of
the external endpoint (A1=A3), but the external endpoint uses an
address tuple provided by the NAT (A2!=A0). In case of a twice-
NAT device, both endpoints use address tuples provided by the NAT
for addressing their communication partner (A3!=A1 and A2!=A0).
If a firewall is combined with a NAT or a twice-NAT, the replied
address tuples will be the same as for pure traditional NAT or
twice-NAT, respectively, but the middlebox will configure its
packet filter in addition to the performed NAT bindings. In case
of a firewall combined with a traditional NAT, the policy rule may
imply more than one enable action for the firewall configuration,
as incoming and outgoing packets may use different source-
destination pairs.
For middleboxes supporting interface specific policy rules, as
defined in Section 2.3.7, the optional inside and outside
interface parameters must both be included in the request, or
neither of them should be included. In the presence of these
parameters, the middlebox uses the outside interface parameter to
select the interface at which the outside address tuple (outside
IP address and port number) is bound, and the inside interface
parameter to select the interface at which the inside address
tuple (inside IP address and port number) is bound. Without the
presence of these parameters, the middlebox selects the particular
interfaces based on its internal configuration.
Checking the Policy Reservation Rule Identifier
If the parameter specifying the policy reservation rule
identifier is not empty, then the middlebox checks whether the
referenced policy rule exists, whether the agent is authorized
to replace this policy rule, and whether this policy rule is a
policy reserve rule.
In case of success, this transaction creates a new policy
enable rule. If a policy reserve rule was referenced, then the
policy reserve rule is terminated without an explicit
notification sent to the agent (other than the successful PER
reply).
The PRR transaction sets the internal endpoint A0 during the
reservation process. In the process of creating a new policy
enable rule, the middlebox may check whether the requested A0
is equal to the reserved A0. The middlebox may reject a PER
request with a requested A0 not equal to the reserved A0 and
must then send an appropriate failure message. Alternatively,
the middlebox may change A0 due to the PER request.
The middlebox generates a middlebox-unique identifier for the
new policy rule. If a policy reserve rule was referenced, then
the identifier of the policy reserve rule is reused.
The owner of the new policy rule is the authenticated agent
that sent the request.
Checking the Policy Rule Group Identifier
If no policy reserve rule was specified, then the policy rule
group parameter is checked. If a non-existing policy rule
group is specified, or if an existing policy rule group is
specified that is not owned by the requesting agent, then no
new policy rule is established, and an appropriate failure
reply is generated.
If an already existing policy rule group is specified, then the
new policy rule becomes a member. If no policy group is
specified, then a new group is created with the new policy rule
as its only member.
If the transport protocol parameter value is ’ANY’, then the
middlebox enables communication between the specified external IP
address and the specified internal IP address. The addresses to
be used by the communication partners to address each other are
returned to the agent as inside IP address and outside IP address.
If the reservation identifier is not empty and if the reservation
used the same transport protocol type, then the reserved IP
addresses are used.
For the transport protocol parameter values ’UDP’ and ’TCP’, the
middlebox acts analogously as for ’ANY’ but also maps ranges of
port numbers, keeping the port parity, if requested.
The configuration of the middlebox may fail because of lack of
resources, such as available IP addresses, port numbers, or
storage for further policy rules. It may also fail because of a
conflict with an established policy rule. In case of a conflict,
the first-come first-served mechanism is applied. Existing policy
rules remain unchanged and arriving new ones are rejected.
However, in case of a non-conflicting overlap of policy rules
(including identical policy rules), all policy rules are accepted.
The middlebox chooses a lifetime value that is greater than zero
and less than or equal to the minimum of the requested value and
the maximum lifetime specified by the middlebox at session
startup, i.e.,
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where
- lt_granted is the lifetime actually granted by the middlebox
- lt_requested is the lifetime the agent requested
- lt_maximum is the maximum lifetime specified at session
setup
In each case of failure, an appropriate failure reply is
generated. The policy reserve rule that is referenced in the PER
transaction is not affected in case of a failure within the PER
transaction -- i.e., the policy reserve rule remains.
After a new policy enable rule is successfully established and the
reply message has been sent to the requesting agent, the middlebox
checks whether there are other authenticated agents participating
in open sessions that can access the new policy rule. If the
middlebox finds one or more of these agents, then it sends a REN
message reporting the new policy rule to each of them.
2.3.10. Policy Rule Lifetime Change (RLC)
transaction-name: policy rule lifetime change
transaction-type: configuration
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
- policy rule identifier: Identifying the policy rule for which
the lifetime is requested to be changed. This may identify
either a policy reserve rule or a policy enable rule.
- policy rule lifetime: The new lifetime proposal for the policy
rule.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- policy rule lifetime: The remaining policy rule lifetime granted
by the middlebox.
failure reason:
- agent not authorized for this transaction
- agent not authorized to change lifetime of this policy
rule
- no such policy rule
- lifetime cannot be extended
notification message type: Policy Rule Event Notification (REN)
semantics:
The agent can use this transaction type to request the extension
of an established policy rule’s lifetime, the shortening of the
lifetime, or policy rule termination. Policy rule termination is
requested by suggesting a new policy rule lifetime of zero.
The middlebox first checks whether the specified policy rule
exists and whether the agent is authorized to access this policy
rule. If one of the checks fails, an appropriate failure reply is
generated. If the requested lifetime is longer than the current
one, the middlebox also checks whether the lifetime of the policy
rule may be extended and generates an appropriate failure message
if it may not.
A failure reply implies that the new lifetime was not accepted,
and the policy rule remains unchanged. A success reply is
generated by the middlebox if the lifetime of the policy rule was
changed in any way.
The success reply contains the new lifetime of the policy rule.
The middlebox chooses a lifetime value that is greater than zero
and less than or equal to the minimum of the requested value and
the maximum lifetime specified by the middlebox at session
startup, i.e.,
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
whereas
- lt_granted is the lifetime actually granted by the middlebox
- lt_requested is the lifetime the agent requested
- lt_maximum is the maximum lifetime specified at session
setup
After sending a success reply with a lifetime of zero, the
middlebox will consider the policy rule non-existent. Any further
transaction on this policy rule results in a negative reply,
indicating that this policy rule does not exist anymore.
Note that policy rule lifetime may also be changed by the Group
Lifetime Change (GLC) transaction, if applied to the group of
which the policy rule is a member.
After the remaining policy rule lifetime was successfully changed
and the reply message has been sent to the requesting agent, the
middlebox checks whether there are other authenticated agents
participating in open sessions that can access the policy rule.
If the middlebox finds one or more of these agents, then it sends
a REN message reporting the new remaining policy rule lifetime to
each of them.
2.3.11. Policy Rule List (PRL)
transaction-name: policy rule list
transaction-type: monitoring
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- policy list: List of policy rule identifiers of all policy rules
that the agent can access.
failure reason:
- transaction not supported
- agent not authorized for this transaction
semantics:
The agent can use this transaction type to list all policies that
it can access. Usually, the agent has this information already,
but in special cases (for example, after an agent fail-over) or
for special agents (for example, an administrating agent that can
access all policies) this transaction can be helpful.
The middlebox first checks whether the agent is authorized to
request this transaction. If the check fails, an appropriate
failure reply is generated. Otherwise a list of all policies the
agent can access is returned indicating the identifier and the
owner of each policy.
This transaction does not have any effect on the policy rule
state.
2.3.12. Policy Rule Status (PRS)
transaction-name: policy rule status
transaction-type: monitoring
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
- policy rule identifier: The middlebox-unique policy rule
identifier.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- policy rule owner: An identifier of the agent owning this policy
rule.
- group identifier: A reference to the group of which the policy
rule is a member.
- policy rule action: This parameter has either the value
’reserve’ or the value ’enable’.
- transport protocol: Identifies the protocol for which a
reservation is requested; see section 2.3.5.
- port range: The number of consecutive port numbers; see section
2.3.5.
- direction: The direction of the communication enabled by the
middlebox. Applicable only to policy enable rules.
- internal IP address version: The version of the internal IP
address (IP version of A0 in Figure 3).
- external IP address version: The version of the external IP
address (IP version of A3 in Figure 3).
- internal IP address: The IP address of the internal
communication endpoint (A0 in Figure 3); see section 2.3.5.
- internal port number: The port number of the internal
communication endpoint (A0 in Figure 3); see section 2.3.5.
- external IP address: The IP address of the external
communication endpoint (A3 in Figure 3); see section 2.3.5.
- external port number: The port number of the external
communication endpoint (A3 in Figure 3); see section 2.3.5.
- inside interface (optional): The inside interface at the
middlebox; see section 2.3.7.
- inside IP address: The internal IP address provided at the
inside of the NAT (A1 in Figure 3); see section 2.3.5.
- inside port number: The internal port number provided at the
inside of the NAT (A1 in Figure 3); see section 2.3.5.
- outside interface (optional): The outside interface at the
middlebox; see section 2.3.7.
- outside IP address: The external IP address provided at the
outside of the NAT (A2 in Figure 3); see section 2.3.5.
- outside port number: The external port number provided at the
outside of the NAT (A2 in Figure 3); see section 2.3.5.
- port parity: The parity of the allocated ports.
- service: The selected service in the case of mixed traditional
and twice-NAT middlebox (see section 2.3.8).
- policy rule lifetime: The remaining lifetime of the policy rule.
failure reason:
- transaction not supported