Re: [tcpm] New Version Notification for draft-boucadair-tcpm-rst-diagnostic-payload-01.txt

Hi Lars, 

I'm not aware of large scale experiments but only behaviors of some specific implementations. These implementations are aligned with the BEHAVE RFCs (RFC7857, in particular):

      This document adopts a similar default behavior as in
      [RFC6146].  Concretely, when the NAT receives a TCP RST matching
      an existing mapping, it MUST translate the packet according to the
      NAT mapping entry.  Moreover, the NAT SHOULD wait for 4 minutes
      before deleting the session and removing any state associated with
      it if no packets are received during that 4-minute timeout.

However, this is not representative. A more formal evaluation would be helpful to assess whether it is safe to send only diagnostic RSTs or a mix of null-payload RST and a diagnostic RST.

Note that there are already some middlebox implementations that already share a reason code as ascii in the RST payload sent to peers. 

Cheers,
Med 

> -----Message d'origine-----
> De : Lars Eggert <lars@eggert.org>
> Envoyé : mercredi 6 avril 2022 18:40
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> Cc : tcpm@ietf.org
> Objet : Re: [tcpm] New Version Notification for draft-boucadair-
> tcpm-rst-diagnostic-payload-01.txt
> 
> Hi,
> 
> have there been experiments on the middlebox traversal properties
> of RST segments with payloads?
> 
> (Because if they got dropped, the peer would retry the failed
> connection for potentially much longer.)
> 
> Thanks,
> Lars
> 
> --
> Sent from a mobile device; please excuse typos.
> 
> > On Apr 6, 2022, at 08:27, mohamed.boucadair@orange.com wrote:
> >
> > Hi all,
> >
> > An updated version is now available:
> > https://www.ietf.org/archive/id/draft-boucadair-tcpm-rst-
> diagnostic-pa
> > yload-02.txt
> >
> > The updated version makes use of CBOR for compact encoding +
> magic number to unambiguously identify an RST payload that follows
> this spec.
> >
> > Many examples are provided in the draft to illustrate the usage.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : tcpm <tcpm-bounces@ietf.org> De la part de
> >> mohamed.boucadair@orange.com Envoyé : jeudi 31 mars 2022 09:19
> À :
> >> tcpm@ietf.org Objet : [tcpm] TR: New Version Notification for
> >> draft-boucadair-tcpm- rst-diagnostic-payload-01.txt
> >>
> >> Hi all,
> >>
> >> This draft intends to provide an interoperable solution that
> covers
> >> the last sentence of draft-ietf-tcpm-rfc793bis:
> >>
> >>   TCP implementations SHOULD allow a received RST segment to
> include
> >>   data (SHLD-2).  It has been suggested that a RST segment
> could
> >>   contain diagnostic data that explains the cause of the RST.
> No
> >>   standard has yet been established for such data.
> >>
> >> Comments and suggestions are welcome.
> >>
> >> Cheers,
> >> Med
> >>
> >> -----Message d'origine-----
> >> De : internet-drafts@ietf.org <internet-drafts@ietf.org> Envoyé
> :
> >> jeudi
> >> 31 mars 2022 09:14 À : BOUCADAIR Mohamed INNOV/NET
> >> <mohamed.boucadair@orange.com> Objet : New Version Notification
> for
> >> draft-boucadair-tcpm-rst-diagnostic-payload-01.txt
> >>
> >>
> >> A new version of I-D,
> >> draft-boucadair-tcpm-rst-diagnostic-payload-01.txt
> >> has been successfully submitted by Mohamed Boucadair and posted
> to
> >> the IETF repository.
> >>
> >> Name:        draft-boucadair-tcpm-rst-diagnostic-payload
> >> Revision:    01
> >> Title:        TCP RST Diagnostic Paylaod
> >> Document date:    2022-03-31
> >> Group:        Individual Submission
> >> Pages:        8
> >> URL:            https://www.ietf.org/archive/id/draft-
> boucadair-tcpm-
> >> rst-diagnostic-payload-01.txt
> >> Status:         https://datatracker.ietf.org/doc/draft-
> boucadair-tcpm-
> >> rst-diagnostic-payload/
> >> Htmlized:       https://datatracker.ietf.org/doc/html/draft-
> boucadair-
> >> tcpm-rst-diagnostic-payload
> >> Diff:           https://www.ietf.org/rfcdiff?url2=draft-
> boucadair-tcpm-
> >> rst-diagnostic-payload-01
> >>
> >> Abstract:
> >>   This document specifies a diagnostic payload format to be
> returned in
> >>   TCP RST segments.  Such payloads are used to share with the
> endpoints
> >>   the reasons for which a TCP connection has been reset.  This
> is meant
> >>   to ease diagnostic and troubleshooting.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >>
> >>
> >>
> __________________________________________________________________
> ___
> >> ___ _________________________________________________
> >>
> >> 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.
> >>
> >> _______________________________________________
> >> tcpm mailing list
> >> tcpm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >
> >
> __________________________________________________________________
> ____
> > ___________________________________________________
> >
> > 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.
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm

_________________________________________________________________________________________________________________________

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.