Re: Strange IPSEC traffic

On Nov 14, 2023, at 00:12, Shawn L via NANOG wrote: The destination address is always one of our customer's ip addresses. Attackers will sometimes use synthetic ESP, AH, GRE, or other protocols in DDoS attacks, because organizations often only think about TCP/UDP/ICMP in terms of ACLs, DDoS

Re: FastNetMon Usage in the wild

On 18 Oct 2023, at 19:49, Adam Thompson wrote: Sightline *Insight* is the piece the sales team won't sell me, and TAC won't support me, for deployment in our private-cloud environment Insight isn’t used for first-order DDoS detection/classification/traceback/mitigation; Sightline/TMS

Re: FastNetMon Usage in the wild

On 11 Oct 2023, at 01:50, Adam Thompson wrote: you need to buy a moderately-expensive hardware server (they don’t let you virtualize it) To clarify, Sightline has supported virtualization for many years, FYI. I’m not aware of any anti-DDoS products at ISP scale that aren’t SFlow +

Latest NETSCOUT DDoS Threat Intelligence Report published, no registration required.

This issue covers 1H2023, and the full report is available online: We make these findings freely available as a service to the operational community; feedback welcome. Again, no registration is required to view the full report online. A .pdf summary is

Re: Traffic being directed at random infrastructure with pornhub.com host header (?)

On Sep 13, 2023, at 20:38, Drew Weaver wrote: Has anyone else recently seen a spike of port 80 traffic being sent at seemingly random IP addresses that include the Pornhub host header? It may be related to this:

Re: AKAMAI, Re: Apple blocking all AS29852 iCloud traffic, residential gigabit last mile provider in NYC.

On 18 Aug 2023, at 08:28, Eric Kuhnke wrote: Additionally this appears to have a strong correlation with everything that is hosted by Akamai Edge. Akamai, we are a fairly mundane last mile operator… It might be a good idea to analyze your outbound traffic in order to determine if you/your

Re: Standard DC rack rail distance, front to back question

On 27 Apr 2023, at 20:51, Chuck Church mailto:chuckchu...@gmail.com>> wrote: Is there a ‘standard’ distance between front and back rails that devices usually adhere to? There isn’t a standard for rack depth, AFAIK, but one typically sees anywhere from 27in/69cm – 50in/127cm, in my

Re: Flow Tools AS-Path

On 4 Apr 2023, at 21:48, Peter Phaal mailto:peter.ph...@gmail.com>> wrote: Export of destination AS-Path is supported in the sFlow extended_gateway structure. As a consumer of sFlow, [as well as NetFlow, IPFIX, etc.] I haven’t run into the use of this option in production, FWIW. In

Re: Flow Tools AS-Path

On 4 Apr 2023, at 20:04, Mike Hammett mailto:na...@ics-il.net>> wrote: 2) I have seen flow tools that show the entire AS path. Are they just cherry picking which platforms they showcase for the best marketing, or are they enriching the data they receive from "lesser" platforms from an outside

Re: Scanning activity from 2620:96:a000::/48

> On 6 Jul 2021, at 16:53, Tore Anderson wrote: > > I was just curious to hear if anyone else is seeing the same thing, and also > whether or not people feel that this is an okay thing for this «Internet > Measurement Research (SIXMA)» to do (assuming they are white-hats)? Scanning is part of

Re: Layer 2 based anycast - Kind like GLBP - Research

> On 2 Jul 2021, at 01:04, Douglas Fischer wrote: > > Answering suggestions in advance: As others have pointed out, what you’re describing isn’t anycast, nor anything directly to do with high availability. There are multiple well-understood frameworks which can be used to do what you’re

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

On Feb 3, 2021, at 17:01, Douglas Fischer wrote: It should be announced to another box, running other software than that one on the Perimeter, and filtering and refiltering should be done on both layers. This is how the inter-operator implementations of which I'm aware function, via a

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

On Feb 2, 2021, at 00:34, Douglas Fischer wrote: Or even know if already there is a solution to that and I'm trying to invent the wheel. Many flow telemetry export implementations on routers/layer3 switches report both passed & dropped traffic on a continuous basis for DDoS

Re: Unexplainable router log entries mentioning IPSEC from Yahoo IPs

