misunderstanding scale

Tue Mar 25 05:53:13 UTC 2014

>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 at opsys.com> wrote:
>
>
>> -----Original Message-----
>> From: Naslund, Steve [mailto:SNaslund at medline.com]
>> Sent: Monday, March 24, 2014 10:48 PM
>> To: Owen DeLong; mark.tinka at seacom.mu
>> Cc: nanog at 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
>>
>>
>
>