Alert Standard Format (ASF) Specification

Alert Standard Format (ASF) Specification v2.0 DMTF Document DSP0136
DSP0136 23 April 2003 Page 27 of 94
3.2.3.3.1 Lower-Layer Protocol Processing
When a frame containing a protected RMCP message reaches its destination, the lower-layer
protocols (e.g. 802.3/Ethernet and IP) in the receiving device perform their processing and pass
the resulting packet to the next higher-layer protocol (UDP) for additional processing. UDP in the
receiving device then validates the Checksum field in the UDP header. If the Checksum field is
invalid, UDP silently discards the packet.
If the Checksum field is valid, UDP verifies that it supports the upper-layer protocol specified by
the value in the Destination Port field. If the upper-layer protocol is not supported, UDP silently
discards the packet. If the upper-layer protocol is supported, UDP strips off its header, updates
the protected RMCP message Length, and passes the protected RMCP message and its Length
to the next higher-layer protocol (RSP) for additional processing.
3.2.3.3.2 Device Security Policy and Session State Lookup
When RSP receives a protected RMCP message from UDP, RSP accesses the Device Security
Policy to determine whether RMCP security extensions functionality is enabled. If the
functionality is disabled, RSP silently discards the message.
If the functionality is enabled, RSP uses the RSP Header's Session ID value to locate the session
state for this message. If no session state can be located for this message, RSP silently discards
the message. If a session exists but the session is in a phase does not that allows this protected
RMCP message to be accepted (e.g. “Set” RMCP messages received prior to reaching the
Message Transfer session phase), RSP silently discards the message.
3.2.3.3.3 Message De-Encapsulation
If a session exists and the session is in a phase that allows this protected RMCP message to be
accepted, RSP uses the integrity algorithm specified in the session state and the protected
RMCP message Length passed up from UDP to locate and validate the Integrity Data field in the
RSP Trailer. If the Integrity Data field is invalid, RSP silently discards the message.
If the Integrity Data field is valid, RSP uses the RSP Header's Sequence Number field and the
Sliding Receive Window information in the session state and determines if this message is “new”
(i.e. it is not a duplicate of a previously received message) and where the message falls with
respect to the Sliding Receive Window.
As shown in the figure below, the left-end of the Sliding Receive Window represents the
Sequence Number of the beginning of the window and the right-end of the Sliding Receive
Window is “window size” messages into the future. For v2.0 of this specification, the "window
size" is 32 messages; the figure below uses a 16-message size for illustration purposes only.
The received message must be “new” and must fall either inside the window or to the right of the
window or RSP silently discards the message. If the received message falls to the right of the
window, the window is advanced to the right to encompass the message. A message may be
received out-of-order and still be properly processed.
Important Note: The window must not be advanced until the Integrity Data of the message that
would cause the advancement has been validated. Doing otherwise would allow an attacker to
generate bogus messages with large sequence numbers that would move the window outside the
range of valid sequence numbers and cause RSP in the receiving device to drop valid messages.
If the Sequence Number processing completes successfully, RSP saves the value in the Next
Header field and uses the value in the Pad Length field to compute the number of Pad bytes that
need to be removed from the end of the message. RSP then strips off the RSP Header and
Trailer and updates the Length value for the RMCP message. RSP then passes the RMCP
message and its Length to the next higher-layer protocol (RMCP) for additional processing.