Signaling Session Lifetime Object

The signaling session lifetime object carries the requested or granted lifetime of a NATFW NSLP signaling session measured in seconds.

Type: NATFW_LT (0x00C) Length: 1

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| NATFW NSLP signaling session lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 22: Signaling Session Lifetime Object 4.2.2. External Address Object

The external address object can be included in RESPONSE messages (Section 4.3.3) only. It carries the publicly reachable IP address, and if applicable port number, at an edge-NAT.

Type: NATFW_EXTERNAL_IP (0x00D) Length: 2

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| port number |IP-Ver | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 23: External Address Object for IPv4 Addresses

Please note that the field ’port number’ MUST be set to 0 if only an IP address has been reserved, for instance, by a traditional NAT. A port number of 0 MUST be ignored in processing this object.

IP-Ver (4 bits): The IP version number. This field MUST be set to 4.

4.2.3. External Binding Address Object

The external binding address object can be included in RESPONSE messages (Section 4.3.3) and EXTERNAL (Section 3.7.2) messages. It carries one or multiple external binding addresses, and if applicable port number, for multi-level NAT deployments (for an example, see Section 2.5). The utilization of the information carried in this object is described in Appendix B.

Type: NATFW_EXTERNAL_BINDING (0x00E) Length: 1 + number of IPv4 addresses

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| port number |IP-Ver | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| IPv4 address #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

// . . . //

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| IPv4 address #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 24: External Binding Address Object

Please note that the field ’port number’ MUST be set to 0 if only an IP address has been reserved, for instance, by a traditional NAT. A port number of 0 MUST be ignored in processing this object.

IP-Ver (4 bits): The IP version number. This field MUST be set to 4.

4.2.4. Extended Flow Information Object

In general, flow information is kept in the message routing information (MRI) of the NTLP. Nevertheless, some additional

information may be required for NSLP operations. The ’extended flow information’ object carries this additional information about the action of the policy rule for firewalls/NATs and a potential contiguous port.

Type: NATFW_EFI (0x00F) Length: 1

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| rule action | sub_ports | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 25: Extended Flow Information

This object has two fields, ’rule action’ and ’sub_ports’. The ’rule action’ field has these meanings:

o 0x0001: Allow: A policy rule with this action allows data traffic to traverse the middlebox and the NATFW NSLP MUST allow NSLP signaling to be forwarded.

o 0x0002: Deny: A policy rule with this action blocks data traffic from traversing the middlebox and the NATFW NSLP MUST NOT allow NSLP signaling to be forwarded.

If the ’rule action’ field contains neither 0x0001 nor 0x0002, an error RESPONSE of class ’Signaling session failure’ (7) with response code ’Unknown policy rule action’ (0x05) MUST be generated.

The ’sub_ports’ field contains the number of contiguous transport layer ports to which this rule applies. The default value of this field is 0, i.e., only the port specified in the NTLP’s MRM or NATFW_DTINFO object is used for the policy rule. A value of 1 indicates that additionally to the port specified in the NTLP’s MRM (port1), a second port (port2) is used. This value of port 2 is calculated as: port2 = port1 + 1. Other values than 0 or 1 MUST NOT be used in this field and an error RESPONSE of class ’Signaling

session failure’ (7) with response code ’Requested value in sub_ports field in NATFW_EFI not permitted’ (0x08) MUST be generated. These two contiguous numbered ports can be used by legacy voice over IP equipment. This legacy equipment assumes two adjacent port numbers for its RTP/RTCP flows, respectively.

4.2.5. Information Code Object

This object carries the response code in RESPONSE messages, which indicates either a successful or failed CREATE or EXTERNAL message depending on the value of the ’response code’ field. This object is also carried in a NOTIFY message to specify the reason for the

notification.

Type: NATFW_INFO (0x010) Length: 1

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Resv. | Class | Response Code |r|r|r|r| Object Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 26: Information Code Object

