[Dshield] Possible solution for ISP (was DShield's public goals)
jeff-kell at utc.edu
Thu Jan 19 15:11:10 GMT 2006
Frank Knobbe wrote:
> On Thu, 2006-01-19 at 01:00 -0500, Valdis.Kletnieks at vt.edu wrote:
>> And Joe Sixpack didn't set up his NAT router, UPnP did it.. ;)
> That still doesn't explain how it properly NAT's inbound audio stream
> UDP packets to the right IP address (Joe, not his wife Suzie).
> I think a lot of the newer protocols are able to tunnel through NAT
> connections, even streaming services.
There's a mixed bag of functionality regarding NAT, not all NAT devices are created equally.
* Straightforward NAT just "works" for outbound connections, but requires both a predictable mapping and a firewall/access control permission to allow inbound connections for a given port.
* If the IP addresses are never passed in the data stream and the above criteria are met, there are generally no problems.
* When the application requires passing the IP in the data stream, some form of "fixup" is necessary to make things work since plain NAT only translates addresses at the IP layer (pure NAT) or protocol layer (overload NAT, or PAT).
* If the application is really NAT-aware, it knows it's internal and external address and adjusts things itself as needed when the source address is needed in the data stream.
* If the application is not NAT-aware, the NAT device must interact at the protocol or application layer and adjust things as necessary. The most common example is FTP, where the low-level "PORT" command passes IP source addresses in the data stream (in both active and passive modes). Almost all NAT implementations can account for FTP fixup.
* Other fixups vary by NAT implementation. Things which require fixups to traverse NAT include DNS (with server behind NAT), H.32x and SIP protocols, or anything that tries to pass [NAT-affected] addresses in the data stream.
* Things that involve incoming connections through NAT, in addition to the earlier conditions, are complicated by both the NAT specifics and any firewall/access permissions, especially with UDP. For one-to-one inside/outside NAT, incoming connections always map one-to-one, e.g., FTP command channel goes to server, data channel opened by server comes back to same source IP as the command channel. For many-to-one overload NAT/PAT, something must map incoming traffic on the outside IP to the proper inside IP. If there is only one device in the local network behind NAT, you can statically map all incoming connections back to that host; otherwise you must somehow map incoming connections to the proper IP. This is typically done by static port associations, or by protocol fixups that anticipate incoming dynamic connections.
* The "NAT-aware" applications are often very network-unfriendly. Protocols like Skype and many P2Ps work from behind firewalls by using an intermediate proxy to which both source and destination initiate connections. This is fine and good for the folks on either end, but it's a network burden on the intermediate proxy, especially when such traffic is unexpected. The scary part here is applications which default to offer proxy services or determine if they are candidates to offer proxy on their own, without notifying or asking the user; unlike those that have a configuration option (e.g., Ultrapeer or Supernode). You start getting bombarded with traffic seeking a proxy, and may be bombarded with probes from peers to determine latency, and you may or may not notice, depending on your available bandwidth and the load on your system.
It is the latter category that is most annoying to network administrators. This isn't just an end-user issue.
More information about the list