Re: [tsvwg] signaling packet importance [was Re: New Version Notification for draft-herbert-fast]

[Tom Herbert <[e-mail]>]

On Thu, Aug 17, 2023, 4:42 AM Huangyihong (Rachel) <rachel.huang=
[e-mail]> wrote:

> Hi Tom,
>
>
>
> Please see below.
>
>
>
> BR，
>
> Rachel
>
>
>
> *发件人:* Tom Herbert <tom=[e-mail]>
> *发送时间:* 2023年8月17日 11:03
> *收件人:* Huangyihong (Rachel) <[e-mail]>
> *抄送:* Sri Gundavelli (sgundave) <[e-mail]>; Joe Touch <
> [e-mail]>; TSVWG <[e-mail]>
> *主题:* Re: [tsvwg] signaling packet importance [was Re: New Version
> Notification for draft-herbert-fast]
>
>
>
>
>
> On Tue, Aug 15, 2023, 11:18 PM Huangyihong (Rachel) <rachel.huang=
> [e-mail]> wrote:
>
> Hi all,
>
> BR，
> Rachel
>
> > -----邮件原件-----
> > 发件人: tsvwg <[e-mail]> 代表 Tom Herbert
> > 发送时间: 2023年8月16日 4:36
> > 收件人: Sri Gundavelli (sgundave) <[e-mail]>
> > 抄送: [e-mail]; TSVWG <[e-mail]>
> > 主题: Re: [tsvwg] signaling packet importance [was Re: New Version
> > Notification for draft-herbert-fast]
> >
> > On Mon, Aug 14, 2023 at 9:35 PM Sri Gundavelli (sgundave)
> > <[e-mail]> wrote:
> > >
> > > Hi Tom,
> > >
> > > Thank you for your response.  The focus of the draft
> (media-hdr-wireless) is
> > on the meta-data elements, their definitions, and the related semantics.
> How
> > we show the relationships between different frames that are part of the
> same
> > IP flow, so elements in the network (e.g., RAN) can make certain choices
> when
> > there are limiting forwarding resources at its disposal.  The mechanics
> around
> > how we transport them is not the primary focus, as such any decent
> transport
> > would meet the goals.
> >
> > Yes, I agree with that. FAST is about the mechanics of signaling.
> >
> > >
> > > Also, "Signaling" is a very broad term.
> >
> > This is specifically about host to network signaling where packets to
> some
> > destination are annotated with information intended for consumption by
> > intermediate nodes in the packet's path. It's not intended to mean
> signals that
> > are explicitly sent in packets directly to network elements. Perhaps, we
> should
> > use the term "inband host to network signaling" or something like that
> to be
> > clear.
>
> [Rachel]: I think the signaling should be bi-directional, not only about
> host to network, but also network to host where information (usually are
> network configuration or network conditions) could be signaled for host to
> consume. This would facilitate the application to make good decisions. So
> if we wanna talk about a general enough mechanism, personally I prefer it
> to include both.
>
>
>
> Hi Rachel,
>
>
>
> I believe that's covered by IOAM.
>
>
>
> [Rachel]: If IOAM could do this, it definitely has to deal with the same
> security issues that you describes. So more discussion are needed.
>
>
>
> Besides that, a reason not to combine these too quickly is that network to
> host signaling has very different security characteristics than host to
> network signaling-- in flight modification of data, attribution, and how to
> authenticate with multiple writers.
>
>
>
> [Rachel]: I understand that you guys are trying to narrow the scope, and
> focus on the solutions. But, wouldn’t it be better if there’s a general
> solution could support both cases? Unless IETF agrees that they should be
> separated and it’s impossible to have such one.
>
Hi Rachel,

I think architecture for a general solution to support both cases already
exists in HBH options. For instance, a packet could carry both a FAST
option and IOAM option. The FAST option in not modifiable (can be covered
by Auth header), and the IOAM option is modifiable (data not covered by
Auth header).

Also, the IOAM option doesn't need additional mechanisms to for hosts to
authenticate the data since the source of data is the network and being
connected to the network requires a level of implicit trust by the host
anyway. So if a host receives IOAM option in a network interface, that is
sufficient validation that network is the source of the IOAM data. This
only works if IOAM is restricted to limited domains which is the
recommendation.

The converse isn't true, when a host connects the network has no incentive
to implicitly trust the host. When a host requests services, like
throughput guarantees, the network needs to validate that the identity of
the client, the client is entitled to the services, and the client is
confirming to the parameters of and SLA.

Tom


