RE: DDOS solution recommendation

[David Hofstee]

Hi Mike, 

About trying to hit the mail ports... It is very easy for a domain to set its 
MX to a random host name. So before you block you might want to check the 
To-domain in the header of the mail. Otherwise it is too easy to DoS yourself 
(by planting email addresses in systems, such as mine, and then changing the MX 
of that domain to your hosts).



David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)


-Oorspronkelijk bericht-
Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Mike Hammett
Verzonden: Sunday, January 11, 2015 2:46 PM
Aan: Roland Dobbins
CC: nanog@nanog.org
Onderwerp: Re: DDOS solution recommendation

Well there's going to be two sources of the attack... infested clients or 
machines setup for this purpose (usually in a datacenter somewhere). Enough 
people blackhole the attacking IPs, those IPs are eventually going to have a 
very limited view of the Internet. They may not care of it's a server in a 
datacenter being used to attack, but an infested home PC would care once they 
can't get to Google, FaceBook, Instagram, whatever. 

If the attacker's abuse contact doesn't care, then just brute force of more and 
more of the Internet being offline to them, they'll figure it out. 

You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to my 
non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, etc. You 
have more than say 5 bad login attempts to my mail server in 5 minutes, 
blackholed for 30 days. You're trying to access various web pages known for 
home router or Wordpress exploitation, blackholed for 30 days. 

No point in letting troublemakers (manual or scripted) spend more time on the 
network than necessary. The more people (as a collective or not) that do this, 
the better. 




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com 



- Original Message -

From: "Roland Dobbins" 
To: nanog@nanog.org
Sent: Sunday, January 11, 2015 7:24:55 AM
Subject: Re: DDOS solution recommendation 


On 11 Jan 2015, at 20:07, Mike Hammett wrote: 

> but I'd think that if their network's abuse department was notified, 
> either they'd contact the customer about it issue or at least have on 
> file that they were notified.

Just because we think something, that doesn't make it true. 

;> 

> The way to stop this stuff is for those millions of end users to clean 
> up their infected PCs.

You may want to do some reading on this topic in order to gain a better 
understanding of the issues involved: 

 

Some of us have been dealing with DDoS attacks for a couple of decades, now. If 
it were a simple problem, we would've solved it long ago. 

Here's a hint: scale alone makes any problem literally orders of magnitude more 
difficult than any given instance thereof. 

---
Roland Dobbins  

Re: DDOS solution recommendation

[Colin Johnston]

> On 12 Jan 2015, at 08:29, David Hofstee  wrote:
> 
> Hi Mike, 
> 
> About trying to hit the mail ports... It is very easy for a domain to set its 
> MX to a random host name. So before you block you might want to check the 
> To-domain in the header of the mail. Otherwise it is too easy to DoS yourself 
> (by planting email addresses in systems, such as mine, and then changing the 
> MX of that domain to your hosts).
> 


Should be overcome by good dont block range checker and header checks as above

Colin

Re: DDOS solution recommendation

[Tore Anderson]

* "Roland Dobbins" 

> On 11 Jan 2015, at 20:52, Ca By wrote:
> 
> > 3.  Have RTBH ready for some special case.
> 
> S/RTBH and/or flowspec are better (S/RTBH does D/RTBH, too).

But are there any transit providers that support flowspec these days?
As I understand it, only GTT used to, but they stopped.

I'd love to use flowspec over D/RTBH, but to me it seems like
vapourware.

Tore

Re: DDOS solution recommendation

[Roland Dobbins]

On 12 Jan 2015, at 16:19, Tore Anderson wrote:

I'd love to use flowspec over D/RTBH, but to me it seems like 
vapourware.


I meant on your own infrastructure, apologies for the confusion.

Transit providers can't offer S/RTBH to their downstreams for obvious 
reasons.


Transit providers utilizing Juniper aggregation edge routers could do it 
now - why they don't, I don't know.


And now Cisco are now supporting flowspec on some of their platforms, as 
well.


---
Roland Dobbins 

Re: DDOS solution recommendation

[Tore Anderson]

* "Roland Dobbins" 

> On 12 Jan 2015, at 16:19, Tore Anderson wrote:
> 
> > I'd love to use flowspec over D/RTBH, but to me it seems like 
> > vapourware.
> 
> I meant on your own infrastructure, apologies for the confusion.

Right. So if I first need to accept the traffic onto my infrastructure
before I can discard it, I'm dead in the water anyway: My uplinks will
sit there at 100% ingress utilisation, dropping legitimate traffic.
/32 or /128 D/RTBH announcements towards my transits is my only real
option at this point. That helps protect against collateral damage, and
if the customer's audience is local, it can also restore full operation
for the attacked customer's primary markets (which are usually reached
via peers instead of transits).

For attacks that are conveniently sized smaller than my upstream
capacity, I could see that flowspec could be useful, but not in a
unique way, as inside my own network I can easily distribute targeted
stateless discard ACLs in many other ways too (I use Netconf currently).

> Transit providers utilizing Juniper aggregation edge routers could do it 
> now - why they don't, I don't know.

I'd definitively be willing to pay a premium for such a feature.

Tore

command that can display routes containing AS loops

[Song Li]

Hi everyone,

I am curious about the AS loops in the AS-path. I think there should be 
a very, very few received BGP routes that contain the local AS#. But 
because such routes will be dropped and not installed in Loc-RIB, I want 
to know if there is a command that can display the dropped routes 
containing AS loops (in cisco or juniper router). Does anybody know?


Thanks!

Best!

--
Song Li
Room 4-204, FIT Building,
Network Security,
Department of Electronic Engineering,
Tsinghua University, Beijing 100084, China
Tel:( +86) 010-62446440
E-mail: refresh.ls...@gmail.com

Re: Recommended L2 switches for a new IXP

[Mike Hammett]

I look forward to this thread. 

I think one important thing is who is your addressable market size? I'm working 
with a startup IXP and there's only 20 carriers in the building. A chassis 
based switch would be silly as there would never be that many people present. 
2x 1U switches would be more than plenty in their environment. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



- Original Message -

From: "Manuel Marín"  
To: nanog@nanog.org 
Sent: Monday, January 12, 2015 12:35:15 AM 
Subject: Recommended L2 switches for a new IXP 

Dear Nanog community 

We are trying to build a new IXP in some US Metro areas where we have 
multiple POPs and I was wondering what do you recommend for L2 switches. I 
know that some IXPs use Nexus, Brocade, Force10 but I don't personally have 
experience with these switches. It would be great if you can share your 
experience and recommendations. There are so many options that I don't know 
if it makes sense to start with a modular switch (usually expensive because 
the backplane, dual dc, dual CPU, etc) or start with a 1RU high density 
switch that support new protocols like Trill and that supposedly allow you 
to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G 
ports for exchange participants, 40G/100G for uplinks between switches and 
flow support for statistics and traffic analysis. 

Thank you and have a great day. 

Regards 

Re: command that can display routes containing AS loops

[Dave Bell]

On a Juniper, you could do something like:

 show route hidden aspath-regex .*.*

Regards,
Dave

On 12 January 2015 at 13:05, Song Li  wrote:
> Hi everyone,
>
> I am curious about the AS loops in the AS-path. I think there should be a
> very, very few received BGP routes that contain the local AS#. But because
> such routes will be dropped and not installed in Loc-RIB, I want to know if
> there is a command that can display the dropped routes containing AS loops
> (in cisco or juniper router). Does anybody know?
>
> Thanks!
>
> Best!
>
> --
> Song Li
> Room 4-204, FIT Building,
> Network Security,
> Department of Electronic Engineering,
> Tsinghua University, Beijing 100084, China
> Tel:( +86) 010-62446440
> E-mail: refresh.ls...@gmail.com

Re: command that can display routes containing AS loops

[Song Li]

Hi Dave,

thanks! I tried the command and found that it works. Do you know the 
similar command on cisco?


Regards,

Song

在 2015/1/12 21:16, Dave Bell 写道:

On a Juniper, you could do something like:

  show route hidden aspath-regex .*.*

Regards,
Dave

