[AusNOG] Dealing with global route views

Sat Aug 2 23:42:16 EST 2014

Scratch that. Wrong traffic direction to use prefixes received. Would have
to be ACLs purely based on downstream authorised prefixes rather than
prefixes received :(

On Saturday, August 2, 2014, Mark Tees <marktees at gmail.com> wrote:

> RPKI handling route authentication then ACLs generated from authorised
> prefixes received maybe? Might work for transit provider networks.
>
> On Saturday, August 2, 2014, Joshua D'Alton <joshua at railgun.com.au
> <javascript:_e(%7B%7D,'cvml','joshua at railgun.com.au');>> wrote:
>
>> Indeed!
>>
>> Sadly no AU network has probably enough pull to force even one lowly
>> tier1 to do that :(
>>
>> Beyond OP, but would be interesting to see the ideas of making  BCP38
>> happen!
>>
>>
>> On Sat, Aug 2, 2014 at 9:30 PM, James Braunegg <
>> james.braunegg at micron21.com> wrote:
>>
>>> Dear Joshua
>>>
>>>
>>>
>>> If the entire world of network operators simultaneously implemented BCP
>>> 38 globally - http://www.bcp38.info the Internet would be a much
>>> cleaner place stopping the ability of spoofed traffic being generated which
>>> is the key component in launching a Distributed Reflection Denial of
>>> Service (DRDoS) attacks.
>>>
>>>
>>>
>>> Kindest Regards
>>>
>>>
>>>
>>>
>>> *James Braunegg **P:*  1300 769 972  |  *M:*  0488 997 207 |  *D:*
>>> (03) 9751 7616
>>>
>>> *E:*   james.braunegg at micron21.com  |  *ABN:*  12 109 977 666
>>> *W:*  www.micron21.com/ddos-protection   *T:* @micron21
>>>
>>>
>>>
>>>
>>> [image: Description: Description: Description: Description: M21.jpg]
>>> This message is intended for the addressee named above. It may contain
>>> privileged or confidential information. If you are not the intended
>>> recipient of this message you must not use, copy, distribute or disclose it
>>> to anyone other than the addressee. If you have received this message in
>>> error please return the message to the sender by replying to it and then
>>> delete the message from your computer.
>>>
>>>
>>>
>>> *From:* Joshua D'Alton [mailto:joshua at railgun.com.au]
>>> *Sent:* Saturday, August 02, 2014 9:14 PM
>>> *To:* James Braunegg
>>> *Cc:* Andrew Yager; ausnog at lists.ausnog.net
>>> *Subject:* Re: [AusNOG] Dealing with global route views
>>>
>>>
>>>
>>> Unfortunately The Internet has seen a jump in DDoS capability in the
>>> past year or so that hasn't been meted, generally, by an increase in
>>> mitigation. IE DDoS is winning, at the moment :(
>>>
>>>
>>>
>>> The specificity of the current attacks ought to be able to be addressed
>>> by the tier1s/major players, however doesn't seem to be!
>>>
>>>
>>>
>>> Might be a different topic for this, or if people can PM information
>>> they have on this (not having found much on nanog etc), I'd be interested!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Aug 2, 2014 at 9:00 PM, James Braunegg <
>>> james.braunegg at micron21.com> wrote:
>>>
>>> Dear Andrew
>>>
>>>
>>>
>>> This week has been “crazy” for DDoS attacks with SSDP amplification
>>> attacks being the flavor of the week internationally, so I can understand
>>> your “pain”
>>>
>>>
>>>
>>> A key part of isolating yourself from “back ground noise” is the ability
>>> separate Domestic Transit and Peering from International transit and if you
>>> can International peering using BGP communities.
>>>
>>>
>>>
>>> Both Vocus and Pipe support BGP communities, however in both cases I
>>> highly recommend contacting the NOC for up to date communities as upstream
>>> providers change all the time and the NOC of each provider can provide
>>> great assistance in “tuning” your service.
>>>
>>>
>>>
>>> That being said
>>>
>>>
>>>
>>> Examples of Vocus (AS4826) communities can be found here (not all
>>> communities listed )
>>> http://tools.vocus.com.au/additionals/communities2.2.html
>>>
>>>
>>>
>>> Examples of Pipe (AS 24130) communities can be found here (not all
>>> communities listed)
>>> https://lg.pipenetworks.com/PIPE%20Networks%20AS24130%20BGP%20Routing%20Policy.pdf
>>>
>>>
>>>
>>> With reference to influencing outbound traffic I highly recommend
>>> creating route maps or using software such as http://www.noction.com/
>>>
>>>
>>>
>>> Depending how far you want to engineer your network you can also get
>>> very “funky” with your own international upstream providers and say
>>> establish GRE tunnels back to Australia and if you can justify it your own
>>> capacity across cable systems which can be used independently from your
>>> current two upstream providers.
>>>
>>>
>>>
>>> Alternately this is also a perfect example of how useful having a backup
>>> on demand IP transit provider on a service such as Megaport which allows
>>> you to turn on / off a service on demand within minutes if required, use a
>>> bit of SDN and you could automate the entire process upon detecting issues!
>>>
>>>
>>>
>>> Hope that helps, happy to provide more information if you require it.
>>>
>>>
>>>
>>> Kindest Regards
>>>
>>>
>>>
>>>
>>> *James Braunegg **P:*  1300 769 972  |  *M:*  0488 997 207 |  *D:*
>>> (03) 9751 7616
>>>
>>> *E:*   james.braunegg at micron21.com  |  *ABN:*  12 109 977 666
>>> *W:*  www.micron21.com/ddos-protection   *T:* @micron21
>>>
>>>
>>>
>>>
>>> [image: Description: Description: Description: Description: M21.jpg]
>>> This message is intended for the addressee named above. It may contain
>>> privileged or confidential information. If you are not the intended
>>> recipient of this message you must not use, copy, distribute or disclose it
>>> to anyone other than the addressee. If you have received this message in
>>> error please return the message to the sender by replying to it and then
>>> delete the message from your computer.
>>>
>>>
>>>
>>> *From:* AusNOG [mailto:ausnog-bounces at lists.ausnog.net] *On Behalf Of *Andrew
>>> Yager
>>> *Sent:* Saturday, August 02, 2014 7:23 PM
>>> *To:* ausnog at lists.ausnog.net
>>> *Subject:* [AusNOG] Dealing with global route views
>>>
>>>
>>>
>>> Hi All,
>>>
>>>
>>>
>>> Coming to the end of a couple of long weeks, and brain is a bit fried.
>>>
>>>
>>>
>>> For the last few days we've had issues where one or other of our two
>>> primary internal upstreams has had DOS attacks affecting their connectivity
>>> on foreign soil (i.e. connectivity via Level 3 is borked, or connectivity
>>> via he.net is borked), which has adversely affected our ability to
>>> reach certain parts of the world, and conversely their ability to reach us.
>>>
>>>
>>>
>>> In both cases we don't really want to drop either transit provider
>>> completely as the domestic performance we get from them both is good.
>>>
>>>
>>>
>>> On another day my brain might see this really clearly, but just can't
>>> get my head into it for now.
>>>
>>>
>>>
>>> Can we:
>>>
>>>
>>>
>>> a) adjust our internal preferences accurately enough to influence our
>>> outbound traffic to prefer one or the other in particular, operator driven
>>> scenarios
>>>
>>> b) influence our rest of the world traffic to avoid he.net or level 3
>>>
>>>
>>>
>>> … and how?
>>>
>>>
>>>
>>> I believe one of our upstreams (Vocus) will honour some "do not
>>> advertise here" communities (but I don't know where the list is), but I
>>> suspect the other (PIPE) will not?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Andrew
>>>
>>>
>>>
>>> --
>>> *Andrew Yager, Managing Director*   *MACS (Snr) CP BCompSc MCP*
>>> Real World Technology Solutions Pty Ltd - IT people you can trust
>>> ph: 1300 798 718 or (02) 9037 0500
>>> fax: (02) 9037 0591
>>> http://www.rwts.com.au/
>>>
>>>
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>>
>>>
>>
>>
>
> --
> Regards,
>
> Mark L. Tees
>
>

-- 
Regards,

Mark L. Tees
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140802/fd6fca00/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2683 bytes
Desc: not available
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140802/fd6fca00/attachment.jpg>