Re: Norms and Standards

> On Aug 3, 2024, at 01:03, Howard, Lee via NANOG wrote: > > If a group of people can pick one topic and start documenting best practices, > we may be able to do something good. I’m not worried about process yet: > content first. There is a long history of the operational community engaging

Re: [c-nsp] ACL to block udp/0?

On Dec 6, 2023, at 17:46, Gert Doering wrote: I'd argue that the DNS folks recommend using EDNS0 with 1232 bytes, which works just fine to avoid fragments... Of course, the last true Internet flag day was in 1994, flag days aren’t possible anymore, & this is far from universally implemented. ;

Re: [c-nsp] ACL to block udp/0?

On Dec 6, 2023, at 04:45, Gert Doering via cisco-nsp wrote: deny ipv4 any any fragments This is approach is generally contraindicated, as it tends to break EDNS0, & DNSSEC along with it. If the target is a broadband access network, you can use flow telemetry to measure normal rates of non-

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 provide

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 + Flowspec,

Re: [c-nsp] Netflow vs SNMP

On 2 Oct 2023, at 17:10, Hank Nussbacher mailto:h...@interall.co.il>> wrote: cache timeout inactive 15 Kentik recommends 15s: This is an old, out-of-date recommendation from Cisco should be retired. 5s is plenty of time for inactive flows. ___ cisc

Re: [c-nsp] Netflow vs SNMP

On 2 Oct 2023, at 13:13, Hank Nussbacher via cisco-nsp mailto:cisco-nsp@puck.nether.net>> wrote: Does this make sense to go 1:1 which will only increase the number of Netflow record to export? Everyone that does 1:1000 or 1:1 sampling, do you also seen a discrepancy between Netflow stat

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 cu

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 experien

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 addition

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: [dns-operations] DNS contact at Barkleys?

> On 20 Jul 2021, at 23:10, Viktor Dukhovni wrote: > > There are (at least) two Barclays gTLDs that share a published > technical concat address: Simon Edlington I also have contacts there, so ping me if you don’t get a response. Roland Dobbins

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 des

Re: [AusNOG] Draytek 130 blank username/passwords

> On 22 Jun 2021, at 14:12, Benjamin Ricardo wrote: > > I was hoping to get an indication from other providers on how they handle > these “blank” authentications hitting their radius servers and whether this > is a wide spread problem as it became a huge problem for us. How many pps are thes

Re: [c-nsp] Nexus Architecture question

> On Jun 2, 2021, at 20:46, Drew Weaver wrote: > > The reason I am asking is because I've noticed that no matter what I do I > cannot seem to "close" the BGP port by using CoPP. iACLs can accomplish the goal, yes? --- roland.dobb...@netscout.com _

Re: [dns-operations] cheap traffic measure for a small set of zones

> On Mar 26, 2021, at 8:12 PM, Frank Louwers wrote: > > This message originated outside of NETSCOUT. Do not click links or open > attachments unless you recognize the sender and know the content is safe. > > As an alternative, you might look at dnsdist dnsdist is a great tool, but it might

Re: [dns-operations] cheap traffic measure for a small set of zones

On Mar 26, 2021, at 10:23, Randy Bush wrote: is there a simple tool to run on a server to measure query and data rates for a small set of zones? Maybe dsc, or dnstop? < https://github.com/DNS-OARC/dsc>

Re: [c-nsp] tcp intercept on IOS-XE?

> On 15 Mar 2021, at 14:08, Bryan Holloway wrote: > > Care to elaborate? Under any kind of load, it tends to send the RP up through 100%, which causes routing adjacencies to be lost. I tried to get this misfeature deprecated when I was at Cisco; sadly, marketing pressure kept it in the soft

Re: [c-nsp] tcp intercept on IOS-XE?

On Mar 14, 2021, at 14:10, h...@interall.co.il wrote: We are trying to implement tcp intercept on some brand new ASR1009x running IOS-XE 16.12.5 yet nothing is seen (sometimes). TCP Intercept is a self-DoS waiting to happen. Strongly suggest not doing this.

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 polic

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 detection/classi

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 destadd

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 general

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 te

Re: [c-nsp] Netflow/Sflow for "irrelevant" traffic?

> On 30 Jul 2020, at 18:48, Drew Weaver wrote: > > I'm just curious mostly but has anyone found a platform that has high enough > sflow/netflow "resolution" that it picks up things like single pings, or > broadcast traffic, or other very low volume traffic? I think what you’re looking for is

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 th

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 operat

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 s

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 h

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 th

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 sys

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 S/RT

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. Rola

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 sour

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: [dns-operations] s3.amazonaws.com problem?