On 12 January 2015 at 13:05, Song Li  wrote:

Hi everyone,

I am curious about the AS loops in the AS-path. I think there should be a
very, very few received BGP routes that contain the local AS#. But because
such routes will be dropped and not installed in Loc-RIB, I want to know if
there is a command that can display the dropped routes containing AS loops
(in cisco or juniper router). Does anybody know?

Thanks!

Best!

--
Song Li
Room 4-204, FIT Building,
Network Security,
Department of Electronic Engineering,
Tsinghua University, Beijing 100084, China
Tel:( +86) 010-62446440
E-mail: refresh.ls...@gmail.com



--
Song Li
Room 4-204, FIT Building,
Network Security,
Department of Electronic Engineering,
Tsinghua University, Beijing 100084, China
Tel:( +86) 010-62446440
E-mail: refresh.ls...@gmail.com

Re: DDOS solution recommendation

[Colin Johnston]

unfortunately chinanet antispam/abuse email box is always full, after a while 
people block .
always check arin/ripe for known good provider blocks and actively exclude from 
rules



ddos protection via careful overview ips rules and active web source ip 
monitoring works well, the hard part is daily rule updates and blocks until you 
know most traffic is genuine.

colin

Sent from my iPhone

> On 11 Jan 2015, at 19:42, "Patrick W. Gilmore"  wrote:
> 
> I do love solutions which open larger attack surfaces than they are supposed 
> to close. In the US, we call that "a cure worse than the disease".
> 
> Send packet from random bot with source of Google, Comcast, Akamai, etc. to 
> Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off 
> from the world.
> 
> Voilà! Denial of service accomplished without all the hassle of sending 100s 
> of Gbps of traffic.
> 
> Best part is he was willing to explain this to 10,000+ of his not-so-closest 
> friends, in a search-engine-indexed manner.
> 
> -- 
> TTFN,
> patrick
> 
>> On Jan 11, 2015, at 14:34 , Phil Bedard  wrote:
>> 
>> Many attacks can use spoofed source IPs, so who are you really blocking?  
>> 
>> That's why BCP38 as mentioned many times already is a necessary tool in 
>> fighting the attacks overall.  
>> 
>> Phil 
>> 
>> 
>> 
>> 
>>> On 1/11/15, 4:33 PM, "Mike Hammett"  wrote:
>>> 
>>> I didn't necessarily think I was shattering minds with my ideas. 
>>> 
>>> I don't have the time to read a dozen presentations. 
>>> 
>>> Blackhole them and move on. I don't care whose feelings I hurt. This 
>>> isn't kindergarten. Maybe "you" should have tried a little harder to not 
>>> get a virus in the first place. Quit clicking on male enhancement ads or 
>>> update your OS occasionally. I'm not going to spend a bunch of time and 
>>> money to make sure someone's bubble of bliss doesn't get popped. Swift, 
>>> effective, cheap. Besides, you're only cut off for 30 days. If in 30 days 
>>> you can prove yourself to be responsible, we can try this again. Well, 
>>> that or a sufficient support request. 
>>> 
>>> Besides, if enough people did hat, the list of blackholes wouldn't be 
>>> huge as someone upstream already blocked them. 
>>> 
>>> 
>>> 
>>> 
>>> - 
>>> Mike Hammett 
>>> Intelligent Computing Solutions 
>>> http://www.ics-il.com 
>>> 
>>> 
>>> 
>>> - Original Message -
>>> 
>>> From: "Roland Dobbins"  
>>> To: nanog@nanog.org 
>>> Sent: Sunday, January 11, 2015 9:29:33 AM 
>>> Subject: Re: DDOS solution recommendation 
>>> 
>>> 
 On 11 Jan 2015, at 22:21, Mike Hammett wrote: 
 
 I'm not saying what you're doing is wrong, I'm saying whatever the 
 industry as a whole is doing obviously isn't working and perhaps a 
 different approach is required.
>>> 
>>> You haven't recommended anything new, and you really need to do some 
>>> reading in order to understand why it isn't as simple as you seem to 
>>> think it is. 
>>> 
 Security teams? My network has me, myself and I.
>>> 
>>> And a relatively small network, too. 
>>> 
 If for example ChinaNet's abuse department isn't doing anything about 
 complains, eventually their whole network gets blocked a /32 at a 
 time. *shrugs* Their loss.
>>> 
>>> Again, it isn't that simple. 
>>> 
>>> --- 
>>> Roland Dobbins 
> 

Re: Office 365 Expert - I am not. I have a customer that...

[Dave Pooser]

>Wonder when Cloud providers get a clue, step up and help recommend a
>circuit size based on users and the services their customer buy from them.

When they think that poor customer word of mouth will cost them more sales
then they are currently gaining from customers who would *not* move away
from on-prem if they understood all the costs including increased
bandwidth?
-- 
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com

IEEE International Workshop on Manageability and Security of Network Function Virtualization and Software Defined Network (MASONS)

[Chen Liu]

---
Apologies for cross-postings!
---

Call for Papers

IEEE International Workshop on Manageability and Security of Network
Function Virtualization and Software Defined Network (MASONS)
With ICCCN 2015 at Las Vegas, Aug 3 – 6, 2015
http://www.icccn.org/icccn15/

MASONS 2015 is Technically Co-Sponsored by the IEEE Communication Society

1. Theme

Today, many research organizations in academia, government labs and
industry are exploring SDN and NFV technologies to study and materialize
their benefits in real world networks. These benefits are enabling
automation, reducing time to market in case of new service introductions,
optimization and/or improving overall economics of network and system
management and operations. However to materialize the benefits of SDN and
NFV at larger scale across multiple domains, similar to today’s internet,
additional investigations are needed which should focus beyond the core
SDN, NFV features and functionalities. This involves: development of
multi-domain SDN network to support Internet; large scale deployment of
novel applications, identification of technological and operational gaps in
research and development over the longer term to increase the capability of
SDN and NFV powered networks, and better integrate them with existing
public Internet and emerging cloud technologies; Identification of
security, manageability gaps, including opportunities to build in
additional levels of security, resilience and management capabilities.

2. Topics of interest

This workshop aims to show case and disseminate new ideas and high quality
research on manageability and security of Software Defined Network and
Network Function Virtualization. We solicit original research articles,
review papers, theoretical studies, and practical software systems
incorporating new paradigms, experimental prototypes, and insightful
requirement analysis with the above theme including, but not limited to the
topics below:
* Design, requirements and prototypes of Software Defined Exchanges (SDX)
to enable interoperability and use of new approaches with the current
Internet infrastructure.
* Security, privacy, authentication, trust, verification for SDN and NFV.
* Integration of compute, storage and network under the Software Defined
Infrastructure (SDI) paradigm.
* Analysis of new management challenges that SDN and NFV has introduced.
* Network management practices and business processes for SDN and NFV, in
service provider and data center infrastructures.
* Tools and operational procedures for managing SDN.
* New paradigms in network operations, administration and management (OAM),
service orchestration, service engineering, converged network-compute and
data center management.
* Software Defined Network (SDN), abstraction, programmability, application
Interface, south and northbound API.
* Network Function Virtualization (NFV), distributed control, virtual
switches, routing virtualization.
* Network system management, orchestration, resource management and
optimization, integration, interoperability.
* Network operations management related automation, troubleshooting and
management tools.
* Cloud based network and system management application paradigms.
* Application of artificial intelligence (AI), machine learning (ML),
analytics and big data in network and system management.
* Insights about Network Management System architectural requirements
analysis.
* Scalability of SDN, NFV, SDI, NMS systems.
* User experience, user interface design issues and challenges in NMS for
SDN, NFV, ethnographic studies on network operations centers, usability
studies of management applications.

3. Instructions for IEEE MASONS 2015 Workshop Authors:

