Re: SMTP-friendly VPS provider where I can also get a BGP feed
That is extremely good and important advice! It seemed much less pertinent back when I was in my 30's, but planning for the unexpected is, or should be, a key part of all our jobs. Jim Shankland On 9/26/23 10:01 AM, Mel Beckman wrote: One thing you should consider about running a "family" mail server (or any other IT services for friends and family): that you have a clearly documented path of management succession. A dear friend of mine passed away last year and was running just such an email server. Nobody really knew how to get into it for maintenance, and a couple weeks after he passed. it crashed, and none of us knew precisely where it was physically located (on the end of a VPN tunnel, it tuns out). This took down email for 100 of his closest friends and family members for several weeks. We couldn't even unlock the domain, Personally, this has spurred me to create much better documentation of my own client services, and to involve a successor unlikely to be traveling with me -mel *From:* NANOG on behalf of Jim Shankland via NANOG *Sent:* Tuesday, September 26, 2023 9:46 AM *To:* nanog@nanog.org *Subject:* Re: SMTP-friendly VPS provider where I can also get a BGP feed I've been using Linode, also; works fine on the Linode end, but I still see occasional rejections based on my Linode IP address (most recently from outlook.com). It's nothing my specific IP is doing, but appears to be blacklisting of an address range. And gmail randomly puts some outgoing mail into recipients' spam folders. Trying to get an address unblocked by a major provider works almost as well as howling into the wind. Maybe I'm being stubborn to insist on continuing to run what's basically a family mail server, but it does seem like there's a matter of principle there: it should be possible to have an email account without having all the emails stored by a third party. If the answer ends up being, "Oh, just use gmail, everybody else does!" ... well, so be it, I guess, but we should be clear that something got lost in that transition. Jim Shankland On 9/26/23 9:10 AM, Jay R. Ashworth wrote: > I've run a mail server on Linode for 6 or 7 years now; no technical problems. > > End-node, Zimbra, postfix. > > Cheers, > -- jra > > - Original Message - >> From: "Jonathan Leist via NANOG" >> To: "Daniel Corbe" >> Cc: nanog@nanog.org >> Sent: Tuesday, September 26, 2023 10:32:51 AM >> Subject: Re: SMTP-friendly VPS provider where I can also get a BGP feed >> Pretty much every popular provider blocks port 25 out by default, and >> they'll instead try to steer customers to use a smart host. However, some, >> including Linode, will unblock port 25 by request: >> https://www.linode.com/docs/guides/running-a-mail-server/#sending-email-on-linode >> >> On Tue, Sep 26, 2023 at 6:11 AM Daniel Corbe wrote: >> >>> Hey all, >>> >>> I apologize if this isn't the right place to post this; however, I >>> thought maybe the NANOG community would be able to point me in the right >>> direction. >>> >>> I'm looking for a place that I can host a mailer. My primary use case >>> is a Mailman-style technical discussion list; much like NANOG but >>> software related instead of network related: READ: non-commercial in >>> nature. >>> >>> I'm currently a vultr customer, but they're refusing to unblock port 25 >>> on my account. I've tried explaining my use case but no matter who I >>> talk to over there they just keep pointing me to their spam policy. >>> >>> Thanks! >>> -Daniel >>> >> >> -- >> Jonathan Leist >> Staff Engineer
Re: SMTP-friendly VPS provider where I can also get a BGP feed
I've been using Linode, also; works fine on the Linode end, but I still see occasional rejections based on my Linode IP address (most recently from outlook.com). It's nothing my specific IP is doing, but appears to be blacklisting of an address range. And gmail randomly puts some outgoing mail into recipients' spam folders. Trying to get an address unblocked by a major provider works almost as well as howling into the wind. Maybe I'm being stubborn to insist on continuing to run what's basically a family mail server, but it does seem like there's a matter of principle there: it should be possible to have an email account without having all the emails stored by a third party. If the answer ends up being, "Oh, just use gmail, everybody else does!" ... well, so be it, I guess, but we should be clear that something got lost in that transition. Jim Shankland On 9/26/23 9:10 AM, Jay R. Ashworth wrote: I've run a mail server on Linode for 6 or 7 years now; no technical problems. End-node, Zimbra, postfix. Cheers, -- jra - Original Message - From: "Jonathan Leist via NANOG" To: "Daniel Corbe" Cc: nanog@nanog.org Sent: Tuesday, September 26, 2023 10:32:51 AM Subject: Re: SMTP-friendly VPS provider where I can also get a BGP feed Pretty much every popular provider blocks port 25 out by default, and they'll instead try to steer customers to use a smart host. However, some, including Linode, will unblock port 25 by request: https://www.linode.com/docs/guides/running-a-mail-server/#sending-email-on-linode On Tue, Sep 26, 2023 at 6:11 AM Daniel Corbe wrote: Hey all, I apologize if this isn't the right place to post this; however, I thought maybe the NANOG community would be able to point me in the right direction. I'm looking for a place that I can host a mailer. My primary use case is a Mailman-style technical discussion list; much like NANOG but software related instead of network related: READ: non-commercial in nature. I'm currently a vultr customer, but they're refusing to unblock port 25 on my account. I've tried explaining my use case but no matter who I talk to over there they just keep pointing me to their spam policy. Thanks! -Daniel -- Jonathan Leist Staff Engineer
Re: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a phishing E-mail or real...)
On 4/24/23 9:24 AM, Niels Bakker wrote: * na...@ve4.ca (Glen A. Pearce) [Mon 24 Apr 2023, 17:42 CEST]: Well, I eventually had a friend open the attachment on his Linux machine Not necessarily a safe idea: https://www.welivesecurity.com/2023/04/20/linux-malware-strengthens-links-lazarus-3cx-supply-chain-attack/ (scroll down to "Operation DreamJob with a Linux payload", sadly no anchors) The key security concern here is "don't inspect/interpret bytes in an attachment with an application of the attacker's choosing". cat, or even emacs, seem pretty safe. For me, that's easiest to do with Linux or MacOS (terminal). But sure, if "open on a Linux machine" still means "point and click", then you're absolutely correct. Jim Shankland
Re: DoD IP Space
On 2/11/21 6:29 AM, Owen DeLong wrote: On Feb 11, 2021, at 05:55 , Izaac wrote: On Wed, Feb 10, 2021 at 04:04:43AM -0800, Owen DeLong wrote: without creating partitioned networks. Ridiculous. Why would you establish such a criteria? The defining characteristic of rfc1918 networks is that they are partitioned. The ability to recognize and exploit partitions within a network, natural or otherwise, is the measure of competence in a network engineer. Stop making excuses. Ridiculous… TCP/IP was designed to be a peer to peer system where each endpoint was uniquely addressable whether reachable by policy or not. IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol. Stop making excuses and let’s fix the network. Owen TCP/IP wasn't designed; it evolved (OK, a slight exaggeration). The ISO-OSI protocol stack was designed. Many years ago, I taught a course on TCP/IP networking. The course was written by someone else, I was just being paid to present/teach it. Anyway, I vividly remember a slide with bullet points explaining why TCP/IP was a transitional technology, and would be rapidly phased out, replaced by the "standard", intelligently designed ISO-OSI stack. By the time I taught the course, I had to tell the class that every single statement on that slide was incorrect. In the end, evolution beat out intelligent design, by a country mile. It was probably a couple of years later -- the year definitely started with a 1 -- that I first heard that IPv4 was being phased out, to be replaced over the next couple of years by IPv6. We've been hearing it ever since. That doesn't mean that we'll be living with IPv4 forever. A peer to peer system where each endpoint is uniquely addressable is desirable. But in a world of virtual machines, load balancers, etc., the binding of an IP address to a particular, physical piece of hardware has long since become tenuous. IPv4 is evolving into a 48-bit address space for endpoints (32-bit host + 16-bit port). That development has extended IPv4's useful life by many years. There is pain associated with continuing to make IPv4 work. And there is pain associated with transitioning to IPv6. IPv6 will be adopted when the pain of the former path is much larger than the pain of the latter path. Saying "RFC-1918 is a bandaid for an obsolete protocol" is using a normative, rather than empirical, definition of "obsolete". In the empirical sense, things are obsolete when people stop using them. Tine will tell when that happens. Jim Shankland
Re: all major US carriers received text messages overnight that appear to have been sent around Valentine's Day 2019
On 11/8/19 10:34 AM, Kain, Becki (.) wrote: Esp on Valentine’s day. Of all the days that clear communication is important. I’d be very interested in their reasoning for why these messages were not sent and held. Roses are red, Violets are blue, Hope we're still together When this reaches you. (Sorry, it's Friday afternoon. I'll show myself out.) Jim **
Re: syn flood attacks from NL-based netblocks
On 8/17/19 3:16 PM, Damian Menscher wrote:
On Fri, Aug 16, 2019 at 3:05 PM Jim Shankland <mailto:na...@shankland.org>> wrote:
I'm seeing slow-motion (a few per second, per IP/port pair) syn flood
attacks ostensibly originating from 3 NL-based IP blocks:
88.208.0.0/18 <http://88.208.0.0/18>
, 5.11.80.0/21 <http://5.11.80.0/21>, and 78.140.128.0/18
<http://78.140.128.0/18> ("ostensibly" because ... syn flood,
and BCP 38 not yet fully adopted).
Is anybody else seeing the same thing? Any thoughts on what's
going on?
Or should I just be ignoring this and getting on with the weekend?
This appears to be a TCP amplification attack. Similar to UDP
amplification (DNS, NTP, etc) you can get some amplification by
sending a SYN packet with a spoofed source, and watching your victims
receive multiple SYN-ACK retries. It's a fairly weak form of attack
(as the amplification factor is small), but if the victim's gear is
vulnerable to high packet rates it may be effective.
That thought crossed my mind, but it seems to me that the weak
amplification factor, plus the broadly distributed set of forged source
addresses (within the blocks cited above), would make the attack
ineffective -- the whole point of DDoS being to focus a broadly
distributed set of (illegitimately obtained) source resources on a
narrow set of destination targets. Attacking 2 /18 blocks plus a /21
block in parallel with a weak-amplification attack doesn't look like a
successful DDoS strategy to me.
Jim
The victim (or law enforcement) could identify the true source of the
attack by asking transit providers to check their netflow to see where
it enters their networks.
Damian
Re: syn flood attacks from NL-based netblocks
On 8/16/19 3:50 PM, Emille Blanc wrote: Have been seeing these at $DAYJOB off and on for the past week. First logged events began for on 2019-08-04, at approx 1500hrs PST. Impact for us has been negligible, but some older ASA's were having trouble with the scan volume and their configured log levels which has since been remedied. Thanks for the various responses. The pattern I (and apparently quite a few others) are seeing differs from an ordinary probe in that it is repeated a few times per second (if somebody wants to know who has a visible ssh server on port 22, and what version of sshd is running, they don't have to hit it multiple times per second). It differs from a SYN flood DoS attack in that its rate is too low to be effective. And it differs from both a port probe and a SYN flood attack (or somebody "learning how to use nmap") in that it is targeting a broad set of destinations in parallel; if source addresses are forged, they are from a fairly narrow set of source IPs. The atypical pattern seems noteworthy in itself. Not a crisis, but not quite routine, either. Jim
syn flood attacks from NL-based netblocks
Greetings,
I'm seeing slow-motion (a few per second, per IP/port pair) syn flood
attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18
, 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood,
and BCP 38 not yet fully adopted).
Why is this syn flood different from all other syn floods? Well ...
1. Rate seems too slow to do any actual damage (is anybody really
bothered by a few bad SYN packets per second per service, at this
point?); but
2. IPs/port combinations with actual open services are being targeted
(I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs
with those services running), implying somebody checked for open
services first;
3. I'm seeing this in at least 2 locations, to addresses in different,
completely unrelated ASes, implying it may be pretty widespread.
Is anybody else seeing the same thing? Any thoughts on what's going on?
Or should I just be ignoring this and getting on with the weekend?
Jim
Re: Email security: PGP/GPG & S/MIME vulnerability drop imminent
On 5/15/18 2:34 AM, Rich Kulawiec wrote: On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: TL;DR = Don't use HTML email [snip] That's enough right there. HTML markup in email is used exclusively by three kinds of people: (1) ignorant newbies who don't know any better (2) ineducable morons who refuse to learn (3) spammers. There are no exceptions. Which category best describes my wonderful, intelligent (but decidedly non-technical), 84-year-old mother-in-law, who has been using email for a couple of decades (thus certainly not a "newbie"), and is definitely not a spammer. Do you have any advice for how I break it to her that she's an ineducable moron? You know, since there are no exceptions and all. Jim
Re: Are any of you starting to get AI robocalls?
On 4/4/18 7:44 AM, Sean Pedersen wrote: Yep. Add it to the list of IRS scams, fake arrest warrants, credit repair, free vacations, etc. The rate of calls has increased dramatically in the past year, especially with the "neighborhood scam" where they spoof their CLID to a local area code and prefix + through and blast you with calls, trying to trick you into thinking it's someone local and thus important or legitimate. Let me also put in a good word for the Jolly Roger Telephone Co. (http://www.jollyrogertelco.com). Don't just defend, fight back. Jim
Re: Zayo zColo Xcon Pricing
On 3/7/18 9:00 AM, Ian Mock wrote: Everything is negotiable. NRC on a cross-connect is ridiculous. The cost to run should be made up with the amount they're charging monthly. I wouldn't pay more than $200/mo for copper. Actually, as a reflection of the provider's cost, NRC for a cross-connect makes more sense than a recurring cost. After all, there's labor involved in setting up the cross-connect, but once it's in, it pretty much just sits there. The fallacy here, though, is assuming that rational pricing bears some relation to the vendor's cost to provide the good or service. Actual price is based on what the market will bear. Sharing pricing information on NANOG likely helps consumers by increasing market transparency (which is why vendors love to block such sharing via NDA). Much as I sympathize with the sentiment, though, "ridiculous" is meaningless in this context. It may even be construed as positive, as in: "Awesome, we're making ridiculous profits on all these copper cross-connects." :-) Jim
Re: PCIe adapters supporting long distance 10GB fiber?
On 6/20/17 8:15 AM, Baldur Norddahl wrote: The real question here is: will my NIC support other SFP+ modules than the few options carried by the NIC vendor? For example Intel claims the Intel NICs can only accept SFP+ modules by Intel. They probably do not make optics themselves and only have few options available. And indeed if you put in a third party optic it will be rejected. The last I looked -- and it's been a few years, so it might no longer be true -- the check for this was in the driver software, which is open-sourced. The check was even guarded by an ifdef so that it was easily disabled. If you disabled the check, you got a hyperventilating syslog warning saying you were taking your life into your hands by using unapproved equipment. That warning could then be ignored while it receded into rotated and, eventually, expunged log history. As I said, that was a few years ago, so would need to be reconfirmed. Jim
Re: IoT security, was Krebs on Security booted off Akamai network
On 10/9/16 11:30 AM, valdis.kletni...@vt.edu wrote: On Sun, 09 Oct 2016 18:05:20 -, Mel Beckman said: I don't know why it's "sub optimal" to use the cloud from an isolated network. Can you elaborate? Why should something out in the cloud have any part of the communication, other than perhaps telling your cellphone the current address of your widget? (And *that* should probably have a standardized protocol/service rather than every vendor rolling their own. Hello, IETF?) And even *that* can be bypassed if you cellphone is able to talk to your home network directly. A fair question, if it's intended rhetorically. If not, then the short answer is: because monetizing your personal information is a large (possibly dominant) part of the IoT business model, today. Rampant security holes don't necessarily perturb that model excessively -- though goodness knows they should, and maybe eventually they will. In the meantime, we have what Zeynep Tufekci has called the "Internet of Hacked Things" (anybody want to help get the acronym IoHT into general currency?). Jim
Re: John McAfee: Massive DDoS attack on the internet was from smartphone botnet on popular app
Also, this jumped out at me: "The problem with the recent attack is that the originating IP addresses were evenly distributed within the IPV4 universe," McAfee says. "This is virtually impossible using spoofing." Am I missing something, or is an even distribution of originating IP addresses virtually impossible *without* using spoofing? Jim
Re: Galaxy S6 is IPv6 on all US National Mobile carriers
On 4/13/15 8:17 PM, Joe Klein wrote: Was in a meeting over 4 years ago, where the people from Verizon were claiming they would be rolling out IPv6 for FIOS in the following years. Still waiting. C For those of us of a certain age, I'm wondering: what was the year when you first heard that the entire Internet was going to be switching over to IPv6 Real Soon Now? I distinctly remember my first time (who ever forgets?). I'm a little hazy on the exact year, but I know it started with a 1. Jim
Re: scaling linux-based router hardware recommendations
On 1/26/15 11:33 PM, Pavel Odintsov wrote: Hello! Looks like somebody want to build Linux soft router!) Nice idea for routing 10-30 GBps. I route about 5+ Gbps in Xeon E5-2620v2 with 4 10GE cards Intel 82599 and Debian Wheezy 3.2 (but it's really terrible kernel, everyone should use modern kernels since 3.16 because buggy linux route cache). My current processor load on server is about: 15%, thus I can route about 15 GE on my Linux server. I looked into the promise and limits of this approach pretty intensively a few years back before abandoning the effort abruptly due to other constraints. Underscoring what others have said: it's all about pps, not aggregate throughput. Modern NICs can inject packets at line rate into the kernel, and distribute them across per-processor queues, etc. Payloads end up getting DMA-ed from NIC to RAM to NIC. There's really no reason you shouldn't be able to push 80 Gb/s of traffic, or more, through these boxes. As for routing protocol performance (BGP convergence time, ability to handle multiple full tables, etc.): that's just CPU and RAM. The part that's hard (as in can't be fixed without rethinking this approach) is the per-packet routing overhead: the cost of reading the packet header, looking up the destination in the routing table, decrementing the TTL, and enqueueing the packet on the correct outbound interface. At the time, I was able to convince myself that being able to do this in 4 us, average, in the Linux kernel, was within reach. That's not really very much time: you start asking things like will the entire routing table fit into the L2 cache? 4 us to think about each packet comes out to 250Kpps per processor; with 24 processors, it's 6Mpps (assuming zero concurrency/locking overhead, which might be a little bit of an ... assumption). With 1500-byte packets, 6Mpps is 72 Gb/s of throughput -- not too shabby. But with 40-byte packets, it's less than 2 Gb/s. Which means that your Xeon ES-2620v2 will not cope well with a DDoS of 40-byte packets. That's not necessarily a reason not to use this approach, depending on your situation; but it's something to be aware of. I ended up convincing myself that OpenFlow was the right general idea: marry fast, dumb, and cheap switching hardware with fast, smart, and cheap generic CPU for the complicated stuff. My expertise, such as it ever was, is a bit stale at this point, and my figures might be a little off. But I think the general principle applies: think about the minimum number of x86 instructions, and the minimum number of main memory accesses, to inspect a packet header, do a routing table lookup, and enqueue the packet on an outbound interface. I can't see that ever getting reduced to the point where a generic server can handle 40-byte packets at line rate (for that matter, line rate is increasing a lot faster than speed of generic server these days). Jim
Re: Major California Faults Ready To Rupture | IFLScience
On 10/19/14 2:03 AM, Eliot Lear wrote: This was my recollection as well. Many corporate PBXes failed, and as it happened, for some reason, the mobile towers functioned with excess capacity, to the point where I had a line coming out of my car. Best form of communication into and out of the region during the crisis was the Internet. No surprise. That's what it was designed for. So I guess heartbeat.belkin.com stayed up? Jim
Re: best practice for advertising peering fabric routes
On 1/14/14, 8:41 PM, Patrick W. Gilmore 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. So ... RFC1918 addresses for the IXP fabric, then? (Half kidding, but still ) Jim Shankland
Re: Mikrotik Cloud Core Router and BGP real life experiences?
On 12/27/13 6:40 AM, matt kelly wrote: They can not handle a full routing table. The load balancing doesn't work. They can not properly reassemble fragmented packets, and therefore drop all but the first piece. They can not reliably handle traffic loads over maybe 200 Mbps, we needed 4-6 Gbps capacity. They can not hold a gre tunnel connection. Can't say anything about MicroTik specifically, but I've used Linux as a routing platform for many years, off and on, and took a reasonably close look at performance about a year ago, in the previous job, using relatively high-end, but pre-Sandy Bridge, generic hardware. We were looking to support ca. 8 x 10 GbE ports with several full tables, and the usual suspects wanted the usual 6-figure amounts for boxes that could do that (the issue being the full routes -- 8 x 10 GbE with minimal routing is a triviality these days). Routing table size was completely not an issue in our environment; we were looking at a number of concurrent flows in the high-5 to low-6-digit range, and since Linux uses a route cache, it was that number, rather than the number of full tables we carried, that was important. Doing store-and-forward packet processing, as opposed to cut-through switching, took about 5 microseconds per packet, and consumed about that much CPU time. The added latency was not an issue for us; but at 5 us, that's 200Kpps per CPU. With 1500-byte packets, that's about 2.4 Gb/s total throughput; but with 40-byte packets, it's only 64 Mb/s (!). But that's per CPU. Our box had 24 CPUs (if you count a hyperthreaded pair as 2), and this work is eminently parallelizable. So a theoretical upper bound on throughput with this box would have been 4.8 Mpps -- 57.6 Gb/s with 1500-byte packets, 1.5 Gb/s with 40-byte packets. The Linux network stack (plus RSS on the NICs) seemed to do quite a good job of input-side parallelism - but we saw a lot of lock contention on the output side. At that point, we abandoned the project, as it was incidental to the organization's mission. I think that with a little more work, we could have gotten within, say, a factor of 2 of the limits above, which would have been good enough for us (though surely not for everybody). Incrementally faster hardware would have incrementally better performance. OpenFlow, which marries cheap, fast, and dumb ASICs with cheap, slower, and infinitely flexible generic CPU and RAM, seemed, and still seems, like the clearly right approach. At the time, it didn't seem ready for prime time, either in the selection of OpenFlow-capable routers or in the software stack. I imagine there's been some progress made since. Whether the market will allow it to flourish is another question. Below a certain maximum throughput, routing with generic boxes is actually pretty easy. Today, I'd say that maximum is roughly in the low-single-gigabit range. Higher is possible, but gets progressively harder to get right (and it's not a firm bound, anyway, as it depends on traffic mix and other requirements). Whether it's worth doing really depends on your goals and skill. Most people will probably prefer a canned solution from a vendor. People who grow and eat their own food surely eat better, and more cheaply, than those who buy at the supermarket; but it's not for everybody. Jim Shankland
Re: If you're on LinkedIn, and you use a smart phone...
Well, this concerned me at first, but then I read the description of how it's done (http://engineering.linkedin.com/mobile/linkedin-intro-doing-impossible-ios): We understand that operating an email proxy server carries great responsibility. We respect the fact that your email may contain very personal or sensitive information, and we will do everything we can to make sure that it is safe. I find this completely reassuring. I'd expand on that, but I have to go buy a used car now. Jim Shankland
Re: PacketShader
Mark Smith wrote: On Mon, 23 Aug 2010 05:59:43 -0400 valdis.kletni...@vt.edu wrote: I missed that, and that answers the was it a GigaBytes verses Gigabits error question. Nothing new here by the looks of it - people in this thread were getting those sorts of speeds a year ago out of PC hardware under Linux - http://lkml.org/lkml/2009/7/15/234 I have achieved a collective throughput of 66.25 Gbit/s. We've achieved 70 Gbps aggregate unidirectional TCP performance from one P6T6 based system to another. Very nice, but doing this with 1514-byte packets is the low-hanging fruit. (9K packets? That's the fruit that falls off the tree and into your basket while you're napping :-).) The more interesting limit: how many 40-byte packets per second can you shovel into this system and still have all of them come out the other end? Jim Shankland
Re: black listing of web traffic
Andrey Gordon wrote: Can't find my IP on any of the black lists. Don't have any proxies. Sites that behave poorly are consistent. That is to say that facebook.com, apple.com would always come up without an issue, but cnn.com, forever21.com(i know, don't ask, students), store.apple.com would consistently take forever to come up. Just wanted to check of rate-limiting web clients is a common practice nowdays in the industry. If it's not, it's probably an unlikely cause of my troubles... Other things you might want to check out include whether your NAT gateway is well-behaved in the presence of PMTU discovery, TCP timestamps, and ECN. The web sites your students are having trouble with may share some property that, correctly or not, is interacting poorly with your NAT implementation. (I remain astonished at the number of big name web sites out there that send out their content with the DF bit set, then drop the fragmentation required ICMP packets they get back on the floor.) Jim Shankland
Re: Revisiting the Aviation Safety vs. Networking discussion
Eddy Martinez wrote: On Dec 24, 2009, at 10:09 AM, Randy Bush wrote: I _do_ create action plans and _do_ quarterback each step and _do_ slap down any attempt to deviate. imagine a network engineering culture where the concept of 'attempt to deviate' just does not occur. I find the thought of *any* culture in which attempts to deviate just do not occur a little unnerving. Jim Shankland http://blog.oliver-gassner.de/archives/225-Guenter-Eich,-Traeume.html
Re: Cogent Considerations [was: Re: Cogent Haiku v2.0]
Adam Young wrote: I wouldn't take my word for it but truthfully, you get what you pay for. Given you have other, more reliable transit, adding Cogent may be ok. I wouldn't rely on it for anything serious though. That has not been my experience. Peering wars have been an issue, but aside from that, they've been fine. (This is transit in San Francisco at the gigabit-plus level.) Jim Shankland
Re: [Fwd:] Nvidia NICs with duplicate mac addresses
The Nvidia NIC on the Asus motherboard on my desktop computer spontaneously changed its MAC maybe a year ago from 00:13:d4:fe:04:ee to 00:0b:e0:f0:00:ed. It can still be overridden in software, but the default MAC address -- the one stored in ROM -- simply made a one-time, spontaneous, permanent change. Nvidia NICs ... as my mother said, if you can't say anything nice, don't say anything at all. So the rest is silence. Jim Shankland
Re: IP Fragmentation
Leo Bicknell wrote: In a message written on Wed, Aug 20, 2008 at 09:43:44PM +0530, Glen Kent wrote: Do transit routers in the wild actually get to do IP fragmentation these days? [...] Yes. A GigE jumbo frames host (9120) to a standard POS interface (4420) to a DS3 customer (1500) happens, and the GigE-POS and POS-DS3 routers must both do fragmentation. From the application (as opposed to network operator) point of view, the big problem with fragmentation is that if you lose one fragment in transit, all the fragments eventually get discarded, even if they've made it all the way to the destination. This hurts performance and wastes resources. So you may be better off not sending those jumbo frames in the first place. If your packet loss rate, end-to-end, is epsilon, and epsilon is so small that even several times epsilon is negligible, then maybe you don't care. But you're clearly now relying on a higher standard of performance from the network fabric than you otherwise would be. Way back when, before my beard was gray, Sun came out with the Sun-4 servers, based on the new SPARC architecture. These were then widely deployed as NFS servers for Sun-3 desktops. The default NFS blocksize was 8K, the default (maybe only) transport was UDP. Sun-3 would make a read request, Sun-4 would send an 8K+ UDP response, which would get fragmented into a burst of 6 IP fragments, Sun-3 would get the first 3 or 4 before falling behind (this was, after all, the blistering fast 10 megabit Ethernet) and dropping a fragment. Eventually, the reassembly would time out, all the received fragments would get discarded, NFS would resend ... lather, rinse, repeat. Setting the NFS read and write sizes to 1460 fixed this by avoiding fragmentation. This concludes today's presentation from the history channel. Jim Shankland
Re: ICANN opens up Pandora's Box of new TLDs
Phil Regnauld wrote: Requirement ? What requirement ? There's no requirement for reverse DNS for email in any RFC. As a practical matter, I've found that sending out email from a host without rDNS doesn't work: too many sites bounce the mail. It will not come as news to anyone on this list that the world of SMTP is hardly well-defined or well-regulated in practice. Like Rowlf the dog, we can't live with it, we can't live without it, but we're stuck until something better comes along: http://www.youtube.com/watch?v=1vvV9LjBsNw Jim Shankland
Security gain from NAT (was: Re: Cool IPv6 Stuff)
Owen DeLong [EMAIL PROTECTED] writes: There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding. This is one of those assertions that gets repeated so often people are liable to start believing it's true :-). *No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site? Shall I do the experiment again where I set up a Linux box at an RFC1918 address, behind a NAT device, publish the root password of the Linux box and its RFC1918 address, and invite all comers to prove me wrong by showing evidence that they've successfully logged into the Linux box? When I last did this, I got a handful of emails, some quite snide, suggesting I was some combination of ignorant, stupid, and reckless; the Linux box for some reason remained unmolested. Jim Shankland
Security gain from NAT (was: Re: Cool IPv6 Stuff)
[EMAIL PROTECTED] writes: On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said: *No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site? Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly configured stateful *non*-NAT firewall should be doing for you already. Thanks for the clarification, Owen and Valdis. We are, of course, 100% in agreement that it is stateful inspection that provides (a measure of) security, and that stateful inspection can be had without NAT. But NAT *requires* stateful inspection; and the many-to-one, port translating NAT in common use all but requires affirmative steps to be taken to relay inbound connections to a designated, internal host -- the default ends up being to drop them. All this can be done without NAT, but with NAT you get it for free. I can't pass over Valdis's statement that a good properly configured stateful firewall should be doing [this] already without noting that on today's Internet, the gap between should and is is often large. If what you meant to say is that NAT provides no security benefits that can't also be provided by other means, then I completely agree. Jim Shankland
