Depending on its input parameters, it may make use of the reservation
established by a PRR transaction or create a new rule from scratch.
On a NAT, the enable action is interpreted as a bind action
establishing bindings between internal and external addresses. At a
firewall, the enable action is interpreted as one or more allow
actions configuring pinholes. The number of allow actions depends on
the parameters of the request and the implementation of the firewall.
On a combined NAT/firewall, the enable action is interpreted as a
combination of bind and allow actions.
The PRR transaction and the PER transaction are described in more
detail in sections 2.3.8 and 2.3.9 below.
2.3.3. Maintaining Policy Rules and Policy Rule Groups
Each policy rule has a middlebox-unique identifier.
Each policy rule has an owner. Access control to the policy rule is
based on ownership (see section 2.1.5). Ownership of a policy rule
does not change during lifetime of the policy rule.
Each policy rule has an individual lifetime. If the policy rule
lifetime expires, the policy rule will be terminated at the
middlebox. Typically, the middlebox indicates termination of a
policy rule by an ARE transaction. A policy rule lifetime change
(RLC) transaction may extend the lifetime of the policy rule up to
the limit specified by the middlebox at session setup. Also an RLC
transaction may be used for shortening a policy rule’s lifetime or
deleting a policy rule by requesting a lifetime of zero. (Please
note that policy rule lifetimes may also be modified by the group
lifetime change (GLC) transaction.)
Each policy rule is a member of exactly one policy rule group. Group
membership does not change during the lifetime of a policy rule.
Selecting the group is part of the transaction establishing the
policy rule. This transaction implicitly creates a new group if the
agent does not specify one. The new group identifier is chosen by
the middlebox. New members are added to an existing group if the
agent’s request designates one. A group only exists as long as it
has member policy rules. As soon as all policies belonging to the
group have reached the ends of their lifetimes, the group does not
exist anymore.
Agents can explore the properties and status of all policy rules they
are allowed to access by using the Policy Rule Status (PRS)
transaction.
2.3.4. Policy Events and Asynchronous Notifications
If a policy rule changes its state or if its remaining lifetime is
changed in ways other than being decreased by time, then all agents
that can access this policy rule and that participate in an open
session with the middlebox are notified by the middlebox. If the
state or lifetime change was requested explicitly by a request
message, then the middlebox notifies the requesting agent by
returning the corresponding reply. All other agents that can access
the policy are notified by a Policy Rule Event Notification (REN)
message.
Note that a middlebox can serve multiple agents at the same time in
different parallel sessions. Between these agents, the sets of
policy rules that can be accessed by them may overlap. For example,
there might be an agent that authenticates as administrator and that
can access all policies of all agents. Or there could be a backup
agent running a session in parallel to a main agent and
authenticating itself as the same entity as the main agent.
In case of a PER, PRR, or RLC transaction, the requesting agent
receives a PER, PRR, or RLC reply, respectively. To all other agents
that can access the created, modified, or terminated policy rule (and
that participate in an open session with the middlebox) the middlebox
sends an REN message carrying the policy rule identifier (PID) and
the remaining lifetime of the policy rule.
In case of a rule termination by lifetime truncation or other events
not triggered by an agent, then the middlebox sends an REN message to
each agent that can access the particular policy rule and that
participates in an open session with the middlebox. This ensures
that an agent always knows the most recent state of all policy rules
it can access.
2.3.5. Address Tuples
Request and reply messages of the PRR, PER, and PRS transactions
contain address specifications for IP and transport addresses. These
parameters include
- IP version
- IP address
- IP address prefix length
- transport protocol
- port number
- port parity
- port range
Additionally, the request message of PER and the reply message of PRS
contain a direction of flow parameter. This direction of flow
parameter indicates for UDP and IP the direction of packets
traversing the middlebox. For ’inbound’, the UDP packets are
traversing from outside to inside; for ’outbound’, from inside to the
outside. In both cases, the packets can traverse the middelbox only
uni-directionally. A bi-directional flow is enabled through ’bi-
directional’ as direction of flow parameter. For TCP, the packet
flow is always bi-directional, but the direction of the flow
parameter is defined as
- inbound: bi-directional TCP packet flow. First packet, with TCP
SYN flag set and ACK flag not set, must arrive at the middlebox
at the outside interface.
- outbound: bi-directional TCP packet flow. First packet, with
TCP SYN flag set and ACK flag not set, must arrive at the
middlebox at the inside interface.
- bi-directional: bi-directional TCP packet flow. First packet,
with TCP SYN flag set and ACK flag not set, may arrive at inside
or outside interface.
We refer to the set of these parameters as an address tuple. An
address tuple specifies either a communication endpoint at an
internal or external device or allocated addresses at the middlebox.
In this document, we distinguish four kinds of address tuples, as
shown in Figure 3.
+----------+ +----------+
| internal | A0 A1 +-----------+ A2 A3 | external |
| endpoint +----------+ middlebox +----------+ endpoint |
+----------+ +-----------+ +----------+
Figure 3: Address tuples A0 - A3
- A0 -- internal endpoint: Address tuple A0 specifies a
communication endpoint of a device within -- with respect to the
middlebox -- the internal network.
- A1 -- middlebox inside address: Address tuple A1 specifies a
virtual communication endpoint at the middlebox within the
internal network. A1 is the destination address for packets
passing from the internal endpoint to the middlebox and is the
source for packets passing from the middlebox to the internal
endpoint.
- A2 -- middlebox outside address: Address tuple A2 specifies a
virtual communication endpoint at the middlebox within the
external network. A2 is the destination address for packets
passing from the external endpoint to the middlebox and is the
source for packets passing from the middlebox to the external
endpoint.
- A3 -- external endpoint: Address tuple A3 specifies a
communication endpoint of a device within -- with respect to the
middlebox -- the external network.
For a firewall, the inside and outside endpoints are identical to the
corresponding external or internal endpoints, respectively. In this
case the installed policy rule sets the same value in A2 as in A0
(A0=A2) and sets the same value in A1 as in A3 (A1=A3).
For a traditional NAT, A2 is given a value different from that of A0,
but the NAT binds them. As for the firewall, it is also as it is at
a traditional NAT: A1 has the same value as A3.
For a twice-NAT, there are two bindings of address tuples: A1 and A2
are both assigned values by the NAT. The middlebox outside address
A2 is bound to the internal endpoint A0, and the middlebox inside
address A1 is bound to the external endpoint A3.
2.3.6. Address Parameter Constraints
For transaction parameters belonging to an address tuple, some
constraints exist that are common for all messages using them.
Therefore, these constraints are summarized in the following and are
not repeated again when describing the parameters in the transaction
descriptions are presented.
The MIDCOM semantics defined in this document specifies the handling
of IPv4 and IPv6 as network protocols, and of TCP and UDP (over IPv4
and IPv6) as transport protocols. The handling of any other
transport protocol, e.g., SCTP, is not defined within the semantics
but may be supported by concrete protocol specifications.
The IP version parameter has either the value ’IPv4’ or ’IPv6’. In a
policy rule, the value of the IP version parameter must be the same
for address tuples A0 and A1, and for A2 and A3.
The value of the IP address parameter must conform with the specified
IP version.
The IP address of an address tuple may be wildcarded. Whether IP
address wildcarding is allowed or in which range it is allowed
depends on the local policy of the middlebox; see also section 6,
"Security Considerations". Wildcarding is specified by the IP
address prefix length parameter of an address tuple. In line with
the common use of a prefix length, this parameter indicates the
number of high significant bits of the IP address that are fixed,
while the remaining low significant bits of the IP address are
wildcarded.
The value of the transport protocol parameter can be either ’TCP’,
’UDP’, or ’ANY’. If the transport protocol parameter has the value
’ANY’, only IP headers are considered for packet handling in the
middlebox -- i.e., the transport header is not considered. The
values of the parameters port number, port range, and port parity are
irrelevant if the protocol parameter is ’ANY’. In a policy rule, the
value of the transport protocol parameter must be the same for all
address tuples A0, A1, A2, and A3.
The value of the port number parameter is either zero or a positive
integer. A positive integer specifies a concrete UDP or TCP port
number. The value zero specifies port wildcarding for the protocol
specified by the transport protocol parameter. If the port number
parameter has the value zero, then the value of the port range
parameter is irrelevant. Depending on the value of the transport
protocol parameter, this parameter may truly refer to ports or may
refer to an equivalent concept.
The port parity parameter is differently used in the context of
policy reserve rules (PRR) and policy enable rules (PER). In the
context of a PRR, the value of the parameter may be ’odd’, ’even’, or
’any’. It specifies the parity of the first (lowest) reserved port
number.
In the context of a PER, the port parity parameter indicates to the
middlebox whether port numbers allocated at the middlebox should have
the same parity as the corresponding internal or external port
numbers, respectively. In this context, the parameter has the value
’same’ or ’any’. If the value is ’same’, then the parity of the port
number of A0 must be the same as the parity of the port number of A2,
and the parity of the port number of A1 must be the same as the
parity of the port number of A3. If the port parity parameter has
the value ’any’, then there are no constraints on the parity of any
port number.
The port range parameter specifies a number of consecutive port
numbers. Its value is a positive integer. Like the port number
parameter, this parameter defines a set of consecutive port numbers
starting with the port number specified by the port number parameter
as the lowest port number and having as many elements as specified by
the port range parameter. A value of 1 specifies a single port
number. The port range parameter must have the same value for each
address tuple A0, A1, A2, and A3.
A single policy rule P containing a port range value greater than one
is equivalent to a set of policy rules containing a number n of
policies P_1, P_2, ..., P_n where n equals the value of the port
range parameter. Each policy rule P_1, P_2, ..., P_n has a port
range parameter value of 1. Policy rule P_1 contains a set of
address tuples A0_1, A1_1, A2_1, and A3_1, each of which contains the
first port number of the respective address tuples in P; policy rule
P_2 contains a set of address tuples A0_2, A1_2, A2_2, and A3_2, each
of which contains the second port number of the respective address
tuples in P; and so on.
2.3.7. Interface-specific Policy Rules
Usually agents request policy rules with the knowledge of A0 and A3
only, i.e., the address tuples (see section 2.3.5). But in very
special cases, agents may need to select the interfaces to which the
requested policy rule is bound. Generally, the middlebox is careful
about choosing the right interfaces when reserving or enabling a
policy rule, as it has the overall knowledge about its configuration.
For agents that want to select the interfaces, optional parameters
are included in the Policy Reserve Rule (PRR) and Policy Enable Rule
(PER) transactions. These parameters are called
- inside interface: The selected interface at the inside of the
middlebox -- i.e., in the private or protected address realm.
- outside interface: The selected interface at the outside of the
middlebox -- i.e., in the public address realm.
The Policy Rule Status (PRS) transactions include these optional
parameters in its replies when they are supported.
Agents can learn at session startup whether interface-specific policy
rules are supported by the middlebox, by checking the middlebox
capabilities (see section 2.1.6).
2.3.8. Policy Reserve Rule (PRR)
transaction-name: policy reserve rule
transaction-type: configuration
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
- group identifier: A reference to the group of which the policy
reserve 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.
- service: The requested NAT service of the middlebox. Allowed
values are ’traditional’ or ’twice’.
- 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.
- outside interface (optional): Interface at the outside of the
middlebox; see Section 2.3.7.
- 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 first (lowest) port
number to be reserved; allowed values for this parameter are
’odd’, ’even’, and ’any’. See also section 2.3.5.
- 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, particularly to
refer to the policy reserve rule in a subsequent PER
transaction.
- group identifier: A reference to the group of which the policy
reserve rule is a member.
- reserved inside IP address: The reserved IPv4 or IPv6 address on
the internal side of the middlebox. For an outbound flow, this
will be the destination to which the internal endpoint sends its
packets (A1 in Figure 3). For an inbound flow, it will be the
apparent source address of the packets as forwarded to the
internal endpoint (A0 in Figure 3). The middlebox reserves and
reports an internal address only in the case where twice-NAT is
in effect. Otherwise, an empty value for the addresses
indicates that no internal reservation was made. See also
Section 2.3.5.
- reserved inside port number: See section 2.3.5.
- reserved outside IP address: The reserved IPv4 or IPv6 address
on the external side of the middlebox. For an inbound flow,
this will be the destination to which the external endpoint
sends its packets (A2 in Figure 4). For an outbound flow, it
will be the apparent source address of the packets as forwarded
to the external endpoint (A3 in Figure 3). If the middlebox is
configured as a pure firewall, an empty value for the addresses
indicates that no external reservation was made. See also
section 2.3.5.
- reserved outside port number: See section 2.3.5.
- policy rule lifetime: The policy rule lifetime granted by the
middlebox, after which the reservation will be revoked if it has
not been replaced already by a policy enable rule in a PER
transaction.
failure reason:
- agent not authorized for this transaction
- agent not authorized to add members to this group
- lack of IP addresses
- lack of port numbers
- lack of resources
- specified inside/outside interface does not exist
- specified inside/outside interface not available for specified
service
notification message type: Policy Rule Event Notification (REN)
semantics:
The agent can use this transaction type to reserve an IP address
or a combination of IP address, transport type, port number, and
port range at neither side, one side, or both sides of the
middlebox as required to support the enabling of a flow.
Typically the PRR will be used in scenarios where it is required
to perform such a reservation before sufficient parameters for a
complete policy enable rule transaction are available. See
section 4.2 for an example.
When receiving the request, the middlebox determines how many
address (and port) reservations are required based on its
configuration. If it provides only packet filter services, it
does not perform any reservation and returns empty values for the
reserved inside and outside IP addresses and port numbers. If it
is configured for twice-NAT, it reserves both inside and outside
IP addresses (and an optional range of port numbers) and returns
them. Otherwise, it reserves and returns an outside IP address
(and an optional range of port numbers) and returns empty values
for the reserved inside address and port range.
The A0 parameter (inside IP address version, inside IP address,
and inside port number) can be used by the middlebox to determine
the correct NAT mapping and thus A2 if necessary. Once a PRR
transaction has reserved an outside address (A2) for an internal
end point (A0) at the middlebox, the middlebox must ensure that
this reserved A2 is available in any subsequent PER and PRR
transaction.
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 reserved, and the inside interface
parameter to select the interface at which the inside address
tuple (inside IP address and port number) is reserved. Without
the presence of these parameters, the middlebox selects the
particular interfaces based on its internal configuration.
If there is a lack of resources, such as available IP addresses,
port numbers, or storage for further policy rules, then the
reservation fails, and an appropriate failure reply is generated.
If a non-existing policy rule group was specified, or if an
existing policy rule group was specified that is not owned by the
requesting agent, then no new policy rule is established, and an
appropriate failure reply is generated.
In case of success, this transaction creates a new policy reserve
rule. If an already existing policy rule group is specified, then
the new policy rule becomes a member of it. If no policy group is
specified, a new group is created with the new policy rule as its
only member. The middlebox generates a middlebox-unique
identifier for the new policy rule. The owner of the new policy
rule is the authenticated agent that sent the request. 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
A middlebox with NAT capability always reserves a middlebox
external address tuple (A2) in response to a PRR request. In the
special case of a combined twice-NAT/NAT middlebox, the agent can
request only NAT service or twice-NAT service by choosing the
service parameter ’traditional’ or ’twice’, respectively. An
agent that does not have any preference chooses ’twice’. The
’traditional’ value should only be used in order to select
traditional NAT service at middleboxes offering both traditional
NAT and twice NAT. In the ’twice’ case, the combined twice-
NAT/NAT middlebox reserves A2 and A1; the ’traditional’ case
results in a reservation of A2 only. An agent
must always use the PRR transaction for choosing NAT only or
twice-NAT service in the special case of a combined twice-NAT/NAT
middlebox. A firewall middlebox ignores this parameter.
If the protocol identifier is ’ANY’, then the middlebox reserves