On Dec 19, 2020, at 01:19, Frank Bulk wrote: Curious if someone can point me in the right direction. In the last three days our core router (Cisco 7609) has logged the following events: Dec 16 19:04:59.027 CST: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for

Re: Ingress filtering on transits, peers, and IX ports

> On 15 Oct 2020, at 05:43, Brian Knight via NANOG wrote: > > I think that's good for an enterprise network, but as an SP, I'm very > hesitant to include this. Is this included in anyone else's transit / peer / > IX ACL? This must not be done on peering links and on transit networks

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

> On 25 Aug 2020, at 18:13, Douglas Fischer wrote: > > With some analysis of what is running over our network, ISP or ITP, we will > be able to see some TCP/UDP(mostly UDP) packets with source or destination to > port 0. Are you certain that the UDP packets exhibit port 0, or is this flow

Don Smith, RIP.

It is with a heavy heart that I must relate the news that Don Smith, formerly of CenturyLink and more lately of Netscout Arbor, passed away in his sleep last night. Don was a colleague, friend, and mentor to many; he was a mainstay of the operational community, and tirelessly worked to make

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

On 28 Jan 2020, at 18:15, Octolus Development wrote: > The problem is that they are spoofing our IP, to millions of IP's > running port 80. So that does in fact sound like a TCP reflection/amplification attack. If you have the relevant information, as it seems that you do, you can ask

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

On Jan 28, 2020, at 11:40, Dobbins, Roland wrote: And even if his network weren't on the receiving end of a reflection/amplification attack, OP could still see backscatter, as Jared indicated. In point of fact, if the traffic was low-volume, this might in fact be what he was seeing

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

On Jan 28, 2020, at 07:39, Mike Hammett wrote: If someone is being spoofed, they aren't receiving the spoofed packets. How are they supposed to collect anything on the attack? OP stated that *his own network* was being packeted with a TCP reflection/amplification attack. This means that if

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

On Jan 28, 2020, at 04:12, Octolus Development wrote: I don't have an exact timestamp, because the attacks are really difficult to see as well. If you implement an open-source flow telemetry collection system & export flow telemetry from your edge routers to it, this becomes trivial. See

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

On Jan 28, 2020, at 04:12, Octolus Development wrote: It is impossible to find the true origin of where the spoofed attacks are coming from. This is demonstrably untrue. If you provide the requisite information to operators, they can look through their flow telemetry collection/analysis

Re: DDoS Mitigation Survey

On 20 Jan 2020, at 23:34, Jean | ddostest.me wrote: > so one of the best option to fight DDoS is not available through > public information. I just posted a link to a public presentation which describes how to enable it on one's own network. Giving end-customers the ability to block using

Re: DDoS Mitigation Survey

On 20 Jan 2020, at 22:49, Jean | ddostest.me wrote: > uRPF loose or strict. Either. > Which ISP supports it? Some operators use it themselves. I don't know of any who allow customer-triggered S/RTBH; several offer customer-triggered D/RTBH.

Re: DDoS Mitigation Survey

On 20 Jan 2020, at 19:59, Jean | ddostest.me via NANOG wrote: > Where can we find public information on how to use S/RTBH This .pdf preso on mitigation techniques describes how it works: Roland Dobbins

Re: DDoS Mitigation Survey