The field ’resv.’ is reserved for future extensions and MUST be set to zero when generating such an object and MUST be ignored when receiving. The ’Object Type’ field contains the type of the object causing the error. The value of ’Object Type’ is set to 0, if no object is concerned. The leading fours bits marked with ’r’ are always set to zero and ignored. The 4-bit class field contains the error class. The following classes are defined:

o 0: Reserved

o 1: Informational (NOTIFY only) o 2: Success

o 3: Protocol error o 4: Transient failure o 5: Permanent failure

o 7: Signaling session failure

Within each error class a number of responses codes are defined as follows.

o Informational:

* 0x01: Route change: possible route change on the outbound path.

* 0x02: Re-authentication required.

* 0x03: NATFW node is going down soon.

* 0x04: NATFW signaling session lifetime expired.

* 0x05: NATFW signaling session terminated.

o Success:

* 0x01: All successfully processed.

o Protocol error:

* 0x01: Illegal message type: the type given in the Message Type field of the NSLP header is unknown.

* 0x02: Wrong message length: the length given for the message in the NSLP header does not match the length of the message data.

* 0x03: Bad flags value: an undefined flag or combination of flags was set in the NSLP header.

* 0x04: Mandatory object missing: an object required in a message of this type was missing.

* 0x05: Illegal object present: an object was present that must not be used in a message of this type.

* 0x06: Unknown object present: an object of an unknown type was present in the message.

* 0x07: Wrong object length: the length given for the object in the object header did not match the length of the object data present.

* 0x08: Unknown object field value: a field in an object had an unknown value.

* 0x09: Invalid Flag-Field combination: An object contains an invalid combination of flags and/or fields.

* 0x0A: Duplicate object present.

* 0x0B: Received EXTERNAL request message on external side.

o Transient failure:

* 0x01: Requested resources temporarily not available.

o Permanent failure:

* 0x01: Authentication failed.

* 0x02: Authorization failed.

* 0x04: Internal or system error.

* 0x06: No edge-device here.

* 0x07: Did not reach the NR.

o Signaling session failure:

* 0x01: Session terminated asynchronously.

* 0x02: Requested lifetime is too big.

* 0x03: No reservation found matching the MRI of the CREATE request.

* 0x04: Requested policy rule denied due to policy conflict.

* 0x05: Unknown policy rule action.

* 0x06: Requested rule action not applicable.

* 0x07: NATFW_DTINFO object is required.

* 0x08: Requested value in sub_ports field in NATFW_EFI not permitted.

* 0x09: Requested IP protocol not supported.

* 0x0A: Plain IP policy rules not permitted -- need transport layer information.

* 0x0B: ICMP type value not permitted.

* 0x0C: Source IP address range is too large.

* 0x0D: Destination IP address range is too large.

* 0x0E: Source L4-port range is too large.

* 0x0F: Destination L4-port range is too large.

* 0x10: Requested lifetime is too small.

* 0x11: Modified lifetime is too big.

* 0x12: Modified lifetime is too small.

4.2.6. Nonce Object

This object carries the nonce value as described in Section 3.7.6.

Type: NATFW_NONCE (0x011) Length: 1

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 27: Nonce Object 4.2.7. Message Sequence Number Object

This object carries the MSN value as described in Section 3.5.

Type: NATFW_MSN (0x012) Length: 1

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| message sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 28: Message Sequence Number Object 4.2.8. Data Terminal Information Object

The ’data terminal information’ object carries additional information that MUST be included the EXTERNAL message. EXTERNAL messages are transported by the NTLP using the Loose-End message routing method (LE-MRM). The LE-MRM contains only the DR’s IP address and a signaling destination address (destination IP address). This destination IP address is used for message routing only and is not necessarily reflecting the address of the data sender. This object contains information about (if applicable) DR’s port number (the destination port number), the DS’s port number (the source port number), the used transport protocol, the prefix length of the IP address, and DS’s IP address.

