[j-nsp] DDoS to core interface - mitigation

Saku Ytti saku at ytti.fi
Sat Mar 10 04:09:39 EST 2018


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 <marktees at gmail.com> 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 <saku at ytti.fi> wrote:
>>
>> On 9 March 2018 at 16:35,  <adamv0025 at netconsultings.com> 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> --
> Regards,
>
> Mark L. Tees



-- 
  ++ytti


More information about the juniper-nsp mailing list