Re: [Bier] BIER-TE looping example (was: Re: Genart last call review of draft-ietf-bier-te-arch-10)

Robert Sparks <rjsparks@nostrum.com> Fri, 13 August 2021 17:31 UTC

Return-Path: <rjsparks@nostrum.com>
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 6E4D83A201F; Fri, 13 Aug 2021 10:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.281
X-Spam-Level:
X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 lBk-dJMEkZjK; Fri, 13 Aug 2021 10:31:23 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0F9CD3A201D; Fri, 13 Aug 2021 10:31:20 -0700 (PDT)
Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 17DHV1Es066475 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 13 Aug 2021 12:31:02 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1628875862; bh=SYckDHqjIJ+wTeoTDGFVmGTVHbIlj6iAk/IzRfrdRt0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=hKIH3uVNXqqyyPwqPrWeex9MG7F+Lk4dP8LBTdBidD4i5/oz1DdpqGx6+97+T0qto m1mA955yFDuZ+0hjMLRrGhH96F+ORARuXzwyX+pNS9/PUNWWzLWJCprjDFZuR/0ham C7yxlN+cxslJS2wPA+iIwWXFlQ0P36ghJl0RXbP8=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain
To: Toerless Eckert <tte@cs.fau.de>
Cc: gen-art@ietf.org, bier@ietf.org, draft-ietf-bier-te-arch.all@ietf.org, last-call@ietf.org
References: <162837612276.27380.5075158730530971495@ietfa.amsl.com> <20210813171737.GA18788@faui48f.informatik.uni-erlangen.de>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <43c81d9c-352a-cdba-34ab-c8785eace0d8@nostrum.com>
Date: Fri, 13 Aug 2021 12:30:56 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <20210813171737.GA18788@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/I995_IrdGdbvFLmuHgmH7Ypyl3M>
Subject: Re: [Bier] BIER-TE looping example (was: Re: Genart last call review of draft-ietf-bier-te-arch-10)
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 13 Aug 2021 17:31:29 -0000

On 8/13/21 12:17 PM, Toerless Eckert wrote:
> Thanks, Robert
>
> Let me quickly reply on your looping example, and Cc bier list,
> because the problem as you describe does not exist thanks to how
> BIER-TE handles DNC, but maybe you and others want to chime in whether
> or not your example of an attempted attack by misconfiguration and
> what it results in would be good to add to the text anyhow, and
> if you think so, then where (security considerations or any
> other place you think it fits). Will be happy to add it for the
> next rev, if more people than you think it would be helpfull.
>
> inline...
>
> On Sat, Aug 07, 2021 at 03:42:02PM -0700, Robert Sparks via Datatracker wrote:
>> If you have the following configuration (best read in a fixed-width font):
>>
>> BFRA: p1 -> forward_connected(DNC) BFRC
>>        p2 -> forward_connected(DNC) BFRD
>>        p3 -> local_decap
>>
>> BFRB: p1 -> forward_connected(DNC) BFRC
>>        p2 -> forward_connected(DNC) BFRD
>>        p3 -> local_decap
>>
>> BFRC: p1 -> forward_connected(DNC) BFRA
>>        p2 -> forward_connected(DNC) BFRB
>>        p3 -> local_decap
>>
>> BFRD: p1 -> forward_connected(DNC) BFRA
>>        p2 -> forward_connected(DNC) BFRB
>>        p3 -> local_decap
>>
>> A single packet with bits (p1,p2,p3) introduced to any of the 4 BFR will
>> produce an exponentially increasing amount of internal traffic, and traffic
>> sent to whatever the local_decaped packets is configured for.
>>
>>           p3              p3
>>          BFRA p1 ---- p1 BFRC
>>                \     /
>>                 \   /
>>                   X
>>                 /   \
>>                /     \
>>          BFRB p2 ---- p2 BFRD
>>           p3              p3
>>
>> This may be easy to achieve accidentally if following the suggestion for
>> creating a bidirectional ring described in section 5.1.6.
>   c0(p1,p2,p3) -> BFRA -> c1(p1) -> BFRC <- ttl expiry -> BFRA
>                        -> c2(p2) -> BFRD <- ttl expiry -> BFRB
>                        -> receive
>
> Aka: The DNC flag on an adjacency will only keep the bit set on
> the copy made for this bit, not on the other copies.

Got it.

I don't feel strongly about adding additional text in this case. If you 
do, I would prefer framing it as accidental misconfiguration rather than 
malicious.

