> From: Colm Buckley [mailto:c...@tuatha.org] > > I think we may be differing on the meaning of "unknown". If the > firewall is configured not to allow P2P traffic, then there is no way > to use these protocols. If, however, the network administrator does > allow P2P traffic (either by requiring proxy authorisation, or simply > opening the relevant ports), then it becomes trivial. It doesn't mean > that the firewall needs to open "unknown" connections; what do you mean > by the term "unknown"? > > If the intention is to allow P2P traffic, then it's vastly easier on > IPv6 where the IP address of the endpoint is consistent everywhere; > there's no need either for ugly external to internal port/IP mappings, > nor for hacky reflector or STUN setups.
If you have a many-to-one NAT perimeter firewall/router, and a packet arrives at the external interface of the router, the router needs some way to know which internal IP address and port should receive the packet. Or else the packet must be dropped. That is an unknown packet, and that is the fundamental problem of traditional NAT which stands in the way of p2p. Punching holes in the firewall isn't a solution except in the most specialized cases. This will not allow random users to make video calls (or whatever) to each other, while travelling around and hopping from network to network on the fly. One solution is to use IPv6, and have world routable addresses on all the devices. Then all these endpoints can talk directly to each other. Another solution is to have a whole bunch of world routable IP's on the external interface of the firewall, so each internal interface can be NAT'd to its own external IP. This is unlikely to happen with IPv4, but very possible with IPv6. I haven't read about NAT-PMP yet, but thank you Phil for the suggested reading. I gather it's a protocol that allows the internal client to talk directly to the router, and negotiate with the router to accept some inbound traffic for the client, which would otherwise be unknown. So then there's the question of ... IPv6 vs NAT-PMP ... which would you bet on? NAT-PMP seems to be more commonly deployed right now. But will it stay that way? Are we only in round-1 or round-2 of this epic rumble? Is anyone even listening to me? That's it, I'm going home. (drops mic on the floor and walks out the door) ;-) > RFC3041, first of all, is client-based. It doesn't allow a sysadmin to > mask > the internal network topology; it's up to all the internal clients to > do it > voluntarily. > > Yes; this is true. I don't really see that it's important, though. It doesn't matter if you see it as important, as long as someone else does. All I said was, to identify the reasons people implement NAT (a) address space (b) blocking inbound unknown traffic (c) covering up your internal network road map. Some people see it as important, so some people may still wish to use NAT on IPv6 for purposes (b) or (c). > It's client security which is important; subnets and the like don't > actually have an existence apart from the clients which exist on them. Suppose one of the machines in there is a mail server. And an active directory server. And a file server. Etc. You're not suggesting all these machines should have their IP addresses changing all the time, are you? What about the routers themselves? And DNS servers? This is the material for a useful remote network attack roadmap, and this is the information which could be useful to cover up, if some sysadmins choose to do so, possibly by using NAT and IPv6 together. An attacker targeting a corporate or private network will care much less about hacking into your laptop, which is one of the devices that's ok to have IP's changing frequently, and likely to have security software and somebody noticing weird things happening. An attacker would much prefer to have an old unmaintained server to attack. Perhaps one which has not had security updates applied in a long while, because it needs to stay powered on 24/7, like a DNS or mail or web server. _______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
