[p2p-sip] NATs and P2P
lowekamp at cs.wm.edu (Bruce Lowekamp) Tue, 21 March 2006 01:58 UTC
From: "lowekamp at cs.wm.edu"
Date: Mon, 20 Mar 2006 19:58:02 -0600
Subject: [p2p-sip] NATs and P2P
In-Reply-To: <9151EA5D-BA55-4A69-8F6A-7118492C4283@magma.ca>
References: <9151EA5D-BA55-4A69-8F6A-7118492C4283@magma.ca>
Message-ID: <e9132f820603201758n727d6d25p62f4c4d60dac42d9@mail.gmail.com>
Philip, I absolutely agree that we need to have a solution for this type of environment. IMHO, some of the worries about NATs causing problems have been somewhat overstated. As you point out, the majority of NATs in the wild are address independent mapping, and it is relatively trivial to punch holes to establish communications. But you're also right that, especially for corporate networks, this doesn't solve the entire problem. I spent some time thinking about how to solve the specific problems you pose in terms of the protocol we have been playing with in draft-bryan-sipping-p2p. We completely ignore the issue of NATs in there (not because we don't think it's a challenge, but just because we want to work on a basic protocol first). If I was to address some of the problems you pose using that framework (modified chord), then one approach would be to remove the requirement that DHT operations be iterative and allow them to be recursive. If DHT operations can be recursive, then the number of connections that a node must maintain through the firewall is limited by the size of the finger table. That number doesn't have to be very big to have a rather efficient DHT. (never more than 128, and I think in practice the number can be much smaller. If your guess of 160 is correct, we're more than OK here.) I'm a bit unhappy with that because I really like the iterative approach for a variety of reasons, but certainly the protocol could be modified that way and a hybrid environment could be established where some nodes are open (or easy to request opens) and support iterative queries with anyone, but others are recursive queries only. One problem is that the burden of having a finger-table entry to a recursive-only host is placed on the non-recursive node that would otherwise redirect to its finger-table entry, but now must recurse the request. Right now the scheme would also have problems because, as Eric rightly points out in a separate thread on this mailing list, we don't have a good way of selecting Identifiers for nodes behind NATs (in particular). But if you have node certificates or another way of authenticating your nodes, this is less of a problem. I want to make it clear that I'm not ready to propose a specific solution, but I think there are ways to support structured DHT algorithms that are not really very painful and work reasonably well inside these environments. Clearly support for such an environment needs to be a listed in eventual requirements docs. Bruce On 3/20/06, Philip Matthews <philip_matthews at magma.ca> wrote: > [I guess all this traffic on the mailing list will teach me not to go > on vacation > just before an IETF meeting!] > > As I catch up on all the messages about NATs over the past two weeks, > it seems to me that many people are thinking only of the "Public P2P > Service Provider" > use-case as described in the use-cases document. In other words, a Skype > competitor. > > However, the use-cases document that David Bryan and his co-authors > wrote > identified a number of other use-cases and it seems to me that these > have somewhat > different NAT traversal requirements. > > In particular, in some of these other use-cases, it seems to me that > we CANNOT assume > there are peers with public IP addresses. > > For example, consider the "Presence using Multimedia Consumer > Electronics Devices" > use-case (section 3.1.3) -- essentially a P2P network of multimedia > consumer electronics devices > that need presence information. Who is going to pay the extra money > to give their digital camera (or those > neat 770 tablets that Nokia is demoing here in Dallas?) a public IPv4 > address?? On the contrary, > devices like this are almost certainly going to have private IP > addresses -- it is very common today for > wireless internet providers to place a big NAT in front of their > entire network and give private addresses > to all their customers. > > Or consider the "IP PBX" use-case -- a IP PBX system for a company > with a number of small branches > scattered throughout the world. Each branch is going to have a NAT in > front of its network, and all > the phones in that branch are going to have private IP addresses. > None of the phones are going to > have public IP addresses. > > It is handling the NAT traversal issues for use-cases like these that > Eric Cooper and I wrote our > internet-draft on NAT Traversal for P2P: > http://www.ietf.org/internet-drafts/draft-matthews-p2psip-nats- > and-overlays-00.txt > > - Philip > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > >
- [p2p-sip] NATs and P2P Philip Matthews
- [p2p-sip] NATs and P2P Bruce Lowekamp
- [p2p-sip] NATs and P2P Effi Shiri
- [p2p-sip] NATs and P2P Zhou Ya Jin
- [p2p-sip] NATs and P2P Effi Shiri
- [p2p-sip] NATs and P2P Zhou Ya Jin
- [p2p-sip] NATs and P2P Effi Shiri
- [p2p-sip] NATs and P2P Zhou Ya Jin
- [p2p-sip] NATs and P2P Brijesh Kumar
- [p2p-sip] NATs and P2P Michael Slavitch
- [p2p-sip] NATs and P2P Eunsoo Shim
- [p2p-sip] NATs and P2P Philip Matthews
- [p2p-sip] NATs and P2P Brijesh Kumar
- [p2p-sip] NATs and P2P Peter Pan
- [p2p-sip] NATs and P2P Dean Willis
- [p2p-sip] NATs and P2P Peter Pan
- [p2p-sip] NATs and P2P Juha Heinanen
- [p2p-sip] NATs and P2P Martin Stiemerling
- [p2p-sip] NATs and P2P Mike Robinson
- [p2p-sip] NATs and P2P Roy, Radhika R.
- [p2p-sip] NATs and P2P Dean Willis
- [p2p-sip] NATs and P2P Juha Heinanen
- [p2p-sip] NATs and P2P Dean Willis
- [p2p-sip] NATs and P2P Peter Pan