Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4540

NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0

Pages: 67
Experimental
Updated by:  8996
Part 3 of 3 – Pages 45 to 67
First   Prev   None

Top   ToC   RFC4540 - Page 45   prevText

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.
Top   ToC   RFC4540 - Page 46

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.
Top   ToC   RFC4540 - Page 47
     - 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).
Top   ToC   RFC4540 - Page 48
   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
Top   ToC   RFC4540 - Page 49
   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,
Top   ToC   RFC4540 - Page 50
   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.
Top   ToC   RFC4540 - Page 51

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).
Top   ToC   RFC4540 - Page 52
   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.
Top   ToC   RFC4540 - Page 53
   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
Top   ToC   RFC4540 - Page 54
   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.
Top   ToC   RFC4540 - Page 55

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.
Top   ToC   RFC4540 - Page 56

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.
Top   ToC   RFC4540 - Page 57
   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.
Top   ToC   RFC4540 - Page 58

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.
Top   ToC   RFC4540 - Page 59
   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.
Top   ToC   RFC4540 - Page 60
     - 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.
Top   ToC   RFC4540 - Page 61

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.
Top   ToC   RFC4540 - Page 62

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.
Top   ToC   RFC4540 - Page 63

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.
Top   ToC   RFC4540 - Page 64
   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.
Top   ToC   RFC4540 - Page 65

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.
Top   ToC   RFC4540 - Page 66
   [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
Top   ToC   RFC4540 - Page 67
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).