On 24 Oct 2019, at 11:03, Daniel Stirnimann wrote: > I tried. It turned out to be an open resolver with dnsmasq and DNS > forwarding to our resolver. :-/ That was actually my guess — an open recursor/forwarder. Thanks much! Roland Dobbins

Re: [dns-operations] s3.amazonaws.com problem?

On 23 Oct 2019, at 19:37, Daniel Stirnimann wrote: > I have located a host in our network which sends such queries the > network resolver (which we operate): Can you get your hands on said host in order to analyze it? Roland Dobbins _

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.

Re: [AusNOG] Google and FB outages

On 14 Mar 2019, at 7:09, Glenn Lake wrote: > According to TechCrunch: Yes, I wasn't commenting directly on Facebook or Google. There was an internal miscommunication in that regard; there were some other reachability issues earlier US time, which is what I was citing. Clarifications have b

Re: [AusNOG] Google and FB outages

On 14 Mar 2019, at 2:25, Bevan Slattery wrote: > Just wondering if industry people have more of a handle on the cause > of the outages of the above major platforms within 12 hours of each > other. There was a non-trivial routing leak a few hours ago which was propagated to peers and downstre

Re: [c-nsp] UDP/0 ACL IOSXR issue?

On 9 Feb 2019, at 3:02, Bryan Holloway wrote: > I suspect you are right. Saku made the same suggestion off-line. Concur that these are likely non-initial fragments. Don't just block all non-initial fragments willy-nill, or you'll break EDNS0. If the targeted networks are endpoint networks wi

Re: [c-nsp] IKEv2 unknown connections

On 3 Jan 2019, at 16:58, Robert Hass wrote: > How I can check which IP is trying constantly connect via IKEv2 to my > router ? Use flow telemetry to look for incoming traffic directed to your router on UDP/4500? You could also use a classification ACL. Or if your circumstances permit, just u

Larry Roberts, RIP.

Roland Dobbins

Re: [AusNOG] google potential route hijacked.

On 13 Nov 2018, at 13:50, Paul Wilkins wrote: > If RPKI only had the same chain of trust for in-addr.arpa as the rest > of DNS does back to iana. Strong route origin policies via RPKI, plus draft-azimov-sidrops-aspa-verification-01 & draft-ietf-grow-rpki-as-cones-00 are ultimately the way to

Re: [AusNOG] google potential route hijacked.

On 13 Nov 2018, at 11:53, Binh Lam wrote: > just to whom who provided critical infrastructures (ie, email, DNS > hosting, cloud providers, > online banking sites subnets, high profile sensitive online sites , > etc..) This is both untenable and undesirable. Nor is Internet nor 'critical infra

[outages] Storm damage to ASE, Asia-American Gateway, TGA-Intra Asia, and SEA-ME-WE3; significant impact between Southeast Asia - North America & - Europe.

I can confirm that some consumer broadband access networks in ASEAN are currently seeing a ~90% drop in available trans-Pacific & APAC-Europe bandwidth as a result. ---

Re: [AusNOG] Telstra IP Transit (maybe only ADSL) Issue

