Re: [Detnet] Flow Identification in IPv6

How about taking a bit from the "reserved" field in the draft
to indicate if/when the IPv6 header flow label is being used
as the flow identification field. That would make using the flow
label field an option for the operator to decide.

For example, i could see not wanting to use the flow label field
if it's pushed down from encapulated IPv6 traffic and used already
for some other purpose than PREOF.

Cheers
    Toerless

On Tue, Mar 09, 2021 at 05:03:22PM +1300, Brian E Carpenter wrote:
> On 09-Mar-21 05:31, Tom Herbert wrote:
> > On Mon, Mar 8, 2021 at 2:38 AM Yangfan (IP Standard)
> > <shirley.yangfan@huawei.com> wrote:
> >>
> >> Hi Greg,
> >>
> >> Literally speaking, IPv6  Flow Label could be used to identify a specific flow needing redundancy protection in SRv6 data plane. But I may have concerns that flow label cannot be protected to be unmodified en route. A modified flow label can be a disaster for the traffics  which are seeking for deterministic forwarding, not only this flow, also affecting other flows using redundancy protection. And with several security issues mentioned in RFC6437, I doubt if it is a good idea to user IPv6 Flow Label.
> >>
> >> Just my 2cents opinion, how do you and other people see it?
> >>
> > 
> > If this is to be used in a SRv6 domain which is itself a limited
> > domain, then I think the problems you mention aren't as much of a
> > concern since flow label would be used in a controlled environment.
> > The upside of using flow label is that it's already in the IPv6
> > header, it can be consumed by non-SRv6 devices, and putting the same
> > information in TLVs incurs the overhead and cost of processing TLVs in
> > the critical datapath.
> 
> The main downside is that it cannot convey any semantics and there is
> a rule about how its value is created. It's no more at risk of being
> modified than any other unauthenticated header field, so I agree that
> within an SRV6 domain malicious modification doesn't seem like a
> big risk. An attacker who could do that could do any kind of damage
> they wanted.
> 
> Regards
>     Brian
> 
> 
> > 
> > Tom
> > 
> >>
> >>
> >> Regards,
> >>
> >> Fan
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ?????????: Greg Mirsky [mailto:gregimirsky@gmail.com]
> >> ????????????: 2021???3???7??? 4:20
> >> ?????????: draft-geng-6man-redundancy-protection-srh@ietf.org
> >> ??????: 6man WG <ipv6@ietf.org>; DetNet WG <detnet@ietf.org>; Greg Mirsky <gregory.mirsky@ztetx.com>
> >> ??????: Flow Identification in IPv6
> >>
> >>
> >>
> >> Dear Authors,
> >>
> >> thank you for bringing your proposal to the discussion. I agree with your view that the explicit routing enabled by SRv6 creates an environment where PREOF can be used. And, as we know, The PREOF may be used in a DetNet domain to lower packet loss ratio and provide bounded latency.
> >>
> >> After reading the draft, I've got a question for you. What do you see as the difference between the IPv6 Flow Label per RFC 6437 and the Flow Identification field in the TLV proposed in the draft? Could the IPv6 Flow Label be used to identify the flow for the PREOF?
> >>
> >>
> >>
> >> Regards,
> >>
> >> Greg
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
> 
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet

-- 
---
tte@cs.fau.de