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.lo...@opsys.com> wrote:
-----Original Message-----
From: Naslund, Steve [mailto:snasl...@medline.com]
Sent: Monday, March 24, 2014 10:48 PM
To: Owen DeLong; mark.ti...@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