On Aug 30, 2017, at 08:02, Narelle mailto:narel...@gmail.com>> wrote: Or even a DNS implementation 101 session at Ausnog? This example diagram may be relevant: --- Roland Dobbins mailto:rdobb...@arbor.net>>

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 19, 2017, at 20:06, Blumenthal, Uri - 0553 - MITLL > wrote: > > It’s not the networks that need to be “totally redesigned”, but the mechanism > to do surveillance. You underestimate the cascade effect of such measures. It's neither operationally nor economically viable.

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 19, 2017, at 20:06, Blumenthal, Uri - 0553 - MITLL > wrote: > > most of them already carry all that’s necessary (and more) to perform > surveillance from inside the endpoint. Unfortunately, this is not the case. Quite the opposite, actually. It's already been explained why endpoi

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL > wrote: > > Or are you simply trying to delay the inevitable? I'm open to any solution which meets the stated requirements & is deployable & usable on real-world production networks, without necessitating a total redesign of said

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 19, 2017, at 19:48, Watson Ladd mailto:watsonbl...@gmail.com>> wrote: Technical solutions to political problems are not the right approach. --- Roland Dobbins mailto:rdobb...@arbor.net>> ___ TLS mailing list TLS

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL > wrote: > > My point is that if you own/control the endpoint, then it doesn’t matter from > the architecture point of view It absolutely matters from an operational perspective, which both informs and is informed by the architectu

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 19, 2017, at 18:35, Colm MacCárthaigh wrote: > > That's not what I've seen. Instead, I see administrators creating port > mirrors on demand and then filtering the traffic they are interested in using > standard tcpdump rules, and I see MITM boxes that selectively decrypt some > traf

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 19:28, Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>> wrote: Organized crime capabilities are reaching the level of nation states, ankle biters reach up to where the organized crime was yesterday… I understand all this - I have to deal with it every day, so I unde

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 17, 2017, at 17:08, Salz, Rich mailto:rs...@akamai.com>> wrote: Let's not guess. Agreed. --- Roland Dobbins mailto:rdobb...@arbor.net>> ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tl

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 15:59, Carl Mehner mailto:c...@cem.me>> wrote: the only way that this draft would help you with malware analyzing) This statement is factually incorrect. It’s not the only way, as I've just explained. Again, why are you trying to pretend that the use of this technique is

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 15:40, Carl Mehner mailto:c...@cem.me>> wrote: Why would malware use this draft? Nobody said anything about malware using this draft. What I'm saying is that the ability to look inside the TLS tunnel & infer the presence of an additional, unexpected cryptostream - even wit

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 15:15, Carl Mehner mailto:c...@cem.me>> wrote: beginning to encrypt traffic inside the TLS tunnel. Yes, some (but by no means all) are - which means that in such cases, the ability to look inside the TLS tunnel so as to be able to detect the presence of an additional level

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 14:14, Russ Housley mailto:hous...@vigilsec.com>> wrote: I think that the IDS is trying to detect the an infected server trying to migrate to another server. Malware often includes a series of exploits that are tried in sequence to infect a neighbor, and this activity pro

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 17, 2017, at 14:21, Tom Ritter mailto:t...@ritter.vg>> wrote: It should be visible on the outside on the connection, so middle boxes that don't break TLS can see that TLS is being broken. With the caveat that the details of how it's actually implemented are key (pardon the pun), I thin

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Predicting the future is hard. Does anyone have a crystal ball that says this MUST be done within, say, three years? We can look at the PCI DSS timeline for previous revs - there's no guarantee it would be the same, of course. And there are other relevant regulators, as well. Perhaps someeone

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 17, 2017, at 13:50, Salz, Rich mailto:rs...@akamai.com>> wrote: Which brings me to my second question (or first, depending on how you read email). Will this be needed within five years? Within three? That's a very good question. Unfortunately, we don't know, yet. But we do know it w

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 17, 2017, at 13:48, Salz, Rich mailto:rs...@akamai.com>> wrote: Sometimes it is. Not at scale, in the vast majority of cases - as I'm sure you're aware, hence the 'sometimes'. Corner-cases are just that. Can we stop making definitive declarations like this? About factual matters, no,

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 14:01, Martin Thomson mailto:martin.thom...@gmail.com>> wrote: My point was that you don't get that visibility when it is malware at both ends of the connection (assuming a modest amount of competency from the authors). Seeing it when it's only at one end is quite useful.

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 15, 2017, at 22:36, Ackermann, Michael mailto:mackerm...@bcbsm.com>> wrote: So you can collect packet trace information at thousands or nodes This is precisely what is being posited, which is obviously unworkable. There's a real lack of understanding of the challenges of scale, here.

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 15, 2017, at 22:36, Ackermann, Michael mailto:mackerm...@bcbsm.com>> wrote: That being the unencrypted stream is available to the endpoints Even where it is eventually available, they don't have the horsepower to capture & forward. --- Roland Dobbins ma

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 15, 2017, at 16:30, Ted Lemon wrote: > > Roland, the reason that I made that particular comment was to try to show you > that the position you have taken here is untenable. It is not untenable. It is operational really. > There is no such textbook. As you now, that was a euphemi

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 15, 2017, at 16:05, Dobbins, Roland wrote: > > There is plenty of information on these topics available on the Internet > today. At the risk of self-replying, it should also be noted that highly informative discussions of these challenges, & detailed presentatio

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 15, 2017, at 15:49, Ted Lemon mailto:mel...@fugue.com>> wrote: Can you point me to the textbook for that class, because I must have missed it! There is plenty of information on these topics available on the Internet today. Search engines exist. It isn't reasonable to expect a class t

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 15, 2017, at 15:07, Ted Lemon mailto:mel...@fugue.com>> wrote: I think that your first and third points are actually non-sequiturs: the unencrypted stream is available to the entities controlling either endpoint, not just the log. This assertion is both incorrect & incomplete in its sc

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 15, 2017, at 14:48, Ted Lemon wrote: > > In the event that it is not feasible for an operator to obtain the plaintext > of a message without the key, isn't that because they don't control either > endpoint? First of all, what goes on the wire is often contextually different (and p

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor wrote: > > (b) we know that network capture is widely used adversarially by the > kinds of attackers that TLS is explicitly intended to defend > against? Because we know that network capture is an absolute, unquestionable requirement in

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor wrote: > > Could you point to an example of any regulation that requires plaintext > from network capture specifically? It often isn't feasible to obtain the plaintext any other way in a given circumstance. Not to mention the security & troub

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 15, 2017, at 13:14, Daniel Kahn Gillmor wrote: > > * This proposed TLS variant is *never* acceptable for use on the public > Internet. At most it's acceptable only between two endpoints within > a datacenter under a single zone of administrative control. I would strongly attempt

Re: Proxying NetFlow traffic correctly

On Jun 7, 2017, at 06:32, Sami via NANOG mailto:nanog@nanog.org>> 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 mentioned.

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

On May 9, 2014, at 2:48 PM, Vitkovský Adam 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 that it would still be i

Re: About NetFlow/IPFIX and DPI

On May 7, 2014, at 10:45 PM, Paolo Lucente 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 haven't run acro

Re: About NetFlow/IPFIX and DPI

On May 7, 2014, at 8:11 PM, Antoine Meillet 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 PSAMP exported over IPFIX

Re: [c-nsp] ACL TCAM LOU exhaustion on 7600 running 15.1 code

On May 6, 2014, at 6:25 AM, Mack McBride wrote: > One other note is that the acl compiler will attempt to expand acls for range > commands provided there aren't > too many ports in the range. This can cause TCAM exhaustion rather than LOU > exhaustion. sh fm sum has been helpful to me in thi

Re: [c-nsp] ASA 5520 icmp error inspection not functioning after upgrade

On May 4, 2014, at 11:16 AM, vinny_abe...@dell.com wrote: > I've always allowed echo-reply in the outside interface as well as > ttl-exceeded in the access-list applied to it. You should also allow ICMP type-3/code-4, or you're breaking PMTU-D. -

Re: [c-nsp] Cisco to support flow spec?

On May 4, 2014, at 1:26 PM, Justin M. Streiner wrote: > I remember hearing a while ago that Cisco was working on a competing > technology to flowspec, but no details were available at that time. You're thinking of this, which they didn't implement properly, and eventually EoLed because they'd

Re: oss netflow collector/trending/analysis

On May 2, 2014, at 9:36 PM, Matthew Galgoci 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 NetFlow tools:

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

On Apr 28, 2014, at 3:18 PM, Cliff Bowles 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 export/collection/analysis for detect

Re: [c-nsp] IP Options Drop

On Apr 22, 2014, at 1:28 AM, Phil Mayers wrote: > I'm wondering if other people stop because of ACL sizes too, if you have > large numbers of interfaces in non-aggregatable ranges e.g. customer-owned > space? This is why having a rationalized address plan is important for security purposes;

Re: [c-nsp] IP Options Drop

On Apr 21, 2014, at 11:26 PM, Saku Ytti wrote: > As ACL match work, you could do it in iACL and then you're only left with own > customers attacking you. iACLs should be applied at all edges of the network, including customer aggregation edges, IDC distribution edges, et. al. ---

Re: [c-nsp] IP Options Drop

On Apr 21, 2014, at 5:47 PM, Saku Ytti wrote: > While some traceroute programs do support IP options, it's very rare for > people to use IP options while traceroute. Network engineers tend to use traceroute in this manner more than most . . . --

Re: [c-nsp] IP Options Drop

On Apr 21, 2014, at 4:37 PM, Saku Ytti wrote: > It's RP only, it's cross-platform feature. That is RP receives IP options > like it normally does, but will always drop them. Does Sup2T/DFC4 drop options on the linecard? How about ip options ignore? Note to OP: traceroute uses options . . .

Re: Requirements for IPv6 Firewalls

On Apr 20, 2014, at 10:15 PM, Seamus Ryan 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 8:52 PM, Seamus Ryan 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 > everywhere and s

Re: Requirements for IPv6 Firewalls

On Apr 20, 2014, at 1:47 PM, Eugeniu Patrascu wrote: > Just go watch government at work :) Precisely. ;> --- Roland Dobbins // Luck is the residue of opportunity and design.

Re: Requirements for IPv6 Firewalls

On Apr 20, 2014, at 2:32 AM, George William Herbert 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: [OPSEC] Thoughts on draft-gont-opsec-ipv6-firewall-reqs

On Apr 19, 2014, at 6:38 AM, Fred Baker (fred) wrote: > I’m join to suggest that this be broken up into a number of > separately-discussable documents, each of which defines a test target. Concur 100% - and with everything else Fred noted, along with my previous comments. --

Re: Requirements for IPv6 Firewalls

On Apr 19, 2014, at 10:29 AM, Jeff Kell 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. In fact, it's far

Re: Requirements for IPv6 Firewalls

On Apr 19, 2014, at 9:04 AM, Jeff Kell 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 routers and/or laye

  1   2   3   4   5   6   7   8   9   10   >