Subject: [Sigtran] Question on HB in SCTP Multihoming

From: "Janaka Sooriyaaratchi" <[email-masked]>
Date: Mon, 29 Dec 2008 16:50:25 +1100

Hi Experts,
The following question is related to SCTP multihoming with Two IP
addresses in each Node (Client and the Server). 
I need to know the correct behavior of Heart beat response when one of
the IP addresses are not reachable.

Pls look at the example below;

Local Node							Remote
Node
(Client, Port 2905) 						(Server,
Port 2906)
(Primary)   10.114.4.132  Ip Interface1(Link1)		<---------->
10.102.232.7
(Secondary) 10.114.4.140 Ip Interface2(Link2)		<---------->
10.102.232.39
SCTP is Configured as Multihomed.

In the above configuration SCTP port address 10.114.4.140 is down, and
local node sends ICMP response as below;

2008-08-12 15:09:32.666577	10.102.232.39	10.114.4.140	SCTP
HEARTBEAT 
2008-08-12 15:09:32.667161	10.114.4.140	10.102.232.39	ICMP
Destination unreachable (Port unreachable)
ICMP:
Type: Destination Unreachable
Code: protocol Unreachabel

This causes the Remote Node to react badly , that is, Remote node sends
SCTP abort to the primary link (10.114.4.132  ) taking down the whole
SCTP user.
We donot have the full internal visibility to Remote Node as it belongs
to another Vendor. But what  we do know is that the  Remote Node does
not like the ICMP message as a response to the HB request.

According to RFC 4960 ICMP handling is Defined in Appendix C, we may
argue that the Local behaves correctly in sending the ICMP message. But
the question remains not answered is that "can the Local node sends ICMP
message as a response to HB request?". Is this specifically mentioned in
RFC 4960. What is the equivalent NAK message to HB request in SCTP?
Other Argument we had there related to ICMP message was that Remote node
does not support ICMP messages, meaning follows RFC 2960 , where ICMP
handling is not defined.
In this case what would be the Response to HB request? Should the local
Node Silently Discard the HB message?

Pls would you discuss this issues with respect relevant RFCs.
Thanks in Advance.

According to 
Best Regards 
Janaka Sooriyaaratchi

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Dec 2008 03:01:09 -0700

Janaka,

Regardless of RFC, if the local node is sending ICMP (port unreachable)
and ICMP (protocol unreachable) for a port for which there is an existing
SCTP assocation, then the local node is messed up: it is not only
telling the remote node that there is no association for the SCTP port
but it is telling the remote node that one of its IP addresses does not
even have SCTP support.  The remote node is correct in dropping the
association.

There is no nak for a HEARTBEAT: if the implementation receive a valid HB
(correct tag) port and IP address that is part of an existing association
from an address with which the node has an association, it MUST respond
with a HEARTBEAT ACK.

--brian

Janaka Sooriyaaratchi wrote:                 (Mon, 29 Dec 2008 16:50:25)
>    (Client, Port 2905)
>    (Server, Port 2906)
>    2008-08-12 15:09:32.666577      10.102.232.39   10.114.4.140
>    SCTP    HEARTBEAT
>    2008-08-12 15:09:32.667161      10.114.4.140    10.102.232.39
>    ICMP    Destination unreachable (Port unreachable)
>    ICMP:
>    This causes the Remote Node to react badly , that is, Remote node
>    sends SCTP abort to the primary link (10.114.4.132  ) taking down the
>    whole SCTP user.
> 
>    We donot have the full internal visibility to Remote Node as it
>    belongs to another Vendor. But what  we do know is that the  Remote
>    Node does not like the ICMP message as a response to the HB request.
> 
>    argue that the Local behaves correctly in sending the ICMP message.
>    But the question remains not answered is that "can the Local node
>    sends ICMP message as a response to HB request?". Is this specifically
>    mentioned in RFC 4960. What is the equivalent NAK message to HB
>    request in SCTP?
> 
>    Other Argument we had there related to ICMP message was that Remote
>    node does not support ICMP messages, meaning follows RFC 2960 , where
>    ICMP handling is not defined.
> 
>    In this case what would be the Response to HB request? Should the
>    local Node Silently Discard the HB message?
> 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Janaka Sooriyaaratchi" <[email-masked]>
Date: Mon, 29 Dec 2008 22:02:54 +1100