Submitted manuscripts must be formatted in standard IEEE camera ready
format (double column, 10 pt font) and must be submitted via EasyChair (
http://www.easychair.org/) as PDF files (formatted for 8.5×11 inch paper).
It should be no longer than 6 pages with up to two extra pages given the
authors are willing to pay an over-length charge per extra page. The
detailed information can be found in the ICCCN 2015 (Las Vegas) website.
For any workshop related questions or additional information please contact
the General, TPC, or Workshop Chairs.

Submitted papers should not be previously published in or be under
consideration for publication in another conference or journal. Paper
titles and/or author names cannot be changed and/or added to the papers
once papers are submitted to ICCCN 2015 for review. Submissions must
include a title, abstract, keywords, author(s) and affiliation(s) with
postal and email address(es) and phone number(s). A paper abstract must be
registered on EasyChair by the deadline indicated below.

4. Important dates:

* A

MISSION 2015 - IEEE Workshop on Management Issues in SDN, SDI and NFV

[Chen Liu]

---
Apologies for cross-postings!
---

IEEE Workshop on Management Issues in SDN, SDI and NFV
LONDON, UK, APRIL 13-17, 2015
http://sites.ieee.org/netsoft/workshop/MISSION/

CALL FOR PAPERS

SCOPE

The IEEE International Workshop on Management Issues in Software defined
network, Software defined infrastructure and network function
virtualizatION (MISSION 2015) will be held between April 13-17, 2015 in
London, U.K. at the Cruciform Building of University College London (UCL)
along with 1st IEEE International Conference on Network Softwarization
(NetSoft 2015). Software is increasing flexibility and programmability of
infrastructure in SDN, SDI and NFV. This softwarization trend has
materialized new product and services that lead to significant business
benefits. To realize these benefits, we also need to rethink the management
issues along with making progress in core functionalities for SDN, SDI and
NFV. A holistic system-oriented innovation approach is needed to redesign
infrastructure management operations, NMS artefacts and functionalities at
multiple levels. The MISSION 2015 workshop will address these new and
emerging management issues in SDN, SDI and NFV.

TOPICS OF INTEREST

Authors are invited to submit papers that fall into the area of
software-defined and virtualized infrastructures. Topics of interest
include, but are not limited to, the following:

- System management challenges in SDN, SDI, NFV
- Network management practices and business procedures for SDN, NFV, SDI in
telco and enterprise data center infrastructures
- New paradigms in network operations, administration and management for
SDN, SDI and NFV
- Management challenges in mobile and wireless SDN and NFV environment
- Service orchestration in converged network-compute and data center
management
- Reliability issues in SDN and NFV
Network management & operations related automation, troubleshooting and
administration tools for SDN, SDI and NFV
- Cloud based network and system management application paradigms for SDN ,
SDI and NFV
- Application of artificial intelligence (AI), machine learning (ML),
analytics and big data in network and system management of SDN, SDI and NFV
- Insights about Network Management System (NMS) architectural requirements
& analysis
- User experience, user interface design issues and challenges in NMS for
SDN, SDI, NFV ethnographic studies on network operations centers, usability
studies of management applications


PAPER SUBMISSION

Authors are invited to submit only original papers not published or
submitted for publication elsewhere. Papers should be within 6 pages, in
IEEE 2-column US-Letter style using IEEE Conference (
www.ieee.org/conferences_events/conferences/publishing/templates.html)
templates and submitted in PDF format via EDAS at: http://edas.info/19315.
Papers exceeding these limits, multiple submissions elsewhere, and
self-plagiarized papers will be rejected without further review. All
submitted papers will be subject to a peer-review process. Accepted and
presented papers will be published in the MISSION 2015 Workshop Proceedings
and submitted to IEEE Xplore.


IMPORTANT DATES

- Paper Submission: January 30, 2015
- Notification of Acceptance: February 28, 2015
- Camera Ready Papers: March 13, 2015

WORKSHOP CO-CHAIRS

- Kashinath Basu, Oxford Brookes University, UK
- Chen Liu, Microsoft, US


NETSOFT WORKSHOP CO-CHAIRS

- Amitava Biswas, Cisco Systems, US
- Noura Limam, University of Waterloo, Canada


NETSOFT GENERAL CO-CHAIRS

- Prosper Chemouil, Orange Labs, France
- George Pavlou, University College London, UK


IEEE SDN Initiative Chair

- Antonio Manzalini, Telecom Italia, Italy


TECHNICAL SPONSORS

- IEEE Communications Society, IEEE Computer Society, IEEE Consumer
Electronics Society and IEEE Signal Processing

Re: DDOS solution recommendation

[Roland Dobbins]

On 12 Jan 2015, at 3:28, Colin Johnston wrote:

> ips rules and active web source ip monitoring works well

Until it doesn't:




---
Roland Dobbins 

Re: Office 365 Expert - I am not. I have a customer that...

[Bob Evans]

>>Wonder when Cloud providers get a clue, step up and help recommend a
>>circuit size based on users and the services their customer buy from
>> them.
>
> When they think that poor customer word of mouth will cost them more sales
> then they are currently gaining from customers who would *not* move away
> from on-prem if they understood all the costs including increased
> bandwidth?

Agreed - it will be the smart ones that don't wait for that end user
experience to go bad.
In the meantime, I can tell you sitting here in silicon valley that all
these sharp VCs don't see the hole in many of these basic business plans
called "Cloud, Rack of servers in multiple locations".

Bob Evans
CTO

Re: Recommended L2 switches for a new IXP

[Aaron]

We used to use Brocade FastIrons until we needed more 10G port density.  
We moved to Brocade SX's.


Originally, when it was 2 or 3 peers, we used an old Netgear switch. :)

Aaron

On 1/12/2015 7:07 AM, Mike Hammett wrote:

I look forward to this thread.

I think one important thing is who is your addressable market size? I'm working 
with a startup IXP and there's only 20 carriers in the building. A chassis 
based switch would be silly as there would never be that many people present. 
2x 1U switches would be more than plenty in their environment.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com



- Original Message -

From: "Manuel Marín" 
To: nanog@nanog.org
Sent: Monday, January 12, 2015 12:35:15 AM
Subject: Recommended L2 switches for a new IXP

Dear Nanog community

We are trying to build a new IXP in some US Metro areas where we have
multiple POPs and I was wondering what do you recommend for L2 switches. I
know that some IXPs use Nexus, Brocade, Force10 but I don't personally have
experience with these switches. It would be great if you can share your
experience and recommendations. There are so many options that I don't know
if it makes sense to start with a modular switch (usually expensive because
the backplane, dual dc, dual CPU, etc) or start with a 1RU high density
switch that support new protocols like Trill and that supposedly allow you
to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G
ports for exchange participants, 40G/100G for uplinks between switches and
flow support for statistics and traffic analysis.

Thank you and have a great day.

Regards




--

Aaron Wendel
Chief Technical Officer
Wholesale Internet, Inc. (AS 32097)
(816)550-9030
http://www.wholesaleinternet.com

Re: Recommended L2 switches for a new IXP

[Justin Wilson - MTIN]

Like Mike says, it depends on your market.   Are these markets where there are 
existing exchanges? 

Cost per port is what we always look at.  If we are going into a market where 
there won’t be much growth we look at Cisco and Force 10.  Their cost per port 
is usually cheaper for smaller 10 Gig switches. You need something that is 
fairly robust.

Reliability in an exchange is a key component.  If you go with a non-chassis 
switch make sure you have redundancy in your design.  We like Chassis based 
switches because they tend to be more robust.  But thats just my take on it.

Justin

---
Justin Wilson j...@mtin.net
http://www.mtin.net
Managed Services – xISP Solutions – Data Centers
http://www.thebrotherswisp.com 
Podcast about xISP topics
http://www.midwest-ix.com
Peering – Transit – Internet Exchange 

