Re: [Bier] Feedback on draft-eckert-bier-rbs-00

IJsbrand Wijnands <ice@braindump.be> Thu, 09 March 2023 10:24 UTC

Return-Path: <ice@braindump.be>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE40C14CE2F; Thu, 9 Mar 2023 02:24:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailprotect.be
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9O69L_QZ4wv; Thu, 9 Mar 2023 02:24:23 -0800 (PST)
Received: from com-out001.mailprotect.be (com-out001.mailprotect.be [83.217.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA852C14CE2C; Thu, 9 Mar 2023 02:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mailprotect.be; s=mail; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:reply-to:sender:bcc; bh=B/C+VtuyKiyNqW4Knmn9qKX9A3GPQy8FDqjFK1wnzPg=; b=Zl5WwB5JCWcxgYPsU/xCjIdrRU bEqakO6Uj/OydihO735F9aHebQTWC+7SPRtNKJhr70/jllG5j543f7v1Ck5nqoGzW2kngzPzV4mL2 UHzP/MGuSARx8lS4O7q/yfSyetVM00BNHp8ll1+E9dLgW9PakHGOwfkEJAftAWaANqrFCWSE8aNiv qj7v9Mm+UruuYfi1NNlsYBg9xNzfW0fxhWv+ozQs6RfaAfgPNHGfujBJKaQpnwAxrvc3Mq+D3mVUz k8EKmhRapgAo/obWcCwSRvfcQ6fddxz2JLS3gmXk6w1PyQMP/ofl9GoMPzfpXxnL3RwtcUKrW/hzz +TSy85TQ==;
Received: from smtp-auth.mailprotect.be ([178.208.39.155]) by com-mpt-out001.mailprotect.be with esmtp (Exim 4.92) (envelope-from <ice@braindump.be>) id 1paDRX-0006rw-HK; Thu, 09 Mar 2023 11:24:16 +0100
Received: from smtpclient.apple (29.225-241-81.adsl-static.isp.belgacom.be [81.241.225.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-auth.mailprotect.be (Postfix) with ESMTPSA id 94AA3C9473; Thu, 9 Mar 2023 10:55:44 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: IJsbrand Wijnands <ice@braindump.be>
In-Reply-To: <ZAlExKy8yGyz9h8R@faui48e.informatik.uni-erlangen.de>
Date: Thu, 09 Mar 2023 10:55:44 +0100
Cc: draft-eckert-bier-rbs@ietf.org, BIER WG <bier@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE75B3B2-7004-4A1A-A226-012FA076BCDA@braindump.be>
References: <Y3NpPev+bIhWrtyS@faui48e.informatik.uni-erlangen.de> <0DD084D4-429B-4126-AC47-22471BCBA7A9@braindump.be> <F5ECC551-341C-4C5E-98BF-28E4D9F11C43@braindump.be> <ZAFILEvZWDowZr4j@faui48e.informatik.uni-erlangen.de> <5A31AF91-19B8-458F-B6C9-90521CD62673@braindump.be> <ZAlExKy8yGyz9h8R@faui48e.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Originating-IP: 178.208.39.155
X-SpamExperts-Domain: mailprotect.be
X-SpamExperts-Username: 178.208.39.128/27
Authentication-Results: mailprotect.be; auth=pass smtp.auth=178.208.39.128/27@mailprotect.be
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.12)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8GLBkquC+pIQZu0TbXbSqKPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wqL5ce0izo3MEwlThXh+L+Eq1uToV35zEggExruXqwDns7 zmR8SrJBKoHsJAkCbDqD2rMopwoVQz84tBAdBLvFyQLfXoabdmF7Z8uHfA5hh7UDcftAPZqXAv+O TxMDSaMEybI1sOftHmSKUCHCvcq0TzZjnkrrL1mACMw/UF0G0bQ7KakNnWEuMvWMJYJgW0RcniGV 00rcqD8ns3hJjqSIJYN6Crh9DXUDEtWWsjsNUWDlGPaDR+Aes7asAZpVFyfMODodi5MLJiAvrVIi QFNhc8S+HKYI1vbaqYoREZsvVKq8YZ9/SG1CqFB/T9oOuGkszjGcI+mbLJLuOAP016dVWgH88tf6 uZ3Odz3W94IkDNey7wEf3rBXwmzCivpMYSIRN1GWdLWiieE4sApt6oWVGSRxJYEqfHH6e3h3i3L5 b/siHDX/ZpgnR2L6ZSxUhuCgUnzQUUh7zrY+gccQHlvFRbojusghAHJVSwcPHv0z3JA5Fxib54ho r19Rav1EA3X0VjYiWyhWVAgRTI92lX0U8pjOFfnWL8N84Gl+TAvkmIQpRkKgWi6P+HuUVk3o3aTB eNDGo37FEc/C+HZkCypl2eHIgfodXOAsKprebW4raQ4yiMdx93ZmHZ6F/fkurvR6STBVn6+W3keP xSYlwJ5B1C9SYHs1HVkNOVbBoq352rVtcQ+zTxxVZMQuWFZ1NemnYhV4s0WHRXGZZPQzDltIAHOu 27cKJle450MdBm594FVdc2K+waea2lUOnotr/fNQvy23SZXSfMZ7RzHGH1l2naPKc3yQvxQmzKsA iXiBbOXHnxMBz1akGfHW8zJZfW0f4ngLmK0LObbZiXBeyQEpViU4oE+ncQYpfHQGnNPTwRxrN3XQ 8ABQoz/Q6PkRZAZ326zBXCRRkPNZOeZhl83ItgZkcRkCnoMzps1w8ZlyWp5OlwYUQ1ejeQ1GJqZG MW0WCHtA05KYHui9AUj7nFxAZyCgxZHINA6A5+7T9o6byzvDwAcft/nzfIptzPRrK2/ShgkK/IUj CNCeBQgjifLRQVNUvx4T911LgXOuhzWRBTEvuGslKTrRIXcXpFg5ivY=
X-Report-Abuse-To: spam@com-mpt-mgt001.mailprotect.be
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/BuN-Zm75fD8O6IlbYYqL7iQi3hM>
Subject: Re: [Bier] Feedback on draft-eckert-bier-rbs-00
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Mar 2023 10:24:28 -0000

Toerless,

> Once we feel we've worked through open issues, it will be "stable" wrt. to being
> able to parse packets with the same level of confidence and possible mishaps as comparable
> pre-existing headers we have.  I think specifically MPLS where semantic of header fields is
> derived a lot more from state than IP addresses is a good reference to compare to. But certainly
> we want something that fails in well defined ways.

I disagree with that being a reference. As you say, with MPLS the control-plane gives meaning to the semantics of the Label, but the ability of the data-plane to reliable parse the packet is not depending on the control-plane.

>> 
>> My understanding is based on what I’m gleaning from draft-eckert-bier-rbs-00.html section 3.4. It says:
>> 
>> "the length of the BitString is known from the length of the RBS-BIFT. In the case of R1 it is therefore known to be 6 bits long.”
>> 
>>  BitString (of RU0)
>> 1 2 3 4 5 6
>> +-+-+-+-+-+-+-..-+...+...+
>> |0|1|1|1|0|1|AF1 |RU1|RU2|
>> +-+-+-+-+-+-+-..-+...+…+
>> 
>> If there is a mismatch of the BIFT table in R1 (say its 7 bits and the packet has 6), the router will read an incorrect value of RU1 because its offset by 1 bit and everything fails onwards.
> 
> Sure, i knew thats, but thanks for bringing the example to the list ;-)

Great, just making sure we are all on the same page :-)

>> 
>>> Secondly, the RBS forwarding plane must recognize incorrect RU-length fields
>> 
>> An other failure case would be where the BIFT-Table length stays the same, but bits are re-assigned to different interfaces. 
> 
> As said, i need to write more text, maybe into a separate control plane draft
> how to do this via control plane (Achieve desired consistency).

That doesn’t solve the transient problem.

> 
>>> anyhow, because they can not result in pointing past the RBS header, and an attacker
>>> could always create malicious RBS headers, same as creating malicious MPLS or IPv6
>>> extension headers. If one can parse all the address offsets before replicating one
>>> can probably eliminate almost all wrong copies. But even if this only happens
>>> copy-by-copy, it still seems to me that almost all those wrong copies would die
>>> somewhere along the path.
>> 
>> If each BFR parses the entire RBS, you might be able to detect inconsistency in the packet encoding. But this goes against the architecture principle that a BFR only needs to look at its own part of the BIFT.
> 
> Right. Thats a NoGo.
> 
>>> Now, i had also though about a bitstring-length field in the header, rewrite
>>> hop-by-hop, but IMHO that does not buy anything, because ultimately we need for
>>> the sender that created the RBS header and every RBS router on the tree to agree.
>>> So when we want to indicate length it would need to be for each bitstring in
>>> the RBS address separately, which would be header-size-prohibitive, unless we
>>> end up with variable bitstring length not in bits, but maybe larger quantity, like bytes.
>>> Thats something we investigate anyhow for reasons of possible lowest-common
>>> denominator data center forwarding plane restrictions. See update we want to give @IETF116.
>> 
>> I understand its inconvenient to encode the size of the BIFTs, but it would make the encoding more solid and have each BFR just reject the packet immediately without incorrect parsing of the BIFT. Allowing packets to be forwarded randomly across the BIER network due to packet/control-plane inconsistency is pretty ugly, IMO.
> 
> Well, the one thing i loved to learn from MPLS is to solve problems
> in the control plane so we can to keep the forwarding plane simple,
> or in this case compact. So let me create that try and if that fails,
> i'll go back to make the header longer ;-))

Keeping the data-plane simple AND deterministic ;-)

Thx,

Ice.