nanog mailing list archives
Re: misunderstanding scale
From: hslabbert () stargate ca
Date: Mon, 24 Mar 2014 22:53:13 -0700
I don't want to try to even think about SMTP on IPv6. Reputation of email servers as well as the whole thought process of spam control rely on a list of IP address.IPv6 adds an entirely new aspect to it.
Really? It ain't that hard. Who in this list is going to set up generic PTRs for all your v6 space? Good luck shoving 2^64 addresses in a zone file, so you're doing it programmatically; quick show up of hands for anybody actually doing generic v6 PTRs? So, we're doing PTRs on an as-needed basis, e.g. router interface primary addresses (for traceroute prettiness), mail servers, etc. You try sending me email on v6 without a PTR, you're going to have to make a pretty damned convincing case for why I should accept mail from you.
If you want to do address-based reputations for v6 similar to v4, my guess is that it will start to aggregate to at least the /64 boundary (i.e. if you have a spambot in your /64, that block starts to get a bad reputation and any other hosts in that block are less likely to have their mail accepted). So, there's risk of collateral damage, but no more (and probably less) than the v4 equivalent where any hosts sitting NAT'd behind a single IP are blacklisted. In this v6 equivalent, you could probably even get away with whitelisting a single, trusted IP in that /64 while the remainder of the /64 has a bad rep.
If you mean that e.g. you have a spambot that's using SLAAC and so can/will bounce around to different GUAs all over the place and so get around blacklisting, I would venture aggregating at the /64 level should take care of that; each additional IP within that block that's found to be spamming adds another hit to the block's reputation.
IP addresses and sender reputation do form a part of spam identification, but TBH so far I'm only seeing ways in which GUA helps *improve* the granularity at which those tools can be applied in order to reduce false positives. Granted, I haven't yet considered IP-based RBLs in v6 extensively, so I'm open to insights on this.
-- Hugo On 2014-03-25, Alexander Lopez <alex.lopez () opsys com> wrote:
-----Original Message----- From: Naslund, Steve [mailto:SNaslund () medline com] Sent: Monday, March 24, 2014 10:48 PM To: Owen DeLong; mark.tinka () seacom mu Cc: nanog () nanog org Subject: RE: misunderstanding scale Look at it this way. If I see an attack coming from behind your NAT, I'm gonna deny all traffic coming from your NAT block until you assure me you have it fixed because I have no way of knowing which host it is coming from. Now your whole network is unreachable. If you have a compromised GUA host I can block only him. Better for both of us, no?That is assuming that the infected piece does not request another address in the /64, and that the person blocking at the target end blocks a /128 instead of the /64.How about a single host spamming behind your NAT blocking your entire corporate public network from email services? Anyone ever see that one. Ipv6 GUAs allow us to use fly swatters instead of sledgehammers to deal with that.I don't want to try to even think about SMTP on IPv6. Reputation of email servers as well as the whole thought process of spam control rely on a list of IP address. IPv6 adds an entirely new aspect to it.Maybe GUAs will convince (scare) more enterprise users to actually treat the internal network as an environment that needs to be secured as well. We can only hope.Most enterprise admins, segment their BYOD (wifi) network from the production network. Some will even use a different WAN ip for the wifi network or in the minimum block outbound request to well known services ports. I generally see where the only outbound connections allowed are http and https. All other ports are blocked.Steven Naslund >>Bzzzt... But thanks for playing. >>An IPv6 host with a GUA behind a stateful firewall with default deny is every bit as secure as an iPv4 host with an RFC-1918 address behind a NAT44 gateway.I can't argue there.....>>Owen
Current thread:
- Re: misunderstanding scale, (continued)
- Re: misunderstanding scale Owen DeLong (Mar 24)
- Re: misunderstanding scale Timothy Morizot (Mar 24)
- Re: misunderstanding scale Mark Tinka (Mar 24)
- RE: misunderstanding scale Naslund, Steve (Mar 24)
- Message not available
- RE: misunderstanding scale Naslund, Steve (Mar 24)
- Re: misunderstanding scale hslabbert (Mar 24)
- Re: misunderstanding scale Owen DeLong (Mar 24)
- RE: misunderstanding scale Naslund, Steve (Mar 24)
- Re: misunderstanding scale Valdis . Kletnieks (Mar 24)
- RE: misunderstanding scale Alexander Lopez (Mar 24)
- Re: misunderstanding scale hslabbert (Mar 24)
- Re: why IPv6 isn't ready for prime time, SMTP edition John Levine (Mar 25)
- Re: why IPv6 isn't ready for prime time, SMTP edition Brielle Bruns (Mar 25)
- Re: why IPv6 isn't ready for prime time, SMTP edition Jim Popovitch (Mar 25)
- Re: why IPv6 isn't ready for prime time, SMTP edition John Levine (Mar 25)
- Re: why IPv6 isn't ready for prime time, SMTP edition Brielle Bruns (Mar 25)
- Re: why IPv6 isn't ready for prime time, SMTP edition Paul Ferguson (Mar 25)
- Re: why IPv6 isn't ready for prime time, SMTP edition Elizabeth Zwicky (Mar 25)
- Re: why IPv6 isn't ready for prime time, SMTP edition Paul Ferguson (Mar 25)
- Re: why IPv6 isn't ready for prime time, SMTP edition Laszlo Hanyecz (Mar 25)
- Re: why IPv6 isn't ready for prime time, SMTP edition Jim Popovitch (Mar 25)