Re: [Detnet] Flow Identification in IPv6

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 09 March 2021 04:03 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056333A0DFE; Mon, 8 Mar 2021 20:03:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level:
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34JV5-1tcfU2; Mon, 8 Mar 2021 20:03:30 -0800 (PST)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4B03A0DFF; Mon, 8 Mar 2021 20:03:30 -0800 (PST)
Received: by mail-pl1-x631.google.com with SMTP id j6so5909014plx.6; Mon, 08 Mar 2021 20:03:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eSvcdBEJOPIsmP95kMC5IFwDDrauSSldzY22FKGjDWM=; b=a/PZ7p4M8ZimL+zWeQ+6JHmqcOXfvrSEqAiVfO0SDUk1Jco6r0BdORyaRZSpZvHObt Fl8rtP0h0A2fWREqFNOLjKwkGjLRjJco+ZW39VF615r4qCRfpd0yhqWUmqWmFZrXOzng +FDX4PoE0Jex/5tzBr1pM6pMXTo2OwLyCwy32ka6ExGUHHB9eqNdNWQMOC9Y565BVP3P L4GO5mK2DFy9xqgv0LWqfXo7rfcAwxXrqIw25nvS1vbYA69dMTggTmwjOTipMRKe5qx8 FRrETEcPh9OLmjAY52ESCVJHS9mWPUkYOkOpue9f6hE0X4lWX+APwLx8TYQFNKGb7OMe hDGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eSvcdBEJOPIsmP95kMC5IFwDDrauSSldzY22FKGjDWM=; b=afXKEd4DHETrMkOnCm4z2lGTkeflgGrLJ2GNOk37vI82aWO2ymR+vaL3rrwFVGjTbo m4/G/rupnOqEtbIiECHunCkUPxBWN7fqhZBWSHrbuvV6VtBdnJiRMt1PjWeZGUeJu7qM rBpnfWg8FE4fSYmWyrhuTPmxb8VckE7ww0VpB2drz84m9qonnNX86iqbgdkhRJf8w3+6 9FVa7Oxl29E1x8xUqa7VZzzIrG4dzf+8SzPLaHYI6sLn3trf/B+phXAUu7j/bEt8w063 jrZQ4Y9TwY8Vrra8w4L9YI6u8v2uBXvH+5mVnhxW6IsrMssGHSvZaFKd68IKaWfZM5wV hJVg==
X-Gm-Message-State: AOAM530pgS65JU9Uv0QcbOOZ1DEaRAy6RI87kK2HmLr/Br68zjCpUy00 CLOAQek2OX1qKn0mKrz7GvzSH1BAJFZBTw==
X-Google-Smtp-Source: ABdhPJzS0JunBHUBKxqg/kSvyAmJa89kffqjvkzuGpglHdLpOwJA8Rc34BpmsUXeiqlQBqYoahPfDA==
X-Received: by 2002:a17:90a:5510:: with SMTP id b16mr2496867pji.87.1615262608524; Mon, 08 Mar 2021 20:03:28 -0800 (PST)
Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id s27sm10917685pgk.77.2021.03.08.20.03.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Mar 2021 20:03:27 -0800 (PST)
To: Tom Herbert <tom@herbertland.com>, "Yangfan (IP Standard)" <shirley.yangfan@huawei.com>
Cc: DetNet WG <detnet@ietf.org>, 6man WG <ipv6@ietf.org>, "draft-geng-6man-redundancy-protection-srh@ietf.org" <draft-geng-6man-redundancy-protection-srh@ietf.org>
References: <CA+RyBmW9XCwSmsrm291GgdRV1UivNzO7m8b1AYWkCDkfDT61jA@mail.gmail.com> <3fdc1006788e47e59cfb8dcc03e9bce6@huawei.com> <CALx6S34CunfW=69YdGn2Yu1+B-dPps_uJg7sMPmfoii7Yn2Bpw@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <9ff8cb12-d23d-74c2-fea7-900d1d4e2974@gmail.com>
Date: Tue, 9 Mar 2021 17:03:22 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CALx6S34CunfW=69YdGn2Yu1+B-dPps_uJg7sMPmfoii7Yn2Bpw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/ColrJWoFFQadhfKdZrEi1NS3vT4>
Subject: Re: [Detnet] Flow Identification in IPv6
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Mar 2021 04:03:32 -0000

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>rg>; DetNet WG <detnet@ietf.org>rg>; 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
> --------------------------------------------------------------------
>