Re: [j-nsp] BGP timer

[Jeff Haas via juniper-nsp]

BFD holddown is the right feature for this.
WARNING: BFD holddown is known to be problematic between Juniper and Cisco 
implementations due to where each start their state machines for BFD vs. BGP.

It was a partial motivation for BGP BFD strict:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bfd-strict-mode

BGP BFD strict was added in 23.2R1.

-- Jeff


On 4/28/24, 05:13, "juniper-nsp on behalf of Thomas Bellman via juniper-nsp" 
mailto:juniper-nsp-boun...@puck.nether.net> on behalf of 
juniper-nsp@puck.nether.net > wrote:


[External Email. Be cautious of content]





Juniper Business Use Only
On 2024-04-27 09:44, Lee Starnes via juniper-nsp wrote:


> Having difficulty finding a way to prevent BGP from re-establishing after a
> BFD down detect. I am looking for a way to keep the session from
> re-establishing for a configured amount of time (say 5 minutes) to ensure
> we don't have a flapping session for a. link having issues.


Isn't that what the holddown-interval setting does? It is limited
to 255 seconds (4 minutes 15 seconds), though, and for BGP it is
only allowed for EBGP sessions, not iBGP sessions.


The documentation also says that you need to set holddown-interval
on *both* ends. I'm gueesing that the holddown only prevents your
end from initiating the BGP session, but that it will still accept
a connection initiated from the other end.


https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/bfd-liveness-detection-edit-protocols-bgp.html
 



I haven't used BFD for BGP myself, though, only for static routes
on a couple of links. But there I do use holddown-interval, and
at least when I set it up several years ago, it seemed to do what
I expected: after the link and the BFD session came up again, it
waited (in my case) 15 seconds before enabling my static route
again.




--
Thomas Bellman, National Supercomputer Centre, Linköping Univ., Sweden
"We don't understand the software, and sometimes we don't understand
the hardware, but we can *see* the blinking lights!"





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

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Sean Clarke via juniper-nsp]

I personally love the "apply path" commands with wildcards

Therefore it ONLY looks for peers in your configuration 

set policy-options prefix-list bgp-addresses apply-path \"protocols bgp 
group <*> neighbor <*>\"
set policy-options prefix-list dns-addresses apply-path \"system 
name-server <*>\"
set policy-options prefix-list ntp-addresses apply-path \"system ntp 
server <*>\"
set policy-options prefix-list radius-addresses apply-path \"system 
radius-server <*>\"
set policy-options prefix-list tacacs-addresses apply-path \"system 
tacplus-server <*>\"



cheers

Sean



On 28-Apr-24 11:21 AM, Martin Tonusoo via juniper-nsp wrote:

Hi.


In practical life IOS-XR control-plane is better protected than JunOS,
as configuring JunOS securely is very involved, considering that MX
book gets it wrong, offering horrible lo0 filter as does Cymru, what
chance the rest of us have?

I recently worked on a RE protection filter based on the examples
given in the "Juniper MX Series" book:
https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c

It's a tight filter for a simple network, e.g MPLS is not in use and
thus there are no filters for signaling protocols or MPLS LSP
ping/traceroute, routing instances are not in use, authentication for
VRRPv3 or OSPF is not in use, etc.

Few differences compared to filters in the MX book:

* "ttl-except 1" in "accept-icmp" filter was avoided by simply moving
the traceroute related filters in front of "accept-icmp" filter

* "discard-extension-headers" filter in the book discards certain Next
Header values and allows the rest. I changed it in a way that only
specified Next Header values are accepted and rest are discarded. Idea
is to discard unneeded extension headers as early as possible.

* in term "neighbor-discovery-accept" in filter "accept-icmp6-misc"
only the packets with Hop Limit value of 255 should be accepted

* the "accept-bgp-v6" filter or any other IPv6 related RE filter in
the book does not allow the router to initiate BGP sessions with other
routers. I added a term named "accept-established-bgp-v6" in filter
"accept-established-v6" which addresses this issue.

* for the sake of readability and simplicity, I used names instead of
numbers if possible. For example "icmp-type router-solicit" instead of
"icmp-type 133".

* in all occurrences, if it was not possible to match on the source IP
address, then I strictly policed the traffic

* traffic from management networks is not sharing policers with
traffic from untrusted networks


The overall structure of the RE filters in "Juniper MX Series" book is
in my opinion very good. List of small filters which accept specific
traffic and finally discard all the rest.

