Re: [Bier] Feedback on draft-eckert-bier-rbs-00
Toerless Eckert <tte@cs.fau.de> Thu, 09 March 2023 02:30 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 989E1C15C520; Wed, 8 Mar 2023 18:30:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.645
X-Spam-Level:
X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
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 xhvcfDfcofhg; Wed, 8 Mar 2023 18:30:33 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (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 958B0C1522BE; Wed, 8 Mar 2023 18:30:33 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4PXCpD6pWXznkdj; Thu, 9 Mar 2023 03:30:28 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4PXCpD66YDzkvGL; Thu, 9 Mar 2023 03:30:28 +0100 (CET)
Date: Thu, 09 Mar 2023 03:30:28 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: IJsbrand Wijnands <ice@braindump.be>
Cc: draft-eckert-bier-rbs@ietf.org, BIER WG <bier@ietf.org>
Message-ID: <ZAlExKy8yGyz9h8R@faui48e.informatik.uni-erlangen.de>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5A31AF91-19B8-458F-B6C9-90521CD62673@braindump.be>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/TH5By3eSv9j4I3OQHzrsJgqNSTs>
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 02:30:37 -0000
Ice, inline On Mon, Mar 06, 2023 at 10:58:17AM +0100, IJsbrand Wijnands wrote: > Hi Toerless, > > > Sorry for the long delay. I was hoping that i could answer the questions > > in a draft update, but the productive work that has happened around RBS > > primarily with Michael Menths team has somewhat put other issues than a > > draft update in the front burner for the last quarter, so i will > > ask for a slot at IETF116 to explain how we're progressing, but that also means its > > best to discuss your questions on the list now. > > I understand. However, do make sure this is addressed in the draft sooner than later. It would be unfortunate if the encoding appears to be unstable/fragile and the work you’ve done is invalided. It is currently "unstable" in so far as we have not finalized the encoding but are still experimenting with details of course. And what was presented was our first round of refinement. 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. > > 1) mismatch of bitstring length between sender and receiver > > > > Thanks for bringing this up. A actually had to think about this issue already > > some time ago when doing some researchy unicast forwarding scheme > > draft-eckert-intarea-functional-addr-internets. And trying to figure out if, and then > > what new quality or quantity of a problem this could be. > > > > First of all, i don't think the worst-case network-layer problem of a > > mismatched packet is bad with RBS. It can result in some additional packet > > copies in the network with a low likelyhood to even reach any destinations. > > This is because every copy created will have a smaller remaining RBS address > > to proceed. This is RBS's equivalent to BIER/BIER-TE clearing bits in the > > bitstring and thus exhausting incorrect copies even before TTL exiry hits. > > 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 ;-) > > > 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). > > 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 ;-)) > > But: I think we can much better and cheaper solve this problem in the control plane > > with an approach that is equally applicable for BIER-TE - but thats a somewhat longer writeup, > > so give me a bit more time for that. > > > > 2) recursive flag > > > > Yes, agreed. We are experimenting with that encoding. If you remember my slides (and the drafts > > reference to the github URHL), there is also the optimization for dense trees > > to reduce their RBS tree size by indicating on the pre-ultimate hop to replicate to > > all leaf neighbors. Typical case would be IPTV of course or similar "dense-trees". > > This is what on the china simulation results brings down the total number of copies towards > > those dense trees. There are a few options to encode, have not concluded on it. > > The BIFT leaf bit might then simply be to distinguish leaf neighbors for the purpose > > of such last-hop broadcast from non-leaf neighbors. > > This is also something to address sooner rather than later. Sure ;-) Cheers Toerless > Thx, > > Ice. > > > > > > Cheers > > Toerless > > > > On Fri, Feb 17, 2023 at 02:09:10PM +0100, IJsbrand Wijnands wrote: > >> Hey Toerless, > >> > >> Do you have a timeline in mind to address my questions? > >> > >> Thx, > >> > >> Ice. > >> > >>> On 23 Jan 2023, at 18:26, IJsbrand Wijnands <ice@braindump.be> wrote: > >>> > >>> Hey Toerless, > >>> > >>> Did you address the issues I raised below? > >>> > >>> Thx, > >>> > >>> Ice. > >>> > >>> Sent from my iPhone > >>> > >>>> On 15 Nov 2022, at 11:26, Toerless Eckert <tte@cs.fau.de> wrote: > >>>> > >>>> Thanks, Ice - also Tony/Greg feedback/mails.. > >>>> > >>>> want to incooporate feedback into draft updates, hence no quick reply here, > >>>> as to other discus here. > >>>> > >>>> Cheers > >>>> Toerless > >>>> > >>>> > >>>>> On Thu, Nov 10, 2022 at 01:32:51AM +0000, IJsbrand Wijnands wrote: > >>>>> Dear Authors, > >>>>> > >>>>> Here is some feedback on the RBS encoding. This is based on my understanding of the draft and discussion with Toerless today. > >>>>> > >>>>> 1. It seems that when a BIER router is parsing the RecursiveUnit, the length of the BitString is derived from the length of the BIFT Table on the router processing the packet. To me that seems very tricky as the length of the BIFT table might change when interfaces/adjacencies get added and removed. There might always be transient cases where the length of the BitString in the packet might be different from the router’s BIFT Table. If that happens, the complete parsing of the RBS packet goes to sh*t. It would be good to somehow add the length of the BitString inside the RBS header to prevent these cases from happening and be more defensive. > >>>>> > >>>>> 2. The BIFT table has a Recursive flag to indicate if a BIER node has downstream receivers. This is also required to correctly parse the RBS header. In my mind this should not be a property of the BIFT table. A bier node might have nodes connected to it, but that doesn’t mean they are part of the tree. The recursive flag should be part of the encoded tree inside the RBS header. > >>>>> > >>>>> Thx, > >>>>> > >>>>> Ice. > >>>>> > >>>> > >>>> -- > >>>> --- > >>>> tte@cs.fau.de > >>> > >>> _______________________________________________ > >>> BIER mailing list > >>> BIER@ietf.org > >>> https://www.ietf.org/mailman/listinfo/bier > >> -- --- tte@cs.fau.de
- [Bier] Feedback on draft-eckert-bier-rbs-00 IJsbrand Wijnands
- Re: [Bier] Feedback on draft-eckert-bier-rbs-00 Toerless Eckert
- Re: [Bier] Feedback on draft-eckert-bier-rbs-00 IJsbrand Wijnands
- Re: [Bier] Feedback on draft-eckert-bier-rbs-00 IJsbrand Wijnands
- Re: [Bier] Feedback on draft-eckert-bier-rbs-00 Toerless Eckert
- Re: [Bier] Feedback on draft-eckert-bier-rbs-00 IJsbrand Wijnands
- Re: [Bier] Feedback on draft-eckert-bier-rbs-00 Toerless Eckert
- Re: [Bier] Feedback on draft-eckert-bier-rbs-00 IJsbrand Wijnands