On 2010-04-20 at 23:12 -0400, Edward Ned Harvey wrote: > If you're behind a firewall, which blocks inbound unknown connections, > And I'm behind a firewall, which blocks inbound unknown connections, > > Then how do you propose you and I can communicate p2p? It's only possible > via techniques such as NAT traversal and STUN, which will only work on > braindead firewalls.
There is, I'm sorry to say, UPnP, the IGD protocol. *shudder* And before you get too interested in that, dig out presentations on the security weaknesses in common implementations (such as, permitting the control commands to come in on the WAN interface). Those are a few years old now, but I'm not optimistic that things have improved much. It's also one of those grotesquely complicated protocols which might lead one to think that it had been designed to be difficult to implement, to increase revenue and lock out competition. Alas, the IETF was, per usual, hung up on how evil NAT devices are and for a long time there was nothing happening in this area to provide a sane alternative. One might also wonder if the vendors who promote UPnP might be opposed to competition and how they might go about that (but I'm just a cynic and haven't actually looked to see where the problems came from here, I don't want to get that depressed). Aside (but *not* off-topic for the thread): I'm also cynical enough to note that the really big ISPs in the USA have a vested interest in closing the market to new entrants, by hindering IPv6 deployment -- if they don't deploy, the eyeballs can't use it, so the content providers won't bother, so when IPv4 addresses become scarce and only available expensively in dribs and drabs, no new market entrant can upset them. A successful migration to IPv6 will keep the market *open*. That's why Comcast's work here is so impressive, they actually have bucked the trend, and so some of the other US ISPs are starting to have to examine this too. Bravo, Comcast! (For clarity, I'm being serious, not sarcastic. Many kudos to Comcast). Back onto NATs ... Then there was MIDCOM, which got RFC 3303, 3304 and a few more since, all about the problem space, the protocols they'd like to see, the desired semantics, etc, but no working protocol. RFC 3303 was in 2002 (the year). We did get RFC4540 in 2005, which lays out what NEC do here, with something called SIMCO. I've never heard of any common products supporting this. What we did *finally* get was NAT-PMP, the NAT Port Mapping Protocol. It's another Stuart Cheshire protocol, like Bonjour, which means that it actually works, is designed sanely and looks like older (decent) IETF work, since it's also backed by running code. Like his other work, it bucks IETF convention, promotes reality instead of ideals and has not succeeded within the IETF. If you hunt around, there's "draft-cheshire-nat-pmp-03.txt" But as Mr Cheshire is an Apple employee and supported by his employer, NAT-PMP is actually deployed and available. Hrm, I sound like a fan-boi. I think I might be. I need a Stuart Cheshire T-shirt ... Apple Airport routers support NAT-PMP, and there's a list of client software at: http://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol which mostly appears to be file-sharing software. :/ Oh cool, OpenWrt also supports NAT-PMP too. And Apple's Bonjour for Windows stack supplies a client-side library of some kind, it seems. So, you can choose from: * NAT-PMP: simple binary protocol, easy to understand, does what it says on the tin, very simple overview at: http://miniupnp.free.fr/nat-pmp.html * corporate backer: Apple * UPnP IGD: SOAP XML stuff, IIRC, layers and layers of cruft; Wikipedia notes, "UPnP was published as a 73-part International Standard, ISO/IEC 29341, in December, 2008." * Long history of security problems * more widely supported than NAT-PMP * corporate backer: Microsoft * vapourware from the IETF; hrm, it appears the WG disbanded. * for really simple uses, STUN. If you have someone with lots of bandwidth to spare, out on the net, then TURN. Regards, -Phil _______________________________________________ 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/
