SMF Tie Cable Standards for Data Center Applications
In our new data center builds we're transitioning from MMF to SMF for the tie cabling between networking gear in the MDF/IDF racks to the server racks. Today those interconnects are short (under 100 meters) 10GE and 40GE-LX4 over MMF. We’re transitioning to SMF to support services beyond that, such as 100GBASE-LR4. Would G.652.D be the right specification for the infrastructure tie cabling? Are there other considerations around this? Thank you
Re: syn flood attacks from NL-based netblocks
On Mon, Aug 19, 2019, 9:24 PM Florian Brandstetter wrote: > Load balancing is done on Layer 4 or Layer 3 when routing, so your > ingress connection will have the same hash as the outgoing connection > (unless the source port of the connection changes on the ACK - which it > really should not). > If the hash is symmetric, yes. No wonder topology issues would have more impact, my point was that there are also other things to look at here. -- Töma >
Re: syn flood attacks from NL-based netblocks
On Mon, Aug 19, 2019, 9:27 PM Valdis Klētnieks wrote: > On Mon, 19 Aug 2019 21:18:49 +0300, Töma Gavrichenkov said: > > > If you're doing load balancing for *outgoing* traffic — and in exactly > the > > same manner as you do with incoming — then maybe. > > On the other hand, your servers should probably be doing non-loadbalanced > outbound on a different IP address than the inbound load balancer, and > thus the > syn-ack should have zero trouble getting back to the box it thought the syn > came from. > Killing it with the packet rate in the process? I assume this is about time to start drawing diagrams, otherwise we'll be quickly lost in context. -- Töma >
Re: syn flood attacks from NL-based netblocks
On Mon, 19 Aug 2019 21:18:49 +0300, T�ma Gavrichenkov said: > If you're doing load balancing for *outgoing* traffic — and in exactly the > same manner as you do with incoming — then maybe. On the other hand, your servers should probably be doing non-loadbalanced outbound on a different IP address than the inbound load balancer, and thus the syn-ack should have zero trouble getting back to the box it thought the syn came from. pgpZQ9VCs8QPy.pgp Description: PGP signature
Re: syn flood attacks from NL-based netblocks
On Mon, Aug 19, 2019, 8:57 PM Valdis Klētnieks wrote: > On Mon, 19 Aug 2019 20:44:47 +0300, Töma Gavrichenkov said: > > > Not in a typical DC/ISP environment! With the solution you propose, a > > perfect routing symmetry is a hard requirement, b/c you need to make > > sure a returning SYN/ACK hits the very same machine as the initial > > SYN. > > If your load balancer isn't doing something to make that situation work > properly, > you need to talk to your vendor. > If you're doing load balancing for *outgoing* traffic — and in exactly the same manner as you do with incoming — then maybe. This also assumes that instead of mitigating an attack near the border you set up and keep an internal cluster of filtering machines somewhere and route, in the worst case scenario, *all* of your traffic through that cluster. Depending on the size of your network, it might or might not be an effective solution. -- Töma >
Re: syn flood attacks from NL-based netblocks
On Mon, 19 Aug 2019 20:44:47 +0300, T�ma Gavrichenkov said: > Not in a typical DC/ISP environment! With the solution you propose, a > perfect routing symmetry is a hard requirement, b/c you need to make > sure a returning SYN/ACK hits the very same machine as the initial > SYN. If your load balancer isn't doing something to make that situation work properly, you need to talk to your vendor. pgpeMouZOG2zD.pgp Description: PGP signature
Re: syn flood attacks from NL-based netblocks
On Mon, Aug 19, 2019 at 8:12 PM Damian Menscher wrote: > A factor of 2 is "rounding error" and we probably shouldn't > waste our time on it (eg, by designing solutions to reduce > amplification factors) when we could instead be targeting > the sources of spoofed traffic. Ah, fine. Spoofing is obviously the root cause here. I was mostly addressing the statement that factors of 2 to 5 aren't "particularly interesting for attackers or defenders". In my experience they certainly are. > this particular "carpet-bombing" attack isn't likely to be > mitigated at the network layer anyway... the load is > distributed across thousands of machines which can > each trivially handle the state. Not in a typical DC/ISP environment! With the solution you propose, a perfect routing symmetry is a hard requirement, b/c you need to make sure a returning SYN/ACK hits the very same machine as the initial SYN. As long as you expect a DDoS to be handled somewhere close to the border of your network, this is hardly achievable for a network growing in size. -- Töma
Re: syn flood attacks from NL-based netblocks
On Mon, Aug 19, 2019 at 4:15 AM Töma Gavrichenkov wrote: > Dealing with TCP flags is a different story: > I agree these attacks can be large: the one under discussion probably exceeded 10Mpps (Gbps is the wrong metric for small-packet attacks) I agree they can cause significant outages: this style of attack played a role in the Liberia outages in 2016 My main disagreement is whether small amplification factors are noteworthy. A factor of 2 is "rounding error" and we probably shouldn't waste our time on it (eg, by designing solutions to reduce amplification factors) when we could instead be targeting the sources of spoofed traffic. I was highlighting this as a DDoS (rather than a port scan) mainly to raise awareness. This is definitely an interesting form of attack, largely for the reasons you state (it's subtle to detect and therefore harder to mitigate). But this particular "carpet-bombing" attack isn't likely to be mitigated at the network layer anyway... the load is distributed across thousands of machines which can each trivially handle the state. It's more a question of bandwidth to the provider... and if you're targeting the provider's bandwidth you'd do better to use traditional UDP amplification. Damian
Re: syn flood attacks from NL-based netblocks
Peace, On Mon, Aug 19, 2019 at 7:39 AM Damian Menscher via NANOG wrote: > Most kernels will return 3-5 SYN-ACK packets for an incoming > SYN, so it's not particularly interesting for attackers or defenders. Well, producing 1000 Gbps as opposed to 200 Gbps is still pretty impressive, isn't it? More on that later, b/c the point here aren't even jiggabits, > it's somewhat pointless to worry about a small amplification > factor -- an attacker could [..] use UDP to get a massive > bandwidth (or even significant packet) amplification. Most of the resources hosted by a typical hosting company are essentially Web sites.[citation needed] Unless you are really really dependant on QUIC (and, unless we're all really unlucky and recent initiatives to get rid of TCP/TLS fallback in HTTP/3 would gain support), as a Web hosting company, you can use whatever you want to get rid of UDP completely very quickly, and that won't harm your business a lot. Dealing with TCP flags is a different story: - Your ability to handle them with the likes of RFC 5575 depend on what particular sort of equipment is deployed in your network; - To make matters worse, for a huge portion of customers the ability to connect to an external service/API gateway/Web site via TCP is crucial. A simple example is Google which cannot survive for long if Googlebot keeps being unable to operate. Think also OAuth, Skyscanner, credit scoring systems, insurance companies, etc.; - To ensure proper handling of spoofed SYN/ACKs while still maintaining a possibility to connect to an external service you, as a hosting company under an attack, would have to track all of the outgoing SYNs to match them against received SYN/ACKs later. This is where the "1kGbps-vs-200Gbps" argument becomes important, b/c every existing free connection state tracking solution doesn't scale beyond 200 Gbps at best given the best hardware money can buy given a single machine, and no existing solution is able to share its state across multiple machines. [there are proprietary products doing that though, we have one, but proprietary solutions are always a different kind of story] -- Töma
Re: syn flood attacks from NL-based netblocks
Peace, On Sun, Aug 18, 2019 at 6:48 PM Mike wrote: > [..] I do have an idea > that may be potentially a good mitigation strategy and for the exact > reason stated above; low load to individual end points may still, in > aggregate, overwhelm an IX or provider, so cutting off the SYN-ACK > traffic to those hosts which have not requested connections is good > internet hygiene... In theory, yes, but it's incredibly complicated to do that properly at scale. > My idea is to maintain a penaltybox for any client IP that initiated a > connection but did not complete, while also maintaining a whitelist of > 'frequent fliers' who have previously completed their connections > successful. Unless a connection is completed, you do not know if the source IP address of your client is spoofed or not. (Under certain circumstances you don't know it even then, but it is unlikely that you would have to take such a possibiity into account). Therefore, you should not populate anything in your RAM from such a source. See also my short talk from RIPE 77 for more information: - https://ripe77.ripe.net/presentations/154-ddoswww_ripe77_004.pdf - https://ripe77.ripe.net/archives/video/2336/ Also, odds are a whitelist won't help either. > While looking around, I came across the SYNPROXY netfilter module. Not sure if it's still supported. I think I've read in LKML that it was dropped since Linux 4.4. Anyhow, it's impossible to scale without a complete rewrite. -- Töma