Type: NATFW_DTINFO (0x013)

Length: variable. Maximum 3.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|I|P|S| reserved | sender prefix | protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: DR port number | DS port number : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: IPsec-SPI : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| data sender’s IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 29: Data Terminal IPv4 Address Object The flags are:

o I: I=1 means that ’protocol’ should be interpreted.

o P: P=1 means that ’dst port number’ and ’src port number’ are present and should be interpreted.

o S: S=1 means that SPI is present and should be interpreted.

The SPI field is only present if S is set. The port numbers are only present if P is set. The flags P and S MUST NOT be set at the same time. An error RESPONSE of class ’Protocol error’ (3) with response code ’Invalid Flag-Field combination’ (0x09) MUST be generated if they are both set. If either P or S is set, I MUST be set as well and the protocol field MUST carry the particular protocol. An error RESPONSE of class ’Protocol error’ (3) with response code ’Invalid Flag-Field combination’ (0x09) MUST be generated if S or P is set but I is not set.

The fields MUST be interpreted according to these rules:

o (data) sender prefix: This parameter indicates the prefix length of the ’data sender’s IP address’ in bits. For instance, a full IPv4 address requires ’sender prefix’ to be set to 32. A value of 0 indicates an IP address wildcard.

o protocol: The IP protocol field. This field MUST be interpreted if I=1; otherwise, it MUST be set to 0 and MUST be ignored.

o DR port number: The port number at the data receiver (DR), i.e., the destination port. A value of 0 indicates a port wildcard, i.e., the destination port number is not known. Any other value indicates the destination port number.

o DS port number: The port number at the data sender (DS), i.e., the source port. A value of 0 indicates a port wildcard, i.e., the source port number is not known. Any other value indicates the source port number.

o data sender’s IPv4 address: The source IP address of the data sender. This field MUST be set to zero if no IP address is provided, i.e., a complete wildcard is desired (see the dest prefix field above).

4.2.9. ICMP Types Object

The ’ICMP types’ object contains additional information needed to configure a NAT of firewall with rules to control ICMP traffic. The object contains a number of values of the ICMP Type field for which a filter action should be set up:

Type: NATFW_ICMP_TYPES (0x014)

Length: Variable = ((Number of Types carried + 1) + 3) DIV 4 Where DIV is an integer division.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Count | Type | Type | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ... | Type | (Padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 30: ICMP Types Object

The fields MUST be interpreted according to these rules:

count: 8-bit integer specifying the number of ’Type’ entries in the object.

type: 8-bit field specifying an ICMP Type value to which this rule applies.

padding: Sufficient 0 bits to pad out the last word so that the total size of the object is an even multiple of words. Ignored on reception.

4.3. Message Formats

This section defines the content of each NATFW NSLP message type.

The message types are defined in Section 4.1.

Basically, each message is constructed of an NSLP header and one or more NSLP objects. The order of objects is not defined, meaning that objects may occur in any sequence. Objects are marked either with mandatory (M) or optional (O). Where (M) implies that this

particular object MUST be included within the message and where (O) implies that this particular object is OPTIONAL within the message.

Objects defined in this memo always carry the flag combination AB=00 in the NSLP object header. An error RESPONSE message of class

’Protocol error’ (3) with response code ’Mandatory object missing’

(0x04) MUST be generated if a mandatory declared object is missing.

An error RESPONSE message of class ’Protocol error’ (3) with response code ’Illegal object present’ (0x05) MUST be generated if an object was present that must not be used in a message of this type. An error RESPONSE message of class ’Protocol error’ (3) with response code ’Duplicate object present’ (0x0A) MUST be generated if an object appears more than once in a message.

Each section elaborates the required settings and parameters to be set by the NSLP for the NTLP, for instance, how the message routing information is set.

4.3.1. CREATE

The CREATE message is used to create NATFW NSLP signaling sessions and to create policy rules. Furthermore, CREATE messages are used to refresh NATFW NSLP signaling sessions and to delete them.

The CREATE message carries these objects:

o Signaling Session Lifetime object (M) o Extended flow information object (M) o Message sequence number object (M)

o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise (O)

o ICMP Types Object (O)

The message routing information in the NTLP MUST be set to DS as source IP address and DR as destination IP address. All other

parameters MUST be set according to the required policy rule. CREATE messages MUST be transported by using the path-coupled MRM with the direction set to ’downstream’ (outbound).

4.3.2. EXTERNAL

The EXTERNAL message is used to a) reserve an external IP address/

