Re: [c-nsp] Best practise/security design for BGP and OSPF

[adamv0025]

> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Tuesday, May 23, 2017 11:16 AM
> 
> On 23 May 2017 at 13:06,   wrote:
> 
> > Router listening for all IS m-cast MAC addresses on all interfaces rather
> than solely on interfaces actually configured with ISIS seems like a bug.
> 
> Not all HW support per-port punt-masks. So if you have to punt ISIS frames
> on one interface, you may need to punt them on all interfaces.
> I know that 7600 will happily punt ISIS/CLNS on all interfaces. Back in 11.4R5
> Juniper MX dd this too, with just 'inet' family configured, but that was 
> fixed.
> 
Seems like a legacy HW/SW problem but one never knows unless tested, worse 
things still lure in modern ASICs and codes so I wouldn't be surprised at all. 
And thinking about it it's a specific case, the packet/frame undergoes a 
standard lookup in the NPU (which hosts several interfaces) and once figuring 
out it's a for host packet (all NPUs in the system are programed with the same 
forwarding info, unless explicitly disabled) it then tries to figure out what 
kind of exception it is and what to do with it (punt/drop), but nothing in 
these stages is going to check whether the packet/frame is allowed to enter the 
box via a specific interface -that can happen only at the filtering stage in 
the NPU's pipeline, and unless the system maintains these filters automatically 
on a per interface bases one has to do it manually -if that's even possible 
(e.g. in case of ISO).   

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[adamv0025]

> Saku Ytti [mailto:s...@ytti.fi]
> Sent: Friday, May 26, 2017 2:48 PM
> 
> On 26 May 2017 at 14:44,   wrote:
> 
> Hey,
> 
> > Regarding OSPF unless you are using virtual-links or sham-links, then
> > all messages are bound to a directly connected subnet so you can
> > safely implement the ttl check with 254 (one hop).
> 
> This is implementation specific and you need to know which one it is.
> If figuring out it is challenging start with 255 and see if it works, if not, 
> revert
> to 254. For example in JNPR lo0 filter we verify that ICMP ND has hop-limit
> 255, because it's done before TTL is decremented, verifying 254 would
> expose us to ICMP ND attacks from one hop off-link.
> 
Yeah it might need a bit of jigging to get the TTL value right.
But once again the edge filters (iACLs) should not allow OSPF towards 
edge-interfaces, internal-infrastructure and loopbacks address ranges. 
As a matter of fact the set of protocols that should be allowed in iACLs is 
pretty narrow.  

All I'm trying to say is that doing security within the core is too little too 
late, yes security has to be implemented in a layered approach (e.g. if your 
iACL is misconfigured you still have TTL sec), but securing OSPF without good 
iALCs won't cut it.

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[Saku Ytti]

On 26 May 2017 at 14:44,   wrote:

Hey,

> Regarding OSPF unless you are using virtual-links or sham-links, then all
> messages are bound to a directly connected subnet so you can safely
> implement the ttl check with 254 (one hop).

This is implementation specific and you need to know which one it is.
If figuring out it is challenging start with 255 and see if it works,
if not, revert to 254. For example in JNPR lo0 filter we verify that
ICMP ND has hop-limit 255, because it's done before TTL is
decremented, verifying 254 would expose us to ICMP ND attacks from one
hop off-link.


-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[adamv0025]

Hi 

Don't use ttl check on iBGP sessions, it doesn't add any security. 

Regarding OSPF unless you are using virtual-links or sham-links, then all
messages are bound to a directly connected subnet so you can safely
implement the ttl check with 254 (one hop). 

 

Regarding securing PE-RR iBGP sessions, there's nothing that can be done
from security perspective, other than maybe the obligatory MD5 hash, cause
at this stage it's too late or way too complex to implement any security.
The BGP infrastructure has to be protected at the edges of the AS. 

 

Maybe the only other thing that you can enable if not enabled by default and
supported is the BGP enhanced attribute error handling (or even BGP
attribute filtering -but again that if implemented should be done at the
edge).  

But just checked and the enhanced attribute error handling is enabled by
default on XE 3S and IOS 15. and XR 4.3. 

 

adam

 

netconsultings.com

::carrier-class solutions for the telecommunications industry::

 

From: CiscoNSP List [mailto:cisconsp_l...@hotmail.com] 
Sent: Thursday, May 25, 2017 3:25 AM
To: Saku Ytti; adamv0...@netconsultings.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Best practise/security design for BGP and OSPF

 

Cheers for the replies - Just to clarify, these templates were for purely
PE->RR (Not for transit), we do run key-chain auth on OSPF, and I was hoping
to do likewise for iBGP -> RR's, but I dont *think* key-chains are supported
in XE (Yet?)...I need to do some more reading, but I believe XR supports it,
but not XE?  Regarding TTL(In both OSPF and BGP)hop count can be
arbitrary, if we encounter a link failure...do we just use worse case
scenario hops ?  Is there anything you'd add/remove from the templates that
Ive sent through?  (Obviously soft-reconfig inbound chews memory, and can be
removed, but things like max-prefix .have it currently set at warning
only...recommend killing the session for x minutes if it's exceed?)any
other suggestions are greatly appreciatedthanks. 

 

  _  

From: Saku Ytti <s...@ytti.fi <mailto:s...@ytti.fi> >
Sent: Tuesday, 23 May 2017 7:10 PM
To: adamv0...@netconsultings.com <mailto:adamv0...@netconsultings.com> 
Cc: CiscoNSP List; cisco-nsp@puck.nether.net
<mailto:cisco-nsp@puck.nether.net> 
Subject: Re: [c-nsp] Best practise/security design for BGP and OSPF 

 

On 23 May 2017 at 12:00,  <adamv0...@netconsultings.com
<mailto:adamv0...@netconsultings.com> > wrote:

Hey,

> Regarding OSPF,
> Best security is to use it solely for routing PE loopbacks (i.e. no
> connectivity outside the core).

But because it's IP, you might receive spooffed packet further down
the line and believe you received it from far-end. So OP's question
about TTL-security is valid one, and I'd support that. I'd also run
MD5 auth.
But of course if you have good iACL, stopping internet from sending
other than ICMP, UDP highports to links and loops, you should be
pretty safe.

ISIS and OSPF have quite interesting properties, ISIS is more secure
out-of-the-box, but in many cases you cannot stop box from punting
CLNS packets, so any edge-interface may reach control-plane by crafted
CLNS packets (without ISIS being configured on the interface).
Where-as OSPF out-of-the-box is less secure due to IP, but pretty much
every box supports ACLs, allowing you to consistently protect box.'

-- 
  ++ytti

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[Saku Ytti]

On 25 May 2017 at 14:28, CiscoNSP List  wrote:

> Thanks very much Saku - Ive googled, but not found anything confirming...but
> ttl sec check under ospf, would it cause any issues with rLFA/FRR...i.e
> dynamic creation of tunnels?

No. rLFA is about having visibility onto Q-space's labels (nodes where
your destination is in SPT, without using the broken link). How you
gain this visibility is either targeted LDP or SR, neither imply
multihop OSPF.

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[CiscoNSP List]

Thanks very much Saku - Ive googled, but not found anything confirming...but 
ttl sec check under ospf, would it cause any issues with rLFA/FRR...i.e dynamic 
creation of tunnels?

Cheers.


From: Saku Ytti <s...@ytti.fi>
Sent: Thursday, 25 May 2017 7:23 PM
To: CiscoNSP List
Cc: adamv0...@netconsultings.com; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Best practise/security design for BGP and OSPF

On 25 May 2017 at 05:25, CiscoNSP List <cisconsp_l...@hotmail.com> wrote:

Hey,

> but not XE?  Regarding TTL(In both OSPF and BGP)hop count can be
> arbitrary, if we encounter a link failure...do we just use worse case

In iBGP yes, in eBGP and OSPF usually no. Typical design guarantees
eBGP and OSPF to be on-link or down.

--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[Saku Ytti]

On 25 May 2017 at 05:25, CiscoNSP List  wrote:

Hey,

> but not XE?  Regarding TTL(In both OSPF and BGP)hop count can be
> arbitrary, if we encounter a link failure...do we just use worse case

In iBGP yes, in eBGP and OSPF usually no. Typical design guarantees
eBGP and OSPF to be on-link or down.

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[CiscoNSP List]

