Re: Question regarding RFC 4960 Out of the Blue packets

On Oct 12, 2011, at 12:15 PM, Horsham, Ian wrote:

> 
> 
> 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.
This covers the handling of incoming packets. You can only decide
that the verification tag is as expected, if you have an expectation.
This means you can identify the association to which it belongs.
So it is not OOTB.
> 
> However Section 8.4 gives an alternative explanation as to how these packets should be handled:-
8.4 covers OOTB packets.

I hope this makes things clearer.

Best regards
Michael
> 
> 
> 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