Barry, have I summed up your points correctly below"
1) You can't do nothing because as access link speeds increase at a
greater rate than aggregation of core link speeds there is an
unacceptable risk that single digit numbers of users will cause
significant link saturation.
2) You can't filter at the edge because in most cases you don't own
the edge. You don't own the CPE in any meaningful way, nor do you own
the access network. By the time the traffic arrives at your handover
it's already causing you problems.
3) There needs to be some way to remotely disconnect customers at L2,
in the access network, who are causing issues.
Macca, your points are:
1) The environment is fundamentally different than it was in the
past. Single digit numbers of home users have not historically had
the ability to cause substantial issues in table resource, CPU and
memory across the access, aggregation and core networks.
2) The only way to mitigate this is to limit what the end users are
able to do from a service point of view "unfiltered and unfettered
provision of default residential services is coming to an end"
Have I missed anything?
On Tue, Nov 4, 2014 at 7:13 PM, Barry Murphy
I don¹t believe this to be true, you can¹t just police the users data at the access port, the data is already consuming the full capacity of the connection before you can police it, your policing will do nothing. You¹d need chorus to do the policing before it reached you which is not likely as it¹s a layer 2 service, so you¹d have to police at the egress of each CPE, if you were in control of it.
I understand (and we do it) that you can scan your own network, detect where open relays or open DNS servers are and firewall on your ingress from transit and peering upstreams to ensure the downstream clients aren¹t the source of the attack, but it simply takes one nasty worm someone wasn¹t expecting and you haven¹t blocked and bam your 10gig is full, the only fix is to disconnect the affected users you cannot police them.
While there is cheap tin these days such as mikrotiks, second hand ciscos or junipers etc for the small entrants of sub 500 users. To get scale you need big devices that can scale in size to support 100,000+ subscribers like what we use, Alcatel Lucent 7750. Your cost per 10G port is around $15k USD per port, this considering you¹ve already spent around $100k on the chassis. While these prices may seem like nothing to the likes of Telecom or Vodafone, majority of those on the list that operate an ISP, adding an extra 10G handover for a UFB location at $10-15k plus backhaul is not really cheap I don¹t believe, not when you¹re competing with mass market products where people are price conscious. While we don¹t compete for such services, some of our wholesalers do, at the end of the day we have to point out the quantity vs quality points for them to understand.
The problem still lies, if you have a 10gig handover and you have 10 infected downstream customers that have 1Gbps access circuits pumping out 1gbps of data, they can easily consume the size of the handover and affect everyone else on that handover until you disconnect their session. With the theoretical maximum capacity being 80Gbps per region (say telecom can have a maximum of 80Gbps to service the whole of auckland), it would only take 80 of their 100¹s of thousands of customers to consume all their Auckland region UFB handover. With the amount of data Telecom would be passing through their routers consuming 80gbps of data, it would take some time for some one to pick those 80 infected customers our of 100,000 customers and then disconnect each, all while the 100,000 other customers have packet loss and bad connectivity.
I guess the fix is to have 100gbps handovers, but even then these would likely go into aggregation switches then back to the BNG/BRAS, you¹d have to have multiple 100gbps handovers directly into your BNG/BRAS.
Kind regards, Barry Murphy / Chief Operating Officer
From: Kris Price
Date: Tuesday, 4 November 2014 5:17 pm Cc: nznog Subject: Re: [nznog] UFB 1 gig plans for retail and impact they have There are networks out there that cope with these issues. Develop means to monitor and detect DDoS and police users in near real time at the access port. Think about what happens when someone tries to launch a DDoS from a cloud provider.
The related aspect to this is we can, if we choose provide very high amounts of bandwidth with very low over sub ratios. Network equipment is now a commodity. Provided you have the fiber you can light vast amounts of bandwidth for surprisingly low cost, not just in the access but also the long haul.
Sent from my mobile
On Nov 3, 2014, at 6:23 PM, McDonald Richards
wrote: Sure - we had the conversation then, when 1.5Mbit of saturation didn't also exhaust firewall state tables, CPU and memory resources of everything in the service path.
What we do have now, that we didn't have then, are bot-nets for hire and parties who intentionally exploit, infect, test and document these hosts for hire as weapons while the end users in a lot of cases have no idea that it's happening outside of a slower Internet connection.
On Mon, Nov 3, 2014 at 5:53 PM, Jeremy Visser
wrote: On 03/11/14 22:26, McDonald Richards wrote:
The days of the "any to any, open Internet" are slowly coming to an end. One small flaw in one mass produced and mass distributed piece of software (including software that runs on CPE) can easily snowball into hundreds of gigabits of traffic at the "core" of the Internet (I hate that term but I'm too tired to come up with anything else right now).
We had this same conversation when people started moving from dial-up to DSL.
"OMG a single user on 1.5 Mbit/s can saturate our entire server farm bandwidth"
The world didn't end. The same rules apply today that applied back then. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog