Hello
I wonder if you can help me with a question that I have regarding Out of the Blue packets please?
Section 1.5.6 states that these packets should be silently discarded:-
1.5.6. Packet Validation
A mandatory Verification Tag field and a 32-bit checksum field (see
Appendix B for a description of the CRC32c checksum) are included in
the SCTP common header. The Verification Tag value is chosen by each
end of the association during association startup. Packets received
without the expected Verification Tag value are discarded, as a
protection against blind masquerade attacks and against stale SCTP
packets from a previous association. The CRC32c checksum should be
set by the sender of each SCTP packet to provide additional
protection against data corruption in the network. The receiver of
an SCTP packet with an invalid CRC32c checksum silently discards the
packet.
However Section 8.4 gives an alternative explanation as to how these packets should be handled:-
8.4. Handle "Out of the Blue" Packets
An SCTP packet is called an "out of the blue" (OOTB) packet if it is
correctly formed (i.e., passed the receiver's CRC32c check; see
Section 6.8), but the receiver is not able to identify the
association to which this packet belongs.
The receiver of an OOTB packet MUST do the following:
1) If the OOTB packet is to or from a non-unicast address, a
receiver SHOULD silently discard the packet. Otherwise,
2) If the OOTB packet contains an ABORT chunk, the receiver MUST
silently discard the OOTB packet and take no further action.
Otherwise,
3) If the packet contains an INIT chunk with a Verification Tag set
to '0', process it as described in Section 5.1. If, for whatever
reason, the INIT cannot be processed normally and an ABORT has to
be sent in response, the Verification Tag of the packet
containing the ABORT chunk MUST be the Initiate Tag of the
received INIT chunk, and the T bit of the ABORT chunk has to be
set to 0, indicating that the Verification Tag is NOT reflected.
4) If the packet contains a COOKIE ECHO in the first chunk, process
it as described in Section 5.1. Otherwise,
5) If the packet contains a SHUTDOWN ACK chunk, the receiver should
respond to the sender of the OOTB packet with a SHUTDOWN
COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of
the OOTB packet must fill in the Verification Tag field of the
outbound packet with the Verification Tag received in the
SHUTDOWN ACK and set the T bit in the Chunk Flags to indicate
that the Verification Tag is reflected. Otherwise,
6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver
should silently discard the packet and take no further action.
Otherwise,
7) If the packet contains a "Stale Cookie" ERROR or a COOKIE ACK,
the SCTP packet should be silently discarded. Otherwise,
8) The receiver should respond to the sender of the OOTB packet with
an ABORT. When sending the ABORT, the receiver of the OOTB
packet MUST fill in the Verification Tag field of the outbound
packet with the value found in the Verification Tag field of the
OOTB packet and set the T bit in the Chunk Flags to indicate that
the Verification Tag is reflected. After sending this ABORT, the
receiver of the OOTB packet shall discard the OOTB packet and
take no further action.
My initial thoughts were to treat 8.4 as the overriding section as it suggests different responses for packets containing different types of chunks and it goes into more detail. However, I can also see that section 1.5.6 may have a security benefit over section 8.4.
If you can offer any help on this I will be very grateful.
Many Thanks, and Kind Regards
Ian Horsham
Principal DTC/VO Engineer
Cable & Wireless Worldwide
Direct Dial: +44 (0) 1344811151
Mobile: +44 (0) 7822813439
This e-mail has been scanned for viruses by the Cable&Wireless Worldwide e-mail security system. For more information on a proactive managed e-mail secure service, visit http://www.cw.com/managed-exchange
The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
Cable & Wireless Worldwide plc
Registered in England and Wales. Company Number 07029206
Registered office: Liberty House, 76 Hammersmith Road, London W14 8UD, England
RSS Feed