> The
> forwarding pseudocode shows this by clearing all bits with
> adjacencies first and then it sets back the bit for only
> the adjacency when it has DNC flag.
>
> In result, there will be 2 TTL expiring microloops,
> one for  p1 between BFRC,BFRA and one for p2 between BFRD,BFRB,
> and of course, these can overload links.  But there will be no
> duplicate packets received.
>
> This is something you could always do as well for ASM/SSM IP multicast
> and BIER by a misconfiguration attack against RPF (aka: multicast static
> routing misconfig attack) or with a single loop (as there is no replication)
> for IP Unicast by attacking with a static route misconfig.
>
> Of course, for BIER, IP multicast or IP unicast one could argue that
> you may not provide these routing configuration options, but all routers
> i know have them. And hopefully at some point we even have YANG
> nodels representing such configuration options (static (m)routes).
>
> Cheers
>      Toerless
>
>> Larger Nits:
>>
>> The first example uses terms defined later in the document (like local_decap).
>> It would help the reader to say that right before the example.
>>
>> Section 2.3 list 2 item 2. What is a "reference option"? This first sentence of
>> this item should be simplified, possibly by breaking it into two or more.
>>
>> The first sentence of section 2.4 does not parse. Perhaps "BIER-TE forwarding
>> is designed to make it easy to build or program common forwarding hardware."
>> but I'm lost at "with BIER". Please clarify.
>>
>> In section 3.2, there is a nested list that is introduced as "functionality"
>> but later referred to as "steps". Please provide a clearer description, and
>> make it obvious that these are the steps that the subsections (such as 3.2.1)
>> refer to.Is the outer list the steps 3.2.1 refers to?
>>
>> Section 3.2 list item 2, sublist item 3. "Install state on the BFIR to
>> imposition the desired BIER packet header(s) for packets of the overlay flow"
>> does not parse. Please clarify.
>>
>> Please clarify the last sentence (starting "See also") of 3.2.1.2. I don't know
>> what you are really trying to say but "solution describes interaction" doesn't
>> make sense.
>>
>> At 3.2.1.4, what does "out-of-scope FRR procedures" mean? I suggest just
>> dropping "out-of-scope". If that's not right, more clarification is needed.
>>
>> Section 3.4 second paragraph last sentence: Did you mean "BIER specific
>> routing" rather than "BFER specific routing"?
>>
>> Section 4.1, Check that you really meant BFR-id = SI * 2^BSL + BP in paragraph
>> three.
>>
>> Section 5.1, second paragraph: The list of sections '(4.1, ... 4.8)' didn't
>> track a document change. I think you mean to point to '(5.1.1, ...'. But the
>> list is unnecessary - I suggest deleting it.
>>
>> In section 5.1.6, I think you are using L3 to mean different things in the
>> first paragraph and in the example.
>>
>> Section 5.1.9 after Figure 17, you point to figure 20, but I think you really
>> meant figure 17. (It's interesting that figure 17 and 20 are essentially the
>> same, perhaps the document could be simplified).
>>
>> Section 5.3.5: Where did this 20%..80% range come from? The last sentence is
>> unclear.
>>
>> Section 5.3.6.2: paragraph 3. The sentence starting "This is much worse" is
>> complex. Please break it into several.
>>
>> Section 5.3.7 First paragraph. This long sentence fails to parse. Please
>> simplify it.
>>
>> Section 7 paragraph 6 (beginning "For additional,"): This sentence is very hard
>> to parse. Please simplify it.
>>
>> Smaller Nits:
>>
>> Overview: Expand BIFT on first use.
>>
>> The Overview claims that the reader is expected to be familiar with both
>> RFC8279 and RFC 8296, but only lists the first as a normative reference.
>> Consider making RFC 8296 normative, or adjusting the introduction text.
>>
>> First bullet in overview: "reference forwarding examples" -> "forwarding
>> examples"
>>
>> Last bullet in overview: "sections of document" -> "sections of the document"
>>
>> In 2.1, "To send in addition to BFR6 via BFR4 also a copy to BFR3" is hard to
>> parse. Perhaps: "To send a copy to BFR3 in addition to BFR6 via BFR4".
>>
>> Section 3.2.1: Why is "Notwithstanding other option," necessary. I suggest
>> deleting it.
>>
>> Section 3.2.1: "without any active dynamic components" is odd. Perhaps replace
>> the sentence with "Automated configuration of the BIER control plane is not
>> required. An operator can manually configure the BIER control plane via CLI on
>> the BFRs."
>>
>> Section 3.3: "constitutes of the following components" is obtuse. Perhaps you
>> could replace it with "consists of"?
>>
>> Section 3:3: I suggest replacing "This is done to inhibit that packets can
>> loop" with "This inhibits loop detection."
>>
>> Section 4.6: I suggest replacing "support to configure" with "support
>> configuring" and "support to have" with "support having".
>>
>> Section 4.6 (and other places) Saying "clear DNC", that is clear Do-Not-Clear
>> is dissonant. It might help avoid confusion to say "unset DNC", or replace
>> "with clear DNC flag" with "with the DNC flag net set".
>>
>> Section 5.1.7: I suggest replacing "allows to use" with "allows using"
>>
>> Section 5.3.4: Why is complex quoted in 'how "complex" the Tree Engineering is'?
>>
>> Section 5.3.4: "Communications between BFIR flow" -> "Communications between
>> the BFIR flow"
>>
>> Section 5.3.6.1, paragraph 3 first sentence: You say "over time" three times in
>> this sentence. Please simply it.
>>
>> Section 5.3.6.1, paragraph 3, last sentence: I suggest changing "consider to
>> use" to "consider using"
>>