On 15 Jan 2020, at 6:37, Lumin Shi wrote: > What we meant by "may not have necessary capacity" is that routers do > not > have enough CAM/TCAM space to deploy/install ACLs, BGP FlowSpec rules > against large-scale DDoS attacks without 1) incurring major collateral > damage (e.g., deploy /16

Re: DDoS Mitigation Survey

On 14 Jan 2020, at 1:56, Lumin Shi wrote: > We believe that many routers on the Internet > today may not have the necessary capacity to perform fine-grained > traffic > filtering, especially when facing a large-scale DDoS attack with or > without > IP spoofing. There are literally decades of

Re: Seeking Feedback on Mitigation of New BGP-driven Attack

On 11 May 2019, at 11:29, Job Snijders wrote: > The paper contained new information for me, if I hope I summarize it > correctly: by combining AS_PATH poisoning and botnets, the botnet’s > firing power can be more precisely aimed at a specific target. That's my takeaway; it's utilizing illicit

Re: FB?

On 14 Mar 2019, at 19:17, Mike Hammett wrote: > I saw one article quoting Roland saying it was a route leak, but I > haven't seen any other sources that aren't just quoting Roland. That was the result of a miscommunication; a clarification has been issued, FYI.

Larry Roberts, RIP.

Roland Dobbins

Re: Proxying NetFlow traffic correctly

On Jun 7, 2017, at 06:32, Sami via NANOG > wrote: My goal is to centralize NetFlow traffic into a single machine and then proxy some flows to other destinations for further analysis Or nprobe, as was already

Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.

On May 9, 2014, at 2:48 PM, Vitkovský Adam adam.vitkov...@swan.sk wrote: With 6500/7600 I can understand they've been around for ages and no one anticipated the 512k limit back then. Actually, it *was* anticipated. It's just that those who designed the ASIC didn't necessarily envision

Re: About NetFlow/IPFIX and DPI

On May 7, 2014, at 8:11 PM, Antoine Meillet antoine.meil...@gmail.com wrote: Should those protocols be considered as tools to perform DPI ? No - they're flow telemetry exported by routers and switches, and they provide layer-4 information. It's possible with Cisco Flexible NetFlow and with

Re: About NetFlow/IPFIX and DPI

On May 7, 2014, at 10:45 PM, Paolo Lucente pl+l...@pmacct.net wrote: This model is supported on the export side by Cisco with their NetFlow/NBAR integration and on the collection side by some collector. As you'll note in reading that report, NBAR didn't seem to work very well for them; I

Re: oss netflow collector/trending/analysis

On May 2, 2014, at 9:36 PM, Matthew Galgoci mgalg...@redhat.com wrote: A few folks here really seem to like nfsen/nfdump. The good thing about nfdump/nfsen is that you can customize it and do a lot with it, and it's easy to get set up and running. This is the canonical list of open-source

Re: Question for service providers regarding tenant use of public IPv4 on your infrastructure

On Apr 28, 2014, at 3:18 PM, Cliff Bowles cliff.bow...@apollo.edu wrote: Or do ISPs put some level of security between their tenants and the internet to prevent this? I've been told that the majority do not have any intelligent filtering beyond bogon-lists. Flow telemetry

Re: Requirements for IPv6 Firewalls

On Apr 20, 2014, at 1:47 PM, Eugeniu Patrascu eu...@imacandi.net wrote: Just go watch government at work :) Precisely. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue

Re: Requirements for IPv6 Firewalls

On Apr 20, 2014, at 8:52 PM, Seamus Ryan s.r...@uber.com.au wrote: Similarly if most of the time I just need to protect my relatively simple network by implementing a few separate zones I will get a firewall, im not going to deploy expensive stateless devices that can push a billion pps

Re: Requirements for IPv6 Firewalls

On Apr 20, 2014, at 10:15 PM, Seamus Ryan s.r...@uber.com.au wrote: It was more a friendly stab at the way DDoS mitigation providers push their products; stateless router + ddos appliance = problem solved, throw everything else out

Re: Requirements for IPv6 Firewalls

On Apr 20, 2014, at 2:32 AM, George William Herbert george.herb...@gmail.com wrote: I have 20-30,000 counterexamples in mind that I worked with directly in the last decade. People do stupid things all the time - but generally, it's hard to do them at scale. ;

Re: Requirements for IPv6 Firewalls

On Apr 19, 2014, at 1:20 AM, William Herrin b...@herrin.us wrote: There isn't much a firewall can do to break it. As someone who sees firewalls break the Internet all the time for those whose packets have the misfortune to traverse one, I must respectfully disagree. ;

Re: Requirements for IPv6 Firewalls

On Apr 19, 2014, at 9:04 AM, Jeff Kell jeff-k...@utc.edu wrote: It's how we provide access control. Firewalls 'access control'. Firewalls are one (generally, very poor and grossly misused) way of providing access control. They're often wedged in where stateless ACLs in hardware-based

Re: Requirements for IPv6 Firewalls

On Apr 19, 2014, at 10:29 AM, Jeff Kell jeff-k...@utc.edu wrote: I call BS... You can 'call' it all you like - but people who actually want to keep their servers up and running don't put stateful firewalls in front of them, because it's very easy to knock them over due to state exhaustion.

Re: Requirements for IPv6 Firewalls

