[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: Flow Identification in IPv6
From:       Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date:       2021-03-09 4:03:22
Message-ID: 9ff8cb12-d23d-74c2-fea7-900d1d4e2974 () gmail ! com
[Download RAW message or body]

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
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]