Reason for having separate v4 and v6 prefix-lists is a Junos property
to ignore the prefix-list altogether if it's used in a family inet
filter while the prefix-list contains only the inet6 networks. Same is
true if the prefix-list is used in family inet6 filter and the
prefix-list contains only inet networks. For example, if only IPv4
name servers addresses are defined under [edit system name-server] and
prefix-list with apply-path "system name-server <*>" is used as a
source prefix-list in some family inet6 filter, then actually no
source address related restrictions apply. This can be checked with
"show filter index  program" on a PFE CLI.


Martin
___
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

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Michael Hare via juniper-nsp]

Martin,

Saku is illuminating how difficult it can be to effectively protected the 
control plane.   If I were to post our production RE filter I would likely be 
humbled with what I've overlooked as well.  Thanks for sharing for commentary 
and discussion.

Saku's comment about using router-ipv4 in combo with destination address seems 
obvious to me in hindsight, although I have it configured as well in some 
terms.  I think there is still use for that for things like VRRP, OSPF, LDP, 
BFD, IGMP and RSVP when matching source-prefix-list however?  I guess I should 
think more.

Another comment I would make is that you do not appear to have made provisions 
for support of GSTM for BGP.  For my IPv4 [and IPv6] filters I have six terms 
dedicated explicitly to trying to deal with BGP.  GTSM accept/reject near 
initiated vs far initiated + same for non GTSM.

You have the most important component; the end term is discard.  I chose to 
give up on 'log' on that long ago; too much noise, and only use it when I'm 
having troubles.  I do have a term that looks like this before my final discard 
however.  When these counters are non zero, my curiosity definitely gets piqued.

term interesting {
 from {
 source-prefix-list {
 sync_lists_p2p-v4
 sync_lists-all-loopbacks-v4;
 }
 destination-prefix-list {
 sync_lists-p2p-v4
 sync_lists-all-loopbacks-v4;
 }
 }
 then {
 count :count:interesting;
 inactive: log;
 }
 }

-Michael

> -Original Message-
> From: juniper-nsp  On Behalf Of Saku Ytti
> via juniper-nsp
> Sent: Sunday, April 28, 2024 11:15 AM
> To: Martin Tonusoo 
> Cc: adamv0...@netconsultings.com; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of 
> 'things to
> think about'?
> 
> Some comments from quick read of just IPv4.
> 
> - I don't like the level of abstraction, seems it just ensures no one
> will bother reading it up and reuse of the filters and terms wont
> happen anyhow. It feels like first time learning OO language, and
> making everything modular, while adding overhead and abstraction for
> no value. Instead of having flat list, you have multiple filters in a
> list (which is internally concatenate in SW anyhow, into single fat
> list, so no HW benefit), not just that, but filters themselves refer
> to other filters.
> 
> 1) You should have two rules for TCP services, like BGP, inbound and
> outbound, instead just allowing far end to connect, and self-connect
> is handled by flags  This will allow far-end to hit any port they
> want, while it will not have SYN bit, it's still not safe. You could
> improve it, by defining DPORT in the connected check as ephemeral
> range the NOS uses
> 
> 2) OSPF can be TTL==1, not very important for security, tho
> 
> 3) traceroute and ping won't work, if router is the target DADDR and TTL > 1
> 
> 4) useless use of 'router-v4', if it hit lo0, it was for us. You'd
> need something like this in the edge filter, not lo0 filter. And in
> the edge filter it's still broken, because this is all LANs, not
> host/32.
> 
> 5) use of 'port' in NTP and other, this allows the far end to hit any
> port, by setting SPORT port to ntp
> 
> 6) no dport in DNS, every term should have DPORT, if we are
> connecting, it'll be ephemeral range, otherwise far end can hit any
> dport, by setting sport
> 
> 
> 
> 
> Some of these mistakes are straight from the book, like the useless
> level of abstraction without actual reuse and the insecure use of
> 'port'. But unlike the book, at least you have ultimate permit and
> then ultimate deny, which is important.
> 
> 
> On Sun, 28 Apr 2024 at 12:21, Martin Tonusoo  wrote:
> >
> > Hi.
> >
> > > In practical life IOS-XR control-plane is better protected than JunOS,
> > > as configuring JunOS securely is very involved, considering that MX
> > > book gets it wrong, offering horrible lo0 filter as does Cymru, what
> > > chance the rest of us have?
> >
> > I recently worked on a RE protection filter based on the examples
> > given in the "Juniper MX Series" book:
> >
> https://urldefense.com/v3/__https://gist.github.com/tonusoo/efd9ab4fcf2bb5a4
> 5d34d5af5e3f3e0c__;!!Mak6IKo!MQRlf-
> 9wNP2iWHZzeeyA7KIambMGev79eux2sjNd7RBXhagscC_PLFWLcG1x7grSrCvJGx
> QBrMo03dL_sIehI34dkQE$
> >
> > It's a tight filter for a simple network, e.g MPLS is not in use and
> > thus there are no filters for signaling protocols or MPLS LSP
> > ping/traceroute, routing instances are not in use, authentication for
> > VRRPv3 or OSPF is not in use, etc.
> >
> > Few differences compared to filters in the MX book:
> >
> > * "ttl-except 1" in "accept-icmp" filter was avoided by simply moving
> > the traceroute related filters in front of "accept-icmp" filter
> >
> > * "discard-extension-headers" filter in the book discards certain Next
> > Header values and allows the rest. I changed it in a way that only
> > 

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Saku Ytti via juniper-nsp]

