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

From: <[email-masked]>
Date: Wed, 6 Apr 2022 05:27:36 +0000

Hi all, 

An updated version is now available: https://www.ietf.org/archive/id/draft-boucadair-tcpm-rst-diagnostic-payload-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 <[email-masked]> De la part de
> [email-masked]
> Envoyé : jeudi 31 mars 2022 09:19
> À : [email-masked]
> 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 : [email-masked] <[email-masked]> Envoyé : jeudi
> 31 mars 2022 09:14 À : BOUCADAIR Mohamed INNOV/NET
> <[email-masked]> 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
> [email-masked]
> 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.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 6 Apr 2022 19:39:32 +0300

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, [email-masked] wrote:
> 
> Hi all, 
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 7 Apr 2022 08:38:15 +0000

Yes I would be interested in some data as well.

However, I guess that problem can be easily fixed, as you could just always send two RSTs (first the one with the payload and then one without in case the first one gets lost). Still would be interesting to get a feeling if that actually is a problem that needs fixing.

Mirja

On 06.04.22, 18:40, "tcpm on behalf of Lars Eggert" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Thanks,
    Lars

---

From: <[email-masked]>
Date: Thu, 7 Apr 2022 08:40:59 +0000

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 

> De : Lars Eggert <[email-masked]>
> Envoyé : mercredi 6 avril 2022 18:40
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : [email-masked]
> Objet : Re: [tcpm] New Version Notification for draft-boucadair-
> tcpm-rst-diagnostic-payload-01.txt
> 
> Hi,
> 
> > 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.
> >
> >> [email-masked] Envoyé : jeudi 31 mars 2022 09:19
> À :
> >> [email-masked] 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:
> >>
> >> De : [email-masked] <[email-masked]> Envoyé
> :
> >> jeudi
> >> A new version of I-D,
> >> has been successfully submitted by Mohamed Boucadair and posted
> to
> >> the IETF repository.
> >>
> __________________________________________________________________
> ___
> >> ___ _________________________________________________
> >>
> >> 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.
> __________________________________________________________________
> ____
> > ___________________________________________________
> >
> > 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.
> >

---

From: <[email-masked]>
Date: Thu, 7 Apr 2022 08:54:27 +0000

Hi Mirja, 

Agree.

Many implementations are already doing this, but with proprietary codes and so on (e.g., https://support.citrix.com/article/CTX200852). Examples of traces can be found at: https://isc.sans.edu/forums/diary/The+special+case+of+TCP+RST/26824/. etc.  

Also, the lack of a standard way to report back the reset reason has led, for example, to define a specific option included in an RST to encode the reset code (MPTCP, rfc8684.html#name-subflow-reset). The use of an option is more problematic in the presence of middleboxes.  

Cheers,
Med

> De : Mirja Kuehlewind <[email-masked]>
> Envoyé : jeudi 7 avril 2022 10:38
> À : Lars Eggert <[email-masked]>; BOUCADAIR Mohamed INNOV/NET
> <[email-masked]>
> Cc : [email-masked]
> However, I guess that problem can be easily fixed, as you could
> just always send two RSTs (first the one with the payload and then
> one without in case the first one gets lost). Still would be
> interesting to get a feeling if that actually is a problem that
> needs fixing.
> 
> Mirja
> 
> 
> On 06.04.22, 18:40, "tcpm on behalf of Lars Eggert" <tcpm-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     Hi,
> 
>     have there been experiments on the middlebox traversal
> properties of RST segments with payloads?
> 
> diagnostic-payload-02.txt
>     >
>     >> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-boucadair-
> ______
> _______________________________________________________
>     >
>     > 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,
> privileged information that may be protected by law;
>     > As emails may be altered, Orange is not liable for messages
> that have been modified, changed or falsified.
>     > Thank you.
>     >