Re: why IPv6 isn't ready for prime time, SMTP edition
LoL Spellcheck… Helping you correctly spell the incorrect word every time. Owen On Mar 26, 2014, at 1:03 PM, Lamar Owen lo...@pari.edu wrote: On 03/26/2014 03:56 PM, Lamar Owen wrote: Most of the phishing e-mails I've sent don't have a valid reply-to, from, or return-path; replying to them is effectively impossible, and the linked/attached/inlined payload is the attack vector. Blasted spellcheck Now that everybody has had a good laugh; I've not 'sent' *any* phishing e-mails, but I have *seen* plenty. Argh.
Re: IPv6 Security [Was: Re: misunderstanding scale]
On Mar 26, 2014, at 4:25 PM, Luke S. Crawford l...@prgmr.com wrote: On 03/26/2014 03:49 PM, Matt Palmer wrote: On Wed, Mar 26, 2014 at 10:55:03AM -0700, Luke S. Crawford wrote: There are many ways to skin this cat; stateless autoconfig looks like it mostly works, but privacy extensions seem to be the default in many places; outgoing IPv6 from those random addresses will trip my BCP38 filters. Your what-now? You do realise SLAAC works entirely within a single /64, which shouldn't be difficult to decide is either routable or not in one hit, right? If you give every customer their own vlan and /64, sure. That can be done, and there are many advantages to doing it that way. But it's quite a bit more complex than my current setup. The way I'm setup now, I've got an IPv4 address block on a vlan, and an IPv6/64 on the same vlan. I have many customers on that vlan. Each customer has one (or more) IPv4 /32 addresses and one IPv6 /128 addresses. (if the customer wants more IPv6, we just route a /64 to the /128 they are allowed.) There are firewall rules that only allow appropriate packets in and out of the interface.These rules are important for privacy as well as preventing spoofing; they prevent sniffing of most traffic bound for other guests. Why not just use private VLAN layer 2 controls for the privacy you describe? Yes, you risk customer A spoofing customer B, but is that really a problem in your environment? Really? If so, one could argue you might want to consider getting a better class of customers. Owen
Re: IPv6 Security [Was: Re: misunderstanding scale]
On Mar 26, 2014, at 5:50 PM, Chuck Anderson c...@wpi.edu wrote: On Wed, Mar 26, 2014 at 06:52:53PM -0500, Timothy Morizot wrote: On Mar 26, 2014 6:27 PM, Luke S. Crawford l...@prgmr.com wrote: My original comment and complaint, though, was in response to the assertion that DHCPv6 is as robust as DHCPv4. My point is that DHCPv6 does not fill the role that DHCPv4 fills, if you care about tying an IP to a MAC and you want that connection to persist across OS installs by customers. You're right. DHCPv6 is more robust than DHCPv4. At least those of us in the enterprise space appreciate a client identifier that doesn't change when the hardware changes. No, it is LESS robust, because the client identifier changes when the SOFTWARE changes. Around here, software changes MUCH more often than hardware. Heck, even a dual-boot scenario breaks the client identifier stability. Worse yet, DHCPv6 has created a scenario where a client's IPv4 connectivity and IPv6 connectivity break under /different/ scenarios, causing difficult-to-troubleshoot half-connectivity issues when either the hardware is replaced or the software is reloaded. Any client whose DUID changes on software re-install has a very poor choice of default DUID and should be configurable for a better choice of DUID. That is not DHCPv6’s fault. DHCPv6 is perfectly capable of behaving as you wish. Blaming the protocol for poor implementation choices by your (or your client’s) vendors is a little odd in my opinion. Owen
Re: IPv6 isn't SMTP
On Mar 26, 2014, at 8:12 PM, Robert Drake rdr...@direcpath.com wrote: On 3/26/2014 10:16 PM, Franck Martin wrote: and user@2001:db8::1.25 with user@192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the separator for the port in IPv4? A few MTA are confused by it. At the network level the IPv6 address is just a big number. No confusion there. At the plaintext level the naked IPv6 address should be wrapped in square brackets. From: http://tools.ietf.org/html/rfc3986#section-3.2.2 Two errors, actually… As an RFC-821 address, it should be user@[IP]:port in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25). Owen
Re: Level 3 blames Internet slowdowns on Technica
Depends. On some services (L3, etc.), yes, they compete. That should not be conflated with competing at the L1 service. MSOs deliver L1 co-ax or HFC. RLECs deliver copper pairs and/or GPON. Satellite is it’s own peculiar sets of L1 transport. None of them compete head-to-head on the same technology on L1. Owen On Mar 26, 2014, at 10:11 PM, Frank Bulk frnk...@iname.com wrote: And MSOs, wireless carriers, and satellite providers aren't competitors to RLECs? Frank -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Monday, March 24, 2014 9:05 PM To: Frank Bulk Cc: Naslund, Steve; nanog@nanog.org Subject: Re: Level 3 blames Internet slowdowns on Technica Since a second build-out is impractical (if not actually impossible) and they don't sell UNEs, they are, in fact, pretty much exempt from direct competition for the same services. Owen On Mar 23, 2014, at 8:20 PM, Frank Bulk frnk...@iname.com wrote: I think I understand what you're saying -- you believe that RLECs that don't have to provide UNE's are exempt from competition. I guess I don't see the lack of that requirement meaning that there's no competition -- it just means that the kind of competition is different. Frank -Original Message- From: Naslund, Steve [mailto:snasl...@medline.com] Sent: Sunday, March 23, 2014 10:16 PM To: Frank Bulk Cc: nanog@nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica Many rural LECs are not required to provide unbundled network elements. As a network provider you can resell their service but they are not required to provide unbundled elements necessary to compete against them as a facilities based provider. So, for example, in Alamo Tennessee or Northern Wisconsin you can get a T-1 from a competitive carrier that resells their services but you cannot get competitive POTS service. You can buy DSL service from anyone but they are reselling the RLECs DSL access services not just running on their cable pairs. One of the biggest players that specializes in being a rural LEC is Frontier Communications. Yes, there are wireless carriers and satellite providers but especially in rural areas they are not a real viable alternative for high speed data since we know the characteristic of satellite service and WISPs have the same density problem in providing service in rural areas. It is hard for a WISP to be profitable when you only have a handful of customers per mile. Same formula, low density, long distances, high infrastructure per customer cost for the WISP. Steven Naslund Chicago IL -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Sunday, March 23, 2014 10:08 PM To: Naslund, Steve Cc: nanog@nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica Not sure which rural LECs are exempt from competition. Some areas are effectively exempt from facilities-based (i.e. wireline) competition because it's unaffordable, without subsidy, to build a duplicate wireline infrastructure. There are also wireless carriers and WISPs the compete against RLECs, as well as satellite providers. I'm not aware of any exclusivity. Frank -Original Message- From: Naslund, Steve [mailto:snasl...@medline.com] Sent: Sunday, March 23, 2014 9:00 PM To: Joe Greco Cc: nanog@nanog.org Subject: RE: Level 3 blames Internet slowdowns on Technica snip In a low density area you can never fund a build out which is where universal access charges came from and the reason that rural LECs are exempt from competition. In return for building a network that is not profitable easily they get exclusive access to sell services on it to give them a chance. Will your NRC be reasonable anywhere outside a major metro area? snip Steven Naslund Chicago IL
Re: why IPv6 isn't ready for prime time, SMTP edition
On Wednesday, March 26, 2014 08:26:14 PM Lamar Owen wrote: You don't. Their upstream(s) in South Africa would bill them for outgoing e-mail. nit Not all of 41/8 is served by South Africa :-). /nit Mark. signature.asc Description: This is a digitally signed message part.
Re: why IPv6 isn't ready for prime time, SMTP edition
On Thu, Mar 27, 2014 at 3:38 AM, Mark Tinka mark.ti...@seacom.mu wrote: nit Not all of 41/8 is served by South Africa :-). /nit nit But a significant portion of it routes through London :-) /nit *cough *cough co.tz to co.za, etc., etc. -Jim P.
Re: misunderstanding scale
On Thu, Mar 27, 2014 at 6:17 AM, Owen DeLong o...@delong.com wrote: It only takes a single entry if you do not store /128s but that /64. Yes, RBL lookups do not currently know how to handle this, but there are a couple of good proposals around on how to do it. Then the spammers will grab /48s instead of /64s. Lather, rinse, repeat. Admittedly, /48s are only 65,536 RBL entries per, but I still think that address-based reputations are a losing battle in an IPv6 world unless we provide some way for providers to hint at block sizes. That's why I believe having varying levels of granularity is the best trade off between cache friendliness, administrative effort and implementation complexity, independent on whether it's default deny or default accept. We either need to solve (or reduce the impact of) the DNS cache issue or we need to solve the fixed-range issue. Or IP-based reputation as we know it today is more or less dropped from the anti-spam toolset when it comes to IPv6. -- Matthias
Re: IPv6 Security
No, it is LESS robust, because the client identifier changes when the SOFTWARE changes. Around here, software changes MUCH more often than hardware. Heck, even a dual-boot scenario breaks the client identifier stability. Worse yet, DHCPv6 has created a scenario where a client's IPv4 connectivity and IPv6 connectivity break under /different/ scenarios, causing difficult-to-troubleshoot half-connectivity issues when either the hardware is replaced or the software is reloaded. Any client whose DUID changes on software re-install has a very poor choice of default DUID and should be configurable for a better choice of DUID. That is not DHCPv6?s fault. It is reality. DHCPv6 needs to take reality into account. DHCPv6 as defined in RFC 3315 does not offer client MAC address at all (thus making the job more difficult for a number of organizations). All I've seen so far indicates that this was a deliberate choice by the DHCPv6 designers, and in my opinion a very poor one. Fortunately we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and we're waiting for vendors to implement this. That solves one half of the problem. The other half is to actually let the DHCPv6 lease be based directly on the MAC address. The language in RFC 3315, as I read it, makes this difficult or impossible. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: why IPv6 isn't ready for prime time, SMTP edition
On Thursday, March 27, 2014 09:48:09 AM Jim Popovitch wrote: nit But a significant portion of it routes through London :-) /nit *cough *cough co.tz to co.za, etc., etc. Perhaps, but that does not mean it's all served by South African ISP's. The London trombone is a separate issue. Mark. signature.asc Description: This is a digitally signed message part.
Re: IPv6 Security
It is reality. DHCPv6 needs to take reality into account. One modest attempt to do so is dhcpy6d at https://dhcpy6d.ifw-dresden.de. Still work in progress and might not fit into every environment but helps some others. Regards -- Henri Wahl IT Department Leibniz-Institut fuer Festkoerper- u. Werkstoffforschung Dresden tel: (03 51) 46 59 - 797 email: h.w...@ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor Nagstamon: http://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle -- Henri Wahl IT Department Leibniz-Institut fuer Festkoerper- u. Werkstoffforschung Dresden tel: (03 51) 46 59 - 797 email: h.w...@ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor Nagstamon: http://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle signature.asc Description: OpenPGP digital signature
Re: why IPv6 isn't ready for prime time, SMTP edition
Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Wed, Mar 26, 2014 at 03:35:48PM -0400 Quoting John R. Levine (jo...@iecc.com): It must be nice to live in world where there is so little spam and other mail abuse that you don't have to do any of the anti-abuse things that real providers in the real world have to do. What is a real provider? And what in the email specifications tells us that the email needs and solutions of any one individual, as long as they are following protocol (which I'm quite convinced Mark is) are unreal? A real provider is one that provides mail for real users, as opposed to someone who plays RFC language lawyer games. I only have a few dozen users, but I can assure you I use a whole lot of different filtering approaches including DNSBLs to keep my users' mailboxes usable. Ergo, ad hominem. Please quit doing that. As a side note I happen to run my own mail server without spam filters -- it works for me. I might not be the norm, but then again, is there really a norm? (A norm that transcends SMTP RFC reach, that is -- the necessity to stick to protocol is not under debate) I must say it's pretty amusing that someone who works for the organization that published the original DNSBL seems to be ranting against them. The ability to change ones mind when circumstances change is usually seen as advantageous. Why not here? -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 This is a NO-FRILLS flight -- hold th' CANADIAN BACON!! signature.asc Description: Digital signature
RE: [mailop] IPv6 DNSBL
I suggest reputation on the reply-to domain also (if authenticated of course). No more running to other IPs / ESPs if you are a bad boy. You can integrate it in browsers and show it there too (watch out; don't enter your email address here because they will spam you or have spam evading practices [if no authentication takes place]). Show the reputation in the email client if possible. And I would like fine-grained complaining possible (so everyone can filter like the big boys can, one might need the 'ham' numbers too). But you want to be sure such numbers are authentic. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: mailop [mailto:mailop-boun...@mailop.org] Namens Michael Peddemors Verzonden: Thursday, March 27, 2014 1:06 AM Aan: mai...@mailop.org Onderwerp: Re: [mailop] IPv6 DNSBL On 14-03-26 04:42 PM, John Levine wrote: As a reliable rule of thumb, any list that's large enough to be interesting is also large enough to be compromised. I know people who have run whitelists at Returnpath, and I was in charge of the never very successful Spamhaus whitelist. The ones at Returnpath always said that much of the job was dealing with bullshit and deception from people trying to sneak into the whitelist. At Spamhaus, the main problem was that nearly all of the people willing to go to the effort to be whitelisted didn't qualify, which wasn't surprising, since people with good mail behavior rarely have trouble getting their mail delivered. R's, John Here Here.. (For instance, we recommend that people running filtering turn those off right away, eg SA..) But we do see a lot of people discussing this here, and at the risk of making even more noise on this list on this subject, and maybe we should kill the thread there.. It would be interesting to get a poll of sorts.. hands please.. (You can reply off-list) Options: 1) Only allow IPv4 to be used for MTA's 2) Create a Registry of Operators/IPs for MTA's on IPv6 3) Allow all IPv6 to be used for MTA's, and use blacklists 4) Other (Suggestions) And if you believe in item 2, (personally I am happy with 1 or 2 and open to 4) what would you expect such a registry to look like? -- Catch the Magic of Linux... Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca LinuxMagic a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mai...@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: WISP or other options
On Wed, Mar 26, 2014 at 10:30:27PM -0500, Nick wrote: Does any have contacts in Edinburgh Scotland who can provide WISP service at the Hopetoun House and Dundas Castle. I would like to have 20-60mpbs to for 2 days of services. There is a *chance* that we (http://hubs.net.uk/) can help. Our network in Edinburgh is mostly constructed for serving areas to the South -- the Lothians, the Borders, etc. and South Queensferry is to the Northwest. So one way of doing this would be to find an intermediate spot and make two links. Briefly consulting a map there are a few candidates, and for some, a temporary relay (the broadband wagon parked on a hilltop) might work. It also looks as though there may be line of sight to Scolocate in South Gyle which is a major datacentre where IX Scotland is -- unfortunately we don't have anything on the roof there at the moment. If the event is for some sort of not for profit or academic related thing other possibilities open up as well, it may be possible to use one of the universities' networks to get most of the way there. There are definitely possibilities, but it may well be too expensive for such a short duration. Send me a mail off list if you want to discuss in more detail. Our company's event planner claims there are no good ISP options in the area and wants us to go with satellite internet which is pricy and has high latency. Its worth noting both locations have ~7mpbs DLS. It would be interesting to talk to this event planner... Another option is bonded ADSL. I'd recommend Andrews and Arnold (http://aa.net.uk/) for that. It's a bit ugly, and any DSL or FTTx is very expensive for real use (BT Wholesale's tarrif for bandwidth on their DSL carrier interconnect for resale is something like -L-40/Mbps plus lots of other charges) but for a temporary situation it's not a bad option. Cheers, -w
Re: WISP or other options
On Thu, Mar 27, 2014 at 03:35:20AM +, Warren Bailey wrote: You are screwed for LOS microwave, 60mbps on a microwave hope requires real life engineering to function correctly. Well now, really. Yes it needs engineering, but nothing spectacularly difficult. The upper bound on distance the OP needs is something like 10 miles which is peanuts. Any of your typical off the shelf 5GHz stuff will do that, you can even just eyeball the alignment. The upper 5GHz band is not very crowded around here. You do need line of sight which means spending a little time with a topo map. You're right that it isn't as simple as just putting up some antennas, leaving the kit at factory defaults and hoping, but that's not a very high bar. towers Rather conveniently there are lots of hills around here. A typical can easily be something made out of standard scaffolding not more than 2.5m tall. You try to build them at the top of steep bits so that people (and sheep) can't easily stand in front of the antennas. If you¹re looking for satellite Satellite is a last resort, and almost always unnecessary even in very remote places. It is also, as you point out, extremely expensive. Best, -w
Re: WISP or other options
On Thu, Mar 27, 2014 at 12:02:30AM -0400, Miles Fidelman wrote: Laser link, and pray for clear weather? You'll have to pray really hard around here, especially in South Queensferry down by the water... We actually have an FSO link between two tall buildings in South Edinburgh. Only about 500m. It works pretty well except when the haar rolls in. Giant pain in the behind to align though, and given that the wind that comes over the top of these tall buildings can be 5x that at ground level, and gales happen several times a year, keeping them aligned is... interesting... -w
Re: WISP or other options
On Thu, Mar 27, 2014 at 05:09:05AM +, Warren Bailey wrote: It's not 802.11 and it doesn't act that way. Actually most of the installations I've seen -- and my day job is working with community networks around Scotland that have built all manner of strange things -- the problems most often have nothing at all to do with the physical layer. More often they're related to doing things with spanning tree that we all learned in networking long ago to not do, or running many layers of NAT because IP routing is not understood. Things like that. The only common RF problem is leaving the channel selection on auto. Which invariably means one radio, like an access point with a sector antenna, can't hear the point to point link coming in to the dish behind it and picks the wrong channel. Again, yes, you're right, you have to understand how this stuff works and think a little bit when you build, but your messages saying It's really really hard are coming across a little like FUD. A pair of Air Fiber is like 3k USD, and at 24ghz you had better know The AF24 are also illegal here. Or rather the lower channel belongs to the police, and the upper channel is limited to a very low output power. We have a pair of these, with a special non-operational license from Ofcom to put them through their paces. They do work, though they are a pain to align and subject to rain fade. They are on the West coast which is very rainy. Right now we're using them to measure rain intensity rather than to carry real traffic (which we can't do with a non-op license anyways). -w
Re: IPv6 isn't SMTP
On Mar 26, 2014, at 11:26 PM, Owen DeLong o...@delong.com wrote: On Mar 26, 2014, at 8:12 PM, Robert Drake rdr...@direcpath.com wrote: On 3/26/2014 10:16 PM, Franck Martin wrote: and user@2001:db8::1.25 with user@192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the separator for the port in IPv4? A few MTA are confused by it. At the network level the IPv6 address is just a big number. No confusion there. At the plaintext level the naked IPv6 address should be wrapped in square brackets. From: http://tools.ietf.org/html/rfc3986#section-3.2.2 Two errors, actually… As an RFC-821 address, it should be user@[IP]:port in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25). indeed, but MTAs are know to accept any kind of non RFC compliant emails and trying to make some sense out of it… :P see http://tools.ietf.org/html/rfc7103 which tries to address some of it in a more deterministic way. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: IPv6 Security
On Mar 27, 2014, at 12:52 AM, sth...@nethelp.no wrote: No, it is LESS robust, because the client identifier changes when the SOFTWARE changes. Around here, software changes MUCH more often than hardware. Heck, even a dual-boot scenario breaks the client identifier stability. Worse yet, DHCPv6 has created a scenario where a client's IPv4 connectivity and IPv6 connectivity break under /different/ scenarios, causing difficult-to-troubleshoot half-connectivity issues when either the hardware is replaced or the software is reloaded. Any client whose DUID changes on software re-install has a very poor choice of default DUID and should be configurable for a better choice of DUID. That is not DHCPv6.FNs fault. It is reality. DHCPv6 needs to take reality into account. DHCPv6 as defined in RFC 3315 does not offer client MAC address at all (thus making the job more difficult for a number of organizations). Yes it does$B!D(B What do you think $B!H(BLink Layer Address$B!I(B (RFC 3315, Section 9.1 Type 3) is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what this is intended to be. True, it includes an additional 16 bits of media type, but I don.FNt see that as being a problem. All I've seen so far indicates that this was a deliberate choice by the DHCPv6 designers, and in my opinion a very poor one. Fortunately we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and we're waiting for vendors to implement this. That solves one half of the problem. Yes and no. At the time RFC3315 was written, network cards changed independent of motherboards on a regular basis and this fact was a source of great consternation for DHCPv4 operators. Over time, that changed AFTER RFC3315 was written, but if you read section 9.4, it seems pretty clear that this change was anticipated by the authors and that DUID-LL was intended for the situation we have today. Clients failing to implement DUID-LL as defined in RFC-3315 can hardly be blamed on DHCPv6. The other half is to actually let the DHCPv6 lease be based directly on the MAC address. The language in RFC 3315, as I read it, makes this difficult or impossible. Reread section 9.4$B!D(B It seems not only possible, but recommended from my reading. The problem isn.FNt that the MAC address isnNt allowed. The problem is that the clients aren.FNt properly using permanent MAC addresses as DUID. Owen
Re: [mailop] IPv6 DNSBL
On Mar 27, 2014, at 2:37 AM, David Hofstee da...@mailplus.nl wrote: I suggest reputation on the reply-to domain also (if authenticated of course). No more running to other IPs / ESPs if you are a bad boy. You can integrate it in browsers and show it there too (watch out; don't enter your email address here because they will spam you or have spam evading practices [if no authentication takes place]). Show the reputation in the email client if possible. Most are not authenticated. The vast majority of SPAM I see is, among other things, Joe Jobbed. Owen
Re: IPv6 isn't SMTP
On Mar 27, 2014, at 3:24 AM, Franck Martin fmar...@linkedin.com wrote: On Mar 26, 2014, at 11:26 PM, Owen DeLong o...@delong.com wrote: On Mar 26, 2014, at 8:12 PM, Robert Drake rdr...@direcpath.com wrote: On 3/26/2014 10:16 PM, Franck Martin wrote: and user@2001:db8::1.25 with user@192.0.2.1:25. Who had the good idea to use : for IPv6 addresses while this is the separator for the port in IPv4? A few MTA are confused by it. At the network level the IPv6 address is just a big number. No confusion there. At the plaintext level the naked IPv6 address should be wrapped in square brackets. From: http://tools.ietf.org/html/rfc3986#section-3.2.2 Two errors, actually… As an RFC-821 address, it should be user@[IP]:port in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25). indeed, but MTAs are know to accept any kind of non RFC compliant emails and trying to make some sense out of it… :P see http://tools.ietf.org/html/rfc7103 which tries to address some of it in a more deterministic way. Sure, but that doesn’t mean we should be sending random garbage deliberately. Owen
Access Lists for Subscriber facing ports?
With all of the new worms / denial of service / exploits, etc. that are coming out, I'm wondering what others are using for access-lists on residential subscriber-facing ports. We've always taken the stance of 'allow unless there is a compelling reason not to', but with everything that is coming out lately, I'm not sure that's the correct position any more. thanks
RE: [mailop] IPv6 DNSBL
I suggest reputation on the reply-to domain also (if authenticated of course). No more running to other IPs / ESPs if you are a bad boy. You can integrate it in browsers and show it there too (watch out; don't enter your email address here because they will spam you or have spam evading practices [if no authentication takes place]). Show the reputation in the email client if possible. Most are not authenticated. The vast majority of SPAM I see is, among other things, Joe Jobbed. True. But the world must progress too. It would be nice if the spam-issue is better solved on IPv6 (than on IPv4). You would then have a reason to /not/ accept on IPv4 (and give IPv6 a boost). There must be a good reason for people to get of their asses and start implementing things like DMARC. All the banks (!$%^) I talk to do not have any reason to implement it swiftly (they turn on p=none and then all progress stops). Frustrating that they are too lazy to implement a few DNS records. It only needs firm backing by 3+ large companies like Hotmail. Give everyone on IPv6 without DMARC a large spamscore (and publish that beforehand ;-) ). Give me ammunition and all corporates will move. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: Owen DeLong [mailto:o...@delong.com] Verzonden: Thursday, March 27, 2014 1:40 PM Aan: David Hofstee CC: Michael Peddemors; nanog@nanog.org Onderwerp: Re: [mailop] IPv6 DNSBL On Mar 27, 2014, at 2:37 AM, David Hofstee da...@mailplus.nl wrote: I suggest reputation on the reply-to domain also (if authenticated of course). No more running to other IPs / ESPs if you are a bad boy. You can integrate it in browsers and show it there too (watch out; don't enter your email address here because they will spam you or have spam evading practices [if no authentication takes place]). Show the reputation in the email client if possible. Most are not authenticated. The vast majority of SPAM I see is, among other things, Joe Jobbed. Owen
Re: Access Lists for Subscriber facing ports?
On 03/27/2014 05:44 AM, Shawn L wrote: With all of the new worms / denial of service / exploits, etc. that are coming out, I'm wondering what others are using for access-lists on residential subscriber-facing ports. We've always taken the stance of 'allow unless there is a compelling reason not to', but with everything that is coming out lately, I'm not sure that's the correct position any more. As a residential ISP, we have seen quite a lot of this in terms of both compromised customer computers spewing spam and ddos, as well as compromised customer routers participating in ddos attacks as well as dns redirection exploits for phishing and other purposes. I too am an advocate of staying out of the way as much as possible, but I've come around to realize that the average customer NEEDS to be protected against the consequences of their ignorance, MORE than they need the freedom to run a publicly accessible dns or ntp server. We now have a default access list in place which locks down subscriber ports and prevents them from being a server on commonly exploited services like dns,ntp,smtp and so forth. The average customer neither knows nor cares, and suffers absolutely nothing because of it. What tipped it over for me was a rash of dns changers that exploited unknown to us default credentials in a number of subscriber modems, causing no end of customers who secretly depended on a set of DNS resolvers controlled by attackers that were performing poorly and resulting in 'why is it slow?' calls to my support staff. These devices should never have internet facing management, but they do and they did. I should also say that the acl's are also easily removable for any customer who asks. We don't make a big production out of it or anything, we just put the flag on their account and thats that. Mike-
Re: misunderstanding scale
On 2014-03-26, Owen DeLong o...@delong.com sent: Then the spammers will grab /48s instead of /64s. Lather, rinse, repeat. Admittedly, /48s are only 65,536 RBL entries per, but I still think that address-based reputations are a losing battle in an IPv6 world unless we provide some way for providers to hint at block sizes. After all, if you start blocking a /64, what if it’s a /64 shared by thousands of hosting customers at one provider offering virtuals? It was brought to my attention in a parallel thread on Mailop that such a mechanism does exist for allowing ISP to hint about the size of customer allocations, at least in the RIPE database: http://www.ripe.net/ripe/docs/ripe-513 So how do we make this universal and get ISPs to use it? If we know customer sizes, it becomes much easier to do reputation on a per-customer basis, which is probably granular enough for a lot of cases. -- Chip Marshall c...@2bithacker.net http://2bithacker.net/ pgpDfvwQUlHki.pgp Description: PGP signature
Re: IPv6 isn't SMTP
Jimmy Hess wrote the following on 3/26/2014 7:12 PM: The problem is with SMTP and is probably best addressed in the application layer through updates to SMTP or required bolt-ons (e.g SPF or similar); it was just simpler SPF is useful, but not a complete solution. I'm curious what form you think these updates to SMTP would take? What changes to SMTP protocol itself could really have a meaningful impact, without frustrating, confusing, or terribly complicating the lives of millions of mail users? The primary issues I see with SMTP as a protocol related to the lack of authentication and authorization. Take, for instance, the fact that the SMTP protocol requires a mail from: and rcpt to: address (more or less for authentication and authorization purposes), but then in the message allows the sender to specify a completely different set of sender and recipient information that gets displayed in the mail client. SMTP is simple, it is reliable, and it works well for delivering a message, but it does not address authentication or authorization of remote users (to my knowledge). An extension to SMTP that provides some form of authentication and authorization for remote users could address the abuse concerns. For example, one could utilize a public key infrastructure through previously shared vcard or similar contact information to both authenticate and authorize a sender to be allowed to send email to a recipient. There are probably a few ways to accomplish the same goal, a PKI is just one example. This would allow one to configure his or her email as either 'default allow' to receive email from anyone at any time or 'default deny' to only allow authorized senders. There are some folks doing this today outside of SMTP, but without a mass effort these schemes will probably not take a strong foothold. Implementing something like this takes some work in the mail client to be able to generate a private key and hold the public key info of others. Realistically, the key information could be exchanged and verified simply between clients at the remote ends without any SMTP server involvement, but that seems like a waste for servers to process and store messages that are going to be junked in the end that it would make sense that the SMTP servers could also be able to make these decisions server side. On the other hand, putting spam filtering in the hands of the end users could really untie the server operators from costly or cumbersome anti-SPAM efforts. Any open source email clients want to take this task on and build an industry consensus? I'm all for having my emails tagged as trusted/authorized or untrusted/unauthorized in my email client. Once the level of untrusted, yet legitimate, messages drops to a low enough level I can stop accepting untrusted messages altogether. --Blake
Re: IPv6 isn't SMTP
John Levine jo...@iecc.com wrote: There are also some odd things in the spec. For example, according to RFC 5321 this is not a syntactically valid e-mail address: mailbox@[IPv6:2001:12:34:56::78:ab:cd] You aren't allowed to use :: to abbreviate one zero hexadectet according to RFC 5952. http://www.rfc-editor.org/errata_search.php?eid=2467 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Malin: East 5 or 6. Moderate or rough, occasionally very rough in northwest. Showers. Good, occasionally moderate.
Re: why IPv6 isn't ready for prime time, SMTP edition
This is totally ignoring a few facts. A: That the overwhelming majority of users don't have the slightest idea what an MTA is, why they would want one, or how to install/configure one. ISP/ESP hosted email is prevalent only partially to do with technical reasons and a lot to do with technical apathy on the part of the user base at large. Web hosting is the same way. A dedicated mailbox appliance would be another cost to the user that they would not understand why they need, and thus would not want. In a hypothetical tech-utopia, where everyone was fluent in bash (or powershell, take your pick), and read RFCs over breakfast instead of the newspaper, this would be an excellent solution. Meanwhile, in reality, technology frightens most people, and they are more than happy to pay someone else to deal with it for them. B: The relevant technical reason can be summarized as good luck getting a residential internet connection with a static IP (If your response includes the words dynamic DNS then please see point A) (Also I'm just going to briefly touch the fact that this doesn't address spam as a problem at all, and in fact would make that problem overwhelmingly worse, as MTAs would be expected to accept mail from everywhere, and we obviously can't trust end user devices or ISP CPE to be secure against intrusion) Scott Buettner Front Range Internet Inc NOC Engineer On 3/26/2014 8:33 AM, Laszlo Hanyecz wrote: Maybe you should focus on delivering email instead of refusing it. Or just keep refusing it and trying to bill people for it, until you make yourself irrelevant. The ISP based email made more sense when most end users - the people that we serve - didn't have persistent internet connections. Today, most users are always connected, and can receive email directly to our own computers, without a middle man. With IPv6 it's totally feasible since unique addressing is no longer a problem - there's no reason why every user can't have their own MTA. The problem is that there are many people who are making money off of email - whether it's the sending of mail or the blocking of it - and so they're very interested in breaking direct email to get 'the users' to rely on them. It should be entirely possible to build 'webmail' into home user CPEs or dedicated mailbox appliances, and let everyone deal with their own email delivery. The idea of having to pay other people to host email for you is as obsolete as NAT-for-security, and this IPv6 SMTP thread is basically covering the same ground. It boils down to: we have an old crappy system that works, and we don't want to change, because we've come to rely on the flaws of it and don't want them fixed. In the email case, people have figured out how to make money doing it, so they certainly want to keep their control over it. -Laszlo On Mar 26, 2014, at 2:07 PM, Lamar Owen lo...@pari.edu wrote: On 03/25/2014 10:51 PM, Jimmy Hess wrote: [snip] I would suggest the formation of an IPv6 SMTP Server operator's club, with a system for enrolling certain IP address source ranges as Active mail servers, active IP addresses and SMTP domain names under the authority of a member. ... As has been mentioned, this is old hat. There is only one surefire way of doing away with spam for good, IMO. No one is currently willing to do it, though. That way? Make e-mail cost; have e-postage. No, I don't want it either. But where is the pain point for spam where this becomes less painful? If an enduser gets a bill for sending several thousand e-mails because they got owned by a botnet they're going to do something about it; get enough endusers with this problem and you'll get a class-action suit against OS vendors that allow the problem to remain a problem; you can get rid of the bots. This will trim out a large part of spam, and those hosts that insist on sending unsolicited bulk e-mail will get billed for it. That would also eliminate a lot of traffic on e-mail lists, too, if the subscribers had to pay the costs for each message sent to a list; I wonder what the cost would be for each post to a list the size of this one. If spam ceases to be profitable, it will stop. Of course, I reserve the right to be wrong, and this might all just be a pipe dream. (and yes, I've thought about what sort of billing infrastructure nightmare this could be.)
Link Layer Filtering not supported on popular equipment?
Is there any common equipment that doesn't support this kind of filtering? I have no access to the switches where I work (I am just a CS agent at a smaller service provider), but my boss tells me that they do not support doing this... however, I do not believe this at all. I think that all the switches are all from Dell. Issues are happening as some customers accidentally have rogue DHCP servers running from their routers being connected improperly, and his only solution to this issue is to disable the switch port instead of simply preemptively filtering out this. Any insight? Regards.
Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability
The Full-disclosure mailing list was recently... retired, I guess cisco thought NANOG was the next best place. On Wed, Mar 26, 2014 at 10:45 AM, rw...@ropeguru.com rw...@ropeguru.comwrote: Is this normal for the list to diretly get Cisco security advisories or something new. First time I have seen these. Robert On Wed, 26 Mar 2014 12:10:00 -0400 Cisco Systems Product Security Incident Response Team ps...@cisco.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco IOS Software SSL VPN Denial of Service Vulnerability Advisory ID: cisco-sa-20140326-ios-sslvpn Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary === A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of Cisco IOS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. The vulnerability is due to a failure to process certain types of HTTP requests. To exploit the vulnerability, an attacker could submit crafted requests designed to consume memory to an affected device. An exploit could allow the attacker to consume and fragment memory on the affected device. This may cause reduced performance, a failure of certain processes, or a restart of the affected device. Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/ CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+ mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7 RF3x0wYuErbbC7N9m1UH =1Ixo -END PGP SIGNATURE-
Looking for 2M service in CA
Hi all, Apologies if this is the incorrect forum for this request, first time posting to the group! I work for an ISP in Australia and we have a requirement to deliver a service to a client site in CA. I'm not familiar with the American market but I'd be interested in chatting with providers who can deliver 2M tails between the following locations: A End: Washington Avenue, San Leandro CA B End: Equinix San Jose *OR *Coresite San Jose. Response off list to esmithstu...@gmail.com would be appreciated. Thanks in advance! Ed
Re: WISP or other options
Pay someone to worry about all this stuff, MaxWiFi has a good reputation in the UK at least. Stuff like the Ubiquiti Networks AirFiber can be good for getting from A-B over relatively short distances if you've identified another place which has really good connectivity which you can use, and if good connectivity is truly critical to the events. Obviously this involves masts, may involve permitting, and is a bit more complex than just a DSL line. It's usually possible to bond multiple DSL connections, and it's not impossible to get phone lines and DSL installed for short events either, although it does depend on the venue being willing to accommodate you. According to SamKnows the South Queensferry exchange (Dundas Castle) is supposed to have gotten BT FTTC capability from 1st March and some LLU (O2, TalkTalk, Sky) has happened, so again, talk to someone who specialises in this stuff and they'll be able to navigate What is the least fucked up way to solve this for the event?. HTH, -Alex
Re: WISP or other options
I think the AF5 should be legal over here, at least, the lower bands are license free up to 1W transmit power. Not used the AF5 at all yet, it's quite new, and the only AF24 experience I have is only ~1000m worth of distance so comparatively easy to make work. Either way you latched onto the point, which is Where there's a will, there's a way. In a lot of ways the UK is significantly more forward-thinking in terms of what can be done with DSL lines, the US LECs really aren't very imaginative. Who ever thought I'd be praising BT. On 27 March 2014 10:10, William Waites wwai...@tardis.ed.ac.uk wrote: On Thu, Mar 27, 2014 at 05:09:05AM +, Warren Bailey wrote: It's not 802.11 and it doesn't act that way. Actually most of the installations I've seen -- and my day job is working with community networks around Scotland that have built all manner of strange things -- the problems most often have nothing at all to do with the physical layer. More often they're related to doing things with spanning tree that we all learned in networking long ago to not do, or running many layers of NAT because IP routing is not understood. Things like that. The only common RF problem is leaving the channel selection on auto. Which invariably means one radio, like an access point with a sector antenna, can't hear the point to point link coming in to the dish behind it and picks the wrong channel. Again, yes, you're right, you have to understand how this stuff works and think a little bit when you build, but your messages saying It's really really hard are coming across a little like FUD. A pair of Air Fiber is like 3k USD, and at 24ghz you had better know The AF24 are also illegal here. Or rather the lower channel belongs to the police, and the upper channel is limited to a very low output power. We have a pair of these, with a special non-operational license from Ofcom to put them through their paces. They do work, though they are a pain to align and subject to rain fade. They are on the West coast which is very rainy. Right now we're using them to measure rain intensity rather than to carry real traffic (which we can't do with a non-op license anyways). -w
Re: WISP or other options
On 27 March 2014 05:09, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: I think the real problem here is the event is for 2 days and he requires a metric shxt ton of data (for wireless anyways..). Sure you could get all kinds of COOL solutions together, but do you think the (UK Version) LEC is going to run DSL/fiber/blah for a two day event? And who bears that cost burden? Yes. Absolutely. Getting a phone line or multiple installed for 2 days is *completely* feasible, and depending on the length to the cabinet/exchange, the speeds he wants are also not too difficult (~20Mbps) through bonding. Both of the locations he has identified probably already have a significant number of copper pairs into the building. There are more than likely to be enough spare although the install process could be complicated if that is not the case. Typically speaking a line install costs from BT Openreach costs around £50+VAT, but you'd pay £145+VAT to get an expedited install appointment. In *theory* (never tried this myself) they should be able to install multiple lines within the same appointment, so four lines might run you £345+VAT or thereabouts although worst case you could be looking at £195+VAT per line. I believe it's possible to just cancel them immediately after the event, and that it's possible to avoid a 12 month minimum term, so you'd be looking at fairly minimal rental costs (£12+VAT per line, or thereabouts) to cover their rental for the 30 days covering your event. I am not trivialising the use of AirFiber in the slightest, however, if that's what it takes to get him the required bandwidth it's also not out of the realm of possibility for someone (i.e. doing it through MaxWiFi) to set up, for the required amount of money. I specifically stated it would be more complex than a DSL line. I think the OP was looking for solutions, not pages of text about how difficult or impossible his situation actually is ;-)
Re: IPv6 isn't SMTP
Owen DeLong o...@delong.com wrote: Two errors, actually… As an RFC-821 address, it should be user@[IP]:port in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25). You have never been able to specify a port number in an email address. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Lundy, Fastnet: East or northeast 4 or 5, occasionally 6 later. Moderate becoming rough in south. Thundery showers. Good, occasionally poor.
RE: WISP or other options
There are plenty of Microwave products that produce that type of bandwidth and more, LOS and NLOS. I do not know if there is a WISPA counterpart in Scotland but you may want to reach out to WISPA to see if they know of an organization. You can also reach out to Cambium to see whom their partners are in the area. Dustin Jurman -Original Message- From: Warren Bailey [mailto:wbai...@satelliteintelligencegroup.com] Sent: Wednesday, March 26, 2014 11:35 PM To: Nick; nanog@nanog.org Subject: Re: WISP or other options 20-60mbps is a tall order. I¹d say cellular.. Maybe you can pair together a couple of 4g cradle points and do load balancing on them? You are screwed for LOS microwave, 60mbps on a microwave hope requires real life engineering to function correctly. Frequency coordination, towers, AGL requirements. If you¹re looking for satellite, I can tell you for certain that a 60mbps circuit for a month would exceed 140k a month in your neck of the woods. That¹s just to start off, it can get higher as the link budget dictates. Is there any reason you need THAT much? Have you thought about using compression stuff at all? Are these people paying for it? On 3/26/14, 8:30 PM, Nick n...@wiredmedium.com wrote: Hey, I have a weird off the wall question for a NA group. Does any have contacts in Edinburgh Scotland who can provide WISP service at the Hopetoun House and Dundas Castle. I would like to have 20-60mpbs to for 2 days of services. Our company's event planner claims there are no good ISP options in the area and wants us to go with satellite internet which is pricy and has high latency. Its worth noting both locations have ~7mpbs DLS. I'm also open to other options. Thanks, Nick Poulakos
Re: IPv6 isn't SMTP
Hi, On Thu, Mar 27, 2014 at 01:52:27PM +, Tony Finch wrote: John Levine jo...@iecc.com wrote: There are also some odd things in the spec. For example, according to RFC 5321 this is not a syntactically valid e-mail address: mailbox@[IPv6:2001:12:34:56::78:ab:cd] You aren't allowed to use :: to abbreviate one zero hexadectet according to RFC 5952. well, RFC 5952 _recommends_ against using that. Still, it's perfectly valid as of RFC 4291 and the approach can be found in quite large vendors' implementations, see http://labs.apnic.net/blabs/?p=309. RFC 5952 explicitly states: all implementations must accept and be able to handle any legitimate RFC 4291 format. best Enno http://www.rfc-editor.org/errata_search.php?eid=2467 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Malin: East 5 or 6. Moderate or rough, occasionally very rough in northwest. Showers. Good, occasionally moderate. -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ===
Re: IPv6 isn't SMTP
mailbox@[IPv6:2001:12:34:56::78:ab:cd] You aren't allowed to use :: to abbreviate one zero hexadectet according to RFC 5952. http://www.rfc-editor.org/errata_search.php?eid=2467 Oh, look at that. I wonder how many people realized that it made an incompatible change to RFC 4291 four years ago. I certainly didn't. I wonder what problem they thought they were solving. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
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 Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: IPv6 isn't SMTP
On 03/26/2014 08:12 PM, Jimmy Hess wrote: As far as i'm concerned if you can force the spammer to use their own IP range, that they can setup RDNS for, then you have practically won, for all intents and purposes, as it makes blacklisting feasible, once again! Spammers can jump through these hoops --- but spammers aren't going to effectively scale up their spamming operation by using IP address ranges they can setup RDNS on. Tell that to the 100,000+ e-mails I blocked last week (and the several hundred that got through before I was able to get all the blocks entered into my ingress ACLs) from proper rDNS addresses where the addresses were hopping all over a /24, a /22, three /21's, four /20's, and six /19s in widely separated blocks. Every single address in those blocks eventually attempted to send e-mail, and every address had proper rDNS for the pseudorandom domain names, mostly in the .in TLD, but some others, too (the blocks were all over, with some registed through ARIN, some through RIPE, some through AfriNIC, and some through APNIC, with hosters in Europe, North and South America, Asia, and Africa.) Note that these passed full FCrDNS verification in postfix. They all had very similar characteristics, including an embedded image payload/ad and a couple of hundred kB of anti-Bayesian text, including the full text of Zilog's Z80 manual at one point. Of course, the other tens of thousands per day that get blocked for not having rDNS from residential bots make the case for leaving rDNS (and the FCrDNS variant) turned on, but it is not a cure-all.
Re: why IPv6 isn't ready for prime time, SMTP edition
Ergo, ad hominem. Please quit doing that. As a side note I happen to run my own mail server without spam filters -- it works for me. I might not be the norm, but then again, is there really a norm? (A norm that transcends SMTP RFC reach, that is -- I know a lot of people who run a lot of mail systems, and let's just say you're so far out in the long tail we need a telescope to see you. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability
For anyone who was subscribed to the old full-disclosure list ... Fydor of nmap has brought it back to life. Infolink @ http://insecure.org/news/fulldisclosure/ Subscribe @ http://nmap.org/mailman/listinfo/fulldisclosure On Mar 26, 2014, at 10:52 AM, kendrick eastes keas...@gmail.com wrote: The Full-disclosure mailing list was recently... retired, I guess cisco thought NANOG was the next best place. On Wed, Mar 26, 2014 at 10:45 AM, rw...@ropeguru.com rw...@ropeguru.comwrote: Is this normal for the list to diretly get Cisco security advisories or something new. First time I have seen these. Robert On Wed, 26 Mar 2014 12:10:00 -0400 Cisco Systems Product Security Incident Response Team ps...@cisco.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco IOS Software SSL VPN Denial of Service Vulnerability Advisory ID: cisco-sa-20140326-ios-sslvpn Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary === A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of Cisco IOS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. The vulnerability is due to a failure to process certain types of HTTP requests. To exploit the vulnerability, an attacker could submit crafted requests designed to consume memory to an affected device. An exploit could allow the attacker to consume and fragment memory on the affected device. This may cause reduced performance, a failure of certain processes, or a restart of the affected device. Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/ CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+ mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7 RF3x0wYuErbbC7N9m1UH =1Ixo -END PGP SIGNATURE- signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [mailop] IPv6 DNSBL
On Thu, Mar 27, 2014 at 9:21 AM, David Hofstee da...@mailplus.nl wrote: There must be a good reason for people to get of their asses and start implementing things like DMARC. All the banks (!$%^) I talk to do not have any reason to implement it swiftly (they turn on p=none and then all progress stops). Frustrating that they are too lazy to implement a few DNS records. It only needs firm backing by 3+ large companies like Hotmail. Give everyone on IPv6 without DMARC a large spamscore (and publish that beforehand ;-) ). Give me ammunition and all corporates will move. Please no. DMARC is great for 1:1 direct email (from:me, to:you). Anything other than p=none fails miserably once the scope is expanded. Let me give you examples of things that would fail miserably under your suggestion above: 1) This list 2) The recent, heavily forwarded and reflected, Cisco PSIRT notices. NANOG is not the place to debate this, nor is it the place to advocate self inflicted harm. -Jim P.
Re: WKBIs, was why IPv6 isn't ready for prime time, SMTP edition
Actually, a variant on that that might be acceptable� Make e-postage a deposit-based thing. If the recipient has previously white-listed you or marks your particular message as �desired�, then you get your postage back. If not, then your postage is put into the recipients e-postage account to offset the cost of their emails. Thoughts? You could have bought the patent on this WKBI on eBay last year: http://www.ebay.com/itm/251279133681 When I was running the ASRG, I set up a wiki where we could keep a taxonomy of anti-spam techniques, so we could save time and just point people at it when they reinvent them. It's still there, contributions of anything we've missed are still welcome: http://wiki.asrg.sp.am/wiki/Attention_bonds R's, John PS: Well Known Bad Idea
[no subject]
So I certainly admit I am a basic networking guy and in the past have not had to get into the nitty gritty of port statistics. I am trying to understand some statistics off a switch port in a Nexus 4001i. All TX and RX counters look normal except on the TX side, I am showing 1107597 input discards. Last clearing of show counters is 1d8h ago. I have it in my mind that this particular counter is dropping packets coming in from another port inside the switch that are to be transmitted out to the end server. So lets say the interface I am looking at is port 2 on the switch. So server 1 sends a packet to port 1 on the switch. That packet then traverses to backplane, or inside the same ASIC, to port 2 on the switch. It is then dropped and not transmitted out to server 2. Is the scenario I just presented correct? Not looking for the reason in this email, just that my logical understanding is correct. Robert Sent from my Verizon Wireless 4G LTE smartphone
RE: Switchport Counters
Sent from my Verizon Wireless 4G LTE smartphone Original message From: rw...@ropeguru.com Date:03/27/2014 11:52 AM (GMT-05:00) To: nanog@nanog.org Subject:
Re: WISP or other options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/03/14 14:04, Dustin Jurman wrote: There are plenty of Microwave products that produce that type of bandwidth and more, LOS and NLOS. I do not know if there is a WISPA counterpart in Scotland but you may want to reach out to WISPA to see if they know of an organization. You can also reach out to Cambium to see whom their partners are in the area. Indeed - there's fairly local transit capacity (though it is via a BT exchange, so good luck actually getting a reasonable price off BTWC for a temporary line) and doing LOS on some temporary towers should be within the capabilities of some creative engineers. WISPA might be a good starting point, INCA can certainly put you in touch with the local crowd to advise. Either way it'd certainly work out a heck of a lot cheaper than sat. You can do 3G (DC-HSDPA) in that area on at least one MNO but probably want a decent directional antenna with some gain on it. That'd probably work out cheapest, but will be bandwidth limited and you'd be looking at a fair few devices bonded to get that much bandwidth. - -- Cheers, James -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTNEvqAAoJENTyYHL8dmp9StIP/RnilFJ1SzfEqsQ5dkxMO+Hg jc7b4q41h7sNiWoWjRPbjc/nRsG0JNHIK/JicfuOKVzlrCIBdhO30B+EnR2DhZ+i roc09WwbJckwoGwTZjvXESm1qJE1bZTynr7nrrc7WFXak6HDN3MZqhHlkElShYAg i7Al5m5LjUFXKr+xorOam84w/DcmgFCi5SzAQOu5fTvQxbJ1gmiwb+n7q5V6xzRH /B+bRFBwaqW6mtTQ2Wh9lxxXaMoIRHWfo/AlI21Z8FyKANArypqBC3YNw0BSkeBP kN3dRy6AlbmhFQ3XaiOrYiHbx/vp4WV3VVe6S8/Suey2eKASmyglB3nfeCYvokOk kvMs4phfE8lTAntMm0HKykHtZHtPbUdwTOag4TyYCjlBtLZahBDqF9Q6TFwuhhxL e1Vi86PEpPgMGAGlim81DCHu9/BwWsvnp2R98/hAW5bMTanm6sBcAera0EYrAtKr MXYN5WOmAZzVxW/x1nbtxYBM8iNG2fY/w0lGDH+2Z7DgJxP/WQOVUhU3UCJcQYgi jkx9BSjBJJtyR6F/WKxKbDhIaTfZ58Y7qNqXpg27z1KuCxkz9HdpjYH2kuMO5icx Hq29kD4cJm5APCcBjyP8mlIyHG2GZqeNmJLaSfmCWYwhuf/XOKQQbgtOdfMLsoyS z3OJ0iuivtdirXz7RAoR =eyO1 -END PGP SIGNATURE-
Re: IPv6 Security
DHCPv6 as defined in RFC 3315 does not offer client MAC address at all (thus making the job more difficult for a number of organizations). Yes it does… What do you think “Link Layer Address” (RFC 3315, Section 9.1 Type 3) is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what this is intended to be. True, it includes an additional 16 bits of media type, - I cannot a priori know which DUID type a particular client will use. Of the three DUID types in RFC 3315 section 9.1, type 1 and 3 include link layer address while type 2 does not. - As has already been pointed out, the same physical hardware may use different DUID types when booted with different operating systems. - The language in RFC 3315 is pretty explicit in saying that a server *must* treat the DUID as an opaque value - in other words, you are not allowed to inspect it in any way to find the presumed MAC address and take any action based on the MAC address. All I've seen so far indicates that this was a deliberate choice by the DHCPv6 designers, and in my opinion a very poor one. Fortunately we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and we're waiting for vendors to implement this. That solves one half of the problem. Yes and no. At the time RFC3315 was written, network cards changed independent of motherboards on a regular basis and this fact was a source of great consternation for DHCPv4 operators. Over time, that changed AFTER RFC3315 was written, but if you read section 9.4, it seems pretty clear that this change was anticipated by the authors and that DUID-LL was intended for the situation we have today. I think understand the well-meant intentions of the RFC 3315 authors. However, my claim is that the actual end result for IPv6 leaves us in a *worse* situation than for IPv4. And one which, among others, makes it very difficult to correlate IPv4 and IPv6 leases (something which I have no need for today, but which I could easily see a need for in the future). Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: Link Layer Filtering not supported on popular equipment?
On Wed, Mar 26, 2014 at 9:08 AM, hasser css hasserva...@gmail.com wrote: Is there any common equipment that doesn't support this kind of filtering? I have no access to the switches where I work (I am just a CS agent at a smaller service provider), but my boss tells me that they do not support doing this... however, I do not believe this at all. I think that all the switches are all from Dell. Issues are happening as some customers accidentally have rogue DHCP servers running from their routers being connected improperly, and his only solution to this issue is to disable the switch port instead of simply preemptively filtering out this. Any insight? Regards. The supported options vary within the PowerConnect product line. So it depends entirely on WHAT exact switch. Some do support DHCP snooping like that, some don't. Even with it on it can create it's own problems, on the 6248 f/ex this causes the DHCP replies from trusted ports to always get copied to the CPU so it can inspect them and create it's VLAN+MAC+IP bindings databases. All untrusted port DHCP traffic gets punted to CPU. The gist is that this can open up a potential DoS attack on the switch, or, even without that, the DHCP traffic might be too high for the switch to manage. Similar issues with ACLs. There are some options in Cisco (not certain if any of dell's products have this) that basically keep ports from talking to eachother, but allow them to talk to the upstream port (usually a router that can then enforce deeper ACLs and such). All of these additional protection/security methods can have their drawbacks for any particular environment, assuming the hardware even supports them. -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler
Switchport Counters - Take two
Apologies to everyone for the original email with no subject. I am having some senior email moments today. Anyway So I certainly admit I am a basic networking guy and in the past have not had to get into the nitty gritty of port statistics. I am trying to understand some statistics off a switch port in a Nexus 4001i. All TX and RX counters look normal except on the TX side, I am showing 1107597 input discards. Last clearing of show counters is 1d8h ago. I have it in my mind that this particular counter is dropping packets coming in from another port inside the switch that are to be transmitted out to the end server. So lets say the interface I am looking at is port 2 on the switch. So server 1 sends a packet to port 1 on the switch. That packet then traverses to backplane, or inside the same ASIC, to port 2 on the switch. It is then dropped and not transmitted out to server 2. Is the scenario I just presented correct? Not looking for the reason in this email, just that my logical understanding is correct. Robert
Re:
On 3/27/14, rw...@ropeguru.com rw...@ropeguru.com wrote: So I certainly admit I am a basic networking guy and in the past have not had to get into the nitty gritty of port statistics. I am trying to understand some statistics off a switch port in a Nexus 4001i. Good luck. I couldn't find anything for a nexus 4000, but did find this for IOS: In-Discard - The result of inbound valid frames that were discarded because the frame did not need to be switched. This can be normal if a hub is connected to a port and two devices on that hub exchange data. The switch port still sees the data but does not have to switch it (since the CAM table shows the MAC address of both devices associated with the same port), and so it is discarded. This counter can also increment on a port configured as a trunk if that trunk blocks for some VLANs, or on a port that is the only member of a VLAN. so if you've got something like switch a: switchport trunk allowed vlan 1-5 switch b: switchport trunk allowed vlan 1-4 when switch a sends a frame on vlan 5, switch b counts it as an input discard. Lee All TX and RX counters look normal except on the TX side, I am showing 1107597 input discards. Last clearing of show counters is 1d8h ago. I have it in my mind that this particular counter is dropping packets coming in from another port inside the switch that are to be transmitted out to the end server. So lets say the interface I am looking at is port 2 on the switch. So server 1 sends a packet to port 1 on the switch. That packet then traverses to backplane, or inside the same ASIC, to port 2 on the switch. It is then dropped and not transmitted out to server 2. Is the scenario I just presented correct? Not looking for the reason in this email, just that my logical understanding is correct. Robert Sent from my Verizon Wireless 4G LTE smartphone
Re:
It is actually a 4001i for an IBM Blade Chassis. Sorry for that. So in this setup, port a would be a trunk with multiple vlans connection back to a 6509. port b would be a switch port in access mode that connects to an IBM blade in the chassis. Not sure that this situation fits either of those scenarios. Overall problem is that we are seeing performance issues between servers. These servers are all AIX based. We believe/know that we have some misconfigurations in the environment with jumbo frames and flow control. My curiosity about the discards is due to those misconfigurations. The port I mentioned in my original email has around 480 million output packes to the 1.1 million discards. We do have IBM and Cisco support engaged, I am just trying to make sure I understand enough to be dangerous when I am working with them. Robert On Thu, 27 Mar 2014 12:55:46 -0400 Lee ler...@gmail.com wrote: On 3/27/14, rw...@ropeguru.com rw...@ropeguru.com wrote: So I certainly admit I am a basic networking guy and in the past have not had to get into the nitty gritty of port statistics. I am trying to understand some statistics off a switch port in a Nexus 4001i. Good luck. I couldn't find anything for a nexus 4000, but did find this for IOS: In-Discard - The result of inbound valid frames that were discarded because the frame did not need to be switched. This can be normal if a hub is connected to a port and two devices on that hub exchange data. The switch port still sees the data but does not have to switch it (since the CAM table shows the MAC address of both devices associated with the same port), and so it is discarded. This counter can also increment on a port configured as a trunk if that trunk blocks for some VLANs, or on a port that is the only member of a VLAN. so if you've got something like switch a: switchport trunk allowed vlan 1-5 switch b: switchport trunk allowed vlan 1-4 when switch a sends a frame on vlan 5, switch b counts it as an input discard. Lee All TX and RX counters look normal except on the TX side, I am showing 1107597 input discards. Last clearing of show counters is 1d8h ago. I have it in my mind that this particular counter is dropping packets coming in from another port inside the switch that are to be transmitted out to the end server. So lets say the interface I am looking at is port 2 on the switch. So server 1 sends a packet to port 1 on the switch. That packet then traverses to backplane, or inside the same ASIC, to port 2 on the switch. It is then dropped and not transmitted out to server 2. Is the scenario I just presented correct? Not looking for the reason in this email, just that my logical understanding is correct. Robert Sent from my Verizon Wireless 4G LTE smartphone
Re: IPv6 Security [Was: Re: misunderstanding scale]
On 03/26/2014 11:14 PM, Owen DeLong wrote: Why not just use private VLAN layer 2 controls for the privacy you describe? The technology I know of is what cisco calls 'protected ports' - My understanding is that those simply mean you can't pass traffic to or from other 'protected ports' - I use that capability when, say, putting a bunch of IPMIs on a private network, it works great, as if one of the IPMI ports is trying to talk to another, something is very wrong and it gets blocked. They are commonly used in the dedicated server hosting world to do what you are describing, but they have a big downside when being used on the public side;customer 1 can't talk to customer 2.Now, this isn't usually a big deal, except in one very common case; what if one entity buys two hosts? now those two hosts can't talk to oneanother. This is a very common problem for dedicated hosting providers (and why I give my dedicated hosts a vlan and a routed subnet, wasting IPv4.) For my virtuals, though, I have a much more clever switch as it's just some software running in the Dom0, so at least in the IPv4 world, filtering just their /32 in and out is a much better solution. Yes, you risk customer A spoofing customer B, but is that really a problem in your environment? Really? If so, one could argue you might want to consider getting a better class of customers. You wouldn't feel uncomfortable if some other company could come in and not only spoof your IP, but receive the return traffic? Keep in mind that they could do this in a way that is quite difficult to detect or trace, if they were clever about it. I may trust my provider, to a certain extent, but I certainly don't trust everyone who gives my provider money.
Re: IPv6 Security [Was: Re: misunderstanding scale]
It might make sense to just give everyone their own vlan and their own /64; that would, of course, bring its own problems and complexities (namely that I've gotta have the capability to deal with more customers than I can have native vlans - not impossible to get around, but significant added complexity.) I don’t see the point of that. why not? After carefully considering everything you have told me, this sounds like the way forward to do it the IPv6 way - privacy IPs would work fine, and I could filter every port such that only packets from that /64 were allowed out and only addresses to that /64 would be allowed in.Nobody would be able to spoof or listen in on their neighbor; yeah, my router would have to send a lot of RAs, but routers that handle the amount of traffic my customers send are cheap. I have a lot of customers, sure, but they are small. Sure, it's going to cost me in routing complexity, but it looks like the only thing I can do that will actually solve my problems and use IPv6 the way IPv6 is expecting to be used. I'd then have to figure out how to make their ipv4 /32 work, but I can think of several possibilities that might work. If nothing else, I could give them one interface for IPv6 and one for IPv4, and leave the IPv4 interface the current system.
Re: misunderstanding scale
On March 26, 2014 at 22:17 o...@delong.com (Owen DeLong) wrote: Then the spammers will grab /48s instead of /64s. Lather, rinse, repeat. Hang on, do spammers grab address blocks? Ok, I'm sure it happens, this is not an existence proof. But is that really a significant characterization of their behavior? That they go to an RIR or ISP and get an address block allocation? I mean post-Ralsky (almost obscure historical spam reference.) It seems like ALL the spam I see is purloined resources: botnets, unauthorized use of (usually misconfigured) mail servers, web software holes, free sites in general (such as google groups but also those community free sites), etc. I suppose this is the place where someone just says: Yes, Barry, it is and considers the matter settled but it sure doesn't match my experience. We block a lot of /24s (like about 150,000 right now) and even a few larger chunks but not because they're owned by spammers but because they're repeatedly ABUSED by spammers. But unfortunately they're just about always owned by people/companies who believe they're legitimate but just can't seem to keep the spammers from abusing them over and over. And the chance of ham from them is so slight that one just blocks them wholesale. Well, maybe for the purpose of this discussion it's the same thing, how do you block blocks which are being abused or you want to block for whatever reason. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Former 360/Ledcor employees from the NW
I am looking for some fiber in the PNW coastal area and for that field tech that knows where all the skeletons and vaults might be buried. I know Ledcor installed it, 360-networks bought it and then Zayo now owns it but cannot find it on their maps. ryan
Re: IPv6 Security [Was: Re: misunderstanding scale]
On 3/27/2014 12:19 PM, Luke S. Crawford wrote: This is a very common problem for dedicated hosting providers (and why I give my dedicated hosts a vlan and a routed subnet, wasting IPv4.) Implement what some DSL access providers do. Unnumbered interfaces with /32 routing to the vlan. The last I checked, I think a J can even get the /32 route from radius when using autoconfig with radius auth. We did similar things with IPv6, as well. proxy-arp/proxy-nd to handle the cross talk. IOS 12.1 7206 confirmed. No autoconf, but static subinterfaces for each vlan (q-in-q supported or atm), unnumbered to loopback. DHCPv4 and static routing works. IPv6 had issues, but could handle static /64 per subint. ASR/J MX, autoconfig w/ radius backend, manual subint/unit, or combination. DHCPv4 confirmed, static host routes confirmed. IPv6 not confirmed. Radius static host route establishment not confirmed. Still testing. Jack
Re: why IPv6 isn't ready for prime time, SMTP edition
On March 26, 2014 at 22:25 o...@delong.com (Owen DeLong) wrote: Actually, a variant on that that might be acceptable? Make e-postage a deposit-based thing. If the recipient has previously white-listed you or marks your particular message as ?desired?, then you get your postage back. If not, then your postage is put into the recipients e-postage account to offset the cost of their emails. Thoughts? It's a fine idea but too complicated. Look, the (paper) post office doesn't say oh, you WANTED that mail, ok, then we'll return the cost of postage to the sender! Why? Because if they did that people would game the system, THEY'D SPAM! And it would take way too much bookkeeping and fraud identification etc. Let's take a deep breath and re-examine the assumptions: Full scale spammers send on the order of one billion msgs per day. Which means if I gave your account 1M free msgs/day and could reasonably assure that you can't set up 1,000 such accts then you could not operate as a spammer. Who can't operate with 1M msgs/day? Well, maybe Amazon or similar. But as I said earlier MAYBE THEY SHOULD PAY ALSO! We really need to get over the moral component of spam content (and senders' intentions) and see it for what it is: A free ride anyone would take if available. Ok, a million free per acct might be too high but whatever, we can all go into committee and do studies and determine what the right number should be. I'd tend towards some sort of sliding scale myself, 100K/day free, 1M/day for $1, 10M/day for $100, 100M/day for $10K, etc. Something like that. Why would it work? Because that's how human society works. People who are willing to pay their $10K/mo will demand something be done about freeloaders, enforcement has to be part of the cost overhead. And it'd create an economy for hunting down miscreants. There really is none now, outside of the higher profile DDoS or phishing sort of activities. I claim it wouldn't take much of this to shut down spammers. P.S. And in my vision accepting only email with valid e-postage would be voluntary though I suppose that might be voluntary at the provider level. For example someone like gmail at some point (of successful implementation of this scheme) might decide to just block invalid e-postage because hey your gmail acct is free! Let someone else sell you rules you prefer like controlling acceptance of invalid e-postage yourself. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: why IPv6 isn't ready for prime time, SMTP edition
Scott, You are exactly right, in the current environment the things I'm suggesting seem unrealistic. My point is that it doesn't have to work the way it does today, with the webmail providers, the mail originators and the spam warriors all scratching each others' backs. There has been a LOT of work done to make webmail easy and everything else practically impossible, even if you do know how it works. What if Google, Apple, Sony or some other household brand, sold a TV with local mail capabilities, instead of pushing everyone to use their hosted services? If it doesn't work because we are blocking it on purpose, customers would demand that we make it work. Since this isn't a well known option today, casual (non tech) users don't know that they should be demanding it. As far as why someone would want an MTA, it doesn't take long to explain the benefits of having control over your own email instead of having a third party reading it all. The problem is that instead users are told they can't have it. MTAs are built into every user operating system and they would work just fine if the email community wasn't going out of their way to exclude them. The lack of rDNS is just one of the many ways to identify and discriminate against end users who haven't bought their way into the club. Spam is not a big problem for everyone. It's at a different scale for individuals and for large sites with many users. -Laszlo On Mar 26, 2014, at 2:58 PM, Scott Buettner sbuett...@frii.net wrote: This is totally ignoring a few facts. A: That the overwhelming majority of users don't have the slightest idea what an MTA is, why they would want one, or how to install/configure one. ISP/ESP hosted email is prevalent only partially to do with technical reasons and a lot to do with technical apathy on the part of the user base at large. Web hosting is the same way. A dedicated mailbox appliance would be another cost to the user that they would not understand why they need, and thus would not want. In a hypothetical tech-utopia, where everyone was fluent in bash (or powershell, take your pick), and read RFCs over breakfast instead of the newspaper, this would be an excellent solution. Meanwhile, in reality, technology frightens most people, and they are more than happy to pay someone else to deal with it for them. B: The relevant technical reason can be summarized as good luck getting a residential internet connection with a static IP (If your response includes the words dynamic DNS then please see point A) (Also I'm just going to briefly touch the fact that this doesn't address spam as a problem at all, and in fact would make that problem overwhelmingly worse, as MTAs would be expected to accept mail from everywhere, and we obviously can't trust end user devices or ISP CPE to be secure against intrusion) Scott Buettner Front Range Internet Inc NOC Engineer On 3/26/2014 8:33 AM, Laszlo Hanyecz wrote: Maybe you should focus on delivering email instead of refusing it. Or just keep refusing it and trying to bill people for it, until you make yourself irrelevant. The ISP based email made more sense when most end users - the people that we serve - didn't have persistent internet connections. Today, most users are always connected, and can receive email directly to our own computers, without a middle man. With IPv6 it's totally feasible since unique addressing is no longer a problem - there's no reason why every user can't have their own MTA. The problem is that there are many people who are making money off of email - whether it's the sending of mail or the blocking of it - and so they're very interested in breaking direct email to get 'the users' to rely on them. It should be entirely possible to build 'webmail' into home user CPEs or dedicated mailbox appliances, and let everyone deal with their own email delivery. The idea of having to pay other people to host email for you is as obsolete as NAT-for-security, and this IPv6 SMTP thread is basically covering the same ground. It boils down to: we have an old crappy system that works, and we don't want to change, because we've come to rely on the flaws of it and don't want them fixed. In the email case, people have figured out how to make money doing it, so they certainly want to keep their control over it. -Laszlo On Mar 26, 2014, at 2:07 PM, Lamar Owen lo...@pari.edu wrote: On 03/25/2014 10:51 PM, Jimmy Hess wrote: [snip] I would suggest the formation of an IPv6 SMTP Server operator's club, with a system for enrolling certain IP address source ranges as Active mail servers, active IP addresses and SMTP domain names under the authority of a member. ... As has been mentioned, this is old hat. There is only one surefire way of doing away with spam for good, IMO. No one is currently willing to do it, though. That way? Make e-mail cost;
Education Committee Update
Hi folks, I would like to provide a brief update from the NANOG Education Committee. We have filled several of the open committee positions but are still looking for more volunteers. We need a Director of Instruction and several more Members at Large. Please contact Betty or myself if you are interested in participating in the group. My thanks go out to those who have already volunteered, as follows: Vice-Chair: Steve Gibbard Program Director: Paul Emmons Technical Director: Brandon Ross Member at Large: Chris Spears Of course, we continue to receive support from Betty Burke, Executive Director and Valerie Wittkop for Project Management. On the instruction front, we have two classes getting lined up for the Bellevue NANOG. David Barak will be joining us again to teach our 3rd Routing Fundamentals class and we are finalizing contracts now for an IPv6 course. Registration will be open soon for both courses so stay tuned. Dave Siegel Chair, Ad-hoc Education Committee (NANOG)
Re: IPv6 isn't SMTP
On March 27, 2014 at 08:51 bl...@ispn.net (Blake Hudson) wrote: The primary issues I see with SMTP as a protocol related to the lack of authentication and authorization. Take, for instance, the fact that the SMTP protocol requires a mail from: and rcpt to: address (more or less for authentication and authorization purposes), but then in the message allows the sender to specify a completely different set of sender and recipient information that gets displayed in the mail client. This is mostly a UI issue. The user interface could show anything, custom certainly has been as you describe: Show the message From: and make it tricky (for most people) to get the envelope info. Well, it's not mandatory that an MTA transmit the envelope info into the message headers and, almost worse, different MTAs seem to use different header fields for this. For example in SpamAssassin you are encouraged to set which field it should look at for the envelope sender. But that's not REALLY a problem with SMTP per se. Only in practice, if that's a useful distinction. I won't go point by point but I will say that SMTP has been extended several times -- just throw another verb into the mix to extend it. Which is a very useful observation. SMTP also can transmit which verbs are supported. One can extend a new idea and it's immediately interoperable. I suppose the obvious question is: What's to stop a spammer from putting a totally legitimate key into their spam? You also need some sort of reputation layer. Or maybe that makes it unworkable. I remember at the 2006 MIT Spam Conference where Eric Allman and I were keynotes we got into a bit of a tussle over exactly this during his question period. It was...amusing! -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Remote Hands Spokane, WA?
Anyone available for remote hands (installing memory) in Spokane, WA on a Thursday during business hours? -A
Re: IPv6 isn't SMTP
Barry Shein wrote the following on 3/27/2014 2:06 PM: I suppose the obvious question is: What's to stop a spammer from putting a totally legitimate key into their spam? It's entirely likely that a spammer would try to get a hold of a key due to its value or that someone you've done business with would share keys with a business partner . But ideally you'd authorize each sender with a unique key (or some sort of pair/combination). So that 1) you can tell who the spammer sourced the key from and 2) you can revoke the compromised key's authorization to send you subsequent email messages. There's probably some way to generate authorization such that each sender gets a unique key or a generic base is in some way salted or combined with information from the individual you're giving your authorization to such that the result is both unique and identifiable. --Blake
Re: why IPv6 isn't ready for prime time, SMTP edition
On Mar 27, 2014, at 11:15 AM, Barry Shein b...@world.std.com wrote: On March 26, 2014 at 22:25 o...@delong.com (Owen DeLong) wrote: Actually, a variant on that that might be acceptable… Make e-postage a deposit-based thing. If the recipient has previously white-listed you or marks your particular message as “desired”, then you get your postage back. If not, then your postage is put into the recipients e-postage account to offset the cost of their emails. Thoughts? It's a fine idea but too complicated. Look, the (paper) post office doesn't say oh, you WANTED that mail, ok, then we'll return the cost of postage to the sender! Why? Because if they did that people would game the system, THEY'D SPAM! How would they benefit from that? SPAM — Pay, say $0.10/message. Then Claim you wanted the SPAM, get your $0.10/message back for each SPAM you sent to yourself. Or, claim you didn’t want the SPAM and get $0.05/message for each message you received while the original provider keeps the other $0.05. And it would take way too much bookkeeping and fraud identification etc. Please explain in detail where the fraud potential comes in. By my interpretation, you’d have to somehow get more back than you deposited (not really possible) in order to profit from sending SPAM this way. Let's take a deep breath and re-examine the assumptions: Full scale spammers send on the order of one billion msgs per day. Which means if I gave your account 1M free msgs/day and could reasonably assure that you can't set up 1,000 such accts then you could not operate as a spammer. Not sure how you enforce these user account requirements or how you avoid duplicative accounts. Who can't operate with 1M msgs/day? Well, maybe Amazon or similar. But as I said earlier MAYBE THEY SHOULD PAY ALSO! I, for one, don’t want my Amazon prices increased by a pseudo-tax on the fact that they do a large volume of email communications with their customers. They have enough problems trying to get IPv6 deployed without adding this to their list of problems. We really need to get over the moral component of spam content (and senders' intentions) and see it for what it is: A free ride anyone would take if available. I disagree. I see it as a form of theft of service that only immoral thieves would take if available. Ok, a million free per acct might be too high but whatever, we can all go into committee and do studies and determine what the right number should be. I'd tend towards some sort of sliding scale myself, 100K/day free, 1M/day for $1, 10M/day for $100, 100M/day for $10K, etc. Something like that. Why would it work? Because that's how human society works. People who are willing to pay their $10K/mo will demand something be done about freeloaders, enforcement has to be part of the cost overhead. But who charges these fees and how do they enforce those charges against miscreants that are sending from stolen hosts, bots, fraudulent IP addresses, etc.? And it'd create an economy for hunting down miscreants. So you’ve got a set of thieves who are stealing services to send vast volumes of email and you want to solve that problem by charging them more for those services that they are stealing (and, by the way, also charging some legitimate users as well). My guess is that the spammers are going to keep stealing and the people now being taxed for something that used to be free are going to object. P.S. And in my vision accepting only email with valid e-postage would be voluntary though I suppose that might be voluntary at the provider level. For example someone like gmail at some point (of successful implementation of this scheme) might decide to just block invalid e-postage because hey your gmail acct is free! Let someone else sell you rules you prefer like controlling acceptance of invalid e-postage yourself. Well, here we get a hint at how you envision this working. There are lots of details that need to be solved in the implementation of such a scheme and I think the devil is prevalent among them. Owen
Re: IPv6 isn't SMTP
Barry Shein wrote the following on 3/26/2014 11:24 PM: Some will blanche at this but the entire spam problem basically arose from the crap security in Windows systems, particularly prior to maybe XP/SP2. Not sure where all that leads us, however. Better security at those major exploitation points, in a nutshell. And if someone disagrees then please tell me how spammers as we know them (and related miscreants) can operate without these few sources of purloined resources. Preferably without a big hand-wave like oh they'll just find something else! Maybe not! You're largely right. Botnets are a big source of spam. As a mail server operator, they're the biggest source that I see. They're also easy to block through a number of means (The ISPs they're located on often block port 25, PBL (or similar), rDNS, and other behavior). It sounds like it will likely be a similar matter of blocking residential botnet participants on IPv6 due to the fact that residential ISPs will likely apply similar port 25 policy to IPv6 as they do to IPv4 and no rDNS. However, as more attention is being payed to secure these end stations, spammers are looking at alternative avenues. In recent years, they've been harvesting user credentials through various means and then exploiting these compromised accounts to send email through otherwise legitimate servers. These are the spam messages that are hard to block. And these may be the areas where reputation based services will not be able to keep up in an IPv6 landscape. At least this concentrates the sources of spam (from my server's vantage point) and reduces the attack surface so that the problem is likely addressed more quickly and by someone with a higher level of knowledge than the average (unknowing) botnet participant. Unfortunately, I can't keep Suzie teenager or Joe grandpa from giving his or her password out to a phisher. Fortunately, I can place reasonable limits on their accounts and the number of messages they're allowed to send or the rate at which they're allowed to send messages. If everyone else would just do the same we'd be a lot better off against this kind of attack. --Blake
Re: Remote Hands Spokane, WA?
I know a guy that lives out that way if you'd like me to bring him in. -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN On Mar 27, 2014, at 15:11, Aaron C. de Bruyn aa...@heyaaron.com wrote: Anyone available for remote hands (installing memory) in Spokane, WA on a Thursday during business hours? -A smime.p7s Description: S/MIME cryptographic signature
Re: why IPv6 isn't ready for prime time, SMTP edition
On Thu, 27 Mar 2014, Owen DeLong wrote: On Mar 27, 2014, at 11:15 AM, Barry Shein b...@world.std.com wrote: Please explain in detail where the fraud potential comes in. Spammer uses his botnet of zombie machines to send email from each of them to his own domain using the user's legitimate email address as From:. Spammer says it was unsolicited and keeps the full $.10/email that victim users have deposited into this escrow thing. Sounds a lot more profitable than regular spam. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross
Re: IPv6 Security
On Thu, 2014-03-27 at 05:34 -0700, Owen DeLong wrote: What do you think “Link Layer Address” (RFC 3315, Section 9.1 Type 3) is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what this is intended to be. True, it includes an additional 16 bits of media type, but I don’t see that as being a problem. Though to be fair 3315 also says that the DUID should be treated as an opaque blob, not parsed and bits extracted from it. From section 9: Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs. Regarding section 9.4, which you refer to: 3315 only uses MACs to *construct* useful DUIDs, not as a means of communicating MACs to clients or servers. Also, an operator cannot RELY on getting a MAC address in a DUID. DUID's *are* different and *do* require new ways of doing things. People will work it out. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability
On Wed, Mar 26, 2014 at 10:52:42AM -0600, kendrick eastes wrote: The Full-disclosure mailing list was recently... retired, I guess cisco thought NANOG was the next best place. Nope, they've been sending these things here for as long as I can remember. I have NFI why -- probably hubris, thinking that everyone running a network *must* have some Cisco somewhere. - Matt
Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)
john, i think your attemt to move the discussion to the arin ppml list exemplifies one core of the problem. this is not about address policy, but arin thinks of itelf as a regulator not a registry. contrast with the ripe community and the ncc, which is not nirvana but is a hell of a lot better. among other key differences, the ncc is engaged with the community through technical and business working groups. e.g. the database working group covers what you think of as whois and the routing registry. the wg developed the darned irr definition and continues to evolve it. consequence? the irr is actively used in two regions in the world, europe and japan (which likes anything ocd:-). the routing wg works with the ops to develop routing technology such as route flap damping. there is a reason that serious ops attend ripe meetings. yes, a whole lot of folk with enable are engaged. for years there has been a wg on the global layer nine issues. the dns wg deals with reverse delegation, root server ops, etc. and guess what, all the dns heavy techs and ops are engaged. there is a wg for discussing what services the ncc offers. the recent simplification and opening of services to legacy and PI holders happened in the ncc services wg, it was about services not addressing policy. and this is aside from daniel's global measurement empire. not sure it is a registry's job to do this, but it is a serious contribution to the internet. the ncc is engaged with its community on the subhects that actually interest operators and affect our daily lives. there is nothing of interest at an arin meeting, a bunch of junior wannabe regulators and vigilantes making an embarrassing mess. i've even taken to skipping nanog, if ras talks i can watch the recording. all the cool kids will be in warsaw. ops vote with our feet. randy
Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)
On Mar 28, 2014, at 5:27 AM, Randy Bush ra...@psg.com wrote: john, i think your attemt to move the discussion to the arin ppml list exemplifies one core of the problem. Randy - I offered ppml out of respect to the nanog subscribers, that is all... /John and this is aside from daniel's global measurement empire. not sure it is a registry's job to do this, but it is a serious contribution to the internet. the ncc is engaged with its community on the subhects that actually interest operators and affect our daily lives. there is nothing of interest at an arin meeting, a bunch of junior wannabe regulators and vigilantes making an embarrassing mess. i've even taken to skipping nanog, if ras talks i can watch the recording. all the cool kids will be in warsaw. ops vote with our feet. ran
Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)
And I would welcome discussion of how ARIN (and nanog) can be more like RIPE - that is very much up to this community and its participation far more than ARIN.. /John On Mar 28, 2014, at 5:27 AM, Randy Bush ra...@psg.com wrote: john, i think your attemt to move the discussion to the arin ppml list exemplifies one core of the problem. this is not about address policy, but arin thinks of itelf as a regulator not a registry. contrast with the ripe community and the ncc, which is not nirvana but is a hell of a lot better. among other key differences, the ncc is engaged with the community through technical and business working groups. e.g. the database working group covers what you think of as whois and the routing registry. the wg developed the darned irr definition and continues to evolve it. consequence? the irr is actively used in two regions in the world, europe and japan (which likes anything ocd:-). the routing wg works with the ops to develop routing technology such as route flap damping. there is a reason that serious ops attend ripe meetings. yes, a whole lot of folk with enable are engaged. for years there has been a wg on the global layer nine issues. the dns wg deals with reverse delegation, root server ops, etc. and guess what, all the dns heavy techs and ops are engaged. there is a wg for discussing what services the ncc offers. the recent simplification and opening of services to legacy and PI holders happened in the ncc services wg, it was about services not addressing policy. and this is aside from daniel's global measurement empire. not sure it is a registry's job to do this, but it is a serious contribution to the internet. the ncc is engaged with its community on the subhects that actually interest operators and affect our daily lives. there is nothing of interest at an arin meeting, a bunch of junior wannabe regulators and vigilantes making an embarrassing mess. i've even taken to skipping nanog, if ras talks i can watch the recording. all the cool kids will be in warsaw. ops vote with our feet. randy
Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)
hi john, i think your attemt to move the discussion to the arin ppml list exemplifies one core of the problem. I offered ppml out of respect to the nanog subscribers, that is all... i will refrain from characterizing the ppml list. needless to say, i do not subscribe. my point is that what arin does should be of interest to nanog subscribers. in theory, the ops are the arin community, the registry serves operations. if it is not of interest to ops, it is not serving the community. [ get out of s'pore yet? drc got delayed a day with a missing part for his plane! ] randy
Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)
On Mar 27, 2014 3:03 PM, John Curran jcur...@istaff.org wrote: And I would welcome discussion of how ARIN (and nanog) can be more like RIPE - that is very much up to this community and its participation far more than ARIN.. /John How about we fold ARIN into RIPE? Why not? I agree with all of Randy's points. I am sure RIPE can easily scale up to take on ARIN services, with fees being reduced for all involved due to economies of scale. CB On Mar 28, 2014, at 5:27 AM, Randy Bush ra...@psg.com wrote: john, i think your attemt to move the discussion to the arin ppml list exemplifies one core of the problem. this is not about address policy, but arin thinks of itelf as a regulator not a registry. contrast with the ripe community and the ncc, which is not nirvana but is a hell of a lot better. among other key differences, the ncc is engaged with the community through technical and business working groups. e.g. the database working group covers what you think of as whois and the routing registry. the wg developed the darned irr definition and continues to evolve it. consequence? the irr is actively used in two regions in the world, europe and japan (which likes anything ocd:-). the routing wg works with the ops to develop routing technology such as route flap damping. there is a reason that serious ops attend ripe meetings. yes, a whole lot of folk with enable are engaged. for years there has been a wg on the global layer nine issues. the dns wg deals with reverse delegation, root server ops, etc. and guess what, all the dns heavy techs and ops are engaged. there is a wg for discussing what services the ncc offers. the recent simplification and opening of services to legacy and PI holders happened in the ncc services wg, it was about services not addressing policy. and this is aside from daniel's global measurement empire. not sure it is a registry's job to do this, but it is a serious contribution to the internet. the ncc is engaged with its community on the subhects that actually interest operators and affect our daily lives. there is nothing of interest at an arin meeting, a bunch of junior wannabe regulators and vigilantes making an embarrassing mess. i've even taken to skipping nanog, if ras talks i can watch the recording. all the cool kids will be in warsaw. ops vote with our feet. randy
Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)
nanog is a separable game. it is currently very confused between form and substance, making committees for everything. like the bcop thing. two organizations, nanog and isoc, forming organizational structures to create a document store. the ops' doc store is ripe's because the ripe wgs produced work and someone realized they needed a place to stash it. so now nanog and isoc need to flag-plant. the up-side is that it's a great b-ark, keeps them from doing damage. And I would welcome discussion of how ARIN (and nanog) can be more like RIPE i purposefully phrased it a bit differently, how can arin engage, get real participation from, and serve its community, the operators. i was stealing examples from ripe. but, for concrete action, how about a half day session at the next nanog meeting on, for example, arin database services, whois and irr. not to try to reach hard conclusions or plans. but to open a dialog to explore what the community gets and wants from these services and how they are provided. or pick another key service. randy
Re: Access Lists for Subscriber facing ports?
two think that are simple, enforce bcp38 and ntp packet sizes rndy
Re: IPv6 isn't SMTP
On March 27, 2014 at 14:16 bl...@ispn.net (Blake Hudson) wrote: Barry Shein wrote the following on 3/27/2014 2:06 PM: I suppose the obvious question is: What's to stop a spammer from putting a totally legitimate key into their spam? It's entirely likely that a spammer would try to get a hold of a key due to its value or that someone you've done business with would share keys with a business partner . But ideally you'd authorize each sender with a unique key (or some sort of pair/combination). So that 1) you can tell who the spammer sourced the key from and 2) you can revoke the compromised key's authorization to send you subsequent email messages. There's probably some way to generate authorization such that each sender gets a unique key or a generic base is in some way salted or combined with information from the individual you're giving your authorization to such that the result is both unique and identifiable. Ok, this is a form of whitelisting with some authentication using public key technology. Sure. But is this really the problem you run into much? Someone impersonating a sender you consider whitelisted? I'm sure it happens. But at a systems level I think most of us are talking about the much more nefarious non-stop fire-hose of pure sewage. Some white list, but for many that runs too great a risk of rejecting serendipity, that great job offer from someone who was impressed by a post you made on NANOG, etc. So we get Challenge-Response etc as a workaround, which also has problems. Well, whatever, SPAM IS A BIG SUBJECT and there are a lot of perspectives. P.S. I always figured the problem you describe could be very trivially solved by just agreeing to stick some word in the header like: X-PassCode: swordfish It's not like anyone but the sender is likely to know that unless they really are in your mail stream in which case you have other problems. It would be nice if that were automated but it could be done manually. I have certain Subject: phrases I use with people, some funny, so they know it's almost certainly me. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: IPv6 isn't SMTP
On Mar 27, 2014, at 12:16 PM, Blake Hudson bl...@ispn.net wrote: It's entirely likely that a spammer would try to get a hold of a key due to its value or that someone you've done business with would share keys with a business partner . But ideally you'd authorize each sender with a unique key (or some sort of pair/combination). So that 1) you can tell who the spammer sourced the key from and 2) you can revoke the compromised key's authorization to send you subsequent email messages. There's probably some way to generate authorization such that each sender gets a unique key or a generic base is in some way salted or combined with information from the individual you're giving your authorization to such that the result is both unique and identifiable. (Not to single you out, but this is a good entry point.) So somewhere between this and the “every user should have their own MTA” idea, something would need to be done to close the end user usability gap. - “I just bought something from this boutique website, how do I (or my ISP) know how to let them email me my receipt?” - “My friend gave his buddy my email address to send a resume for that job opening I have. How do I permit him to send me email?” - “This .gov entity needs to email me about my (taxes|health care|car registration|…), how do I give them permission?” - “My long lost high school friend found my email address somewhere (and isn’t using gmail, hotmail, yahoo, ….), how do I keep her from getting blocked?” All of these end-user questions will have to be answered by any such technology which seeks to solve the spam problem using a manner such as you describe here. And if you’re going to say the solution is “in addition to my email address, in order to send me mail someone is going to have to know my (key|pass phrase|…)” then anything which currently collects your email address is also going to need to collect “that”. Therefore how do you control “that” from getting in the wrong hands in that list of emails someone is selling to spammers? Am I misunderstanding what’s being proposed here? To me the ubiquity of email is its own undoing — it’s so convenient because you can email anybody, anywhere, from anywhere, but it’s so spammable because you can email anybody, anywhere, from anywhere. -c
Why IPv6 isn't ready for prime time :-)
NANOG arguments on IPv6 SMTP spam filtering. Deutsche Telecom discusses IPv4-IPv6 migration: https://ripe67.ripe.net/presentations/131-ripe2-2.pdf Facebook goes public with their IPv4-IPv6 migration: http://www.internetsociety.org/deploy360/blog/2014/03/facebooks-extremely-impressive-internal-use-of-ipv6/ If you haven't started, you've got some work to do. Y2K/IPv6 consulting gigs? Nice little earner! -- Tim:
Re: why IPv6 isn't ready for prime time, SMTP edition
What if Google, Apple, Sony or some other household brand, sold a TV with local mail capabilities, instead of pushing everyone to use their hosted services? It would suck, because real users check their mail from their desktops, their laptops, and their phones. Your TV would not have the sophisticated mail sorting, archiving, and searching of the large mail systems. And, of course, when its cheap SSD flaked, you'd lose all your saved mail. I swear, this whole conversation feels like I've fallen through a wormhole into 1998.
Re: IPv6 isn't SMTP
On 3/27/2014 6:51 AM, Blake Hudson wrote: The primary issues I see with SMTP as a protocol related to the lack of authentication and authorization. Take, for instance, the fact that the SMTP protocol requires a mail from: and rcpt to: address (more or less for authentication and authorization purposes), Actually, for neither. Mail from was mislabeled; it merely provides an address to send return notices to, which is why it makes sense to permit it to be different from the rfc5322.From value. And, of course, rcpt to specifies a recipient address. auth/auth functions were tacked on much, much later, which is why their utility is so constrained. (20 years?) but then in the message allows the sender to specify a completely different set of sender and recipient information that gets displayed in the mail client. Yeah. Almost like it is approximating the difference between what is on the outside of a postal envelope versus what is on the letterhead and opening of a piece of paper mail, which also permit such independence... The essential problem with seeing these as 'problems' is confusing 'common' with 'required'. Common scenarios are fine, but so are the variants. The variants often blow apart the simplifying assumption that one can incorrectly believe from the common scenarios. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)
On Mar 28, 2014, at 6:04 AM, Randy Bush ra...@psg.com wrote: i will refrain from characterizing the ppml list. needless to say, i do not subscribe. my point is that what arin does should be of interest to nanog subscribers. in theory, the ops are the arin community, the registry serves operations. if it is not of interest to ops, it is not serving the community. I fully agree, but also respect that this community has made some conscience decisions regarding having ARIN be quite registry focused and letting NANOG evolve as as a forum of the operators in the region. I believe that several of the initiatives that you noted from the RIPE region could easily be viewed as falling under either organization. This community should not be disadvantaged by the structure of having a distinct registry and distinct operator forum, but it does mean that we need to be able to sort out _what_ the operators want and then where it gets done. Internet routing registries are a fine example; one could argue that it should be integrated with the number resource registry, but we also have examples of independent routing registries in active use (and I can see some potential reasons why operators might even want there to be a healthy separation between those functions.) If the community has one mind of what routing registry capabilities is wants here, including how it wants it governed and operated, I am quite certain that ARIN will support the direction, regardless of where it ends up being operated and how it ends up being governed. The lack I have noted over the years is lack of clear direction from the community, but that should not be something ARIN jumps in and tries to bring about - it needs to be of interest to (and led by) the operators on this list. We agree that ARIN needs to be relevant to the ops community, and I am very open minded to any suggestions you have, but don't exactly think that your examples from RIPE are necessarily where we want ARIN to go as much as things we want to have happen, whether that's ARIN, NANOG, or other associated organizations. On the other hand, your governance examples from RIPE (e.g. wg for discussing what services the ncc offers) are directly on target, and I will share them on some other lists that may defy characterization by you. [ get out of s'pore yet? drc got delayed a day with a missing part for his plane! ] (Getting closer... the last plane was a fail due to fuel pump issues; my dearest friends at United seemed have rerouted me through Hong Kong but omitted a flight onward. Oh well.) Thanks! /John
Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)
On Fri, Mar 28, 2014 at 02:04:30AM +, John Curran wrote: Internet routing registries are a fine example; one could argue that it should be integrated with the number resource registry, but we also have examples of independent routing registries in active use (and I can see some potential reasons why operators might even want there to be a healthy separation between those functions.) Speaking for myself, only here: I'll be happy to let ARIN manage routability of assignments, once they guarantee routability of said assignments. Cheers, --msa
Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)
On Mar 28, 2014, at 6:42 AM, Randy Bush ra...@psg.com wrote: ... i purposefully phrased it a bit differently, how can arin engage, get real participation from, and serve its community, the operators. i was stealing examples from ripe. but, for concrete action, how about a half day session at the next nanog meeting on, for example, arin database services, whois and irr. not to try to reach hard conclusions or plans. but to open a dialog to explore what the community gets and wants from these services and how they are provided. My earlier message was sent before I saw this, but I think we converged on the important point: ARIN needs to engage in a much better manner with the ops community (more than just an ARIN update preso and registration helpdesk); this should be closer to a services wg model. Got it, /John John Curran President and CEO ARIN
Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability
On 3/27/2014 4:07 PM, Matt Palmer wrote: On Wed, Mar 26, 2014 at 10:52:42AM -0600, kendrick eastes wrote: The Full-disclosure mailing list was recently... retired, I guess cisco thought NANOG was the next best place. Nope, they've been sending these things here for as long as I can remember. I have NFI why -- probably hubris, thinking that everyone running a network *must* have some Cisco somewhere. There used to be cisco 'wigs with well-known names on NANOG. One of them was probably asked to do it. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability
I wonder if they should be invited to only post a single message with the titles and links to the alerts so that people can follow it up. They should also include a link to their own list that they send the full alerts to. That way there could be some headline alerting to people that there is something in that topic available but avoids sending each alert to the list every time. Depends on compliance with the charter for the list but I think it might be nice list etiquette. Regards Alexander On 28/03/2014, at 3:27 pm, Larry Sheldon larryshel...@cox.net wrote: On 3/27/2014 4:07 PM, Matt Palmer wrote: On Wed, Mar 26, 2014 at 10:52:42AM -0600, kendrick eastes wrote: The Full-disclosure mailing list was recently... retired, I guess cisco thought NANOG was the next best place. Nope, they've been sending these things here for as long as I can remember. I have NFI why -- probably hubris, thinking that everyone running a network *must* have some Cisco somewhere. There used to be cisco 'wigs with well-known names on NANOG. One of them was probably asked to do it. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability
On 3/27/2014 7:44 PM, Alexander Neilson wrote: I wonder if they should be invited to only post a single message with the titles and links to the alerts so that people can follow it up. Why? Personally, I think it's fine. It only happens (at most) every six months (and sometimes more like a year). Depends on compliance with the charter for the list but I think it might be nice list etiquette. I'm surprised at the level of concern over this, considering it's an event that has been going on since before most of those posting about this were even on this list. I'm hoping (in vain, I'm sure) that my gently pointing out that those posts are useful to many people, and that their occurrence predates most of you, will make this non-issue die away (and you make me REALLY MISS srh). While I still worked (I don't now; I'm retired), it was nice to have those alerts, because it could be checked against the *things* *that* *should* *be* *patched* for sanity. Even now, there's still Cisco stuff on my toy network, and I *still* care. Could we just stick to the interesting issues of IPv6, and SMTP, and move on? Please? -- You've confused equality of opportunity for equality of outcomes, and have seriously confused justice with equality. (Woodchuck)
Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability
Alexander Neilson alexan...@neilson.net.nz wrote: I wonder if they should be invited to only post a single message with the titles and links to the alerts so that people can follow it up. i would prefer that the header be in blue, the titles in green, and the urls in magenta, in comic sans, of course randy
Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability
On 3/27/2014 11:57 PM, Randy Bush wrote: Alexander Neilson alexan...@neilson.net.nz wrote: I wonder if they should be invited to only post a single message with the titles and links to the alerts so that people can follow it up. i would prefer that the header be in blue, the titles in green, and the urls in magenta, in comic sans, of course I prefer flat ASCII text. That will shut most of them up. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability
On 3/28/2014 12:57 AM, Randy Bush wrote: Alexander Neilson alexan...@neilson.net.nz wrote: I wonder if they should be invited to only post a single message with the titles and links to the alerts so that people can follow it up. i would prefer that the header be in blue, the titles in green, and the urls in magenta, in comic sans, of course randy I disagree vehemently. That's far too simple of a system and doesn't convey the necessary information that should be in a summary document. Titles should be either cerise, amaranth or raspberry coloured, depending on the bug's severity, and the headers should be blue-gray, glaucous or steel blue depending on the day of the week the bug was discovered. Some people might whine that those colors are too close to each other, but they can just buy a colorimeter -- that's an operational problem anyways. I can agree to comic sans, as long as it blinks. Actually, we should probably just set up a committee for report styling. We really need an industry standard for this, and one that covers all possible reporting needs for at least the next 20 years. Shouldn't take more than a few weeks. I think I have a TPS report template around here that would be a great starting point :p
