[Cryptography] peering through NAT Crypto
NAT makes it hard to contact a computer behind nat, but Bitcoin core has no problems with most nats, even when behind multiple levels of nats. It does something to tell the nat to direct incoming messages on port 8333 to it, without the end user usually needing to manually set up port forwarding. What is the protocol to tell a nat to forward incoming messages? What happens if there are two machines both running bitcoin core behind the nat? _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
jamesd@echeque.com wrote on 5/9/19 7:45 AM: > NAT makes it hard to contact a computer behind nat, but Bitcoin core has > no problems with most nats, even when behind multiple levels of nats. > > It does something to tell the nat to direct incoming messages on port > 8333 to it, without the end user usually needing to manually set up port > forwarding. > > What is the protocol to tell a nat to forward incoming messages? I've often wondered about that. A few years ago a networking expert showed me a technique where the client program running on your own computer sends OUT a packet which lingers on the outside of your network interface, awaiting a response. A remote server can reply to it, and your client program sees the response. It's kind of a dummy packet too, with no actual content. At that point I suppose your client program sees the remote IP and can initiate a direct connection to it. With this technique, your grandpa doesn't have to configure iptables. I don't know the specifics, and it has been a while since I looked at it. > > What happens if there are two machines both running bitcoin core behind > the nat? -- Patrick _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
jamesd@echeque.com wrote on 9/05/19 11:45 PM: > NAT makes it hard to contact a computer behind nat, but Bitcoin core has > no problems with most nats, even when behind multiple levels of nats. > > It does something to tell the nat to direct incoming messages on port > 8333 to it, without the end user usually needing to manually set up port > forwarding. And I replied > According to > > https://bitcoin.org/en/full-node#port-forwarding > > and > > https://bitcoin.stackexchange.com/questions/62022/what-is-the-benefit-of-opening-port-8333-to-a-client/62035#62035 > > that is not true. Naturally as soon as I hit Send I remembered something contradictory. Bitcoin core can use UPnP which is probably what you are thinking of See https://dirkmittler.homeip.net/blog/archives/3340 and other results of a Google search for UPnP bitcoin core _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 2019-05-09 at 21:45 +1000, jamesd@echeque.com wrote: > NAT makes it hard to contact a computer behind nat, but Bitcoin core has > no problems with most nats, even when behind multiple levels of nats. > > It does something to tell the nat to direct incoming messages on port > 8333 to it, without the end user usually needing to manually set up port > forwarding. > > What is the protocol to tell a nat to forward incoming messages? > > What happens if there are two machines both running bitcoin core behind > the nat? UPnP ? https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_traversal https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol Now, what does NAT traversal have to do with crypto? And how is this question related to the “NIST announced Round 1 candidates for lightweight crypto competition” thread to which you replied (albeit with a different subject)? Regards _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Look up ICE protocol, and STUN/TURN servers. NATs behave differently. The simplest/common version works on port mapping. Say A is inside and wants to establish a session to B outside. NAT router uses two ports x and y, x for talking to A on local network and y to talk to B on internet IP. Normally, NAT will forward any packet received on y on global ip to port x on local ip. So if you know y and NAT ip, you can talk to A from the outside world. The problem is some NAT firewalls insist that the ip of a connection asking for port y must respond to a request initiated first from NAT itself. ICE and STUN/TURN servers try a series of NAT piercing tricks/hacks to pass through the NAT router. It often works, with a last resort option of having a relay server sitting in between peers. I dont know how Bitcoin Core works exactly however. On Thu, May 9, 2019 at 6:54 PM Patrick Chkoreff <pc@fexl.com> wrote: > jamesd@echeque.com wrote on 5/9/19 7:45 AM: > > NAT makes it hard to contact a computer behind nat, but Bitcoin core has > > no problems with most nats, even when behind multiple levels of nats. > > > > It does something to tell the nat to direct incoming messages on port > > 8333 to it, without the end user usually needing to manually set up port > > forwarding. > > > > What is the protocol to tell a nat to forward incoming messages? > > I've often wondered about that. A few years ago a networking expert > showed me a technique where the client program running on your own > computer sends OUT a packet which lingers on the outside of your network > interface, awaiting a response. A remote server can reply to it, and > your client program sees the response. It's kind of a dummy packet too, > with no actual content. At that point I suppose your client program > sees the remote IP and can initiate a direct connection to it. > > With this technique, your grandpa doesn't have to configure iptables. > > I don't know the specifics, and it has been a while since I looked at it. > > > > > > What happens if there are two machines both running bitcoin core behind > > the nat? > > > -- Patrick > _______________________________________________ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 5/9/2019 1:01 PM, Patrick Chkoreff wrote: > I've often wondered about that. A few years ago a networking expert > showed me a technique where the client program running on your own > computer sends OUT a packet which lingers on the outside of your network > interface, awaiting a response. A remote server can reply to it, and > your client program sees the response. It's kind of a dummy packet too, > with no actual content. At that point I suppose your client program > sees the remote IP and can initiate a direct connection to it NAT traversal has been with us since quite a while. Two variants: the UPNP/IGP or PMP kind, in which a devices inside the network talks to the local router and opens a port; and the "implicit" one, pioneered for video games by Dan Kegel at Activision. The technique was standardized by the IETF in STUN (RFC 5389, 2003). The basic idea is to reverse engineer how the NAT works with the help of a server behind the NAT, and "punch a hole". These techniques are widely used by video games, voice and video over IP, and other P2P systems. -- Christian Huitema _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Patrick Chkoreff <pc@fexl.com> writes: >I've often wondered about that. A few years ago a networking expert showed >me a technique where the client program running on your own computer sends >OUT a packet which lingers on the outside of your network interface, awaiting >a response. A remote server can reply to it, and your client program sees >the response. That's one of many hole punching techniques, typically used by P2P software. UPnP isn't used nearly as much as people seem to think, principally because it's either not present in the first place or disabled by default, while hole punching works in all cases except symmetric NAT, in which case you need an external rendezvous servver (actually even then you can sometimes hole punch it if the NAT uses predictable port allocation techniques). Peter. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
In article <27bf80fc-92e2-d333-2da8-41efeabaa986@fexl.com> you write: >jamesd@echeque.com wrote on 5/9/19 7:45 AM: >> What is the protocol to tell a nat to forward incoming messages? > >I've often wondered about that. A few years ago a networking expert >showed me a technique where the client program running on your own >computer sends OUT a packet which lingers on the outside of your network >interface, awaiting a response. A remote server can reply to it, and >your client program sees the response. ... That just sounds like the way a NAT works. Whenever a device behind a NAT sends a packet to a remote system, the NAT remembers who sent the packet and where it went by IP address and to/from port numbers, so when the remote system replies, the NAT can direct the reply to the right place. The question here is about arranging to receive traffic where the remote system is the first one to send anything. For that you need port forwards, either set up by UPnP or manually. I'm trying to see if there is any crypto relevance to NAT but as far as I can tell there isn't. I suppose on a particularly lame NAT one might be able to predict remapped port numbers but I don't recall that ever being a problem. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
> On May 10, 2019, at 9:22 AM, John Levine <johnl@iecc.com> wrote: > > I'm trying to see if there is any crypto relevance to NAT but as far > as I can tell there isn't. I suppose on a particularly lame NAT one > might be able to predict remapped port numbers but I don't recall that > ever being a problem. With moderator hat on, I'm going to agree that extended discussion of NAT isn't particularly germane. Perhaps even more to the point, there are better resources than this list. (Also, I let through a top post I shouldn't have. Sorry.) However, I don't think we've hit it yet. Yet. I'll add in that NAT traversal has interesting security effects that are hard to characterize. It *changes* the way metadata leaks. Metadata always leaks: every packet has source and destination IP and port, and IP address is often a proxy for physical location. In the general case, if both Alice and Bob are behind horrid NATs (particularly nested NAT), it might be impossible to thread the combined NAT traversal problem, and the only way for them to talk is through a protocol relay, as it has a real IP address. There are many specific cases of complex NAT traversal that work well, and as time goes on, there are more of them, for all the reasons stated by others. Router makers do a better job, client makers do a better job, and service providers are sensitive to the issues as well. There are thorny setups that used to be common but are not any more. Naively one tends to think that relays are a security problem, but it is more complex than that. If a service brokers a direct connection to Alice and Bob, then obviously, the service doesn't learn many details about their communications after brokering the connection. Whereas if they have to be relayed, the relay sees every packet and thus knows things like how long they talked, and the total data size. If they talk directly, the service doesn't know this. However, if you consider the case where Alice is being surveilled and Bob is not, on a direct connection the surveillance system learns Bob's IP address at the very least, along with other things. If the connection is relayed, they know Alice is talking to a relay, but might not be able to learn who Alice is talking to. This might matter in some scenarios, like secure VOIP (which is where I dealt with it), but also things like cryptocurrency protocols. It might actually be better for Alice to talk to a relay if one wants to protect Bob's metadata. It's possible that the trading protocols hide Bob's information, and yet a leak of his IP address gives the whole thing away. In short, it's complex. There are counterintuitive things in all this mess, and dispassionate thought and challenging one's own assumptions is warranted. Jon _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 5/9/19 10:00 PM, Christian Huitema wrote: > The technique was standardized > by the IETF in STUN (RFC 5389, 2003). Somewhat off-topic, but less so than the rest of this thread.... As ||ugh Daniel was fond of pointing out, NAT is an abomination. It is a sad commentary on the whole industry that we are even discussing it. There is a STUN RFC from 2003, but there is an IPv6 RFC from 1995. IPv6 was already widely supported in the early 00s e.g. by windows 2000. It should have been obvious for many years now that every box that does NAT should do native IPv6 if available, and should terminate 6to4 (or 6rd) tunnels otherwise. This his how every network I've set up in the last 15 years has done it. a) IPv6 makes a great many NAT-related questions moot. Every client on the subnet behind the NAT box can have its own globally-routable address. b) It also simplifies IPsec deployment. c) Note that (a) and (b) are not unrelated. When will NAT-box manufacturers get with the program? You'd think this would be a selling point. What in the name of Godot are they waiting for? _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 2019-05-10 09:37, Ángel wrote: > UPnP ? > > https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_traversal > https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol > > Now, what does NAT traversal have to do with crypto? Not much, but it has a little, and here is what it has to do with cryptography: In a world where authorities are increasingly trying to control speech and rewrite the quite recent past at frequent and ever shortening intervals, we will increasingly rely on peer to peer distributed security. For example: Database linking human memorable names and cryptographic key, squaring Zooko's triangle. If that database is a central authority, that central authority is apt to give evil crime thinker Ann the address of the FBI as the address of evil crime thinker Bob, and similarly the address of the FBI to evil crime thinker Bob as the address of evil crime thinker Ann. Suppose we have an append only Patricia Merkle dac, such that if everyone agrees on the root hash, cannot amend the past, nor give different people different versions of the past. The evil crime thinker Ann can know that she is seeing the same story about her key and Bob's key as Bob sees. But we cannot rely on a majority of honest peers - observe how often every single tenured academic in the entire American hegemony agrees on the new version of reality, and remembers that he always agreed on the new version of reality, when yesterday he had a different position. So what we are going to have to do is that each root hash incorporates the previous root hash in a block chain, lots of peers sign the root hash, and record each other signing the root hash, so that if a new hash appears that fails to be legitimately derived from the previous root hash, a root hash that testifies to a history incompatible with that testified by previous root hashes, a single honest peer can call them all out causing a fork. So a large number of peers agree on the one true latest root hash, and each witnesses many of the others agreeing. And if any of the peers are not honest, or if all but one is dishonest, they will get called out, which will keep them all honest. This implies some sort of paxos protocol, weight of stake rather than weight of hashing power, for the government can always seize or build the majority of hashing power. Hence peer to peer security. Even if you are running a client program, you will want it to record the part of the Patricia Merkle tree that relates to your activities, the signatures of numerous major and important peers, and make sure that the people you interact with are seeing the same record of the past, and in particular your past keys, as you are. Nat penetration is messy. Maybe we just do it client server, and wait for IP6. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 5/10/2019 4:23 PM, John Denker wrote: > On 5/9/19 10:00 PM, Christian Huitema wrote: > >> The technique was standardized >> by the IETF in STUN (RFC 5389, 2003). > Somewhat off-topic, but less so than the rest of this thread.... It *is* off topic, wonder why the moderators are not cutting that off already. > > As ||ugh Daniel was fond of pointing out, NAT is an abomination. > It is a sad commentary on the whole industry that we are even > discussing it. > > There is a STUN RFC from 2003, but there is an IPv6 RFC from > 1995. IPv6 was already widely supported in the early 00s > e.g. by windows 2000. > > It should have been obvious for many years now that every box > that does NAT should do native IPv6 if available, and should > terminate 6to4 (or 6rd) tunnels otherwise. This his how > every network I've set up in the last 15 years has done it. > > a) IPv6 makes a great many NAT-related questions moot. > Every client on the subnet behind the NAT box can have > its own globally-routable address. > b) It also simplifies IPsec deployment. > c) Note that (a) and (b) are not unrelated. If I were king, that would have happened years ago. But you know, rough consensus and running code and all that. Perry tried to precipitate the movement with whisky shots and toasts to the universal deployment of IPv6, but that was not too successful either. It took some time for IPv6 to ship on most platforms -- Windows only got a production ready version in 2003. In between, NAT became entrenched. Something to do with business models. NAT was giving you an immediate tangible benefit, connect several computers while paying just one ISP bill. The economic incentive were well aligned: customer shells out maybe $100 for a device, recovers the price in a few month by saving on the ISP bill. The economic incentives of IPv6 were much more "long term", to use an euphemism. > When will NAT-box manufacturers get with the program? > You'd think this would be a selling point. > What in the name of Godot are they waiting for? At this point, they are waiting for explicit requirements from ISP. It is getting there, because it turns out that Net 10 + Carrier Grade NAT does not work well if you have more than 16M customers. With IPv4, ISP cannot give a unique address to each of their customer premise equipment, and that makes network management very costly. Same thing is happening in big data centers. But then, having a unique stable address/identifier for each device has some pretty nasty privacy implications. It is not hard to find privacy advocates who believe that Carrier Grade NAT is great, because it lets people hide. -- Christian Huitema _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 2019-05-11 13:06, Christian Huitema wrote: > But then, having a unique stable address/identifier for each device has some pretty nasty privacy implications. It is not hard to find privacy advocates who believe that Carrier Grade NAT is great, because it lets people hide. On reflection, the best solution would be a peer to peer system where each peer has a public key, some peers have accessible ports and can be accessed by any peer, messages percolate from peer to peer, and the messages can propose a stun rendezvous - a peer that wants a direct connection with another peer behind a NAT nominates a time and an IP port, and at the appointed time, both peers fire off UDP packets to each other on that port. This, however, requires a reliability and bandwidth throttling mechanism on top of udp, an ssl like layer on top of udp. A number of libraries contain such mechanisms, but the mechanism tends to be connected to lots of things, not happy with any of them that I have looked at. You just want a monkey, and get the entire jungle. By and large, VOIP does go through UDP with a throttling mechanism, but libraries that provide this are not small and generic, but rather special purpose - they expect you to use the entire library in the intended way for the intended purpose, and using it in a different way needs a rewrite. The GameNetworkingSockets library sort of provides a udp reliability and throttling layer, though it is a bit broken at the moment, and is thinking about providing this with stun. But integrating stun with the GameNetworkingSockets library seems to need a lot of inside knowledge of the GameNetworkingSockets library. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
In article <19496554-2b3a-8f88-c998-4e9e738f8770@huitema.net>, Christian Huitema <huitema@huitema.net> wrote: >But then, having a unique stable address/identifier for each device has some pretty nasty privacy implications. It is not hard to find privacy advocates who believe >that Carrier Grade NAT is great, because it lets people hide. For most home users, regular NAT has no downside. It automatically firewalls devices behind it* and it is not a bug that nothing outside my house can talk to my printer or other devices on the LAN. There are a few home applications that want to see through the NAT, but not many, mostly multiplayer games. I agree that CGN where you're doing N:M NAT rather than N:1 home NAT is a lot messier and harder to manage, but that's a relatively recent development. I am surprised that when touting the advantages of IPv6 few people mention that the giant address space makes it much more resistant to port scanning. On my home LAN there are two hosts visible from outside but unless you had a hint about where to look like a DNS name it's unlikely you could find them. R's, John * - yes, I know you can do that without NAT, I have IPv6 tunneled onto my LAN too. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On Fri, May 10, 2019 at 08:06:56PM -0700, Christian Huitema wrote: > But then, having a unique stable address/identifier for each device has > some pretty nasty privacy implications. It is not hard to find privacy > advocates who believe that Carrier Grade NAT is great, because it lets > people hide. It is not hard to find *someone* in support of any position. It does not, however, make it correct. CGNAT is no better than per-CPE NAT, from a privacy/anonymity perspective. Common CGNAT equipment, for legal reasons, constrains each customer to a fixed range of source ports on a single public IP, because it's a lot easier and cheaper to log "customer X is on 192.0.2.42 ports 2000-2050" than it is to log every outgoing connection's (IP, port, customer) tuple. IPv6 is no better, of course, but it is also no worse. Use random IPv6 addresses within the /64 assigned to your LAN, chosen for every single outgoing connection if you really want it. The first RFC specifying a standard algorithm for assigning privacy addresses (RFC3041) is now old enough to drink in civilized jurisdictions, so nobody who claims to be knowledgeable in this area should be surprised by its existence. With randomised IPv6 addresses, you get the same benefits as IPv4 NAT (CG- or otherwise). You can be associated with other connections from the same ISP account in all cases. There's always an ISP-assigned identifier -- whether that be an IP+port range, public IP, or /64 prefix -- that doesn't change, but device-level associations have to be done a layer higher than that of network addressing. - Matt _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
With the designed method of bitcoin, you can pay someone quite anonymously. They issue payment address, which is actually a public key, and then value mysteriously appears in the blockchain for that public key, with no indication of how it got into the blockchain. Bitpay, however, initiates a direct conversation between the payee and the wallet, and it looks to me that entities cosy with the state are pushing bitpay onto us, demanding payment by bitpay. Bitpay initiates a conversation between the website and the wallet, and thus, and thus, modulo vpns and all that, locates the physical location of the wallet. But that in itself is pretty harmless, because you have to interact with their website anyway, so you already leak that information. What additional information goes into a bitpay payment? Seems to me that it is being pushed for ulterior and unrevealed reasons. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 5/19/19, jamesd@echeque.com <jamesd@echeque.com> wrote: > With the designed method of bitcoin, you can pay someone quite > anonymously. They issue payment address, which is actually a public > key, and then value mysteriously appears in the blockchain for that > public key, with no indication of how it got into the blockchain. > > Bitpay, however, initiates a direct conversation between the payee and > the wallet, and it looks to me that entities cosy with the state are > pushing bitpay onto us, demanding payment by bitpay. > > Bitpay initiates a conversation between the website and the wallet, and > thus, and thus, modulo vpns and all that, locates the physical location > of the wallet. But that in itself is pretty harmless, because you have > to interact with their website anyway, so you already leak that information. > > What additional information goes into a bitpay payment? Seems to me > that it is being pushed for ulterior and unrevealed reasons. The underlying problem is that most coins are not privacy coins at the protocol level, and hardly that with most mix, but moreso with better coinjoin etc. Or you can push out from privacy coins per tx / day / week, with lots of cost and headaches, or just adopt and use them natively... Zcash, Monero, many more before long, as the better overall solution. The point of opensource cryptocurrency is to evolve and survival of fittest past the genesis... nonprivacy coins are early legacy tech and hardly fit and cannot survive privacy and other attacks... you know much more now, so go and evolve past those early designs. No, you're talking to the chain, bitpay reads the chain. Of course bitpay is a third party seeing both sides, so they're still vomit compared to direct onchain to payee wallet. And governments love that middle siphon op. Expect them to require a checkout ID swipe for that soon... so you have about 30 minutes to adopt and entrench faster than they can fuck you over with that too... thanks to you wasting your time with blocksize and price, instead of adoption and advancing designs. If using the complete garbage Gemini backed Flexa SPEDN app then yes, that's even more severe exploitation of privacy and so many other things on a whole other level beyond even Bitpay. So now brick and mortar retail is trending poorly in regard true adoption of true distributed cryptocurrency. Coins without privacy are worse than fiat cash, no one wants worse, it leads straight to your life controlled and enslaved hell. You need to educate payees on wallet ops, conversions, holdback profits as investment, promise of true distributed cryptocurrency. And everyone on privacy coins. It's not that hard. "Money" is ultimately backed by nothing but belief. And now there's a much more agnostic, fair and less murderous choice than Fiat. So don't let the BankGovCorp FUD propaganda brigade and puppet masters sway you. Distributed scalable private cryptocurrency is solveable tech, and you know it's power for you. So go solve and adopt it. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
89.2 MB — 3,873 messages
Last sync: 15 July 2019 22:44

Move Messages

Save

Apply Labels


Warning: Unknown: write failed: No space left on device (28) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/sessions) in Unknown on line 0