Nemana, Satya | 3 Oct 10:24 2011

Re: SCTP Multihoming

Hi Chris

Thank you for taking time to answer.
I now understand (it just took this long, with help from a Guru in a
Linux forums) that iproute2 has to be used to have the desired
functionality that I want here (4 paths)
Older implementations don't have this, so will have to be contented with
just 2 paths.
In any case, this has only to do with the IP routing and SCTP does not
have to do anything to do here, but to request a retransmission if case
of no acks on one path.

Thanks,

Regards,
Satya

-----Original Message-----
From: Chris Benson [mailto:cbenson <at> adax.com] 
Sent: 26 September 2011 17:57
To: Nemana, Satya
Cc: sigtran <at> ietf.org
Subject: Re: [Sigtran] SCTP Multihoming

Satya,

There are four combinations of end-point pairs.
Two of them may or may not be "usable".

It is desirable (but not always possible) for an IP layer
(Continue reading)

Mahantesh SK | 4 Oct 13:42 2011
Picon

NTFY message in IPSP single exchange mode

Hi Brain,

Is it must to send the NTFY message to the peer node after change in the IPSP state?


Thanks
Mahantesh


_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Brian F. G. Bidulock | 5 Oct 03:20 2011

Re: NTFY message in IPSP single exchange mode

Mahantesh,

As you know, the RFC says:

 RFC 4666/4.3.4.5.1

   Notify works in the same manner as in the SG-AS case.  Ohe of the
   IPSPs can send this message to any remote IPSP that is not in the
   ASP-DOWN state.

Which doesn't offer much help.

In general, any IPSP that responds like an SG (i.e. accepts messages
normally only recieved by an SG in the SG-AS case) must also send NTFY
messages just as the SG would.  This would mean that both IPSP must send
NTFY in DE mode and only an IPSP that is responding like and SG in SE
mode.  All IPSP should be prepared to receive it, but unless the IPSP is
positive about the mode of the peer, it might not be able to rely on it.

Well, those are my thoughts.  Others might differ.

--brian

Mahantesh SK wrote:                       (Tue, 04 Oct 2011 17:12:56)
>    Hi Brain,
> 
>    Is it must to send the NTFY message to the peer node after change in
>    the IPSP state?
> 
>    Thanks
>    Mahantesh

> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Horsham, Ian | 12 Oct 12:15 2011

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
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Michael Tüxen | 12 Oct 18:01 2011
Picon

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
> Sigtran <at> ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran
Horsham, Ian | 13 Oct 10:41 2011

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:Michael.Tuexen <at> lurchi.franken.de] 
Sent: 12 October 2011 17:02
To: Horsham, Ian
Cc: sigtran <at> ietf.org
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
> Sigtran <at> ietf.org
> 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
Jeff Morriss | 13 Oct 16:42 2011
Picon

Re: Question regarding RFC 4960 Out of the Blue packets


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

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.
Horsham, Ian | 13 Oct 18:02 2011

Re: Question regarding RFC 4960 Out of the Blue packets

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:jeff.morriss.ws <at> gmail.com] 
Sent: 13 October 2011 15:43
To: Horsham, Ian
Cc: sigtran <at> ietf.org
Subject: Re: [Sigtran] Question regarding RFC 4960 Out of the Blue
packets

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

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.

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

Gmane