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

[[e-mail]]

Hi Jason,

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

Sure. Feel free to propose changes/text using https://github.com/boucadair/tcp-rst-diagnostic-payload/blob/main/draft-boucadair-tcpm-rst-diagnostic-payload.md.

Will follow-up in private.

Cheers,
Med

> -----Message d'origine-----
> De : Jason Xing <[e-mail]>
> Envoyé : jeudi 28 novembre 2024 16:28
> À : 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
> 
> 
> 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.
____________________________________________________________________________________________________________
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.