Question regarding RFC 4960 Out of the Blue packets

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

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran