Re: [j-nsp] DDoS to core interface - mitigation

[Saku Ytti]

Hey,

We've always advertised externally all our PAs. But the links were not
carried internally, so attack would be discarded at the edge.

However if customer demanded that their link can reach internet, we
would add /32 route for the CE end of the link. This would still not
add attack surface to the PE, as PE is still unreachable outside the
PE. So you too can apply this strategy, as it does not require
consistent network addressing in PE-CE.





On 10 March 2018 at 02:31, Mark Tees  wrote:
> Do you mean the prefix that those PTP subnets were in was not advertised
> globally?
>
> So, those customers couldn’t use their side of the PTP link for internet’s?
>
> My problem is I can easily iACL stuff for core interfaces and loopbacks
> because I have moved that all to specific blocks but for PE-CE internet
> customers PTP subnets, the PE side is always an attack surface unless we
> have autogen ACL on every interface with automation? Unless I’m missing a
> way to deal with this?
>
> On Sat, 10 Mar 2018 at 01:39, Saku Ytti  wrote:
>>
>> On 9 March 2018 at 16:35,   wrote:
>>
>>
>> > Regarding point b)
>> > That one might be cumbersome as IP for CE-PE links in the Internet VRF
>> > are
>> > usually allocated from either your own public address space (so you'd
>> > have
>> > to fragment it and not advertising block used for PE-CE links -creating
>> > more
>> > state in GRT) or come from PI space which you don't have control over
>> > yet
>> > it's part of your infrastructure.
>>
>> In one shop I did /31 or /30 links customer or our pool, but we never
>> advertised the connected networks. If far-end for some reason needed
>> routed linknetwork, after we tried to demotivate, we crated /32 static
>> route for it. So we still didn't have that address as attack surface
>> on the PE from outside the PE.
>>
>>
>> --
>>   ++ytti
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> --
> Regards,
>
> Mark L. Tees



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

Re: [j-nsp] DDoS to core interface - mitigation

[Mark Tees]

Do you mean the prefix that those PTP subnets were in was not advertised
globally?

So, those customers couldn’t use their side of the PTP link for internet’s?

My problem is I can easily iACL stuff for core interfaces and loopbacks
because I have moved that all to specific blocks but for PE-CE internet
customers PTP subnets, the PE side is always an attack surface unless we
have autogen ACL on every interface with automation? Unless I’m missing a
way to deal with this?

On Sat, 10 Mar 2018 at 01:39, Saku Ytti  wrote:

> On 9 March 2018 at 16:35,   wrote:
>
>
> > Regarding point b)
> > That one might be cumbersome as IP for CE-PE links in the Internet VRF
> are
> > usually allocated from either your own public address space (so you'd
> have
> > to fragment it and not advertising block used for PE-CE links -creating
> more
> > state in GRT) or come from PI space which you don't have control over yet
> > it's part of your infrastructure.
>
> In one shop I did /31 or /30 links customer or our pool, but we never
> advertised the connected networks. If far-end for some reason needed
> routed linknetwork, after we tried to demotivate, we crated /32 static
> route for it. So we still didn't have that address as attack surface
> on the PE from outside the PE.
>
>
> --
>   ++ytti
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
-- 
Regards,

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

Re: [j-nsp] DDoS to core interface - mitigation

[Pierre Emeriaud]

2018-03-09 15:48 GMT+01:00  :
>
> But I was actually referring to the very appealing idea you proposed in b) to 
> not to even advertise the range -so the DDoS traffic would not even end up at 
> your doorstep as simply the Internet would not have route for any of your p2p 
> links.

this is really nice and a must-have, but has the side effect (bonus or
not, up to you) to make your network 'invisible' to others if they
have urpf enabled towards you.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] DDoS to core interface - mitigation

[adamv0025]

> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Friday, March 09, 2018 2:39 PM
> 
> On 9 March 2018 at 16:35,   wrote:
> 
> 
> > Regarding point b)
> > That one might be cumbersome as IP for CE-PE links in the Internet VRF
> > are usually allocated from either your own public address space (so
> > you'd have to fragment it and not advertising block used for PE-CE
> > links -creating more state in GRT) or come from PI space which you
> > don't have control over yet it's part of your infrastructure.
> 
> In one shop I did /31 or /30 links customer or our pool, but we never
> advertised the connected networks. If far-end for some reason needed
> routed linknetwork, after we tried to demotivate, we crated /32 static route
> for it. So we still didn't have that address as attack surface on the PE from
> outside the PE.
> 
> 
Ooh yes sure, this would also be taken care of by proper iACLs as well.
But I was actually referring to the very appealing idea you proposed in b) to 
not to even advertise the range -so the DDoS traffic would not even end up at 
your doorstep as simply the Internet would not have route for any of your p2p 
links. 

adam 

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


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

Re: [j-nsp] DDoS to core interface - mitigation

[Saku Ytti]

On 9 March 2018 at 16:35,   wrote:


> Regarding point b)
> That one might be cumbersome as IP for CE-PE links in the Internet VRF are
> usually allocated from either your own public address space (so you'd have
> to fragment it and not advertising block used for PE-CE links -creating more
> state in GRT) or come from PI space which you don't have control over yet
> it's part of your infrastructure.

In one shop I did /31 or /30 links customer or our pool, but we never
advertised the connected networks. If far-end for some reason needed
routed linknetwork, after we tried to demotivate, we crated /32 static
route for it. So we still didn't have that address as attack surface
on the PE from outside the PE.


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

Re: [j-nsp] DDoS to core interface - mitigation

[adamv0025]

> Of Roland Dobbins
> Sent: Friday, March 09, 2018 3:20 AM
> 
> 
> On 9 Mar 2018, at 3:35, Saku Ytti wrote:
> 
> > a) have edgeACL which polices ICMP and UDP high ports to your links
> > and drops rest
> > b) don't advertise your links in IGP or iBGP
> 
> This.  iACL plus no link advertisement (need a sound addressing plan to
make
> both practical at scale).
> 
Well having a dedicated infrastructure address blocks for p2p links and
loopbacks is an absolute must, if absent it should be one's priority 1
project.

Regarding point b) 
That one might be cumbersome as IP for CE-PE links in the Internet VRF are
usually allocated from either your own public address space (so you'd have
to fragment it and not advertising block used for PE-CE links -creating more
state in GRT) or come from PI space which you don't have control over yet
it's part of your infrastructure.
 
adam

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

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

Re: [j-nsp] DDoS to core interface - mitigation

[Gert Doering]

Hi,

On Fri, Mar 09, 2018 at 10:52:51AM +, James Bensley wrote:
> In addition to the above, try to avoid use public IPs on internal
> links if you can, they don't need to be reachable from the Internet
> and it saves on IPv4 address space :)

If you do so, ensure that ICMPs sent from these routers get sent from
global IPv4 addresses - leaking RFC1918 space violates said RFC
(and filtering out those leads to "* * *" in traceroute which 
sucks)

gert
-- 
now what should I write here...

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


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

Re: [j-nsp] DDoS to core interface - mitigation

[James Bensley]