On Apr 17, 2014, at 7:35 PM, Dustin Jurman dus...@rseng.net wrote: - packets per second - Firewall Level - Hosts level This is getting into QoS territory . . . - packet size information Concur - packet-length. - Average for FW of all Network hosts This isn't very

Re: Requirements for IPv6 Firewalls

On Apr 17, 2014, at 10:26 PM, David Newman dnew...@networktest.com wrote: For firewalls handling TCP traffic, upper-layer traffic metrics such as HTTP object size, concurrent connection capacity, and connection setup rate are a lot more meaningful. I'm referring here to the ability to use

Re: Requirements for IPv6 Firewalls

On Apr 18, 2014, at 1:04 AM, Dustin Jurman dus...@rseng.net wrote: - the approach is from an end user than service provider. The firewall operator would be more interested in identifying PPS for attacks / compromised hosts VS QOS but I supposed it could be used for QOS as well. (Not my

Re: Outgoing traffic problem on Citrix Netscaler Load Balancer

On Mar 31, 2014, at 7:17 PM, Anil KARADAG akara...@netas.com.tr wrote: However, we need the source port to be the same on the destination servers. Out of curiosity, why? --- Roland Dobbins rdobb...@arbor.net //

Re: Link Layer Filtering not supported on popular equipment?

On Mar 26, 2014, at 11:08 PM, hasser css hasserva...@gmail.com wrote: Any insight? I don't know about Dell switches, but Cisco switches have DHCP Snooping, IP Source Guard, PACLs, VACLs, and so forth at layer-2. --- Roland

Re: IPv6 Security [Was: Re: misunderstanding scale]

On Mar 24, 2014, at 6:37 AM, Timothy Morizot tmori...@gmail.com wrote: You'll pardon my skepticism over claims that unspecified security weaknesses make it impossible to do what we have done and are continuing to do. All this unfilterable ICMP makes for interesting times - I've already run

Re: How to catch a cracker in the US?

On Mar 12, 2014, at 5:10 PM, Vitkovský Adam adam.vitkov...@swan.sk wrote: Though it's 100% correct would this withstand in the court? TIINAL - The Internet Is Not A Lawyer. ; --- Roland Dobbins rdobb...@arbor.net //

Re: How to catch a cracker in the US?

On Mar 11, 2014, at 2:00 PM, Markus unive...@truemetal.org wrote: Any advice? Start with CERT-BUND, maybe? Although it's questionable whether or not it's possible to remotely absolutely ascertain whether the attacking machine in question was being operated by miscreants unbeknownst to its

Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

On Mar 1, 2014, at 9:14 AM, Keegan Holley no.s...@comcast.net wrote: +1 in my experience uRPF get’s enabled, breaks something or causes confusion (usually related to multi-homing) and then get’s disabled. Enabling loose-check - even with allow-default - is useful solely for S/RTBH, if

Re: NTP DRDos Blog post

On Feb 20, 2014, at 11:14 PM, Niels Bakker niels=na...@bakker.net wrote: Don't invent new terms like DrDos. +1 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of

Re: NTP DRDos Blog post

On Feb 20, 2014, at 11:23 PM, Brian Rak b...@gameservers.com wrote: That's not a new term. It isn't used by folks involved in operational security. It's a marketing term. --- Roland Dobbins rdobb...@arbor.net //

Re: NTP DRDos Blog post

On Feb 20, 2014, at 11:29 PM, antoine.meil...@orange.com antoine.meil...@orange.com wrote: Yes, it was also used here https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212 That's still meaningless.

Re: NTP DRDos Blog post

On Feb 21, 2014, at 2:37 AM, John j...@nuclearfallout.net wrote: This is not a new term (certainly 12yo) Actually, it's much more recent than that (in this context; as others have mentioned, DR-DOS was the acronym for Digital Research's MS-DOS clone). But I'm going to stop posting about

Re: NTP DRDos Blog post

On Feb 21, 2014, at 2:51 AM, John j...@nuclearfallout.net wrote: I know how much Gibson is hated in some circles, He isn't/wasn't part of the operational community. It sure looks like you're right, he coined it then - as a marketing term, for marketing himself, heh. Maybe that's one of

Re: Filter NTP traffic by packet size?

On Feb 21, 2014, at 3:41 AM, Edward Roels edwardro...@gmail.com wrote: From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are typical for a client to successfully synchronize to an NTP server. Correct. 90 bytes = 76 bytes + Ethernet framing. Filtering out packets this

