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

[IJsbrand Wijnands <[e-mail]>]

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.

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


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

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

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

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

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 <[e-mail]> 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 <[e-mail]> 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.
>>>>> 
>>>> 
>>>> -- 
>>>> ---
>>>> [e-mail]
>>> 
>>> _______________________________________________
>>> BIER mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/bier
>>