ASF Specification v2.0 DSP0136 - DMTF

More documents

Recommendations

Info

Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 3. The Next Header field indicates the type of message that is encapsulated between the RSP header and trailer. For this specification, the value in the Next Header field is defined as the value in the Version field of the RMCP Header of the RMCP message being processed (e.g.; 06h for ASF). 4. The Integrity Data field is used to hold the results of an integrity algorithm (e.g., a keyed hash function) performed over the specific fields of the RSP header, RMCP message, and RSP trailer defined earlier. The length of this field depends on the integrity algorithm negotiated during session setup. For this specification, the mandatory-to-implement integrity algorithm is HMAC-SHA1-96 defined in [RFC2404]. These fields are specified in the following table. Contents Type Offset Value Pad Pad Length Next Header Integrity Data Variable Bytes Used to provide DWORD-alignment of the Integrity Data field within the message. If present, each Pad byte is set to 00h. 1 Byte 4n-2 Defines the number of Pad bytes present in the message, in the range 0 to 3. 1 Byte 4n-1 Indicates the type of message that is encapsulated between the RSP header and trailer. For this specification, the value of this field equals the value in the Version field of the RMCP Header of the message being processed. Variable Bytes 4n Holds the results of an integrity algorithm negotiated during session setup. RSP Trailer 3.2.3.2 Outbound Message Processing The sections that follow and the figure below outline the processing steps used by an alertsending device or management console to add security extensions to an outbound RMCP message. RMCP Message RSP Hdr Data RSP Tlr UDP Hdr Data IP Hdr Data Enet Hdr Data 3.2.3.2.1 Device Security Policy and Session State Lookup When an RMCP request initiator creates a message, its RMCP protocol engine accesses the Device Security Policy to determine whether RMCP security extensions functionality is enabled. If the functionality is enabled, RMCP determines if an appropriate RSP session exists for the message. If an appropriate session does not exist, RMCP uses the RSP Session Protocol (RSSP) to create a session (see 3.2.3.4). If a session exists but the session is not in the Message Transfer phase (the phase that allows RMCP messages to be exchanged), RMCP must wait until the session reaches that phase before the RMCP message can be sent. DSP0136 23 April 2003 Page 25 of 94
Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136 If a session exists and the session is in the Message Transfer phase, RMCP passes the Session ID, the RMCP message, and RMCP message Length, to the next lower-layer protocol (RSP) for additional processing. 3.2.3.2.2 Message Encapsulation When the sending device's RSP protocol engine receives a message from RMCP, RSP inserts an RSP Header (see 3.2.3.1) at the beginning of the message and copies the Session ID value into the header's Session ID field. RSP uses the Session ID to access the session state and increments the session's Sequence Number and then inserts that value into the Sequence Number field of the RSP Header. Next, RSP creates an RSP Trailer (see 3.2.3.1) at the end of the message’s Data block. RSP computes the amount of padding required (if any) to align the protected message's Integrity Data field on a DWORD boundary. RSP then uses the RMCP message Length (passed from the RMCP engine) to locate the end of the message’s Data block, and inserts the correct number of pad bytes and the values for the RSP Trailer's Pad Length and Next Header fields. Finally, RSP uses the Session ID to access the session state and determine which integrity algorithm to use with the message, and computes the Integrity Data over the encapsulated message (from Session ID to Next Header fields, inclusive). The calculated value is inserted into the Integrity Data field of the RSP Trailer creating a protected RMCP message. Finally, RSP updates the message Length to account for the addition of the RSP Header and Trailer, and passes the UDP Source and Destination Port values (from the session state), the protected RMCP message Length, and the protected RMCP message to the next lower-layer protocol (UDP) for additional processing. 3.2.3.2.3 Lower-Layer Protocol Processing When it receives a message from RSP, the sending device's UDP protocol engine inserts its header at the beginning of the protected RMCP message. UDP copies the port values passed from RSP into the UDP Header's Source Port and Destination Port fields, and then computes the UDP packet length and checksum and inserts these values into the UDP Length and Checksum fields. The resulting UDP packet is then passed to other lower-layer protocols (e.g. IP and 802.3/Ethernet) for additional processing and eventual transmission to its destination. 3.2.3.3 Inbound Message Processing The follow sections and the figure below outline the processing steps used by an alert-sending device or management console to remove security extensions from an inbound RMCP message. Enet Hdr Data IP Hdr Data UDP Hdr Data RSP Hdr Data RSP Tlr RMCP Message DSP0136 23 April 2003 Page 26 of 94
Page 1 and 2: Alert Standard Format Specification
Page 3 and 4: Alert Standard Format (ASF) Specifi
Page 11 and 12: R Alert Standard Format (ASF) Speci
Page 29: Alert Standard Format (ASF) Specifi
Page 81 and 82:
Alert Standard Format (ASF) Specifi
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99:
show all

ASF Specification v2.0 DSP0136 - DMTF

Create successful ePaper yourself

Delete template?

Save as template?