Re: Filter NTP traffic by packet size?

On Feb 21, 2014, at 9:55 AM, Dobbins, Roland rdobb...@arbor.net wrote: Filtering out packets this size from UDP/anything to UDP/123 allows time-sync requests and responses to work, but squelches both the level-6/-7 commands used to trigger amplification as well as amplified attack traffic

Re: Filter NTP traffic by packet size?

On Feb 21, 2014, at 9:55 AM, Dobbins, Roland rdobb...@arbor.net wrote: Filtering out packets this size from UDP/anything to UDP/123 allows time-sync requests and responses to work, but squelches both the level-6/-7 commands used to trigger amplification as well as amplified attack traffic

Re: Filter NTP traffic by packet size?

On Feb 21, 2014, at 11:40 AM, Harlan Stenn st...@ntp.org wrote: As a reality check, with this filtering in place does ntptrace still work? No, it will not. In order to minimize overblocking of this nature, filtering of this nature should be used with the highest possible degree of

Re: random dns queries with random sources

On Feb 19, 2014, at 10:57 PM, Beeman, Davis davis.bee...@integratelecom.com wrote: I am late to this train, but it appears no one else has brought this up. It is a DNS tunneling setup, not an attack. This makes a lot of sense - good insight, will look into this further!

Re: Changing the way we talk about BCP38 [Was: Re: Everyone should be deploying BCP 38! Wait, they are ....]

On Feb 19, 2014, at 2:43 AM, Paul Ferguson fergdawgs...@mykolab.com wrote: This is why I am now using the phrase anti-spoofing when talking about this in public. +1 It's also more semantically correct, in many cases. ---

Re: Everyone should be deploying BCP 38! Wait, they are ....

On Feb 19, 2014, at 4:52 AM, Tony Tauber ttau...@1-4-5.net wrote: maybe we should conclude that most of the spoofing is coming from somewhere else; perhaps including colo and cloud providers. My theory - not yet backed by data - is that probably most spoofed traffic these days does in fact

Re: random dns queries with random sources

On Feb 19, 2014, at 10:08 AM, Joe Maimon jmai...@ttec.com wrote: What is the purpose of this? Resource-exhaustion attack against the recursive DNS? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Re: random dns queries with random sources

On Feb 19, 2014, at 10:32 AM, Joe Maimon jmai...@ttec.com wrote: How is this any more effective then sending it direct? If they're attacking the authoritative DNS servers for 5kkx.com, just reflecting gives them indirection and presumably makes traceback harder for 5kkx.com (at least, in the

Re: random dns queries with random sources

On Feb 19, 2014, at 10:44 AM, Dobbins, Roland rdobb...@arbor.net wrote: Resource-exhaustion attack against the recursive DNS? Fat-finger, sorry - should also state 'Or against the authoritative servers for 5kkx.com

Re: random dns queries with random sources

On Feb 19, 2014, at 10:48 AM, Christopher Morrow morrowc.li...@gmail.com wrote: apologies. both chl.net and chl.com ... which appear to be parts of ttec ... which is joe. Premature send - I meant to add 'Or against the authoritative servers for 5kkx.com?' We've been seeing a spate of

Re: random dns queries with random sources

On Feb 19, 2014, at 12:44 PM, Joe Maimon jmai...@ttec.com wrote: Get back to me when the same cant be done with auth servers. There are ways to deal with it on authoritative servers, like RRL. --- Roland Dobbins

Re: random dns queries with random sources

On Feb 19, 2014, at 12:48 PM, Joe Maimon jmai...@ttec.com wrote: What I cant figure out is what is the target and how this attack method is any more effective then the others. The target appears to be the authoritative servers for the domain in question, yes? The attacker may consider it

Re: random dns queries with random sources

On Feb 19, 2014, at 1:07 PM, Joe Maimon jmai...@ttec.com wrote: There are ways to deal with it on resolvers as well, like RRL and IDS and iptables None of these things work well for recursive resolvers; they cause more problems than they solve.

Re: OpenNTPProject.org

On Feb 17, 2014, at 10:14 PM, Pete Ashdown pashd...@xmission.com wrote: Does not having nopeer contribute to DDoS amplification? No: http://www.kb.cert.org/vuls/id/348126 --- Roland Dobbins rdobb...@arbor.net //

Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)