Some comments from quick read of just IPv4.

- I don't like the level of abstraction, seems it just ensures no one
will bother reading it up and reuse of the filters and terms wont
happen anyhow. It feels like first time learning OO language, and
making everything modular, while adding overhead and abstraction for
no value. Instead of having flat list, you have multiple filters in a
list (which is internally concatenate in SW anyhow, into single fat
list, so no HW benefit), not just that, but filters themselves refer
to other filters.

1) You should have two rules for TCP services, like BGP, inbound and
outbound, instead just allowing far end to connect, and self-connect
is handled by flags  This will allow far-end to hit any port they
want, while it will not have SYN bit, it's still not safe. You could
improve it, by defining DPORT in the connected check as ephemeral
range the NOS uses

2) OSPF can be TTL==1, not very important for security, tho

3) traceroute and ping won't work, if router is the target DADDR and TTL > 1

4) useless use of 'router-v4', if it hit lo0, it was for us. You'd
need something like this in the edge filter, not lo0 filter. And in
the edge filter it's still broken, because this is all LANs, not
host/32.

5) use of 'port' in NTP and other, this allows the far end to hit any
port, by setting SPORT port to ntp

6) no dport in DNS, every term should have DPORT, if we are
connecting, it'll be ephemeral range, otherwise far end can hit any
dport, by setting sport




Some of these mistakes are straight from the book, like the useless
level of abstraction without actual reuse and the insecure use of
'port'. But unlike the book, at least you have ultimate permit and
then ultimate deny, which is important.


On Sun, 28 Apr 2024 at 12:21, Martin Tonusoo  wrote:
>
> Hi.
>
> > In practical life IOS-XR control-plane is better protected than JunOS,
> > as configuring JunOS securely is very involved, considering that MX
> > book gets it wrong, offering horrible lo0 filter as does Cymru, what
> > chance the rest of us have?
>
> I recently worked on a RE protection filter based on the examples
> given in the "Juniper MX Series" book:
> https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c
>
> It's a tight filter for a simple network, e.g MPLS is not in use and
> thus there are no filters for signaling protocols or MPLS LSP
> ping/traceroute, routing instances are not in use, authentication for
> VRRPv3 or OSPF is not in use, etc.
>
> Few differences compared to filters in the MX book:
>
> * "ttl-except 1" in "accept-icmp" filter was avoided by simply moving
> the traceroute related filters in front of "accept-icmp" filter
>
> * "discard-extension-headers" filter in the book discards certain Next
> Header values and allows the rest. I changed it in a way that only
> specified Next Header values are accepted and rest are discarded. Idea
> is to discard unneeded extension headers as early as possible.
>
> * in term "neighbor-discovery-accept" in filter "accept-icmp6-misc"
> only the packets with Hop Limit value of 255 should be accepted
>
> * the "accept-bgp-v6" filter or any other IPv6 related RE filter in
> the book does not allow the router to initiate BGP sessions with other
> routers. I added a term named "accept-established-bgp-v6" in filter
> "accept-established-v6" which addresses this issue.
>
> * for the sake of readability and simplicity, I used names instead of
> numbers if possible. For example "icmp-type router-solicit" instead of
> "icmp-type 133".
>
> * in all occurrences, if it was not possible to match on the source IP
> address, then I strictly policed the traffic
>
> * traffic from management networks is not sharing policers with
> traffic from untrusted networks
>
>
> The overall structure of the RE filters in "Juniper MX Series" book is
> in my opinion very good. List of small filters which accept specific
> traffic and finally discard all the rest.
>
> Reason for having separate v4 and v6 prefix-lists is a Junos property
> to ignore the prefix-list altogether if it's used in a family inet
> filter while the prefix-list contains only the inet6 networks. Same is
> true if the prefix-list is used in family inet6 filter and the
> prefix-list contains only inet networks. For example, if only IPv4
> name servers addresses are defined under [edit system name-server] and
> prefix-list with apply-path "system name-server <*>" is used as a
> source prefix-list in some family inet6 filter, then actually no
> source address related restrictions apply. This can be checked with
> "show filter index  program" on a PFE CLI.
>
>
> Martin