> On Jan 12, 2015, at 10:24 AM, Aaron  wrote:
> 
> We used to use Brocade FastIrons until we needed more 10G port density.  We 
> moved to Brocade SX's.
> 
> Originally, when it was 2 or 3 peers, we used an old Netgear switch. :)
> 
> Aaron
> 
> On 1/12/2015 7:07 AM, Mike Hammett wrote:
>> I look forward to this thread.
>> 
>> I think one important thing is who is your addressable market size? I'm 
>> working with a startup IXP and there's only 20 carriers in the building. A 
>> chassis based switch would be silly as there would never be that many people 
>> present. 2x 1U switches would be more than plenty in their environment.
>> 
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> 
>> 
>> - Original Message -
>> 
>> From: "Manuel Marín" 
>> To: nanog@nanog.org
>> Sent: Monday, January 12, 2015 12:35:15 AM
>> Subject: Recommended L2 switches for a new IXP
>> 
>> Dear Nanog community
>> 
>> We are trying to build a new IXP in some US Metro areas where we have
>> multiple POPs and I was wondering what do you recommend for L2 switches. I
>> know that some IXPs use Nexus, Brocade, Force10 but I don't personally have
>> experience with these switches. It would be great if you can share your
>> experience and recommendations. There are so many options that I don't know
>> if it makes sense to start with a modular switch (usually expensive because
>> the backplane, dual dc, dual CPU, etc) or start with a 1RU high density
>> switch that support new protocols like Trill and that supposedly allow you
>> to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G
>> ports for exchange participants, 40G/100G for uplinks between switches and
>> flow support for statistics and traffic analysis.
>> 
>> Thank you and have a great day.
>> 
>> Regards
>> 
>> 
> 
> -- 
> 
> Aaron Wendel
> Chief Technical Officer
> Wholesale Internet, Inc. (AS 32097)
> (816)550-9030
> http://www.wholesaleinternet.com
> 
> 

Re: Recommended L2 switches for a new IXP

[Nick Hilliard]

On 12/01/2015 06:35, Manuel Marín wrote:
> We are trying to build a new IXP in some US Metro areas where we have
> multiple POPs and I was wondering what do you recommend for L2 switches. I
> know that some IXPs use Nexus, Brocade, Force10 but I don't personally have
> experience with these switches. It would be great if you can share your
> experience and recommendations.

For a startup IXP, it would probably not be sensible to use chassis based
kit due to cost / real estate issues.

Some personal opinions:

- I have a strong preference for using only open bridging protocols.  This
excludes out vendor proprietary fabrics (VDX, OTV, etc).  This is important
for when you do fabric upgrades on multi-site IXPs.

- You will probably want a product which supports sflow, as peer-to-peer
traffic graphs are massively useful.  Most vendors support sflow on most of
their products with the notable exception of Cisco where only the Nexus 3K
team were enlightened enough to shim it in.  I haven't yet come across a L2
netflow implementation which works well enough to be an adequate
substitute, but ymmv.

- VPLS based fabrics may be important if you have an interesting topology.
 If it is important to you, then you will need a VPLS implementation which
will do proper load balancing over multiple links.  Most don't and this is
a very hard problem to handle on smaller kit.

- There is no excuse for vendor transceiver locking or transceiver
crippling (e.g. refusing to show DDM values) and vendors who do this need
to be made aware that it's not an acceptable business proposition.

- you need kit which will support Layer 2 ACLs and Layer 3 ACLs on layer 2
interfaces.

- you should get in with the open-ix crowd and chat to people over pizza or
peanuts.  You will learn a lot from in an afternoon of immersion with peers.

Nick

Re: Recommended L2 switches for a new IXP

[Martin Hannigan]

Substantial amounts of hive mind went into this topic in the formation of
Open-IX and particularly around optimizing costs and maximizing traffic.
See http://bit.ly/N-OIX1 for a reference.

Best,

-M<




On Mon, Jan 12, 2015 at 10:34 AM, Justin Wilson - MTIN 
wrote:

> Like Mike says, it depends on your market.   Are these markets where there
> are existing exchanges?
>
> Cost per port is what we always look at.  If we are going into a market
> where there won't be much growth we look at Cisco and Force 10.  Their cost
> per port is usually cheaper for smaller 10 Gig switches. You need something
> that is fairly robust.
>
> Reliability in an exchange is a key component.  If you go with a
> non-chassis switch make sure you have redundancy in your design.  We like
> Chassis based switches because they tend to be more robust.  But thats just
> my take on it.
>
> Justin
>
> ---
> Justin Wilson j...@mtin.net
> http://www.mtin.net
> Managed Services - xISP Solutions - Data Centers
> http://www.thebrotherswisp.com
> Podcast about xISP topics
> http://www.midwest-ix.com
> Peering - Transit - Internet Exchange
>
> > On Jan 12, 2015, at 10:24 AM, Aaron  wrote:
> >
> > We used to use Brocade FastIrons until we needed more 10G port density.
> We moved to Brocade SX's.
> >
> > Originally, when it was 2 or 3 peers, we used an old Netgear switch. :)
> >
> > Aaron
> >
> > On 1/12/2015 7:07 AM, Mike Hammett wrote:
> >> I look forward to this thread.
> >>
> >> I think one important thing is who is your addressable market size? I'm
> working with a startup IXP and there's only 20 carriers in the building. A
> chassis based switch would be silly as there would never be that many
> people present. 2x 1U switches would be more than plenty in their
> environment.
> >>
> >>
> >>
> >>
> >> -
> >> Mike Hammett
> >> Intelligent Computing Solutions
> >> http://www.ics-il.com
> >>
> >>
> >>
> >> - Original Message -
> >>
> >> From: "Manuel Marín" 
> >> To: nanog@nanog.org
> >> Sent: Monday, January 12, 2015 12:35:15 AM
> >> Subject: Recommended L2 switches for a new IXP
> >>
> >> Dear Nanog community
> >>
> >> We are trying to build a new IXP in some US Metro areas where we have
> >> multiple POPs and I was wondering what do you recommend for L2
> switches. I
> >> know that some IXPs use Nexus, Brocade, Force10 but I don't personally
> have
> >> experience with these switches. It would be great if you can share your
> >> experience and recommendations. There are so many options that I don't
> know
> >> if it makes sense to start with a modular switch (usually expensive
> because
> >> the backplane, dual dc, dual CPU, etc) or start with a 1RU high density
> >> switch that support new protocols like Trill and that supposedly allow
> you
> >> to create Ethernet Fabric/Clusters. The requirements are simple, 1G/10G
> >> ports for exchange participants, 40G/100G for uplinks between switches
> and
> >> flow support for statistics and traffic analysis.
> >>
> >> Thank you and have a great day.
> >>
> >> Regards
> >>
> >>
> >
> > --
> > 
> > Aaron Wendel
> > Chief Technical Officer
> > Wholesale Internet, Inc. (AS 32097)
> > (816)550-9030
> > http://www.wholesaleinternet.com
> > 
> >
>
>

Re: Recommended L2 switches for a new IXP

[Bill Woodcock]

> On Jan 12, 2015, at 10:34 AM, Justin Wilson - MTIN  wrote:
> Cost per port is what we always look at.  If we are going into a market where 
> there won’t be much growth we look at Cisco and Force 10.  Their cost per 
> port is usually cheaper for smaller 10 Gig switches. You need something that 
> is fairly robust.

We see a lot of IXPs being formed or upgrading with Cisco Nexus 3524 switches, 
which have 48 1G-10G SFP/SFP+ physical ports, license-limited to 24 active, 
upgradeable to 48 active.

FWIW, 83% of IXPs have 48 or fewer participants, and 70% of IXPs have 24 or 
fewer participants.  And the failure rate of chassis-based switches is _way_ 
higher than that of stand-alone switches.  So we never recommend that an IXP 
buy a switch larger than necessary to accommodate 18 months 
reasonably-projectable growth.

-Bill






signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Recommended L2 switches for a new IXP

[Martin Hannigan]

On Mon, Jan 12, 2015 at 10:43 AM, Nick Hilliard  wrote:


[ clip, good stuff ]


- you should get in with the open-ix crowd and chat to people over pizza or
> peanuts.  You will learn a lot from in an afternoon of immersion with
> peers.
>


And you can find that crowd here
http://mailman.open-ix.org/mailman/listinfo/public if interested.

Best,

-M<

129.250.35.250/251 NTT DNS Instability

[A MEKKAOUI]

Hi

 

We've seen some DNS instability and want to know if anyone of you have seen
the same thing. Your comments will be appreciated.

 

Thank you

 

