[tsvwg] Re: [Technical Errata Reported] RFC9260 (7988)

[Zaheduzzaman Sarker <[e-mail]>]

Hi Michael,

Yes, you are accurate about the process ( for more information see :
https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/)
What I need to see is the proposed text then decide on whether the change
is technical or not. I am expecting here, from the discussions, is "*hold
for document update*" status. Let me know if that not the correct status
for this errata.

So, please proposed the text so we can agree on the text.

//Zahed

On Tue, Jun 18, 2024 at 11:45 AM <[e-mail]> wrote:

> > On 18. Jun 2024, at 20:39, Milen Hristov <[e-mail]>
> wrote:
> >
> >
> > Hello,
> >
> > if everyone agree with this statement, can be written in the RFC ?
> You cannot change an RFC. And only ADs can change Erratas. So I can propose
> some text change, we can agree on it, and then either an AD has to put
> that text change in your errata or I (or you) file a new one. That would
> (in my view) be classified as Editorial and can be approved by an AD, if
> the AD agrees with it.
>
> So should I propose some text change?
>
> Best regards
> Michael
> >
> >
> > Regards
> > Milen Hristov
> >
> > From:Milen Hristov <[e-mail]>
> > To:tuexen <[e-mail]>
> > Cc:Randall Stewart <[e-mail]>;RFC Errata System <
> [e-mail]>;kee <[e-mail]>;tsvwg-ads <
> [e-mail]>;Gorry Fairhurst <[e-mail]>;Marten Seemann
> <[e-mail]>;tsvwg <[e-mail]>
> > Date:2024-06-14 12:10:32
> > Subject:RE: [Technical Errata Reported] RFC9260 (7988)
> >
> > Hello, yes, the Secondary path to be used, because the Primary is
> unavailable
> >
> > Regards
> > Milen Hristov
> >
> > From:tuexen <[e-mail]>
> > To:Milen Hristov <[e-mail]>
> > Cc:Randall Stewart <[e-mail]>;RFC Errata System <
> [e-mail]>;kee <[e-mail]>;tsvwg-ads <
> [e-mail]>;Gorry Fairhurst <[e-mail]>;Marten Seemann
> <[e-mail]>;tsvwg <[e-mail]>
> > Date:2024-06-14 12:04:49
> > Subject:Re: [Technical Errata Reported] RFC9260 (7988)
> >
> > > On 14. Jun 2024, at 10:24, Milen Hristov <[e-mail]>
> wrote:
> > >
> > > Hello All,
> > >
> > > Thank you for  the quick reply
> > >
> > > The errata is not intended to change any network element function, but
> only to make the RFC more clear
> > > I am not sure in which section is better to be, you decide
> > >
> > > The multihoming SCTP description by Oracle is very clear and same is
> implemented by most of big vendors like Huawei and other
> > >
> https://docs.oracle.com/cd/E57516_01/docs.70/Transport_Manager/concepts/c_transport_mgr_multihoming.html
> > >
> > > but some small vendors do not accept INIT sent via  the Secondary path
> by Secondary IP Address
> > > they consider Secondary path to be used only for failover , but not to
> re-establish the SCTP association
> > >
> > > this issue was raised by the following scenario:
> > >
> > > endpoint C (acting as a client) has two IP addresses -IP1_client and
> IP2_client
> > > and
> > > endpoint S (acting as a server) two IP addresses- IP1_server and
> IP2_server
> > >
> > > Primary SCTP path1 (IP1_client- IP1_server)
> > > Secondary SCTP path2 (IP2_client- IP2_server)
> > >
> > > Both paths  use  separate IP transmissions
> > > Initially the association was  established by Primary SCTP path1
> > >
> > > There was  transmission outage, affecting both SCTP paths-  SCTP
> association was down
> > > Later only the transmission for  Secondary SCTP path2 was recovered
> > > Endpoint C detected IP2_server is reachable and started sending INIT
> (via Secondary SCTP path2 )
> > > but endpoint S rejected the INIT sent by IP2_client
> > Assuming that the server is bound to both addresses, it should accept
> the INIT and
> > send an INIT ACK back using IP2_client and IP2_server. This should work
> even in the
> > restart case.
> >
> > Is that what you want to clarify?
> >
> > Best regards
> > Michael
> > >
> > > Best Regards
> > > Milen Hristov
> > >
> > >
> > > -----Original Message-----
> > > From: [e-mail] <[e-mail]>
> > > Sent: 14 June 2024 09:10
> > > To: Randall Stewart <[e-mail]>
> > > Cc: RFC Errata System <[e-mail]>; [e-mail];
> [e-mail]; Gorry Fairhurst <[e-mail]>; Marten
> Seemann <[e-mail]>; Milen Hristov <[e-mail]>;
> [e-mail]
> > > Subject: Re: [Technical Errata Reported] RFC9260 (7988)
> > >
> > >> On 13. Jun 2024, at 18:32, Randall Stewart <[e-mail]>
> wrote:
> > >>
> > >> Hello:
> > >>
> > >>
> > >> So I have just had a look at this "Errata". I disagree with it.
> Section 3 defines data formats and
> > >>
> > >> does not specify what IP addresses are accepted or used in sending an
> INIT. Section 5 has details
> > >>
> > >> on association setup. Note also that Section 5 explicitly states that
> the receiver of an INIT must
> > >>
> > >> respond to the senders IP address NOT any of the IP addresses listed
> within the INIT chunk. This
> > >>
> > >> is an important security concern. A secondary listed address cannot
> be used until a heart beat
> > >>
> > >> validates the address by sending a HB to the address and receiving a
> response from the address.
> > >>
> > >>
> > >> The Errata IMO is invalid ... Michael? Do you agree or am I missing
> something??
> > > I agree with content of your answer: the destination address of the
> packet containing
> > > the INIT ACK chunk MUST be the source address of the packet containing
> the INIT chunk.
> > > This is stated in
> > > https://www.rfc-editor.org/rfc/rfc9260.html#section-5.1-4
> > >
> > > But I am not sure if this is what Milen is referring to. He only
> refers to the packet
> > > containing the INIT chunk. SO I guess it would be best if Milen can
> clarify, which
> > > problem he is experiencing.
> > >
> > > Just to be clear:
> > > Assume the endpoint C (acting as a client) has two IP addresses
> P_client and S_client, the
> > > endpoint S (acting as a server) two IP addresses P_server and S_server.
> > > If the application tells C to initiate an association towards S and
> provides both IP addresses
> > > (doing someting like sctp_connectx(P_server, S_server)), the packet
> containing and INIT
> > > chunk sent by C can use P_client or S_client as the source address and
> P_server and S_server
> > > as the destination address. The server S would except all possible
> four combination and would
> > > send a packet containing an INIT ACK chunk in response to the source
> address of the incoming
> > > packet as described above.
> > > I am wondering if Milen has observed a problem related to this
> description.
> > > Please note: whether or not the networks between C and S will forward
> packets with all
> > > four combinations is a different question.
> > >
> > > Best regards
> > > Michael
> > >>
> > >>
> > >> R
> > >>
> > >>
> > >> On 6/13/24 9:57 AM, RFC Errata System wrote:
> > >>> The following errata report has been submitted for RFC9260,
> > >>> "Stream Control Transmission Protocol".
> > >>>
> > >>> --------------------------------------
> > >>> You may review the report below and at:
> > >>> https://www.rfc-editor.org/errata/eid7988
> > >>>
> > >>> --------------------------------------
> > >>> Type: Technical
> > >>> Reported by: Milen Hristov <[e-mail]>
> > >>>
> > >>> Section: 3.3.2.  Initiation
> > >>>
> > >>> Original Text
> > >>> -------------
> > >>> not clearly specified  sending IP Address for INIT
> > >>>
> > >>> Corrected Text
> > >>> --------------
> > >>> INIT can be accepted from either the Primary or Secondary IP Address
> > >>>
> > >>> Notes
> > >>> -----
> > >>> Oracle explained clear
> > >>>
> > >>>
> https://docs.oracle.com/cd/E57516_01/docs.70/Transport_Manager/concepts/c_transport_mgr_multihoming.html
> > >>>
> > >>> Some vendors do not accept INIT sent by Secondary Peer IP Address
> > >>>
> > >>> Instructions:
> > >>> -------------
> > >>> This erratum is currently posted as "Reported". (If it is spam, it
> > >>> will be removed shortly by the RFC Production Center.) Please
> > >>> use "Reply All" to discuss whether it should be verified or
> > >>> rejected. When a decision is reached, the verifying party
> > >>> will log in to change the status and edit the report, if necessary.
> > >>>
> > >>> --------------------------------------
> > >>> RFC9260 (draft-ietf-tsvwg-rfc4960-bis-19)
> > >>> --------------------------------------
> > >>> Title               : Stream Control Transmission Protocol
> > >>> Publication Date    : June 2022
> > >>> Author(s)           : R. Stewart, M. Tüxen, K. Nielsen
> > >>> Category            : PROPOSED STANDARD
> > >>> Source              : Transport and Services Working Group
> > >>> Stream              : IETF
> > >>> Verifying Party     : IESG
> > >
>
>