Re: Question on HB in SCTP Multihoming

> 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