Karim

 

Re: 129.250.35.250/251 NTT DNS Instability

[Jared Mauch]

Can you give examples?  129.250.35.250/251 are anycasted so a trace route would 
be helpful as well.

- jared

> On Jan 12, 2015, at 11:17 AM, A MEKKAOUI  wrote:
> 
> Hi
> 
> 
> 
> We've seen some DNS instability and want to know if anyone of you have seen
> the same thing. Your comments will be appreciated.
> 
> 
> 
> Thank you
> 
> 
> 
> Karim
> 
> 

RE: 129.250.35.250/251 NTT DNS Instability

[A MEKKAOUI]

What we've seen is that this morning some of our clients cannot connect to
internet and when we change the DNS to use Google DNS internet works fine.
I'll see if I can get a tracert to 129.250.35.250 and will send it.

Thank you

A MEKKAOUI
MEKTEL INC
www.mektel.ca


-Original Message-
From: Jared Mauch [mailto:ja...@puck.nether.net] 
Sent: 12 janvier 2015 11:20
To: A MEKKAOUI
Cc: nanog@nanog.org
Subject: Re: 129.250.35.250/251 NTT DNS Instability

Can you give examples?  129.250.35.250/251 are anycasted so a trace route
would be helpful as well.

- jared

> On Jan 12, 2015, at 11:17 AM, A MEKKAOUI  wrote:
> 
> Hi
> 
> 
> 
> We've seen some DNS instability and want to know if anyone of you have 
> seen the same thing. Your comments will be appreciated.
> 
> 
> 
> Thank you
> 
> 
> 
> Karim
> 
> 

Re: 129.250.35.250/251 NTT DNS Instability

[Ammar Zuberi]

Traceroute from my home connection in Dubai, United Arab Emirates:

traceroute to 129.250.35.250 (129.250.35.250), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  2.293 ms  1.549 ms  7.657 ms
 2  94.203.22.1 (94.203.22.1)  3.281 ms  8.348 ms  8.494 ms
 3  10.39.162.65 (10.39.162.65)  5.722 ms  2.753 ms  4.999 ms
 4  10.171.0.19 (10.171.0.19)  2.780 ms  3.022 ms  3.278 ms
 5  10.100.35.78 (10.100.35.78)  6.344 ms  5.340 ms  5.254 ms
 6  10.44.24.162 (10.44.24.162)  90.120 ms  90.141 ms  92.448 ms
 7  116.51.26.81 (116.51.26.81)  276.227 ms  265.609 ms  368.385 ms
 8  ae-1.r21.sngpsi05.sg.bb.gin.ntt.net (129.250.7.20)  275.509 ms  270.857 ms  
274.100 ms
 9  ae-4.r23.tokyjp01.jp.bb.gin.ntt.net (129.250.7.37)  258.667 ms  265.824 ms  
256.990 ms
10  x.ns.gin.ntt.net (129.250.35.250)  251.302 ms  252.865 ms  255.337 ms

> On Jan 12, 2015, at 8:28 PM, A MEKKAOUI  wrote:
> 
> What we've seen is that this morning some of our clients cannot connect to
> internet and when we change the DNS to use Google DNS internet works fine.
> I'll see if I can get a tracert to 129.250.35.250 and will send it.
> 
> Thank you
> 
> A MEKKAOUI
> MEKTEL INC
> www.mektel.ca
> 
> 
> -Original Message-
> From: Jared Mauch [mailto:ja...@puck.nether.net] 
> Sent: 12 janvier 2015 11:20
> To: A MEKKAOUI
> Cc: nanog@nanog.org
> Subject: Re: 129.250.35.250/251 NTT DNS Instability
> 
> Can you give examples?  129.250.35.250/251 are anycasted so a trace route
> would be helpful as well.
> 
> - jared
> 
>> On Jan 12, 2015, at 11:17 AM, A MEKKAOUI  wrote:
>> 
>> Hi
>> 
>> 
>> 
>> We've seen some DNS instability and want to know if anyone of you have 
>> seen the same thing. Your comments will be appreciated.
>> 
>> 
>> 
>> Thank you
>> 
>> 
>> 
>> Karim
>> 
>> 
> 
> 

Re: DDOS solution recommendation

[Valdis . Kletnieks]

On Mon, 12 Jan 2015 18:06:57 +1100, Mark Andrews said:

> >   The ISP will very likely not see ANY traffic originating from spoofed
> > IP destined to your server.
>
> They will see the reply traffic and will see the acks increasing etc.

Assuming they think to *look* for it.

99.8% of ISPs will get a complaint "Your IP w.x.y.z is sending me spam", drop a
tap on the IP address, see no matching outbound traffic, and hit delete on the
complaint.  They will almost certainly not think to look in something like the
ICMP port unreachable packets the address is sending to some *other* address.
(Remember, the compromised relay machine has to send *very* little info back to
the actual sending box - TCP sequence numbers, maybe windows, and SMTP reply
codes that can be encoded in 1 byte or even less)



pgpB1hT0UxDSM.pgp
Description: PGP signature

Re: DDOS solution recommendation

[Valdis . Kletnieks]

On Sun, 11 Jan 2015 15:08:45 -0600, Mike Hammett said:

> If that were to happen, it'd be for 30 days and it'd be whatever random
> residential account or APNIC address that was doing it. Not really a big 
> loss. 

OK. I'll bite.  When you get home today, blackhole www.google.com for your
home IP address(es) and call us back in 30 days and let us know how big a loss
it is.


pgp_YZu6fi43d.pgp
Description: PGP signature

Re: Google's Safe Browsing Alerts for Network Administrators

[Joe]

I've not found it very usefull. As for Shadowserver.org I really wish folks
trying to save the internet from mis-configurations would stop randomly
scanning networks to fix. These folks are one of many "do-gooders" that are
adding to the traffic being dropped and logged. Its only contibuting to the
daily clutter of problem folk already poking and prodding.

Regards,
-Joe


On Thu, Jan 8, 2015 at 5:54 PM, Frank Bulk  wrote:

Root and ARPA DNSSEC operational message - signature validity period

[Wessels, Duane]

DNSSEC signatures in the Root and ARPA zones were initially given a validity
period of 7 days.  The validity period is being increased to 10 days.

Both the Root and ARPA zones publish their NS RRsets with a TTL of 6 days.
A signature validity period of 7 days means that a root server instance
that is not updated within 24 hours may return NS RRset responses whose
TTL exceeds the signature validity.  This could cause problems for validating
recursive name servers that forward queries through non-validators.  A
longer signature validity provides a longer buffer in the distribution of
these zones.

Note that we are not aware of any cases where the 7 day signature validity
period has caused problems for DNSSEC validators.  This is a precautionary
measure.

As of today, the zones now have the increased validity period.  Please
feel free to contact us with concerns or questions.


signature.asc
Description: Message signed with OpenPGP using GPGMail

RE: Google's Safe Browsing Alerts for Network Administrators

[Frank Bulk]

Thanks for that feedback on Google’s Safe Browsing Alerts.  We’ll have to see 
how that works out for us over time.

 

In regards to ShadowServer, I don’t think they’re randomly scanning networks, 
and neither are folks like OpenResolver – I think it’s pretty systematic, 
albeit from perhaps only a certain point of view on the Internet.  If their 
scans are being dropped and logged, that’s great – that means someone has 
measures in place to mitigate attacks that leverage those UDP protocols.   But 
for those who use their output to better secure their own and clients’ endpoint 
devices, it’s much appreciated.  If it’s really just a drop in the ocean, what 
does it matter to you?

 

Frank

 

From: Joe [mailto:jbfixu...@gmail.com] 
Sent: Monday, January 12, 2015 10:39 AM
To: Frank Bulk
Cc: nanog@nanog.org
Subject: Re: Google's Safe Browsing Alerts for Network Administrators

 

 

I've not found it very usefull. As for Shadowserver.org I really wish folks 
trying to save the internet from mis-configurations would stop randomly 
scanning networks to fix. These folks are one of many "do-gooders" that are 
adding to the traffic being dropped and logged. Its only contibuting to the 
daily clutter of problem folk already poking and prodding. 

 

