[tcpm] Re: About having reset reason in TCP option

[Jason Xing <[e-mail]>]

On Fri, Nov 29, 2024 at 12:16 AM <[e-mail]> wrote:
>
> Re-,
>
> Great to hear this feedback.
>
> The set of reason values is not frozen. It is easy to add those reasons for which we have a reference in the 9293.

Do you want me to get involved in this draft to write a few paragraphs
or contribute something else?

>
> The codes with a reference to This_Document cover cases where the rst is sent by an intermediate NAT/firewall. We don't have anchor text for those in the base TCP spec.
> However, rfc5382, for example, says the following:
>
>    Sending a RST notification allows endpoint applications to recover
>    more quickly; however, notifying the endpoints may not always be
>    possible if, for example, session state is lost due to a power
>    failure.
>
> The intent was to also cover deployments that are not shy about the presence of such intermediate nodes :-)

It does make sense to me. Thanks for the explanation.

Thanks,
Jason

>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Jason Xing <[e-mail]>
> > Envoyé : jeudi 28 novembre 2024 15:53
> > À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> > Cc : [e-mail]; Eric Dumazet <[e-mail]>; draft-
> > [e-mail]
> > Objet : Re: [tcpm] About having reset reason in TCP option
> >
> >
> > Hello Mohamed,
> >
> > On Thu, Nov 28, 2024 at 9:46 PM <[e-mail]>
> > wrote:
> > >
> > > Hi Jason,
> > >
> > > FWIW, you may find a proposal in
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-boucadair-tcpm-rst-
> > diagnostic-payload-
> > 08&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd73ab5d3c94046
> > a93f5308dd0fbc7d9c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> > 38684024422562051%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3
> > D%3D%7C0%7C%7C%7C&sdata=9KttUajmJBpbDoMmkLJpPCfOL2cN96PYIEZogft7b
> > Dc%3D&reserved=0, which does not require any new option at all.
> > It uses existing TCP provisions (see RFC9293, section 3.5.3).
> >
> > Thanks for sharing this big information with me :)
> >
> > >
> > > BTW, do you have in mind reasons other than those in draft-
> > boucadair-tcpm-rst-diagnostic-payload-08#Section-5.2? Thanks.
> >
> > After reading the whole draft,  I would like to know more details
> > about a few following cases:
> > 1) for the value 1, what about the case where FIN_WAIT2 socket
> > receives the new data? Also please see RFC 9293 3.5.1. Half-Open
> > Connections and Other Anomalies. I quote one sentence here "Such
> > connections will automatically become reset if an attempt is made
> > to send data in either direction".
> >
> > 2) for the value 9, I wonder if you consider the case (where the
> > receiving side fails to fetch a correct socket when the skb is
> > coming) as "Destination Unreachable"?
> >
> > 3) which category is the abort call case labeled? Please see RFC
> > 9293 3.10.5. ABORT Call.
> >
> > 4) what about the fin-wait-2 socket sending RST case? I quote
> > here "If the SYN is in the window it is an error: send a
> > reset...". Please see RFC 9293 3.10.7.4. Other States. For this
> > one, well, it might need more discussion because it regards the
> > real implementation?
> >
> > 5) for the value 8, what case does it refer to? We cannot reply
> > with an RST when receiving an RST.
> > ...
> >
> > There are some other reasons labelled "[ThisDocument]" that I
> > don't follow, like Not Authorized and Malformed Message. What are
> > the exact meanings of them here, I'm curious?
> >
> > It seems that I miss a lot from the beginning of this draft :(
> >
> > BTW, if you need me to do anything about this, please let me
> > know. I have strong interests in this draft :)
> >
> > Thanks,
> > Jason
> >
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Jason Xing <[e-mail]> Envoyé : jeudi 28
> > > > novembre 2024 02:19 À : [e-mail] Cc : Eric Dumazet
> > > > <[e-mail]> Objet : [tcpm] About having reset
> > reason in
> > > > TCP option
> > > >
> > > >
> > > > Hello experts/tcpm-ers :)
> > > >
> > > > I'd like to make a request to write the TCP reset reason
> > feature as
> > > > a proposed standard RFC. It's my first time doing this, so if
> > there
> > > > is something wrong or inappropriate, please let me know.
> > > > Thanks in advance.
> > > >
> > > > The outline of the full draft would be like this:
> > > > 1. explicitly define each possible reset reason with
> > corresponding
> > > > and accurate meaning, say, TCP_LINGER_REASON, which stands
> > for the
> > > > socket enables the linger option and then triggers the reset
> > > > process.
> > > > 2. negotiate first during a 3-way handshake, like the SACK
> > permitted
> > > > field.
> > > > 3. If both sides enable this feature on, then let the sending
> > side
> > > > that enters the reset process and puts the specific reset
> > reason
> > > > into the TCP option in the RST packet. Then the other side
> > will
> > > > parse the TCP option from the RST packet it receives and then
> > detect
> > > > what is going on. Also, users who use tcpdump can get
> > benefits from
> > > > this without guessing any more.
> > > > Default mode could be off.
> > > >
> > > > MPTCP has already implemented this part in the kernel (please
> > see
> > > > MPTCP_RST_EUNSPEC), which follows the RFC 8684[1].
> > > >
> > > > I think the final format in TCP could be like [2].
> > > >
> > > > [1]:
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8684%23name-
> > mp_tcprst-
> > > > reason-
> > > >
> > codes&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca390029e9d2
> > > >
> > d4975768008dd0f4ad509%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> > > >
> > 7C638683536268372165%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> > > >
> > dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> > > >
> > Q%3D%3D%7C0%7C%7C%7C&sdata=o0bZ1HdsPosTzS5TCx1KmxU6k55nzYD5KMfGFh
> > > > B2OGY%3D&reserved=0
> > > > [2]:
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8684%23name-subflow-
> > > >
> > reset&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca390029e9d2
> > > >
> > d4975768008dd0f4ad509%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> > > >
> > 7C638683536268409404%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> > > >
> > dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> > > >
> > Q%3D%3D%7C0%7C%7C%7C&sdata=6TXZou1JJAEVdqwQBRRd%2Bg33gbiUKWEdNhif
> > > > N5tEzLQ%3D&reserved=0
> > > >
> > > > I've privately discussed with Eric, Neal, Yuchung (which are
> > the TCP
> > > > maintainers in Linux kernel) before this. Then I'd like to
> > hear more
> > > > opinions from this mailing list. Any suggestions are always
> > > > welcome!!!
> > > >
> > > > Thanks,
> > > > Jason
> > > >
> > > > _______________________________________________
> > > > tcpm mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > >
> > _________________________________________________________________
> > _____
> > > ______________________________________
> > > Ce message et ses pieces jointes peuvent contenir des
> > informations
> > > confidentielles ou privilegiees et ne doivent donc pas etre
> > diffuses,
> > > exploites ou copies sans autorisation. Si vous avez recu ce
> > message
> > > par erreur, veuillez le signaler a l'expediteur et le detruire
> > ainsi que les pieces jointes. Les messages electroniques etant
> > susceptibles d'alteration, Orange decline toute responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> > >
> > > This message and its attachments may contain confidential or
> > > privileged information that may be protected by law; they
> > should not be distributed, used or copied without authorisation.
> > > If you have received this email in error, please notify the
> > sender and delete this message and its attachments.
> > > As emails may be altered, Orange is not liable for messages
> > that have been modified, changed or falsified.
> > > Thank you.
> > >
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.