Subject: [Sigtran] Question regarding RFC 4960 Out of the Blue packets

From: "Horsham, Ian" <[email-masked]>
Date: Wed, 12 Oct 2011 11:15:26 +0100

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

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 12 Oct 2011 18:01:57 +0200

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?
> 
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
> 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.
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/sigtran

---

From: "Horsham, Ian" <[email-masked]>
Date: Thu, 13 Oct 2011 09:41:09 +0100

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-masked]] 
Sent: 12 October 2011 17:02
To: Horsham, Ian
Cc: [email-masked]
Subject: Re: [Sigtran] Question regarding RFC 4960 Out of the Blue packets

> an SCTP packet with an invalid CRC32c checksum silently discards the
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.
8.4 covers OOTB packets.

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

---

From: Jeff Morriss <[email-masked]>
Date: Thu, 13 Oct 2011 10:42:45 -0400

Horsham, Ian wrote:

[BTW, SCTP is usually discussed over on the tsvwg list now.]

> 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
> 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).
> 

Maybe this explanation helps:

Section 1.5.6's guidance to discard packets with "unexpected" vtags only 
applies when the receiver of the packet has a matching (based on the 
addresses) association.  So, in Michael's words, the receiver has an 
expectation as to what the vtag should be and the packet does not match it.

OOTB, on the other hand, applies to packets for which the receiver has 
no association.

You shouldn't send an ABORT in the "unexpected" case to avoid aborting a 
valid association due to a lucky hit on a blind masquerade attack or 
because a (very late) packet from a previous instance of that 
association arrived.

You should send an ABORT (as per section 8.4) to correct a peer who 
seems to think you have an association that you don't have.

---

From: "Horsham, Ian" <[email-masked]>
Date: Thu, 13 Oct 2011 17:02:47 +0100

Hi Jeff

I understand now thanks (at last I hear you cry)! 

1. If a packet comes from an endpoint which it has an association with
the packet is silently discarded (to protect against attack).
2. If the packet come from an endpoint which it hasn't got an
association with the packet is OOTB.

I was thinking that the definition of an association would include
having a valid verification tag. Apologies for this misunderstanding.

Thank you Jeff, Michael and Arif for responding to my questions. You
have been very helpful.

Many Thanks
Ian

-----Original Message-----
From: Jeff Morriss [mailto:[email-masked]] 
Sent: 13 October 2011 15:43
To: Horsham, Ian
Cc: [email-masked]
Subject: Re: [Sigtran] Question regarding RFC 4960 Out of the Blue
packets

Horsham, Ian wrote:

> 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.
> 
> packets (CRC32c error) and OOTB packets (CRC32c passed but 
> verification tag incorrect) and that is why section 8.4 exists.
> 

applies when the receiver of the packet has a matching (based on the 
addresses) association.  So, in Michael's words, the receiver has an 
expectation as to what the vtag should be and the packet does not match
it.