>
> Tom
>
>
>
>
> >
> > > Signaling in the context of the above drafts is about providing
> additional
> > information about the frame in question. If we make an argument that even
> > though the application is different, but since there involves some form
> of
> > signaling from the host to network and so it should be based on the same
> > protocol approach. Then that’s a very broad brush we are using.   We
> cannot
> > group a solution related to gaining access grant to a network resource,
> with an
> > application that requires meta-data signaling for frame characterization.
> > These are different applications, each requiring different set of
> services from
> > the network.  There is Radio setup signaling, authentication relation
> signaling,
> > and address configuration related signaling, but each use a specific
> protocol.
> >
> > I see grant of admission, QoS parameters like from characterization,
> etc. to be
> > different service attributes. You're highlighting the fact that there
> can't be any
> > single standard definition of service attributes that covers all
> possible use cases.
> > The old TOS bits for Low latency, High throughput, Low monetary cost
> aren't
> > nearly sufficient, and different networks will offer different services
> that need
> > to be characterized and can be requested.
> >
> > > The domain of the application, use-case and the application environment
> > dictate the protocol design choice. IMO, linking these requirements may
> not
> > be a good idea.
> >
> > I agree to that to the extent that communication is application to
> application,
> > so that there are only two participants. However, if packets are tagged
> with
> > ancillary information intended for consumption by intermediate nodes,
> then
> > the communication now involves N parties and the requirements for
> > interoperability and security increase dramatically.
> >
> > Tom
> >
> >
> > >
> > >
> > > Regards
> > > Sri
> > >
> > >
> > >
> > >
> > >
> > > On 8/14/23, 8:01 AM, "Tom Herbert" <[e-mail]
> > <mailto:[e-mail]>> wrote:
> > >
> > > Hi Sri,
> > >
> > >
> > > draft-media-hdr-wireless would be a use case draft-herbert-fast is a
> > > proposal for a common carrier of network signaling,
> > > draft-media-hdr-wireless describes a use case, content, of host to
> > > network signaling as well as a carrier in a UDP options.
> > >
> > >
> > > > The first drafts talks about fundamentally changing the IP networking
> > model by carrying tickets in IP packets for gaining service / forwarding
> access,
> > and whereas the other draft has very specific requirement for carrying
> > meta-data so a transit network (e.g. RAN) can use this meta-data in
> forwarding
> > decisions. Putting them together and finding a generic solution amounts
> to
> > boiling the ocean, and IMHO, we will achieve nothing.
> > > >
> > > > The idea of carrying service tickets in IP Packets (though not a new
> concept)
> > is an interesting idea. That sounds great on paper, but do you think
> that level
> > of orchestration is suited for IP networks? I am not sure.
> > >
> > >
> > > That is fundamentally no different than the orchestration needed to
> > > carry metadata as described in draft-media-hdr-wireless in IP packets.
> > > In fact, I don't see any material difference between "metadata"
> > > draft-media-hdr-wireless in used in and "tickets", their pretty much
> > > different names for the same thing-- they are data sent in IP packets
> > > to be inspected by intermediate nodes to affect QoS or routing.
> > > Similarly, the "wireless node" that is inspecting the UDP options
> > > in-flight is really just an intermediate node in IETF parlance.
> > > >
> > > > A router will inspect a packet, validate the ticket and allow the
> packet to
> > traverse through? We require a completely new forwarding plane.
> > >
> > >
> > > Only edge routers would want to process tickets, it's the same modes
> > > as in draft-media-hdr-wireless where the Wireless Node is probably the
> > > only node that would need to process the UDP options carrying MED
> > > data. No new forwarding plane is needed any more than what's needed
> > > for "a transit network (e.g. RAN) can use this meta-data in forwarding
> > > decisions" as you mentioned above.
> > >
> > >
> > > > Do you think any router vendors will implement such schemes impacting
> > the forwarding performance, looking at some new hop by options requiring
> > crypto resources? This reminds me of RSVP and COPS, how much traction did
> > we find for that in enterprise IP networks, It is not all diff-serv?
> > >
> > >
> > > Yes, securing tickets to prevent forgery or information leakage is a
> > > hard problem, but it's a common problem with host to network
> > > signaling; for instance, draft-media-hdr-wireless states: "When there
> > > are insecure network segments in between, all packets that carry the
> > > metadata in the MED UDP option must be secured with encryption between
> > > these segments". If that solution is sufficient then it could be used
> > > for FAST as well to meet the security requirements.
> > >
> > >
> > > >
> > > > Maybe these are totally different problems and with no relation.
> > >
> > >
> > > I believe it's the exact opposite, they are very related as they are
> > > solving parts of a common problem. Note that
> > > https://datatracker.ietf.org/doc/html/draft-reddy-tsvwg-explcit-signal
> > > <https://datatracker.ietf.org/doc/html/draft-reddy-tsvwg-explcit-signa
> > > l> is also doing this as that draft defines a mechanism for an
> > > endpoint to explicitly signal encrypted metadata to the network. There
> > > are some other drafts in this same area as well. The common problem
> > > is: how do hosts send signals into the network to affect routing or
> > > QoS in a secure fashion. A common solution to a common problem
> > > benefits everyone :-)
> > >
> > >
> > > Tom
> > >
> > >
> > >
> > >
> > > >
> > > > Regards
> > > > Sri
> > > >
> > > >
> > > >
> > > >
> > > > On 8/13/23, 10:06 AM, "Tom Herbert" <[e-mail]
> > <mailto:[e-mail]> <mailto:[e-mail]
> > <mailto:[e-mail]>>> wrote:
> > > >
> > > >
> > > > On Sun, Aug 13, 2023 at 8:48 AM Kaippallimalil John
> > > > <[e-mail]
> > <mailto:[e-mail]>
> > <mailto:[e-mail]
> > <mailto:[e-mail]>>> wrote:
> > > > >
> > > > > > My concern is that endorsing use of UDP options to signal
> in-network
> > devices could cause the same reaction as IP HBH options - that they
> could be
> > seen as unsafe to routers and could cause an over-reaction that causes >
> > deliberate blocking or stripping.
> > > > > >
> > > > > > As the discussion noted, that’s not currently the case, or at
> > > > > > least as best can be determined. I
> > > > > >
> > > > > > It’d be useful to avoid creating new reasons that routers would
> want to
> > interfere. I.e., the question isn’t whether IP options are an
> alternative - they
> > clearly are the appropriate place for draft-kaippallimalil-tsvwg-media->
> > hdr-wireless and draft-reddy-tsvwg-explcit-signal - it’s whether using
> UDP
> > options for those purposes could jeapordize them for everyone else.
> > > > >
> > > > > The procedures in draft-kaippallimalil-tsvwg-media- hdr-wireless
> can in
> > theory be realized by encoding it in IPv6 HBH options (IPv4 is another
> > questions) but I share Mike's concern about the timeline.
> > > > > (-- " Those might bear fruit someday, though the timeline is at
> best
> > uncertain").
> > > > > The authors (of tsvwg-media- hdr-wireless) are primarily looking to
> > providing a viable solution for 3GPP in the short term (end of 2024 or
> so) even
> > if it is an Experimental or Informational one.
> > > >
> > > >
> > > > John,
> > > >
> > > >
> > > > Your desire for an expedited solution is understandable, however it
> > > > is typical in IETF to work on protocols that have broad
> > > > applicability across many use cases. A common host to network
> > > > signaling solution could eventually benefit all Internet users to
> give them
> > improved QoS.
> > > > You might want to consider how
> > > > draft-kaippallimalil-tsvwg-media-hdr-wireless could be generalized
> > > > to that end.
> > > >
> > > >
> > > > Tom
> > > >
> > > >
> > > > >
> > > > > And I acknowledge the issue that Joe has pointed to - of whether
> UDP
> > options will be seen as unsafe, and a corresponding over-reaction.
> > > > > Our attempt in draft-kaippallimalil-tsvwg-media- hdr-wireless to
> avoid
> > this has been that:
> > > > > - the MED option is to be used only within a limited domain that
> > > > > spans an application network and wireless network with
> > > > > pre-established trust (RFC 8799)
> > > > > - if the MED option crosses an "untrusted network" (e.g. , a
> transport
> > network in between), the entire flow should be encrypted such that MED
> is not
> > visible.
> > > > > - if a MED option is visible outside the limited domain with trust
> (set of
> > application, wireless networks), the draft recommends that MED be
> dropped.
> > > > >
> > > > > BR,
> > > > > John
> > > > >
> > > > >
> > > > >
> > > > > From: tsvwg <[e-mail]
> > > > > <mailto:[e-mail]> <mailto:[e-mail]
> > > > > <mailto:[e-mail]>>> On Behalf Of
> > > > > [e-mail] <mailto:[e-mail]>
> > > > > <mailto:[e-mail] <mailto:[e-mail]>>
> > > > > Sent: Sunday, August 13, 2023 10:07 AM
> > > > > To: C. M. Heard <[e-mail] <mailto:[e-mail]>
> > > > > <mailto:[e-mail] <mailto:[e-mail]>>>
> > > > > Cc: TSVWG <[e-mail] <mailto:[e-mail]>
> > > > > <mailto:[e-mail] <mailto:[e-mail]>>>; Sri Gundavelli
> > > > > <[e-mail] <mailto:[e-mail]>
> > > > > <mailto:[e-mail] <mailto:[e-mail]>>>
> > > > > Subject: Re: [tsvwg] signaling packet importance [was Re: New
> > > > > Version Notification for draft-herbert-fast]
> > > > >
> > > > > My concern is that endorsing use of UDP options to signal
> in-network
> > devices could cause the same reaction as IP HBH options - that they
> could be
> > seen as unsafe to routers and could cause an over-reaction that causes
> > deliberate blocking or stripping.
> > > > >
> > > > > As the discussion noted, that’s not currently the case, or at
> > > > > least as best can be determined. I
> > > > >
> > > > > It’d be useful to avoid creating new reasons that routers would
> want to
> > interfere. I.e., the question isn’t whether IP options are an
> alternative - they
> > clearly are the appropriate place for
> > draft-kaippallimalil-tsvwg-media-hdr-wireless and
> > draft-reddy-tsvwg-explcit-signal - it’s whether using UDP options for
> those
> > purposes could jeapordize them for everyone else.
> > > > >
> > > > > draft-daiya-tsvwg-udp-options-protocol-number is of a completely
> > different nature; it aims to be part of the transport protocol in
> chaining the
> > meaning of protocol layers, rather than encoding them all in the
> destination
> > port of the first exchange. In that regard, it’s more like
> draft-touch-tcpm-sno
> > (service number option), except that it would require similar ’next
> protocol’
> > identifiers at all protocol layers, which is (sadly) not the way current
> services
> > and protocol stacks work.
> > > > >
> > > > > Joe
> > > > >
> > > > >
> > > > > —
> > > > > Dr. Joe Touch, temporal epistemologist http://www.strayalpha.com
> > > > > <http://www.strayalpha.com> <http://www.strayalpha.com>
> > > > > <http://www.strayalpha.com&gt;>
> > > > >
> > > > >
> > > > > On Aug 12, 2023, at 6:14 PM, C. M. Heard <mailto:[e-mail]
> > <mailto:[e-mail]> <mailto:[e-mail]
> > <mailto:[e-mail]>>> wrote:
> > > > >
> > > > > On Fri, Aug 11, 2023 at 7:47 PM Joe Touch wrote:
> > > > > Just to be clear:
> > > > > On Aug 11, 2023, at 2:42 PM, C. M. Heard <mailto:[e-mail]
> > <mailto:[e-mail]> <mailto:[e-mail]
> > <mailto:[e-mail]>>> wrote:
> > > > > I've been pushing the idea to co-opt the per-fragment UDP options
> used
> > for host-to-network signaling, and I'd like to make some comments about
> that.
> > > > >
> > > > > This confuses transport options with network options.
> > > > >
> > > > > Not confusion, but rather an explicit proposal to use the
> per-fragment
> > options as network options instead of transport options. It is put
> forward to
> > provide potentially workable solutions to the problems that
> > draft-kaippallimalil-tsvwg-media-hdr-wireless and
> > draft-reddy-tsvwg-explcit-signal are intended to solve.
> > > > >
> > > > > Granted, an architecturally preferable way to accomplish these
> objectives
> > would be to use IPv4 Options or IPv6 Hop-by-Hop Options. Indeed, I myself
> > would prefer for IPv4/IPv6 Options to be used if the issues of high
> discard rates
> > of packets with these options could be solved. There are efforts
> underway to
> > mitigate the problems for IPv6 Hop-by-Hop Options. Those might bear fruit
> > someday, though the timeline is at best uncertain. But as far as I know,
> the
> > discard rates for IPv4 Options are equally dismal, and there are no
> efforts
> > underway to fix that problem. Correction by parties with better
> knowledge of
> > the facts than mine are invited.
> > > > >
> > > > > My take is that the problems that
> > draft-kaippallimalil-tsvwg-media-hdr-wireless and
> > draft-reddy-tsvwg-explcit-signal (and possibly
> > draft-daiya-tsvwg-udp-options-protocol-number as well) could, in
> principle, be
> > solved by what I see as a modest change of direction to the UDP Options
> spec.
> > Whether that would work out in practice is much less certain, for the
> reasons
> > that Tom Herbert has pointed out. IMO it is a judgement call whether the
> > chances are better to get IP Options (in any version) to work within our
> > professional lifetimes. Given that, I don't think it would be right to
> turn
> > draft-kaippallimalil-tsvwg-media-hdr-wireless and
> > draft-reddy-tsvwg-explcit-signal away without a proper discussion.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mike
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
>