port at NATs, b) to notify firewalls about NSIS capable DRs, or c) to block incoming data traffic at inbound firewalls.

The EXTERNAL message carries these objects:

o Signaling Session Lifetime object (M) o Message sequence number object (M) o Extended flow information object (M) o Data terminal information object (M)

o Nonce object (M) if P flag set to 1 in the NSLP header, otherwise (O)

o ICMP Types Object (O)

o External binding address object (O)

The selected message routing method of the EXTERNAL message depends on a number of considerations. Section 3.7.2 describes exhaustively how to select the correct method. EXTERNAL messages can be

transported via the path-coupled message routing method (PC-MRM) or via the loose-end message routing method (LE-MRM). In the case of PC-MRM, the source-address is set to the DS’s address and the

destination-address is set to the DR’s address, the direction is set to inbound. In the case of LE-MRM, the destination-address is set to the DR’s address or to the signaling destination IP address. The source-address is set to the DS’s address.

4.3.3. RESPONSE

RESPONSE messages are responses to CREATE and EXTERNAL messages.

RESPONSE messages MUST NOT be generated for any other message, such as NOTIFY and RESPONSE.

The RESPONSE message for the class ’Success’ (2) carries these objects:

o Signaling Session Lifetime object (M) o Message sequence number object (M) o Information code object (M)

o External address object (O)

o External binding address object (O)

The RESPONSE message for other classes than ’Success’ (2) carries these objects:

o Message sequence number object (M) o Information code object (M)

o Signaling Session Lifetime object (O)

This message is routed towards the NI hop-by-hop, using existing NTLP messaging associations. The MRM used for this message MUST be the same as MRM used by the corresponding CREATE or EXTERNAL message.

4.3.4. NOTIFY

The NOTIFY messages is used to report asynchronous events happening along the signaled path to other NATFW NSLP nodes.

The NOTIFY message carries this object:

o Information code object (M)

The NOTIFY message is routed towards the next NF, NI, or NR hop using the existing inbound or outbound node messaging association entry within the node’s Message Routing State table. The MRM used for this message MUST be the same as MRM used by the corresponding CREATE or EXTERNAL message.

5. Security Considerations

Security is of major concern particularly in the case of firewall traversal. This section provides security considerations for the NAT/firewall traversal and is organized as follows.

In Section 5.1, we describe how the participating entities relate to each other from a security point of view. That subsection also motivates a particular authorization model.

Security threats that focus on NSIS in general are described in [RFC4081] and they are applicable to this document as well.

Finally, we illustrate how the security requirements that were created based on the security threats can be fulfilled by specific security mechanisms. These aspects will be elaborated in

Section 5.2.

5.1. Authorization Framework

The NATFW NSLP is a protocol that may involve a number of NSIS nodes and is, as such, not a two-party protocol. Figures 1 and 2 of

[RFC4081] already depict the possible set of communication patterns.

In this section, we will re-evaluate these communication patterns with respect to the NATFW NSLP protocol interaction.

The security solutions for providing authorization have a direct impact on the treatment of different NSLPs. As it can be seen from the QoS NSLP [RFC5974] and the corresponding Diameter QoS work [RFC5866], accounting and charging seems to play an important role for QoS reservations, whereas monetary aspects might only indirectly effect authorization decisions for NAT and firewall signaling.