On Feb 8, 2014, at 3:37 AM, John Curran jcur...@arin.net wrote: It's also true that if a sizable group of network operators were to actually deploy source address validation (thus proving that it really is a reasonable approach and doesn't carry too much operational or vendor implications),

Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)

On Feb 8, 2014, at 4:25 AM, Chris Grundemann cgrundem...@gmail.com wrote: Documenting those various mechanisms which are actually utilized is the key here. =) Yes, as well as the various limitations and caveats, like the wholesale/retail issue (i.e., customers of my customer).

Re: BCP38.info

On Feb 3, 2014, at 2:55 PM, Dobbins, Roland rdobb...@arbor.net wrote: It would be useful to know whether there are in fact NATs, or are 'DNS forwarders' . . . Another question is whether or not it's possible that in at least some cases, MITMing boxes on intermediary networks are grabbing

Re: BCP38.info, RELATING: TWC (AS11351) blocking all NTP?

On Feb 3, 2014, at 3:24 PM, Michael DeMan na...@deman.com wrote: I meant mostly that with IPv6 NAT goes away, I don't know if this is true or not - and even if it is true, it's going to be a long, long time before the IPv4 Internet goes away (like, maybe, pretty much forever, heh). An

Re: TWC (AS11351) blocking all NTP?

On Feb 3, 2014, at 4:55 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote: I agree with you but I'm fairly certain that most ISP who deny their users the ability to do DNS requests directly (or to run their own DNS resolver) have no such opt-out (or they make it expensive and/or

Re: TWC (AS11351) blocking all NTP?

On Feb 4, 2014, at 12:42 AM, Peter Phaal peter.ph...@gmail.com wrote: Real-time analytics based on measurements from switches/routers (sFlow/PSAMP/IPFIX) can identify large UDP flows and integrated hybrid OpenFlow, I2RS, REST, NETCONF APIs, etc. can be used to program the switches/routers

Re: TWC (AS11351) blocking all NTP?

On Feb 4, 2014, at 12:11 AM, Brian Rak b...@gameservers.com wrote: You can disable these quite easily, and still run a NTP server that provides accurate time services. Concur 100% - although it should be noted that 1:1 reflection without any amplification is also quite useful to attackers.

Re: TWC (AS11351) blocking all NTP?

On Feb 4, 2014, at 3:09 AM, Brian Rak b...@gameservers.com wrote: It's pretty much the same issue with DNS, even authoritative-only servers can be abused for reflection. They are, every minute of every day - and they provide amplification, too. ;

Re: TWC (AS11351) blocking all NTP?

On Feb 4, 2014, at 5:38 AM, John Kristoff j...@cymru.com wrote: I do realize in practice there are ways to discover systems, but the change in address architecture could change things, not perfectly, but I'll venture to suggest noticeably in some not so difficult to imagine scenarios. I

Re: TWC (AS11351) blocking all NTP?

On Feb 3, 2014, at 10:49 AM, Geraint Jones gera...@koding.com wrote: We block all outbound UDP for our ~200,000 Users for this very reason Actually, you could've (and should've) been far more selective in what you filtered via ACLs, IMHO. What about your users who play online games like BF4?

Re: TWC (AS11351) blocking all NTP?

On Feb 3, 2014, at 10:58 AM, Dobbins, Roland rdobb...@arbor.net wrote: I'm a big believer in using ACLs to intelligently preclude reflection/amplification abuse, but wholesale filtering of all UDP takes matters too far, IMHO. I also think that restricting your users by default to your own

Re: TWC (AS11351) blocking all NTP?

On Feb 3, 2014, at 12:45 PM, Michael DeMan na...@deman.com wrote: From a provider point of view, given the choices between contacting the end-users vs. mitigating the problem, if I were in TW position if I was unable to immediately contact the numerous downstream customers that were

Re: TWC (AS11351) blocking all NTP?

On Feb 3, 2014, at 1:02 PM, Dobbins, Roland rdobb...@arbor.net wrote: b) enforce their AUPs (most broadband operators prohibit operating servers) by blocking *inbound* UDP/123 traffic towards their customers at the customer aggregation edge Actually, this can cause problems for ntpds

Re: TWC (AS11351) blocking all NTP?