Cheers for the replies - Just to clarify, these templates were for purely 
PE->RR (Not for transit), we do run key-chain auth on OSPF, and I was hoping to 
do likewise for iBGP -> RR's, but I dont *think* key-chains are supported in XE 
(Yet?)...I need to do some more reading, but I believe XR supports it, but not 
XE?  Regarding TTL(In both OSPF and BGP)hop count can be arbitrary, if 
we encounter a link failure...do we just use worse case scenario hops ?  Is 
there anything you'd add/remove from the templates that Ive sent through?  
(Obviously soft-reconfig inbound chews memory, and can be removed, but things 
like max-prefix .have it currently set at warning only...recommend killing 
the session for x minutes if it's exceed?)any other suggestions are greatly 
appreciatedthanks.



From: Saku Ytti <s...@ytti.fi>
Sent: Tuesday, 23 May 2017 7:10 PM
To: adamv0...@netconsultings.com
Cc: CiscoNSP List; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Best practise/security design for BGP and OSPF

On 23 May 2017 at 12:00,  <adamv0...@netconsultings.com> wrote:

Hey,

> Regarding OSPF,
> Best security is to use it solely for routing PE loopbacks (i.e. no
> connectivity outside the core).

But because it's IP, you might receive spooffed packet further down
the line and believe you received it from far-end. So OP's question
about TTL-security is valid one, and I'd support that. I'd also run
MD5 auth.
But of course if you have good iACL, stopping internet from sending
other than ICMP, UDP highports to links and loops, you should be
pretty safe.

ISIS and OSPF have quite interesting properties, ISIS is more secure
out-of-the-box, but in many cases you cannot stop box from punting
CLNS packets, so any edge-interface may reach control-plane by crafted
CLNS packets (without ISIS being configured on the interface).
Where-as OSPF out-of-the-box is less secure due to IP, but pretty much
every box supports ACLs, allowing you to consistently protect box.'

--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[Saku Ytti]

On 23 May 2017 at 13:06,   wrote:

> Router listening for all IS m-cast MAC addresses on all interfaces rather 
> than solely on interfaces actually configured with ISIS seems like a bug.

Not all HW support per-port punt-masks. So if you have to punt ISIS
frames on one interface, you may need to punt them on all interfaces.
I know that 7600 will happily punt ISIS/CLNS on all interfaces. Back
in 11.4R5 Juniper MX dd this too, with just 'inet' family configured,
but that was fixed.

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[adamv0025]

> Saku Ytti [mailto:s...@ytti.fi]
> Sent: Tuesday, May 23, 2017 10:11 AM
> 
> On 23 May 2017 at 12:00,   wrote:
> 
> Hey,
> 
> > Regarding OSPF,
> > Best security is to use it solely for routing PE loopbacks (i.e. no
> > connectivity outside the core).
> 
> But because it's IP, you might receive spooffed packet further down the line
> and believe you received it from far-end. So OP's question about TTL-security
> is valid one, and I'd support that. I'd also run
> MD5 auth.
> But of course if you have good iACL, stopping internet from sending other
> than ICMP, UDP highports to links and loops, you should be pretty safe.
>
Yes while on it, tightening iACLs on all edge ports is also key.

> ISIS and OSPF have quite interesting properties, ISIS is more secure out-of-
> the-box, but in many cases you cannot stop box from punting CLNS packets,
> so any edge-interface may reach control-plane by crafted CLNS packets
> (without ISIS being configured on the interface).
> Where-as OSPF out-of-the-box is less secure due to IP, but pretty much
> every box supports ACLs, allowing you to consistently protect box.'
> 
Router listening for all IS m-cast MAC addresses on all interfaces rather than 
solely on interfaces actually configured with ISIS seems like a bug. 

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[Saku Ytti]

On 23 May 2017 at 12:00,   wrote:

Hey,

> Regarding OSPF,
> Best security is to use it solely for routing PE loopbacks (i.e. no
> connectivity outside the core).

But because it's IP, you might receive spooffed packet further down
the line and believe you received it from far-end. So OP's question
about TTL-security is valid one, and I'd support that. I'd also run
MD5 auth.
But of course if you have good iACL, stopping internet from sending
other than ICMP, UDP highports to links and loops, you should be
pretty safe.

ISIS and OSPF have quite interesting properties, ISIS is more secure
out-of-the-box, but in many cases you cannot stop box from punting
CLNS packets, so any edge-interface may reach control-plane by crafted
CLNS packets (without ISIS being configured on the interface).
Where-as OSPF out-of-the-box is less secure due to IP, but pretty much
every box supports ACLs, allowing you to consistently protect box.'

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[adamv0025]

> CiscoNSP List
> Sent: Tuesday, May 23, 2017 7:45 AM
> 
> Hi Everyone,
> 
> Just doing a bit of a refresh of our current bgp+ospf templates to ensure
> they are inline with todays "best pracitse"
> 
> (I have googled this, but majority of the exmaples are from circa 2012 or
> earlierso hoping someone can provide some feebdack :)
> 
Hi 

Regarding OSPF,
Best security is to use it solely for routing PE loopbacks (i.e. no
connectivity outside the core). 

Regarding BGP,
All the security needs to be implemented at the edges of your AS, all of
them, no exceptions. 
Start with Internet eBGP sessions and move your way through all the other
eBGP sessions all the way down to managed CPEs. 
Once you have the overall concept done then it's just about slight
alternations for each different type of eBGP session. 
Best approach is to have the policy modular -that way you can for example
leave out module for blocking Martian addresses from eBGP session to CPEs
but leave it in for Internet eBGP sessions (one example of slight
modification as mentioned above). 
You can use RFC7454 as guidance in designing your BGP policy modules.

adam 

netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Best practise/security design for BGP and OSPF

[CiscoNSP List]

Hi Everyone,

Just doing a bit of a refresh of our current bgp+ospf templates to ensure they 
are inline with todays "best pracitse"

(I have googled this, but majority of the exmaples are from circa 2012 or 
earlierso hoping someone can provide some feebdack :)

Current BGP (We use RR's with a bunch of PEs (primarily vrf solutions + 
standard Inet)

Current setup/template is:


router bgp 
 template peer-policy TO_RR
  prefix-length-size 2
  next-hop-self
  soft-reconfiguration inbound
  maximum-prefix 12000 85 warning-only
  send-community both
  advertise best-external
 exit-peer-policy
!
 template peer-policy TO_RR_2
  prefix-length-size 2
  next-hop-self
  soft-reconfiguration inbound
  maximum-prefix 12000 85 warning-only
  send-community both
  advertise best-external
 exit-peer-policy

 template peer-session IBGP
  remote-as 
  ttl-security hops 10   <-- This recommended
  version 4  <- still rquired?
  password foobar  <-- Add it here, or use a different pass for each neigh
  update-source Loopback0
  ha-mode graceful-restart
 exit-peer-session

bgp router-id XXX.YYY.76.131
 bgp log-neighbor-changes
 bgp graceful-restart restart-time 120
 bgp graceful-restart stalepath-time 360
 bgp graceful-restart
 bgp bestpath compare-routerid
 bgp maxas-limit 54
 no bgp default ipv4-unicast

Then a neigbour example:

 neighbor XXX.YYY.76.204 inherit peer-session IBGP
 neighbor XXX.YYY.76.204 transport path-mtu-discovery disable  <- MTU can 
occassionally rendomly change on carrir interppo links

Address family example

 address-family ipv4
  no bgp recursion host
  bgp additional-paths select best-external
  bgp additional-paths install
  bgp nexthop route-map BGP_NHT
  bgp nexthop trigger delay 0
  redistribute connected route-map TEST_RANGES
  redistribute static route-map TEST_RANGES
  neighbor XXX.YYY.76.212 activate
  neighbor XXX.YYY.76.212 inherit peer-policy TO_RR
  neighbor XXX.YYY.76.212 route-map FROM_TEST_RR in
  neighbor XXX.YYY.76.212 route-map TO_TEST_RR out
!



OSPF Example/template:


router ospf 100
 router-id xxx.xxx.xx.xxx
 log-adjacency-changes detail
 max-lsa 1 warning-only
 prefix-priority high route-map IP_FRR
 fast-reroute per-prefix enable area 0 prefix-priority high
 fast-reroute per-prefix remote-lfa area 0 tunnel mpls-ldp
 fast-reroute per-prefix tie-break linecard-disjoint index 10
 fast-reroute per-prefix tie-break interface-disjoint index 20
 fast-reroute per-prefix tie-break primary-path index 30
 fast-reroute per-prefix tie-break node-protecting index 40
 fast-reroute per-prefix tie-break lowest-metric index 50
 fast-reroute per-prefix tie-break downstream index 60
 timers throttle lsa 0 50 5000
 timers lsa arrival 10
 timers pacing flood 5
 passive-interface default
 no passive-interface GigabitEthernet0/0/3
 network xxx.xxx.xxx.xxx 0.0.0.1 area 0
 mpls ldp sync

interface GigabitEthernet0/0/3
 description
ip ospf ttl-security  x  <-- Recommended?
 dampening
 mtu 9100
 ip address  xxx.xxx.xxx.xxx 255.255.255.254
 no ip proxy-arp
 ip ospf authentication key-chain OSPF_HELLO
 ip ospf network point-to-point
 ip ospf flood-reduction
 ip ospf bfd
 ip ospf cost 240
 load-interval 30
 carrier-delay msec 0
 negotiation auto
 mpls ip
 mpls ldp igp sync delay 10
 bfd interval 50 min_rx 50 multiplier 3
 no bfd echo
end


Thanks in advance.



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/