Mailing List Archive

A network I operate is going with:

bgp-error-tolerance {
malformed-route-limit 0;
}

The thoughts being that there is no real reason to retain the malformed route and the default of 1000 is arbitrary. We haven't really seen a rash of them, so adjusting the logging hasn't proven needed yet.

I don't have anything running 14.x to test, but per the documentation the above should be supported from 13.2.

David

> On Aug 29, 2023, at 2:06 PM, Randy Bush via juniper-nsp <juniper-nsp@puck.nether.net> wrote:
>
> do we have a recommended `bgp-error-tolerance {}` config to deal with
> CVE-2023-4481?
>
> and what does one do on antique hardwhere with. e.g., junos 14?
>
> randy
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Tue, Aug 29, 2023 at 03:42:41PM -0700, David Sinn via juniper-nsp:
> A network I operate is going with:
>
> bgp-error-tolerance {
> malformed-route-limit 0;
> }
>
> The thoughts being that there is no real reason to retain the malformed route and the default of 1000 is arbitrary. We haven't really seen a rash of them, so adjusting the logging hasn't proven needed yet.

It does seem arbitrary. retaining all seems like a better choice,
operationally. allowing the operator diagnose why a route is missing;
show route .... hidden.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi,

Am 30.08.2023 um 18:09 schrieb heasley via juniper-nsp:
> Tue, Aug 29, 2023 at 03:42:41PM -0700, David Sinn via juniper-nsp:
>> A network I operate is going with:
>>
>> bgp-error-tolerance {
>> malformed-route-limit 0;
>> }
>>
>> The thoughts being that there is no real reason to retain the malformed route and the default of 1000 is arbitrary. We haven't really seen a rash of them, so adjusting the logging hasn't proven needed yet.
>
> It does seem arbitrary. retaining all seems like a better choice,
> operationally. allowing the operator diagnose why a route is missing;
> show route .... hidden.

Which in theory opens a new attack vector for the future.

As the update is malformed it could do $something to the handling in
e.g. RPD or other daemons by processing them somehow wrong. By not
holding or further process any of them that could (maybe, hopefully?) be
minimized.

Of course proper code and handling of malformed things would be even
better, but you know ...

regards
Tobias
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 8/31/23, 4:28 AM, "juniper-nsp on behalf of Tobias Heister via juniper-nsp" <juniper-nsp-bounces@puck.nether.net <mailto:juniper-nsp-bounces@puck.nether.net> on behalf of juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net>> wrote:
> Am 30.08.2023 um 18:09 schrieb heasley via juniper-nsp:
> > Tue, Aug 29, 2023 at 03:42:41PM -0700, David Sinn via juniper-nsp:
> >> A network I operate is going with:
> >>
> >> bgp-error-tolerance {
> >> malformed-route-limit 0;
> >> }
> >>
> >> The thoughts being that there is no real reason to retain the malformed route and the default of 1000 is arbitrary. We haven't really seen a rash of them, so adjusting the logging hasn't proven needed yet.
> >
> > It does seem arbitrary. retaining all seems like a better choice,
> > operationally. allowing the operator diagnose why a route is missing;
> > show route .... hidden.

That's the exact use case. Otherwise it's yet another completely arbitrary
case of, "where did this route go and do we have zombies to worry about?"

> Which in theory opens a new attack vector for the future.
>
> As the update is malformed it could do $something to the handling in
> e.g. RPD or other daemons by processing them somehow wrong. By not
> holding or further process any of them that could (maybe, hopefully?) be
> minimized.

You're encouraged to engage in whatever level of paranoia here that makes you
happy operationally. The internal behavior is we throw out the portion of the
path attribute that was decided to be bad. We spent a fair amount of time
doing audit over various bits of code that interact with such stripped path
attribute sets, like logging and tracing. That said, we've had bugs over the
years in logging, trace, etc. that may be fixed in current versions but perhaps
not past ones. I can't identify any bug of concern in running releases from
memory.

Thus, if you're more comfortable with just throwing the things out and not
worrying about tracking down routes that are bad, go for it. It's a supported
scenario.

> Of course proper code and handling of malformed things would be even
> better, but you know ...

For the moment, this depends on configuration of the error-tolerance "feature".
Making the behavior default is working its way through management for a
targeted release.

-- Jeff


Juniper Business Use Only
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

>
> Which in theory opens a new attack vector for the future.
>

What is the attack vector you foresee for a route sitting as hidden with
the potentially offending attributes stripped off?

On Thu, Aug 31, 2023 at 4:27?AM Tobias Heister via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Hi,
>
> Am 30.08.2023 um 18:09 schrieb heasley via juniper-nsp:
> > Tue, Aug 29, 2023 at 03:42:41PM -0700, David Sinn via juniper-nsp:
> >> A network I operate is going with:
> >>
> >> bgp-error-tolerance {
> >> malformed-route-limit 0;
> >> }
> >>
> >> The thoughts being that there is no real reason to retain the malformed
> route and the default of 1000 is arbitrary. We haven't really seen a rash
> of them, so adjusting the logging hasn't proven needed yet.
> >
> > It does seem arbitrary. retaining all seems like a better choice,
> > operationally. allowing the operator diagnose why a route is missing;
> > show route .... hidden.
>
> Which in theory opens a new attack vector for the future.
>
> As the update is malformed it could do $something to the handling in
> e.g. RPD or other daemons by processing them somehow wrong. By not
> holding or further process any of them that could (maybe, hopefully?) be
> minimized.
>
> Of course proper code and handling of malformed things would be even
> better, but you know ...
>
> regards
> Tobias
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi,

On 11.09.2023 19:55, Tom Beecher wrote:
> Which in theory opens a new attack vector for the future.
>
>
> What is the attack vector you foresee for a route sitting as hidden with
> the potentially offending attributes stripped off?

It is theoretical, but if you do $something with a prefix and maybe even
the "malformed" attribute and do not throw the prefix away completely
$something in parsing and keeping the prefix further down the line could
stumble over $whatever else makes the prefix special.

This implies "problems"/bugs in the code parsing the prefix and its
attributes, which can be assumed to not exist, but doing $something is
more likely to hit a problem than not doing $something.

By keeping the prefix and doing $something with it you do more than
before and might hit a code path that was not hit before when the
session was reseted or when the prefixes are just discarded.

In an ideal world where all code and parsing is perfect all is fine.
Do i think this is likely or a real world problem we will hit soon?
Probably not. Do i think that it is a theoretic vector to hit problems
not yet seen in the wild at some point? Yes I do.

So, like with all features and knobs, you might want to consider whether
it brings you any benefit to keep the prefixes in hidden state or
"minimize" processing of things you will maybe never look at.

regards
Tobias
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi,

On Sun, Sep 17, 2023 at 03:07:26PM +0200, Tobias Heister via juniper-nsp wrote:
> So, like with all features and knobs, you might want to consider whether it
> brings you any benefit to keep the prefixes in hidden state or "minimize"
> processing of things you will maybe never look at.

From an operational perspective, knowing that a given prefix *did* arrive
at the local router, and was then dropped (= hidden) for a specific reason
is very valuable. Without that information, you can only guess "did my
peer send it at all?" and troubleshooting *this* means "talk to people
outside your organization" which is way more time consuming than just
looking at hidden prefixes.

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de