> Hi Brian,
> Thanks for the Reply,
> I agree with you that if the Local Node (in our case) sends protocol
> Unreachable, the remote node takes down the association,  which
> RFC4960 also Explains in  ICMP handling, as below;
> 
> According to IETF specification RFC4460, Even though it is not
> specifically given reference to the heart beat message (as in our
> case), in general it say that ; 
> ICMP8) If the ICMP code is a "Unrecognized next header type
> encountered" or a "Protocol Unreachable", an implementation
> MUST treat this message as an abort with the T bit set if it
> does not contain an INIT chunk. If it does contain an INIT
> chunk and the association is in COOKIE-WAIT state, handle the
> ICMP message like an ABORT. 
> 
> As you mentioned below, I also believe that The stricter handling of
> the "protocol unreachable" message is due to security concerns for
> hosts that do NOT support SCTP.
> Just to further clarify my first email below;
> Local Node actually sends as I mentioned below (also in the previous
> email);
> I made a Typography error below in red (sorry for that)
>  ICMP:
> Code: Port Unreachable (Now Corrected)
> Now, Do you think that the Local Node responds correctly  (Destination
> unreachable ,Port unreachable)
> to the HB Request to the redundant association whose address is
> temporarily not reachable, Or do you think that the Local node should
> not reply to the HB Request as the association is not available at the
> time of the HB Request from the local Node.
> And also If the above mentioned ICMP message is the correct cause to
> send to the remote end  and the Remote end takes down the other active
> association as well (with SCTP ABORT), do you think that this is due
> to the  Remote Node not supporting ICMP messages, meaning that it
> supports only RFC 2960 track?
> 
> 
> Thanks again.
> Best Regards 
> Janaka Sooriyaaratchi
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]] 
> Sent: Monday, 29 December 2008 9:01 PM
> To: Janaka Sooriyaaratchi
> Cc: [email-masked]
> Subject: Re: [Sigtran] Question on HB in SCTP Multihoming
> 
> Janaka,
> 
> Regardless of RFC, if the local node is sending ICMP (port
> unreachable) and ICMP (protocol unreachable) for a port for which
> there is an existing SCTP assocation, then the local node is messed
> up: it is not only telling the remote node that there is no
> association for the SCTP port but it is telling the remote node that
> one of its IP addresses does not even have SCTP support.  The remote
> node is correct in dropping the association.
> 
> There is no nak for a HEARTBEAT: if the implementation receive a valid
> HB (correct tag) port and IP address that is part of an existing
> association from an address with which the node has an association, it
> MUST respond with a HEARTBEAT ACK.
> 
> --brian
> 
> >    Local Node
> Remote

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 29 Dec 2008 12:34:05 +0100

Hi Janaka,

if a node does not support SCTP, it sends ICMP(destination  
unreachable, protocol unreachable)
in response to all received SCTP messages.

if a node does support it should never send ICMP(destination  
unreachable, *) messages
on reception of an SCTP message.

I agree with Brian, the local node is broken.

For me, it does not make any sense for an SCTP capable node to send an
IMCP(destination unreachable, port unreachable) message. SCTP uses an
ABORT message for signalling that an SCTP packet was received and there
is no association.

That is the reason for the following text in RFC 4960:

    Note that these procedures differ from [RFC1122] and from its
    requirements for processing of port-unreachable messages and the
    requirements that an implementation MUST abort associations in
    response to a "protocol unreachable" message.  Port-unreachable
    messages are not processed, since an implementation will send an
    ABORT, not a port unreachable.  The stricter handling of the
    "protocol unreachable" message is due to security concerns for hosts
    that do NOT support SCTP.

ICMP3 allows the peer to ignore the ICMP message, but there is no
requirement for doing so. I would call it a protocol violation what
the local node does. When you receive a HEARTBEAT and you do have
an association, send a HEATBEAT-ACK. If you do not have an association,
send an ABORT.

Best regards
Michael

On Dec 29, 2008, at 12:02 PM, Janaka Sooriyaaratchi wrote:

> Now, Do you think that the Local Node responds correctly   
> (Destination unreachable ,Port unreachable)
> temporarily not reachable, Or do you think that the Local node  
> should not reply to the HB Request as the association is not  
> available at the time of the HB Request from the local Node.
>
> send to the remote end  and the Remote end takes down the other  
> active association as well (with SCTP ABORT), do you think that this  
> is due to the  Remote Node not supporting ICMP messages, meaning  
> that it  supports only RFC 2960 track?
>
>
> Thanks again.
> Best Regards
> Janaka Sooriyaaratchi
>
>
> There is no nak for a HEARTBEAT: if the implementation receive a  
> valid HB (correct tag) port and IP address that is part of an  
> existing association from an address with which the node has an  
> association, it MUST respond with a HEARTBEAT ACK.
>
> --brian
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Dec 2008 07:04:01 -0700

Janaka,

Sending ICMP(port unreachable) is incorrect as well: an association
exists with that port, so the local node is still broken.

--brian