On 8 March 2018 at 20:35, Saku Ytti  wrote:
> Hey Daniel,
>
> Apologies for not answering your question, but generally this is not a
> problem, because:
>
> a) have edgeACL which polices ICMP and UDP high ports to your links
> and drops rest
> b) don't advertise your links in IGP or iBGP
>
>
>
> On 8 March 2018 at 22:17, Dan Římal  wrote:
>> Hi all,
>>
>> I would like to discuss, how do you handle ddos attack pointing to IP 
>> address of any router core interface, if your UPLINK/ISP support RTBH and 
>> you would like to drop traffic at ISP level because of congested links.
>>
>> I have tried to implement "classic" BGP signalized RTBH, via changing 
>> next-hop to discard route. It works good for customers IPs, but applied to 
>> core-interface IP address, it drops routing protocol running on this 
>> interfaces between routers (because /32 discard route is more specific than, 
>> at least, /31 p2p). I tried to implement export filter between RIB and FIB 
>> (routing-options forwarding-table export) to not to install this routes to 
>> FIB. It looks better, it doesn't drop BGP/BFD/... anymore, but it works just 
>> by half. Try to explain:
>>
>> I have two routers, both have transit operator (UPLINK-A, UPLINK-B) and they 
>> are connected to each other. Routers interconnect is let's say 
>> 192.168.72.248/31 (248 router-A, 249 router-B). I will start to propagate 
>> via iBGP discard route 192.168.72.248/32 from ddos detection appliance to 
>> both routers. Router-B get RTBH route as the best, skip install to FIB 
>> because of export filter between RIB and FIB and will start to propagate 
>> appropriate route with blackhole community to UPLINK-B. UPLINK-B drops dst 
>> at their edge. Good.
>>
>> But, router A get the same blackhole route, but not as the best, because it 
>> has the same route (/32) as a local route with lower route preference:
>>
>> 192.168.72.248/32  *[Local/0] 34w1d 07:59:10
>>   Local via ae2.3900
>> [BGP/170] 07:43:20, localpref 2000
>>   AS path: I, validation-state: unverified
>> > to 10.110.0.12 via ae1.405
>>
>> So, router-A doesn't start propagate blackhole route to UPLINK-A (because it 
>> is not the best, i guess) and DDOS still came from UPLINK-A.
>>
>> How can i handle this situation? Maybe set lower route preference from 
>> detection appliance than default 170? But "Directly connected network" has 
>> preference 0 and i cannot go lower and cannot get more specific than local 
>> /32. Or maybe use bgp advertise-inactive toward my UPLINKs? Will this help?
>>
>> Thanks!
>>
>> Daniel

In addition to the above, try to avoid use public IPs on internal
links if you can, they don't need to be reachable from the Internet
and it saves on IPv4 address space :)

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

Re: [j-nsp] DDoS to core interface - mitigation

[Daniel Suchy]

Hi,
yes - there's "advertise-inactive" option in BGP, which might help in
such case (in combination with FIB filters): "The advertise-inactive
statement causes Junos OS to advertise the best BGP route that is
inactive because of IGP preference."

You cannot modify preference of directly-connected network - it's always
set to zero...

With regards,
Daniel


On 03/08/2018 09:17 PM, Dan Římal wrote:
> Hi all,
> 
> I would like to discuss, how do you handle ddos attack pointing to IP address 
> of any router core interface, if your UPLINK/ISP support RTBH and you would 
> like to drop traffic at ISP level because of congested links.
> 
> I have tried to implement "classic" BGP signalized RTBH, via changing 
> next-hop to discard route. It works good for customers IPs, but applied to 
> core-interface IP address, it drops routing protocol running on this 
> interfaces between routers (because /32 discard route is more specific than, 
> at least, /31 p2p). I tried to implement export filter between RIB and FIB 
> (routing-options forwarding-table export) to not to install this routes to 
> FIB. It looks better, it doesn't drop BGP/BFD/... anymore, but it works just 
> by half. Try to explain:
> 
> I have two routers, both have transit operator (UPLINK-A, UPLINK-B) and they 
> are connected to each other. Routers interconnect is let's say 
> 192.168.72.248/31 (248 router-A, 249 router-B). I will start to propagate via 
> iBGP discard route 192.168.72.248/32 from ddos detection appliance to both 
> routers. Router-B get RTBH route as the best, skip install to FIB because of 
> export filter between RIB and FIB and will start to propagate appropriate 
> route with blackhole community to UPLINK-B. UPLINK-B drops dst at their edge. 
> Good.
> 
> But, router A get the same blackhole route, but not as the best, because it 
> has the same route (/32) as a local route with lower route preference:
> 
> 192.168.72.248/32  *[Local/0] 34w1d 07:59:10
>   Local via ae2.3900
> [BGP/170] 07:43:20, localpref 2000
>   AS path: I, validation-state: unverified
> > to 10.110.0.12 via ae1.405
> 
> So, router-A doesn't start propagate blackhole route to UPLINK-A (because it 
> is not the best, i guess) and DDOS still came from UPLINK-A.
> 
> How can i handle this situation? Maybe set lower route preference from 
> detection appliance than default 170? But "Directly connected network" has 
> preference 0 and i cannot go lower and cannot get more specific than local 
> /32. Or maybe use bgp advertise-inactive toward my UPLINKs? Will this help?
> 
> Thanks!
> 
> Daniel
> ___
> 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] DDoS to core interface - mitigation

