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

[[e-mail]]

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.

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 :-)

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.