Re: Question on HB in SCTP Multihoming

Michael Tüxen <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <[email protected]> 
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:

>
> 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);
> 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)
>
> I made a Typography error below in red (sorry for that)
>  ICMP:
> Type: Destination Unreachable
> 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 protected]]
> Sent: Monday, 29 December 2008 9:01 PM
> To: Janaka Sooriyaaratchi
> Cc: [email protected]
> 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
>
> Janaka Sooriyaaratchi wrote:                 (Mon, 29 Dec 2008  
> 16:50:25)
> >
> >    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 protected]
> > https://www.ietf.org/mailman/listinfo/sigtran
>
>
> -- 
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sigtran
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.