Hence, there are differences in the semantics of authorization handling between QoS and NATFW signaling. A NATFW-aware node will most likely want to authorize the entity (e.g., user or machine) requesting the establishment of pinholes or NAT bindings. The outcome of the authorization decision is either allowed or

disallowed, whereas a QoS authorization decision might indicate that a different set of QoS parameters is authorized (see [RFC5866] as an example).

5.1.1. Peer-to-Peer Relationship

Starting with the simplest scenario, it is assumed that neighboring nodes are able to authenticate each other and to establish keying material to protect the signaling message communication. The nodes will have to authorize each other, additionally to the

authentication. We use the term ’Security Context’ as a placeholder for referring to the entire security procedure, the necessary

infrastructure that needs to be in place in order for this to work (e.g., key management) and the established security-related state.

The required long-term keys (symmetric or asymmetric keys) used for authentication either are made available using an out-of-band

mechanism between the two NSIS NATFW nodes or are dynamically

established using mechanisms not further specified in this document.

Note that the deployment environment will most likely have an impact on the choice of credentials being used. The choice of these

credentials used is also outside the scope of this document.

+---+ +---+

|Network A | | Network B|

| +---+ +---+ | | +-///-+ Middle- +---///////----+ Middle- +-///-+ | | | | box 1 | Security | box 2 | | | | | +---+ Context +---+ | | | | Security | | Security | | | | Context | | Context | | | | | | | | | +--+---+ | | +--+---+ | | | Host | | | | Host | | | | A | | | | B | | | +---+ | | +---+ | +---+ +---+

Figure 31: Peer-to-Peer Relationship

Figure 31 shows a possible relationship between participating aware nodes. Host A might be, for example, a host in an enterprise network that has keying material established (e.g., a shared secret) with the company’s firewall (Middlebox 1). The network administrator of Network A (company network) has created access control lists for Host A (or whatever identifiers a particular company wants to use).

Exactly the same procedure might also be used between Host B and Middlebox 2 in Network B. For the communication between Middlebox 1 and Middlebox 2 a security context is also assumed in order to allow authentication, authorization, and signaling message protection to be successful.

5.1.2. Intra-Domain Relationship

In larger corporations, for example, a middlebox is used to protect individual departments. In many cases, the entire enterprise is controlled by a single (or a small number of) security department(s), which give instructions to the department administrators. In such a scenario, the previously discussed peer-to-peer relationship might be prevalent. Sometimes it might be necessary to preserve

authentication and authorization information within the network. As a possible solution, a centralized approach could be used, whereby an interaction between the individual middleboxes and a central entity (for example, a policy decision point - PDP) takes place. As an alternative, individual middleboxes exchange the authorization decision with another middlebox within the same trust domain.

Individual middleboxes within an administrative domain may exploit their relationship instead of requesting authentication and

authorization of the signaling initiator again and again. Figure 32 illustrates a network structure that uses a centralized entity.

+---+

| Network A | | +---+ +---+

| -///---+ Middle- ---///---++ Middle- | | Security | box 2 | Security | box 2 | | | Context +----+----+ Context +----+----+

| +----+----+ | | | | | Middle- +---+ +---+ | | | | box 1 | | | | | | +----+----+ | | | | | | Security | +----+---+ | | | | Context | | Policy | | | | +--+---+ +---+ Decision +---+ | | | Host | | Point | | | | A | +---+ | | +---+ | +---+

Figure 32: Intra-Domain Relationship

The interaction between individual middleboxes and a policy decision point (or AAA server) is outside the scope of this document.

5.1.3. End-to-Middle Relationship

The peer-to-peer relationship between neighboring NSIS NATFW NSLP

The peer-to-peer relationship between neighboring NSIS NATFW NSLP

Dans le document This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows (Page 58-0)