[Roland Dobbins]

On 9 Mar 2018, at 3:35, Saku Ytti wrote:


a) have edgeACL which polices ICMP and UDP high ports to your links
and drops rest
b) don't advertise your links in IGP or iBGP


This.  iACL plus no link advertisement (need a sound addressing plan to 
make both practical at scale).


Here's a link to a .pdf preso which talks about network infrastructure 
self-protection.  It's Cisco-centric because that's my background, but 
the concepts are universal:




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

Re: [j-nsp] DDoS to core interface - mitigation

[Saku Ytti]

Hey Daniel,

Apologies for not answering your question, but generally this is not a
problem, because:

a) have edgeACL which polices ICMP and UDP high ports to your links
and drops rest
b) don't advertise your links in IGP or iBGP



On 8 March 2018 at 22:17, Dan Římal  wrote:
> Hi all,
>
> I would like to discuss, how do you handle ddos attack pointing to IP address 
> of any router core interface, if your UPLINK/ISP support RTBH and you would 
> like to drop traffic at ISP level because of congested links.
>
> I have tried to implement "classic" BGP signalized RTBH, via changing 
> next-hop to discard route. It works good for customers IPs, but applied to 
> core-interface IP address, it drops routing protocol running on this 
> interfaces between routers (because /32 discard route is more specific than, 
> at least, /31 p2p). I tried to implement export filter between RIB and FIB 
> (routing-options forwarding-table export) to not to install this routes to 
> FIB. It looks better, it doesn't drop BGP/BFD/... anymore, but it works just 
> by half. Try to explain:
>
> I have two routers, both have transit operator (UPLINK-A, UPLINK-B) and they 
> are connected to each other. Routers interconnect is let's say 
> 192.168.72.248/31 (248 router-A, 249 router-B). I will start to propagate via 
> iBGP discard route 192.168.72.248/32 from ddos detection appliance to both 
> routers. Router-B get RTBH route as the best, skip install to FIB because of 
> export filter between RIB and FIB and will start to propagate appropriate 
> route with blackhole community to UPLINK-B. UPLINK-B drops dst at their edge. 
> Good.
>
> But, router A get the same blackhole route, but not as the best, because it 
> has the same route (/32) as a local route with lower route preference:
>
> 192.168.72.248/32  *[Local/0] 34w1d 07:59:10
>   Local via ae2.3900
> [BGP/170] 07:43:20, localpref 2000
>   AS path: I, validation-state: unverified
> > to 10.110.0.12 via ae1.405
>
> So, router-A doesn't start propagate blackhole route to UPLINK-A (because it 
> is not the best, i guess) and DDOS still came from UPLINK-A.
>
> How can i handle this situation? Maybe set lower route preference from 
> detection appliance than default 170? But "Directly connected network" has 
> preference 0 and i cannot go lower and cannot get more specific than local 
> /32. Or maybe use bgp advertise-inactive toward my UPLINKs? Will this help?
>
> Thanks!
>
> Daniel
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



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