Regards,

-Joe


 

On Thu, Jan 8, 2015 at 5:54 PM, Frank Bulk mailto:frnk...@iname.com> > wrote:

FL-IX in Miami is ready for new members

[Dave Temkin]

Hi all,


FL-IX has started issuing LOAs for both 36 NE 2nd Street and NOTA in Miami.
If you have a network that peers at either location, we'd love to have you
as a member. We've committed to keeping the IX platform free for 3 years
(you bring the cross connect; we have pre-negotiated deals for inexpensive
riser in 36 NE 2nd).


For more information, please see: http://www.fl-ix.net


Here's a list of who's signed up thus far:


  Akamai

Amazon

BroadbandONE

CloudFlare

Coresite

Facebook

GlobeNet/Oi

Google

GTT

Hurricane Electric

Init7

Limelight

Netflix

Reliable Hosting

Quadranet

Snappy Internet

SoftLayer

T-Mobile

Telx

Vault Networks

WebSense

Yahoo

Regards,
-Dave

Re: DDOS solution recommendation

[Owen DeLong]

> On Jan 11, 2015, at 12:28 , Colin Johnston  wrote:
> 
> unfortunately chinanet antispam/abuse email box is always full, after a while 
> people block .
> always check arin/ripe for known good provider blocks and actively exclude 
> from rules

ARIN and RIPE do not provide address reputation information, so I’m not sure 
what you mean by known good blocks.

Anything you can get from ARIN or RIPE, you would also want to check against 
LACNIC, AfriNIC, and APNIC as each of the 5 RIRs has their own region for which 
they are responsible. If you merely check ARIN and RIPE, you will permit only 
North America (exclusive of Mexico), some Caribbean Islands, Antarctica, and 
Europe. If it is not your intent to completely ignore Asia, Africa, Latin 
America, and about half of the Caribbean, then your above statement needs 
adjustment.

> ddos protection via careful overview ips rules and active web source ip 
> monitoring works well, the hard part is daily rule updates and blocks until 
> you know most traffic is genuine.

This helps with PPS attacks against web servers and certain web exploits. It 
does not help with volumetric attacks. The simple fact is that the only way to 
deal with volumetric attacks is to have them blocked or filtered upstream 
unless you have sufficient ingress capacity to sink the attack traffic volume.

Owen

> 
> colin
> 
> Sent from my iPhone
> 
>> On 11 Jan 2015, at 19:42, "Patrick W. Gilmore"  wrote:
>> 
>> I do love solutions which open larger attack surfaces than they are supposed 
>> to close. In the US, we call that "a cure worse than the disease".
>> 
>> Send packet from random bot with source of Google, Comcast, Akamai, etc. to 
>> Mr. Hammett's not-DNS / honeypot / whatever, and watch him close himself off 
>> from the world.
>> 
>> Voilà! Denial of service accomplished without all the hassle of sending 100s 
>> of Gbps of traffic.
>> 
>> Best part is he was willing to explain this to 10,000+ of his not-so-closest 
>> friends, in a search-engine-indexed manner.
>> 
>> -- 
>> TTFN,
>> patrick
>> 
>>> On Jan 11, 2015, at 14:34 , Phil Bedard  wrote:
>>> 
>>> Many attacks can use spoofed source IPs, so who are you really blocking?  
>>> 
>>> That's why BCP38 as mentioned many times already is a necessary tool in 
>>> fighting the attacks overall.  
>>> 
>>> Phil 
>>> 
>>> 
>>> 
>>> 
 On 1/11/15, 4:33 PM, "Mike Hammett"  wrote:
 
 I didn't necessarily think I was shattering minds with my ideas. 
 
 I don't have the time to read a dozen presentations. 
 
 Blackhole them and move on. I don't care whose feelings I hurt. This 
 isn't kindergarten. Maybe "you" should have tried a little harder to not 
 get a virus in the first place. Quit clicking on male enhancement ads or 
 update your OS occasionally. I'm not going to spend a bunch of time and 
 money to make sure someone's bubble of bliss doesn't get popped. Swift, 
 effective, cheap. Besides, you're only cut off for 30 days. If in 30 days 
 you can prove yourself to be responsible, we can try this again. Well, 
 that or a sufficient support request. 
 
 Besides, if enough people did hat, the list of blackholes wouldn't be 
 huge as someone upstream already blocked them. 
 
 
 
 
 - 
 Mike Hammett 
 Intelligent Computing Solutions 
 http://www.ics-il.com 
 
 
 
 - Original Message -
 
 From: "Roland Dobbins"  
 To: nanog@nanog.org 
 Sent: Sunday, January 11, 2015 9:29:33 AM 
 Subject: Re: DDOS solution recommendation 
 
 
> On 11 Jan 2015, at 22:21, Mike Hammett wrote: 
> 
> I'm not saying what you're doing is wrong, I'm saying whatever the 
> industry as a whole is doing obviously isn't working and perhaps a 
> different approach is required.
 
 You haven't recommended anything new, and you really need to do some 
 reading in order to understand why it isn't as simple as you seem to 
 think it is. 
 
> Security teams? My network has me, myself and I.
 
 And a relatively small network, too. 
 
> If for example ChinaNet's abuse department isn't doing anything about 
> complains, eventually their whole network gets blocked a /32 at a 
> time. *shrugs* Their loss.
 
 Again, it isn't that simple. 
 
 --- 
 Roland Dobbins 
>> 

Re: Recommended L2 switches for a new IXP

[Mark Tinka]

On Monday, January 12, 2015 05:54:38 PM Bill Woodcock wrote:

> We see a lot of IXPs being formed or upgrading with Cisco
> Nexus 3524 switches, which have 48 1G-10G SFP/SFP+
> physical ports, license-limited to 24 active,
> upgradeable to 48 active.
> 
> FWIW, 83% of IXPs have 48 or fewer participants, and 70%
> of IXPs have 24 or fewer participants.  And the failure
> rate of chassis-based switches is _way_ higher than that
> of stand-alone switches.  So we never recommend that an
> IXP buy a switch larger than necessary to accommodate 18
> months reasonably-projectable growth.

Would tend to agree with this approach, and the above.

Multi-rate (i.e., 1Gbps/10Gbps SFP/SFP+) standalone 1U 
switches are reasonable these days. The issue you'll 
probably run into with them is limited support for features 
you find being implemented by larger exchange points (VPLS, 
Sflow, e.t.c.), and quirks with the hardware that could 
impact things like Layer 2 or Layer 3 filtering (especially 
if they are using off-the-self silicon), e.t.c.

Test before you buy, in as far as you can anticipate your 
(growth) needs.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: DDOS solution recommendation

[Brandon Ross]

On Sun, 11 Jan 2015, Mike Hammett wrote:

I know that UDP can be spoofed, but it's not likely that the SSH, mail, 
etc. login attempts, web page hits, etc. would be spoofed as they'd have 
to know the response to be of any good.


Okay, so I'm curious.  Are you saying that you do not automatically block 
attackers until you can confirm a 3-way TCP handshake has been completed, 
and therefore you aren't blocking sources that were spoofed?  If so, 
how are you protecting yourself against SYN attacks?  If not, then you've 
made it quite easy for attackers to deny any source they want.


--
Brandon Ross  Yahoo & AIM:  BrandonNRoss
+1-404-635-6667ICQ:  2269442
 Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross

Re: DDOS solution recommendation

[Christopher Morrow]

On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross  wrote:
> On Sun, 11 Jan 2015, Mike Hammett wrote:
>
>> I know that UDP can be spoofed, but it's not likely that the SSH, mail,
>> etc. login attempts, web page hits, etc. would be spoofed as they'd have to
>> know the response to be of any good.
>
>
> Okay, so I'm curious.  Are you saying that you do not automatically block
> attackers until you can confirm a 3-way TCP handshake has been completed,
> and therefore you aren't blocking sources that were spoofed?  If so, how are
> you protecting yourself against SYN attacks?  If not, then you've made it
> quite easy for attackers to deny any source they want.

