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"
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
