8.3.  Processing PER Requests

   Processing PER requests is much simpler on pure firewalls than on
   middleboxes with NAT functions.  Therefore, this section has three
   sub-sections: The first one describes initial checks that are
   performed in any case.  The second sub-section describes processing
   of PER requests on pure firewalls, and the third one describes
   processing on all devices with NAT functions.

8.3.1.  Initial Checks

   When a middlebox receives a PER request message, it first checks if
   the authenticated agent is authorized for requesting middlebox
   configurations for enabling communication.  If not, it returns a
   negative reply message of type 'agent not authorized for this
   transaction' (0x0341).

   If the request contains the optional group identifier, then the
   middlebox checks if the group already exists.  If not, the middlebox
   returns a negative reply message of type 'specified policy rule group
   does not exist' (0x0344).

   If the request contains the optional group identifier, then the
   middlebox checks if the authenticated agent is authorized for adding
   members to this group.  If not, the middlebox returns a negative
   reply message of type 'not authorized for accessing specified group'
   (0x0346).

   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.

   If the direction parameter field in the PER parameter set attribute
   has the value 'bi-directional', then only transport protocol
   wildcarding is allowed.  If any other kind of wildcarding is
   specified in one or both of the IP address tuple attributes, then the
   middlebox returns a negative reply message of type 'inconsistent
   request' (0x034B).

   If the PER 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 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.3.2.  Processing on Pure Firewalls

   If the middlebox is acting 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 (for example, because the pinhole 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 enable rule and assigns to it a policy rule identifier in
   state ENABLED.  It 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.

   If a group identifier attribute is contained in the PER request, then
   the middlebox adds the new policy rule to the members of this group.
   If the PRR request does not contain a group identifier attribute,
   then the middlebox creates a new group with the new policy rule as

   the only member.  In any case, the middlebox reports the group of
   which the new policy rule is a member 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 address tuple (outside) attribute of the PER reply.  The address
   tuple (external) attribute of the PER request is reported as address
   tuple (inside) attribute of the PER reply.

8.3.3.  Processing on Network Address Translators

   If the middlebox is configured as a NAT, then it tries to configure
   the requested NAT binding.  The actions taken by the NAT are quite
   similar to the actions of the Policy Reserve Rule (PRR) request, but
   in the PER request a NAT binding is enabled.

   The following actions are performed, depending on the middlebox NAT
   type:

     - traditional NAT
       A NAT binding is established between the internal and external
       address tuple with the requested transport protocol, port range,
       direction, and port parity.  The outside address tuple is
       created.

     - twice NAT
       A NAT binding is established between the internal and external
       address tuple with the requested transport protocol, port range,
       and port parity.  But two address tuples are created: an outside
       address tuple and an inside address tuple.

   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 enable rule and assigns to it a policy rule identifier in
   state ENABLED.  It 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.

   If a group identifier attribute is contained in the PER request, then
   the middlebox adds the new policy rule to the members of this group.
   If the PRR request does not contain a group identifier attribute,

   then the middlebox creates a new group with the new policy rule as
   the only member.  In any case, the middlebox reports the group of
   which the new policy rule is a member in the group identifier
   attribute of the PER reply.

   The chosen lifetime is reported in the lifetime attribute of the PER
   reply.

   In the address tuple (outside) attribute of the PER reply, the first
   parameter field is set to 'full addresses' (0x0).  The location
   parameter field is set to 'outside' (0x02).  The IP version parameter
   field is set according to the IP version parameter field in the PER
   parameter set attribute of the PER request message.  For IPv4
   addresses, the prefix length field is set to 0x20 to indicate a full
   address, and the reserved outside IPv4 address is set in the address
   field.  For IPv6 addresses, the prefix length field is set to 0x80 to
   indicate a full address, and the reserved outside IPv6 address is set
   in the address field.  The transport protocol parameter field in the
   address tuple (outside) attribute of the PER reply is set identically
   to the transport protocol attribute in the PER parameter set
   attribute of the PER request message.  The reserved outside base port
   number (i.e., the lowest port number of the allocated range) is
   stored in the port number parameter field, and the allocated port
   range is stored in the port range parameter field.

   The address tuple (inside) is only returned if the middlebox is a
   twice NAT; otherwise, it is omitted.  In the address tuple (inside)
   attribute of the PER reply, the first parameter field is set to 'full
   addresses' (0x0).  The location parameter field is set to 'inside'
   (0x01).  The IP version parameter field is set according to the IP
   version parameter field in the PER parameter set attribute of the PER
   request message.  For IPv4 addresses, the prefix length field is set
   to 0x20 to indicate a full address, and the reserved inside IPv4
   address is set in the address field.  For IPv6 addresses, the prefix
   length field is set to 0x80 to indicate a full address, and the
   reserved inside IPv6 address is set in the address field.  The
   transport protocol parameter field in the address tuple (inside)
   attribute of the PER reply is set identically to the transport
   protocol attribute in the PER parameter set attribute of the PER
   request message.  The reserved inside base port number (i.e., the
   lowest port number of the allocated range) is stored in the port
   number parameter field, and the allocated port range is stored in the
   port range parameter field.

8.3.4.  Processing on Combined Firewalls and NATs

   Middleboxes that are combinations of firewalls and NATs are
   configured in such a way that first the NAT bindings are configured
   and afterwards the firewall pinholes.  This sequence is needed since
   the firewall rules must be configured according to the outside
   address tuples and for twice NATs the inside address tuples as well.
   This aspect of middlebox operation may be irrelevant to SIMCO, since
   some NATs already do firewall configuration on their own.

8.4.  Processing PEA Requests

   Processing PEA requests is much simpler on pure firewalls than on
   middleboxes with NAT functions.  Therefore, this section has three
   sub-sections: The first one describes initial checks that are
   performed in any case.  The second sub-section describes processing
   of PEA requests on pure firewalls, and the third one describes
   processing on all devices with NAT functions.

8.4.1.  Initial Checks

   When a middlebox receives a PEA request message, it first checks if
   the authenticated agent is authorized for requesting middlebox
   configurations for enabling communication.  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 PEA 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 there exists a
   policy with this identifier and if it is in a state other than
   RESERVED, then the middlebox returns a negative reply message of type
   'inconsistent request' (0x034B).

   If a policy rule with this identifier exists, but the authenticated
   agent is not authorized for terminating this policy reserve rule,
   then the middlebox returns a negative reply message of type 'agent
   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
   entity looks quite counterproductive on the first glimpse, since an
   attacker using this can possibly configure the middlebox in such way
   that no filtering is applied anymore or that NAT bindings are
   configured for malicious use.  So the middlebox is not performing the
   intended function anymore.  Possible threats to SIMCO are:

     - Man-in-the-middle attack
       A malicious host intercepts messages exchanged between then SIMCO
       agent and middlebox and can change the content of the messages on
       the fly.  This man-in-the-middle attack would result, from the
       agent's view, in a proper middlebox configuration, but the
       middlebox would not be configured accordingly.  The man in the
       middlebox could open pinholes that compromise the protected
       network's security.

     - Changing content
       The message content could be changed in such a way that the
       requested policy rule configuration is not configured in the
       middlebox, but that any other unwanted configuration could be.
       That way, an attacker can open the firewall for his own traffic.

     - Replaying
       Already sent messages could be re-sent in order to configure the
       middlebox in such a way that hosts could configure policy rules
       without the permission of an application-level gateway or system
       administrator.

     - Wiretapping
       An already configured policy rule could be re-used by other hosts
       if the policy rule is configured with too broad a wildcarding
       (see below).  These hosts could send unwanted traffic.

9.2.  Securing SIMCO with IPsec

   The previous subsection identifies several issues on security for
   SIMCO.  SIMCO can rely on IPsec mechanisms, as defined in [RFC4302]
   and [RFC4303], for ensuring proper operations.

   When SIMCO relies on IPsec, it uses IPsec in transport mode with an
   authentication header (AH) [RFC4302] and an encapsulating security
   payload (ESP) [RFC4303], so that IP traffic between SIMCO agent and
   middlebox is protected.  The authentication header is used for
   protecting the whole packet against content changes and replaying.
   The ESP header is used to prevent wiretapping.

   At either the agent or middlebox side, the following should be pre-
   configured: the IP addresses of the agent or middlebox, TCP (as the
   transport protocol), and the port numbers (if possible).  Only
   packets from the pre-configured address of the agents or middlebox
   should be accepted.

   The keys for authentication for both the SIMCO agent and middlebox
   are pre-configured at each side.  For replay protection, the use of a
   key management system is recommended.  For the Internet Key Exchange
   (IKE) protocol, see [RFC4306].

10.  IAB Considerations on UNSAF

   UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a
   process at originating endpoints that attempt to determine or fix the
   address (and port) by which they are known to another endpoint.
   UNSAF proposals, such as STUN [RFC3489], are considered a general
   class of work-arounds for NAT traversal and solutions for scenarios
   with no middlebox communication (MIDCOM).

   This document describes a protocol implementation of the MIDCOM
   semantics and thus implements a middlebox communication (MIDCOM)
   solution.  MIDCOM is not intended as a short-term work-around, but
   more as a long-term solution for middlebox communication.  In MIDCOM,
   endpoints are not involved in allocating, maintaining, and deleting
   addresses and ports at the middlebox.  The full control of addresses
   and ports at the middlebox is located at the SIMCO server.

   Therefore, this document addresses the UNSAF considerations in
   [RFC3424] by proposing a long-term alternative solution.

11.  Acknowledgements

   The authors would like to thank Sebastian Kiesel and Andreas Mueller
   for valuable feedback from their SIMCO implementation and Mary Barnes
   for a thorough document review.

12.  Normative References

   [RFC3989]   Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
               Communications (MIDCOM) Protocol Semantics", RFC 3989,
               February 2005.

   [RFC4302]   Kent, S., "IP Authentication Header", RFC 4302, December
               2005.

   [RFC4303]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
               4303, December 2005.

   [RFC4346]   Dierks, T. and E. Rescorla, "The Transport Layer Security
               (TLS) Protocol Version 1.1", RFC 4346, April 2006.

13.  Informative References

   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
               September 1981.

   [RFC1519]   Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
               Inter-Domain Routing (CIDR): an Address Assignment and
               Aggregation Strategy", RFC 1519, September 1993.

   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.

   [RFC2663]   Srisuresh, P. and M. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations", RFC
               2663, August 1999.

   [RFC3234]   Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
               Issues", RFC 3234, February 2002.

   [RFC3303]   Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
               and A. Rayhan, "Middlebox communication architecture and
               framework", RFC 3303, August 2002.

   [RFC3424]   Daigle, L. and IAB, "IAB Considerations for UNilateral
               Self-Address Fixing (UNSAF) Across Network Address
               Translation", RFC 3424, November 2002.

   [RFC3489]   Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
               "STUN - Simple Traversal of User Datagram Protocol (UDP)
               Through Network Address Translators (NATs)", RFC 3489,
               March 2003.

   [RFC3932]   Alvestrand, H., "The IESG and RFC Editor Documents:
               Procedures", BCP 92, RFC 3932, October 2004.

   [RFC4291]   Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 4291, February 2006.

   [RFC4306]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
               RFC 4306, December 2005.

Authors' Addresses

   Martin Stiemerling
   NEC Europe Ltd.
   Network Laboratories Europe
   Kurfuersten-Anlage 36
   69115 Heidelberg
   Germany

   Phone: +49 6221 4342-113
   EMail: stiemerling@netlab.nec.de


   Juergen Quittek
   NEC Europe Ltd.
   Network Laboratories Europe
   Kurfuersten-Anlage 36
   69115 Heidelberg
   Germany

   Phone: +49 6221 4342-115
   EMail: quittek@netlab.nec.de


   Cristian Cadar
   Muelheimer Strasse 23
   40239 Duesseldorf
   Germany

   EMail: ccadar2@yahoo.com

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).