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

[Claudio Porfiri <[e-mail]>]

Hi Milen,
I think you cannot make assumption on the IP configuration of the remote peer.
May you describe in details your Use Case?
Is the remote Endpoint defined (i.e. it has been public announced) on two IP address or this is only what you have observed by means of a previously existing Association?
How do you know that at a certain time the remote peer hasn’t changed the Endpoint Configuration?
Does the peer reply with an ABORT? (and so with what reason) or simply doesn’t answer?
And why you don’t take into account the possibility that a peer has dynamically allocated IP resources, such as in a Cloud environment?

If the problem exists, I think it’s rather for the SCTP User to give rules on how to define Endpoints rather than for the RFC, but please help with details so that things can be improved.

Thanks,
Claudio


From: Milen Hristov <[e-mail]>
Sent: Wednesday, June 19, 2024 11:09 AM
To: Claudio Porfiri <[e-mail]>; Zaheduzzaman Sarker <[e-mail]>; [e-mail]
Cc: Randall Stewart <[e-mail]>; RFC Errata System <[e-mail]>; tsvwg-ads <[e-mail]>; Gorry Fairhurst <[e-mail]>; tsvwg <[e-mail]>
Subject: RE: [tsvwg] Re: [Technical Errata Reported] RFC9260 (7988)

Hi Claudio,

I cannot agree that The implementor(vendor) can decide anything, when is related to interconnect to other vendors
This is not some internal proprietary  solution

Finally the purpose of RFC is to define rules and all vendors must follow them
Otherwise interconnection will not work, if all vendors  decide to implement  their own solutions

The document from Oracle is describing specific scenario– yes could be, but this scenario should be described in RFC
This is not case with dynamically IPs- all IPs are defined statically on both ends- Client and Server
So the server knows the sending IP, but rejects the INIT, just because is Secondary IP

Finally the rule in RFC should clearly specify- secondary path can be used for INIT or not
If not- then all vendors  should disable sending INIT by secondary IP
Why secondary IP could not be used for INIT?

Best regards
Milen


From: Claudio Porfiri <[e-mail]<mailto:[e-mail]>>
Sent: 19 June 2024 07:10
To: Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Milen Hristov <[e-mail]<mailto:[e-mail]>>; Randall Stewart <[e-mail]<mailto:[e-mail]>>; RFC Errata System <[e-mail]<mailto:[e-mail]>>; tsvwg-ads <[e-mail]<mailto:[e-mail]>>; Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>; tsvwg <[e-mail]<mailto:[e-mail]>>
Subject: RE: [tsvwg] Re: [Technical Errata Reported] RFC9260 (7988)

Hi Michael, Milen,
About the specific case described, I am not sure that anything needs to be changed at the RFC, I think it’s clear as it is.
The implementor can decide that the pubic SCTP Endpoint is limited to a single IP address and then decide that it only answers to that IP address, this cannot be forced by RFC,
It may even be that the other addresses used for multihoming are instantiated dynamically and only exist during the lifetime of an Association.
The owner of the node may have implemented Access Rules that filter out INIT and having the same result.
If you have interoperability problems this should be solved by proper configuration.
The document from oracle is describing a very small subset of what is possible with SCTP and multihoming, it cannot be taken for replacing the RFC.

That is my 10 cent to the discussion.

Best regards,
Claudio

From: Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 18, 2024 10:38 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Milen Hristov <[e-mail]<mailto:[e-mail]>>; Randall Stewart <[e-mail]<mailto:[e-mail]>>; RFC Errata System <[e-mail]<mailto:[e-mail]>>; tsvwg-ads <[e-mail]<mailto:[e-mail]>>; Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>; tsvwg <[e-mail]<mailto:[e-mail]>>
Subject: [tsvwg] Re: [Technical Errata Reported] RFC9260 (7988)

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]<mailto:[e-mail]>> wrote:
> On 18. Jun 2024, at 20:39, Milen Hristov <[e-mail]<mailto:[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]<mailto:[e-mail]>>
> To:tuexen <[e-mail]<mailto:[e-mail]>>
> Cc:Randall Stewart <[e-mail]<mailto:[e-mail]>>;RFC Errata System <[e-mail]<mailto:[e-mail]>>;kee <[e-mail]<mailto:[e-mail]>>;tsvwg-ads <[e-mail]<mailto:[e-mail]>>;Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>;Marten Seemann <[e-mail]<mailto:[e-mail]>>;tsvwg <[e-mail]<mailto:[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]<mailto:[e-mail]>>
> To:Milen Hristov <[e-mail]<mailto:[e-mail]>>
> Cc:Randall Stewart <[e-mail]<mailto:[e-mail]>>;RFC Errata System <[e-mail]<mailto:[e-mail]>>;kee <[e-mail]<mailto:[e-mail]>>;tsvwg-ads <[e-mail]<mailto:[e-mail]>>;Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>;Marten Seemann <[e-mail]<mailto:[e-mail]>>;tsvwg <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
> > Sent: 14 June 2024 09:10
> > To: Randall Stewart <[e-mail]<mailto:[e-mail]>>
> > Cc: RFC Errata System <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>; Marten Seemann <[e-mail]<mailto:[e-mail]>>; Milen Hristov <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> > Subject: Re: [Technical Errata Reported] RFC9260 (7988)
> >
> >> On 13. Jun 2024, at 18:32, Randall Stewart <[e-mail]<mailto:[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]<mailto:[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
> >