this all seems like a fabulous conversation we're watching, but really
.. if someone wants to block large swaths of the intertubes on their
systems it's totally up to them, right? They can choose to not be
functional all they want, as near as I can tell... and arguing with
someone with this mentality isn't productive, especially after several
(10+? folk) have tried to show and tell some experience that would
lead to more cautious approaches.

If mike wants less packets, that's all cool... I'm not sure it's
actually solving anything, but sure, go right ahead, have fun.

-chris

Re: DDOS solution recommendation

[Mike Hammett]

So the preferred alternative is to simply do nothing at all? That seems fair. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



- Original Message -

From: "Christopher Morrow"  
To: "Brandon Ross"  
Cc: "Mike Hammett" , "NANOG list"  
Sent: Monday, January 12, 2015 3:05:14 PM 
Subject: Re: DDOS solution recommendation 

On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross  wrote: 
> On Sun, 11 Jan 2015, Mike Hammett wrote: 
> 
>> I know that UDP can be spoofed, but it's not likely that the SSH, mail, 
>> etc. login attempts, web page hits, etc. would be spoofed as they'd have to 
>> know the response to be of any good. 
> 
> 
> Okay, so I'm curious. Are you saying that you do not automatically block 
> attackers until you can confirm a 3-way TCP handshake has been completed, 
> and therefore you aren't blocking sources that were spoofed? If so, how are 
> you protecting yourself against SYN attacks? If not, then you've made it 
> quite easy for attackers to deny any source they want. 

this all seems like a fabulous conversation we're watching, but really 
.. if someone wants to block large swaths of the intertubes on their 
systems it's totally up to them, right? They can choose to not be 
functional all they want, as near as I can tell... and arguing with 
someone with this mentality isn't productive, especially after several 
(10+? folk) have tried to show and tell some experience that would 
lead to more cautious approaches. 

If mike wants less packets, that's all cool... I'm not sure it's 
actually solving anything, but sure, go right ahead, have fun. 

-chris 

Re: DDOS solution recommendation

[Scott Weeks]

--- na...@ics-il.net wrote:
From: Mike Hammett 

So the preferred alternative is to simply do 
nothing at all? That seems fair. 
---


No, the answer is to find the groups that have 
already looked into the issues, learn what they've
done and see if you can provide quality input to the
group.

scott

RE: Recommended L2 switches for a new IXP

[Tony Wicks]

People seem to be avoiding recommending actual devices, well I would
recommend the Juniper EX4600 -

http://www.juniper.net/us/en/products-services/switching/ex-series/ex4600/

They are affordable, highly scalable, stackable and run JunOS.

cheers

Re: DDOS solution recommendation

[Christopher Morrow]

On Mon, Jan 12, 2015 at 4:35 PM, Mike Hammett  wrote:
> So the preferred alternative is to simply do nothing at all? That seems fair.

fairly certain I didn't say that, no.

I think that lots of smarter-than-me folk have already chimed in with options...
All I wanted to do with this was to note I didn't say 'do nothing'.

-chris

> - Original Message -
>
> From: "Christopher Morrow" 
> To: "Brandon Ross" 
> Cc: "Mike Hammett" , "NANOG list" 
> Sent: Monday, January 12, 2015 3:05:14 PM
> Subject: Re: DDOS solution recommendation
>
> On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross  wrote:
>> On Sun, 11 Jan 2015, Mike Hammett wrote:
>>
>>> I know that UDP can be spoofed, but it's not likely that the SSH, mail,
>>> etc. login attempts, web page hits, etc. would be spoofed as they'd have to
>>> know the response to be of any good.
>>
>>
>> Okay, so I'm curious. Are you saying that you do not automatically block
>> attackers until you can confirm a 3-way TCP handshake has been completed,
>> and therefore you aren't blocking sources that were spoofed? If so, how are
>> you protecting yourself against SYN attacks? If not, then you've made it
>> quite easy for attackers to deny any source they want.
>
> this all seems like a fabulous conversation we're watching, but really
> .. if someone wants to block large swaths of the intertubes on their
> systems it's totally up to them, right? They can choose to not be
> functional all they want, as near as I can tell... and arguing with
> someone with this mentality isn't productive, especially after several
> (10+? folk) have tried to show and tell some experience that would
> lead to more cautious approaches.
>
> If mike wants less packets, that's all cool... I'm not sure it's
> actually solving anything, but sure, go right ahead, have fun.
>
> -chris
>

Re: DDOS solution recommendation

[Roland Dobbins]

On 13 Jan 2015, at 4:35, Mike Hammett wrote:


So the preferred alternative is to simply do nothing at all?


Straw man.

Nobody's said that.  Quite the opposite, in point of fact.

As noted previously in this thread, there's a lot of information out 
there about how operators deal with DDoS attacks.  All it takes is the 
willingness to devote a bit of time to educating oneself.


---
Roland Dobbins 

Re: Recommended L2 switches for a new IXP

[Mehmet Akcin]

That's what I had recommended him directly ;)

Mehmet 

> On Jan 12, 2015, at 1:41 PM, Tony Wicks  wrote:
> 
> People seem to be avoiding recommending actual devices, well I would
> recommend the Juniper EX4600 -
> 
> http://www.juniper.net/us/en/products-services/switching/ex-series/ex4600/
> 
> They are affordable, highly scalable, stackable and run JunOS.
> 
> cheers
> 
> 
> 

Re: Recommended L2 switches for a new IXP

[Christopher Morrow]

On Mon, Jan 12, 2015 at 4:41 PM, Tony Wicks  wrote:
> People seem to be avoiding recommending actual devices, well I would
> recommend the Juniper EX4600 -
>
> http://www.juniper.net/us/en/products-services/switching/ex-series/ex4600/
>
> They are affordable, highly scalable, stackable and run JunOS.

(and you can't do anything worthwhile for acls to protect that device
from the world/ix-users)

Re: DDOS solution recommendation

[William F. Maton Sotomayor]

On Mon, 12 Jan 2015, Mike Hammett wrote:


So the preferred alternative is to simply do nothing at all? That seems fair.


Not at all.  But it is your network and only you know what the suggested 
approaches others have already run through are best for your environment.


But if you haven't yet done so, help the rest of us and deploy BCP38 too. :-)







-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com



- Original Message -

From: "Christopher Morrow" 
To: "Brandon Ross" 
Cc: "Mike Hammett" , "NANOG list" 
Sent: Monday, January 12, 2015 3:05:14 PM
Subject: Re: DDOS solution recommendation

On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross  wrote:

On Sun, 11 Jan 2015, Mike Hammett wrote:


I know that UDP can be spoofed, but it's not likely that the SSH, mail,
etc. login attempts, web page hits, etc. would be spoofed as they'd have to
know the response to be of any good.



Okay, so I'm curious. Are you saying that you do not automatically block
attackers until you can confirm a 3-way TCP handshake has been completed,
and therefore you aren't blocking sources that were spoofed? If so, how are
you protecting yourself against SYN attacks? If not, then you've made it
quite easy for attackers to deny any source they want.


this all seems like a fabulous conversation we're watching, but really
.. if someone wants to block large swaths of the intertubes on their
systems it's totally up to them, right? They can choose to not be
functional all they want, as near as I can tell... and arguing with
someone with this mentality isn't productive, especially after several
(10+? folk) have tried to show and tell some experience that would
lead to more cautious approaches.

If mike wants less packets, that's all cool... I'm not sure it's
actually solving anything, but sure, go right ahead, have fun.

-chris



wfms

Re: DDOS solution recommendation

[Max Clark]

Ditto - we've been seeing average attack size pushing the 40-50 Gbps mark.
The "serious" attacks are much, much larger.

On Sat, Jan 10, 2015 at 8:50 PM, Ammar Zuberi  wrote:

