>> >> 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. I suppose that's possible and you could respond to that by blocking more addresses or the entire /64 if you want. The difference is that by seeing the actual address of the remote system you get to decide rather than blocking an entire corporate network. It would be trivial to program a rule that if multiple addresses in the block are offending we escalate to a bigger block. >> >> 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. Yes, addresses that do not accurately represent the single system causing the problem. >IPv6 adds an entirely new aspect to it. Well, if you mean the entirely new aspect is a list of hex addresses instead of dotted decimal addresses I guess so. I personally would rather have a list of actual end system addresses than a list of addresses that represent a mail server and several thousand other innocent devices behind a NAT. Might be easier to tell the system owner which system is compromised than to call a large company and tell them one of their systems is compromised. It would also be nice to be able to allow legitimate email to a business partner while blocking his compromised system only. >> >> 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. If they knew anything about security they would but I thought we were talking about the same guys that use NAT to secure their networks. >I generally see where the only outbound connections allowed are http and >https. All other ports are blocked. Maybe on the BYOD only networks but very few companies actually segregate the BYOD devices from the general wifi access in a sophisticated way. Just look at how many wifi vendors actually support that well and how many companies can actually tell a corporate owned wifi device from a BYOD device. To do that correctly requires something like a good machine certificate process and complex stuff like 802.1x and TLS, most don't have it. Good luck with allowing only http and https and nothing else. My wifi users happen to like to be able to use IP softphones, have web conferences, and do lots of other stuff that uses more than those two protocols. Steven Naslund Chicago IL
