Re: [tsvwg] Fwd: New Version Notification for draft-reddy-tsvwg-explcit-signal-00.txt

[[e-mail]]

Hi Tom,

The
> sort of signaling described should be in the network layer, IPv6
> HBH options for instance.

That’s indeed an option we considered but the current design in the draft is superior as it covers both v4/v6. 

As you know, we don’t have much (no) choices to provide the same functionality for IPv4. 

Ted's RFC rfc8558.html#section-3.2 briefly touches on this. 

Cheers,
Med

> -----Message d'origine-----
> De : tsvwg <[e-mail]> De la part de Tom Herbert
> Envoyé : mardi 21 février 2023 00:44
> À : C. M. Heard <[e-mail]>
> Cc : [e-mail]
> Objet : Re: [tsvwg] Fwd: New Version Notification for draft-reddy-
> tsvwg-explcit-signal-00.txt
> 
> On Mon, Feb 20, 2023 at 3:26 PM C. M. Heard <[e-mail]>
> wrote:
> >
> > One overall question: per
> > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-
> options#sec
> > tion-14,
> >
> >    UDP options are transport options. Generally, transport
> headers,
> >    options, and data are not intended to be modified in-transit.
> UDP
> >    options are no exception and here are specified as "MUST NOT"
> be
> >    altered in transit. However, the UDP option mechanism
> provides no
> >    specific protection against in-transit modification of the
> UDP
> >    header, UDP payload, or surplus area, except as provided by
> the OCS
> >    or the options selected (e.g., AUTH, or UENC).
> >
> >
> > Does this draft comply with this requirement?
> 
> Mike,
> 
> That addresses modification, but it's also questionable whether
> intermediate nodes should be inspecting UDP Options at all. The
> sort of signaling described should be in the network layer, IPv6
> HBH options for instance. In any case the question might be
> irrelevant considering middlebox hardware devices typically are
> capable of processing only headers and not trailers like UDP
> options.
> 
> Tom
> 
> >
> > Mike Heard
> >
> > On Thu, Feb 9, 2023 at 9:31 PM tirumal reddy <[e-mail]>
> wrote:
> >>
> >> Hi all,
> >>
> >> The new draft https://datatracker.ietf.org/doc/html/draft-
> reddy-tsvwg-explcit-signal defines a mechanism for an endpoint to
> explicitly signal encrypted metadata to the network, and the
> network to signal its ability to accommodate that metadata back to
> the endpoint. This mechanism can be used where the endpoints
> desire that network elements along the path receive these explicit
> signals. It proposes three mechanisms to encrypt or obfuscate the
> metadata in the explicit signal.
> >>
> >> Comments and suggestions are welcome.
> >>
> >> Cheers,
> >> -Tiru
> >>
> >> ---------- Forwarded message ---------
> >> From: <[e-mail]>
> >> Date: Thu, 9 Feb 2023 at 13:26
> >> Subject: New Version Notification for
> >> draft-reddy-tsvwg-explcit-signal-00.txt
> >> To: Tirumaleswar Reddy.K <[e-mail]>, Dan Wing
> >> <[e-mail]>, Mohamed Boucadair
> <[e-mail]>
> >>
> >>
> >>
> >> A new version of I-D, draft-reddy-tsvwg-explcit-signal-00.txt
> >> has been successfully submitted by Tirumaleswar Reddy and
> posted to
> >> the IETF repository.
> >>
> >> Name:           draft-reddy-tsvwg-explcit-signal
> >> Revision:       00
> >> Title:          Encrypted Transport Protocol Path Explicit
> Signals
> >> Document date:  2023-02-08
> >> Group:          Individual Submission
> >> Pages:          18
> >> URL:            https://www.ietf.org/archive/id/draft-reddy-
> tsvwg-explcit-signal-00.txt
> >> Status:         https://datatracker.ietf.org/doc/draft-reddy-
> tsvwg-explcit-signal/
> >> Htmlized:       https://datatracker.ietf.org/doc/html/draft-
> reddy-tsvwg-explcit-signal
> >>
> >>
> >> Abstract:
> >>    This document defines a mechanism for an endpoint to
> explicitly
> >>    signal encrypted metadata to the network, and the network to
> signal
> >>    its ability to accommodate that metadata back to the
> endpoint.  This
> >>    mechanism can be used where the endpoints desire that
> network
> >>    elements along the path receive these explicit signals.
> >>
> >>
> >>
> >>
> >> 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.