> I'd beg to differ on this one. The average attacks we're seeing are double
> that, around the 30-40g mark. Since NTP and SSDP amplification began, we've
> been seeing all kinds of large attacks.
>
> Obviously, these can easily be blocked upstream to your network. Hibernia
> Networks blocks them for us.
>
> Ammar
>
> > On 11 Jan 2015, at 8:37 am, Paul S.  wrote:
> >
> > While it indeed is true that attacks up to 600 gbit/s (If OVH and
> CloudFlare's data is to be believed) have been known to happen in the wild,
> it's very unlikely that you need to mitigate anything close.
> >
> > The average attack is usually around the 10g mark (That too barely) --
> so even solutions that service up to 20g work alright.
> >
> > Obviously, concerns are different if you're an enterprise that's a DDoS
> magnet -- but for general service providers selling 'protected services,'
> food for thought.
> >
> >> On 1/11/2015 午後 12:48, Damian Menscher wrote:
> >>> On Thu, Jan 8, 2015 at 9:01 AM, Manuel Marín 
> wrote:
> >>>
> >>> I was wondering what are are using for DDOS protection in your
> networks. We
> >>> are currently evaluating different options (Arbor, Radware, NSFocus,
> >>> RioRey) and I would like to know if someone is using the cloud based
> >>> solutions/scrubbing centers like Imperva, Prolexic, etc and what are
> the
> >>> advantages/disadvantages of using a cloud base vs an on-premise
> solution.
> >>> It would be great if you can share your experience on this matter.
> >> On-premise solutions are limited by your own bandwidth.  Attacks have
> been
> >> publicly reported at 400Gbps, and are rumored to be even larger.  If you
> >> don't have that much network to spare, then packet loss will occur
> upstream
> >> of your mitigation.  Having a good relationship with your network
> >> provider(s) can help here, of course.
> >>
> >> If you go with a cloud-based solution, be wary of their SLA.  I've seen
> >> some claim 100% uptime (not believable) but of course no refund/credits
> for
> >> downtime.  Another provider only provides 20Gbps protection, then will
> >> null-route the victim.
> >>
> >>> On Sat, Jan 10, 2015 at 4:19 PM, Charles N Wyble 
> wrote:
> >>>
> >>> Also how are folks testing ddos protection? What lab gear,tools,methods
> >>> are you using to determine effectiveness of the mitigation.
> >>
> >> Live-fire is the cheapest approach (just requires some creative
> trolling)
> >> but if you want to control the "off" button, cloud VMs can be tailored
> to
> >> your needs.  There are also legitimate companies that do network stress
> >> testing.
> >>
> >> Keep in mind that you need to test against a variety of attacks, against
> >> all components in the critical path.  Attackers aren't particularly
> >> methodical, but will still randomly discover any weaknesses you've
> >> overlooked.
> >>
> >> Damian
> >
>

Re: DDOS solution recommendation

[Scott Fisher]

In looking at this thread, it's apparent that some are trying to
over-simplify a not-so-simple problem. As someone brought out earlier,
there is no silver bullet to fix for several reasons. Some reasons
that I can come up with at the top of my head are:

1) DDOS types vary.
2) Not every network is the same (shocker I know)
3) Time/Money - not every company has the same budget (again, shocker)
4) Staff/Resources - Not every company have admin/engineers at
different technical levels. So someone may decide on blocking an
attack at different levels because "that's what they know." EG:
wordpress guy blocks attacks at the webserver level, an admin blocks
it at the system, network admin at the edge.


The questions should be much more narrow. "How should I mitigate an
NTP reflection" or "what are common mistakes people make when
mitigating attacks" are questions that more specific that all can
glean from.

Thanks,
Scott

On Mon, Jan 12, 2015 at 4:35 PM, Mike Hammett  wrote:
> So the preferred alternative is to simply do nothing at all? That seems fair.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> - Original Message -
>
> From: "Christopher Morrow" 
> To: "Brandon Ross" 
> Cc: "Mike Hammett" , "NANOG list" 
> Sent: Monday, January 12, 2015 3:05:14 PM
> Subject: Re: DDOS solution recommendation
>
> On Mon, Jan 12, 2015 at 3:17 PM, Brandon Ross  wrote:
>> On Sun, 11 Jan 2015, Mike Hammett wrote:
>>
>>> I know that UDP can be spoofed, but it's not likely that the SSH, mail,
>>> etc. login attempts, web page hits, etc. would be spoofed as they'd have to
>>> know the response to be of any good.
>>
>>
>> Okay, so I'm curious. Are you saying that you do not automatically block
>> attackers until you can confirm a 3-way TCP handshake has been completed,
>> and therefore you aren't blocking sources that were spoofed? If so, how are
>> you protecting yourself against SYN attacks? If not, then you've made it
>> quite easy for attackers to deny any source they want.
>
> this all seems like a fabulous conversation we're watching, but really
> .. if someone wants to block large swaths of the intertubes on their
> systems it's totally up to them, right? They can choose to not be
> functional all they want, as near as I can tell... and arguing with
> someone with this mentality isn't productive, especially after several
> (10+? folk) have tried to show and tell some experience that would
> lead to more cautious approaches.
>
> If mike wants less packets, that's all cool... I'm not sure it's
> actually solving anything, but sure, go right ahead, have fun.
>
> -chris
>



-- 
Scott

Re: DDOS solution recommendation

[Roland Dobbins]

On 13 Jan 2015, at 4:51, Scott Fisher wrote:

The questions should be much more narrow. "How should I mitigate an 
NTP reflection" or "what are common mistakes people make when 
mitigating attacks" are questions that more specific that all can 
glean from.


The answers to a lot of those questions are right here:



In fact, they're discussed in this single presentation:



There are lots more resources available elsewhere on the Internet, as 
well.


We all just need to invest the time to learn from the experiences of 
others, so that we can then make our own contributions starting from a 
firm foundation.


---
Roland Dobbins 

Re: Recommended L2 switches for a new IXP

[Mark Tinka]

On Monday, January 12, 2015 11:41:20 PM Tony Wicks wrote:

> People seem to be avoiding recommending actual devices,
> well I would recommend the Juniper EX4600 -
> 
> http://www.juniper.net/us/en/products-services/switching/
> ex-series/ex4600/
> 
> They are affordable, highly scalable, stackable and run
> JunOS.

We've been quite happy with the EX4550, but the EX4600 is 
good too, particularly if you're coming from its younger 
brother.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Office 365 Expert - I am not. I have a customer that...

[Jimmy Hess]

Dave Pooser  wrote:
> then they are currently gaining from customers who would *not* move away
> from on-prem if they understood all the costs including increased
> bandwidth?

The extra bandwidth needed to utilize most SaaS-based applications is
not significant. I would say the larger problems in some cases would
be the increase in end-to-end latency.

SaaS apps seem most sensible where rapid deployment is desired,  where
the number of users and amount of data are low.

In other cases, there are concerns about the additional vendor
lock-in, loss of strong control of the data.   Cannot assure that it
is encrypted and secure against access by social engineering attacks
against SaaS provider.  Vendors can increase monthly rates later,
after it becomes much harder to switch to an on-prem option. The
list of security hazards expands.   Cannot mitigate application
downtime caused by problems with vendor infrastructure  or  failure of
vendor  to backup data like they promised.

On Mon, Jan 12, 2015 at 9:07 AM, Bob Evans  wrote:

> In the meantime, I can tell you sitting here in silicon valley that all
> these sharp VCs don't see the hole in many of these basic business plans
> called "Cloud, Rack of servers in multiple locations".

Well, I cannot fault those folks for trying, or VCs from dabbling in
Buzzword-Driven financing and risky ventures. Even if there actually
are gaping holes in respective plans that they are accepting:  they
are playing a high-rewards game,  and likely have their odds all
calculated.

2 or 3% of those 'cloud,rack of servers' people may very well manage
to pull off some tricky in-flight maneuvers to escape whichever
perceived hole, or come to realize the "fix" after starting with
otherwise inherently flawwed plans.. just having a flawwed enough plan
was still good enough in theory to show a starting point.

Any plan will essentially have holes of varying sizes,  with varying
amounts of camouflage.

But the results of following a plan with holes are not necessarily
disastrous...  so long as what is actually done is adapted later  in
place of the original plan as required, in order to accommodate
realities.


> Bob Evans
> CTO
--
-JH