Re: Question regarding RFC 4960 Out of the Blue packets

Hello Michael

Thanks for your reply.

Section 1.5.6 only says "Packets received without the expected Verification Tag value are discarded" (it doesn't actually state that they are silently discarded). It does go on to say that "The receiver of an SCTP packet with an invalid CRC32c checksum silently discards the packet.". However I'm considering a packet with a correct CRC32c check and an incorrect verification tag.

This has made me think that there is a difference between invalid packets (CRC32c error) and OOTB packets (CRC32c passed but verification tag incorrect) and that is why section 8.4 exists.

Do you think that section 8.4 can be ignored or is there a difference between invalid packets and OOTB packets? I think that there is a difference and the RFC is saying that OOTB packets should be handled differently (as per section 8.4).

Consequently, I can see the benefits of silently discarding these packets (for security).

Many thanks
Ian

-----Original Message-----
From: Michael Tüxen [mailto:[email protected]] 
Sent: 12 October 2011 17:02
To: Horsham, Ian
Cc: [email protected]
Subject: Re: [Sigtran] 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

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