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

[Jason Xing <[e-mail]>]

Hello Mohamed,

On Thu, Nov 28, 2024 at 9:46 PM <[e-mail]> wrote:
>
> Hi Jason,
>
> FWIW, you may find a proposal in https://datatracker.ietf.org/doc/html/draft-boucadair-tcpm-rst-diagnostic-payload-08, 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.
>