On Feb 3, 2014, at 1:54 PM, Michael DeMan na...@deman.com wrote: I certainly would not want to provide as part the AUP (as seller or buyer), a policy that fundamentals like NTP are 'blocked' to customers. Seems like too much of a slippery slope for my taste. The idea is to block traffic

Re: BCP38.info

On Jan 29, 2014, at 3:03 AM, Jared Mauch ja...@puck.nether.net wrote: Sure, but this means that network is allowing the spoofing :) What I did last night was automated comparing the source ASN to the dest ASN mapped to and reported both the IP + ASN on a single line for those that were

Re: BCP38.info

On Jan 29, 2014, at 4:47 AM, Nick Olsen n...@flhsi.com wrote: After a quick phone conversation with Jared. We concluded that at least in the specific case I was speaking about, I was correct in that nothing was Spoofed. Forgive me for being slow, but doesn't this seem to imply that there

Re: BCP38.info

On Feb 3, 2014, at 2:22 PM, Dobbins, Roland rdobb...@arbor.net wrote: This is pretty slick, relying upon broken CPE NAT implementations. It's the only way I've heard of to remotely infer whether or not a given network allows spoofing. It would be useful to know whether there are in fact

Re: Google causes 40% drop in traffic?

On Jan 25, 2014, at 6:07 AM, Jay Ashworth j...@baylink.com wrote: I wonder what percentage of large website operators whose site designs have such external dependencies have had it occur to them to include those external services in their monitoring systems? This presupposes that they

Re: OpenNTPProject.org

On Jan 15, 2014, at 12:05 AM, Saku Ytti s...@ytti.fi wrote: (We do BCP38 on all ports and verify programmatically, but I know it's not at all practical solution globally for access). Anti-spoofing is eminently practical for most types of access network topologies using even slightly modern

Re: OpenNTPProject.org

On Jan 16, 2014, at 9:56 PM, Saku Ytti s...@ytti.fi wrote: It is not going to happen, the most suspect places are places where it's going to be most difficult to get, either fully on autopilot with no technical personnel capable or having the power to make the change or ghetto gear with no

Re: best practice for advertising peering fabric routes

On Jan 15, 2014, at 9:18 PM, Leo Bicknell bickn...@ufp.org wrote: However, a good engineer would know there are drawbacks to next-hop-self, in particular it slows convergence in a number of situations. There are networks where fast convergence is more important than route scaling, and

Re: best practice for advertising peering fabric routes

On Jan 15, 2014, at 10:31 PM, Leo Bicknell bickn...@ufp.org wrote: I am approaching it from a different perspective, 'where is PMTU-D broken for people who want to use 1500-9K frames end to end?' I understand that perspective, absolutely. But what I'm saying is that that whether or not

Re: best practice for advertising peering fabric routes

On Jan 15, 2014, at 10:52 PM, Leo Bicknell bickn...@ufp.org wrote: (Business class) ISP's don't break PMTU-D, end users break it with the equipment they connect. Concur 100%. That's my point. So a smart user connecting equipment that is properly configured should be able to expect it

Re: best practice for advertising peering fabric routes

On Jan 15, 2014, at 11:41 AM, Patrick W. Gilmore patr...@ianai.net wrote: I repeat: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device except those directly attached to that LAN. Period. +1 Again, folks, this isn't

Re: EIGRP support !Cisco

On Jan 9, 2014, at 12:30 AM, Nick Olsen n...@flhsi.com wrote: Any thoughts? http://tools.ietf.org/html/draft-savage-eigrp-01 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue

Re: EIGRP support !Cisco

On Jan 9, 2014, at 12:50 AM, Nick Hilliard n...@foobar.org wrote: IGP migration is quite do-able, even for large networks, and all cisco +1 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Re: EIGRP support !Cisco

On Jan 9, 2014, at 12:52 AM, Nick Olsen n...@flhsi.com wrote: But this is needed to integrate into an existing network. Route redistribution? cringe or eBGP? --- Roland Dobbins rdobb...@arbor.net //

Re: NSA able to compromise Cisco, Juniper, Huawei switches

On Jan 1, 2014, at 2:07 AM, Randy Bush ra...@psg.com wrote: it's weasel words (excuse the idiom). shoveling kitty litter over a big steaming pile. Clayton is responding to the ability that he's allowed, and he's using words very precisely. Here's Cisco's official responses, so far.

  1   2   3   4   5   6   >