-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Barry Raveendran Greene via juniper-nsp]

Thanks for sharing Martin. As a word of advice, we have a challenge with BGP 
Session security. It seems that operators are not applying filters like these 
to protect the router, the control plane, and BGP. They are not common, but we 
are seeing BGP session attacks. This spurred this post after two types of BGP 
session attacks were observed in one week in on country:

https://www.senki.org/protect-your-bgp-sessions-from-ddos-attacks/

For those who are pulling down the Shadowserver reports, two new reports were 
created to let you know of exposed BGP sessions (check for “BGP” in these 
report list - https://www.shadowserver.org/what-we-do/network-reporting/). 

How bad is this? +300,000 BGP sessions visible with no ACL to protect them from 
external DDoS. 
https://dashboard.shadowserver.org/statistics/combined/time-series/?date_range=7=population=population6=bgp_by=geo=stacked

Recommendation: Check your RE protecting filters. If you don’t know which 
devices are exposed,  sign up to the Shadowserver reports. They are a free 
public service.

> On Apr 28, 2024, at 02:22, Martin Tonusoo via juniper-nsp 
>  wrote:
> 
> Hi.
> 
>> In practical life IOS-XR control-plane is better protected than JunOS,
>> as configuring JunOS securely is very involved, considering that MX
>> book gets it wrong, offering horrible lo0 filter as does Cymru, what
>> chance the rest of us have?
> 
> I recently worked on a RE protection filter based on the examples
> given in the "Juniper MX Series" book:
> https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c
> 
> It's a tight filter for a simple network, e.g MPLS is not in use and
> thus there are no filters for signaling protocols or MPLS LSP
> ping/traceroute, routing instances are not in use, authentication for
> VRRPv3 or OSPF is not in use, etc.
> 
> Few differences compared to filters in the MX book:
> 
> * "ttl-except 1" in "accept-icmp" filter was avoided by simply moving
> the traceroute related filters in front of "accept-icmp" filter
> 
> * "discard-extension-headers" filter in the book discards certain Next
> Header values and allows the rest. I changed it in a way that only
> specified Next Header values are accepted and rest are discarded. Idea
> is to discard unneeded extension headers as early as possible.
> 
> * in term "neighbor-discovery-accept" in filter "accept-icmp6-misc"
> only the packets with Hop Limit value of 255 should be accepted
> 
> * the "accept-bgp-v6" filter or any other IPv6 related RE filter in
> the book does not allow the router to initiate BGP sessions with other
> routers. I added a term named "accept-established-bgp-v6" in filter
> "accept-established-v6" which addresses this issue.
> 
> * for the sake of readability and simplicity, I used names instead of
> numbers if possible. For example "icmp-type router-solicit" instead of
> "icmp-type 133".
> 
> * in all occurrences, if it was not possible to match on the source IP
> address, then I strictly policed the traffic
> 
> * traffic from management networks is not sharing policers with
> traffic from untrusted networks
> 
> 
> The overall structure of the RE filters in "Juniper MX Series" book is
> in my opinion very good. List of small filters which accept specific
> traffic and finally discard all the rest.
> 
> Reason for having separate v4 and v6 prefix-lists is a Junos property
> to ignore the prefix-list altogether if it's used in a family inet
> filter while the prefix-list contains only the inet6 networks. Same is
> true if the prefix-list is used in family inet6 filter and the
> prefix-list contains only inet networks. For example, if only IPv4
> name servers addresses are defined under [edit system name-server] and
> prefix-list with apply-path "system name-server <*>" is used as a
> source prefix-list in some family inet6 filter, then actually no
> source address related restrictions apply. This can be checked with
> "show filter index  program" on a PFE CLI.
> 
> 
> Martin
> ___
> 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

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Martin Tonusoo via juniper-nsp]

Hi.

> In practical life IOS-XR control-plane is better protected than JunOS,
> as configuring JunOS securely is very involved, considering that MX
> book gets it wrong, offering horrible lo0 filter as does Cymru, what
> chance the rest of us have?

I recently worked on a RE protection filter based on the examples
given in the "Juniper MX Series" book:
https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c

It's a tight filter for a simple network, e.g MPLS is not in use and
thus there are no filters for signaling protocols or MPLS LSP
ping/traceroute, routing instances are not in use, authentication for
VRRPv3 or OSPF is not in use, etc.

Few differences compared to filters in the MX book:

* "ttl-except 1" in "accept-icmp" filter was avoided by simply moving
the traceroute related filters in front of "accept-icmp" filter

* "discard-extension-headers" filter in the book discards certain Next
Header values and allows the rest. I changed it in a way that only
specified Next Header values are accepted and rest are discarded. Idea
is to discard unneeded extension headers as early as possible.

* in term "neighbor-discovery-accept" in filter "accept-icmp6-misc"
only the packets with Hop Limit value of 255 should be accepted

* the "accept-bgp-v6" filter or any other IPv6 related RE filter in
the book does not allow the router to initiate BGP sessions with other
routers. I added a term named "accept-established-bgp-v6" in filter
"accept-established-v6" which addresses this issue.

* for the sake of readability and simplicity, I used names instead of
numbers if possible. For example "icmp-type router-solicit" instead of
"icmp-type 133".

* in all occurrences, if it was not possible to match on the source IP
address, then I strictly policed the traffic

* traffic from management networks is not sharing policers with
traffic from untrusted networks


The overall structure of the RE filters in "Juniper MX Series" book is
in my opinion very good. List of small filters which accept specific
traffic and finally discard all the rest.

Reason for having separate v4 and v6 prefix-lists is a Junos property
to ignore the prefix-list altogether if it's used in a family inet
filter while the prefix-list contains only the inet6 networks. Same is
true if the prefix-list is used in family inet6 filter and the
prefix-list contains only inet networks. For example, if only IPv4
name servers addresses are defined under [edit system name-server] and
prefix-list with apply-path "system name-server <*>" is used as a
source prefix-list in some family inet6 filter, then actually no
source address related restrictions apply. This can be checked with
"show filter index  program" on a PFE CLI.


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

Re: [j-nsp] BGP timer

[Thomas Bellman via juniper-nsp]

On 2024-04-27 09:44, Lee Starnes via juniper-nsp wrote:

> Having difficulty finding a way to prevent BGP from re-establishing after a
> BFD down detect. I am looking for a way to keep the session from
> re-establishing for a configured amount of time (say 5 minutes) to ensure
> we don't have a flapping session for a. link having issues.

Isn't that what the holddown-interval setting does?  It is limited
to 255 seconds (4 minutes 15 seconds), though, and for BGP it is
only allowed for EBGP sessions, not iBGP sessions.

The documentation also says that you need to set holddown-interval
on *both* ends.  I'm gueesing that the holddown only prevents your
end from initiating the BGP session, but that it will still accept
a connection initiated from the other end.

https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/bfd-liveness-detection-edit-protocols-bgp.html

I haven't used BFD for BGP myself, though, only for static routes
on a couple of links.  But there I do use holddown-interval, and
at least when I set it up several years ago, it seemed to do what
I expected: after the link and the BFD session came up again, it
waited (in my case) 15 seconds before enabling my static route
again.


-- 
Thomas Bellman,  National Supercomputer Centre,  Linköping Univ., Sweden
"We don't understand the software, and sometimes we don't understand
 the hardware, but we can *see* the blinking lights!"



signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP timer

[Saku Ytti via juniper-nsp]

On Sat, 27 Apr 2024 at 14:29, Rolf Hanßen via juniper-nsp
 wrote:

> at least for link flapping issues (but not other session flapping reasons) 
> you could set the hold-time:
> set interfaces xy hold-time up 30

Since Junos 14.1 it has caught up with Cisco, and it has implemented
exponential back-off for interface damping. So you don't have to cause
a static penalty as above, but can penalise actually flapping
interfaces, instead of killing convergence on the first transition.

But indeed doesn't really address what OP is asking, and I don't
think, outside scripting, there is a direct solution to what OP wants.
Clearly any vendor could implement exponential back-off damping to any
protocol which has up and down state, and they could write the code
once, and reuse it for everything, so it's not a tall order at all.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp