I know I'm late to this particular party, but after catching up with the thread I'll add a few nuggets since I'm actually quite familiar with mesh networking and the security implications, on a theoretical as well as practical level. (Footnote: discrete mathematics is not my favourite pastime, which is why I've largely moved on in my career.)

First, the information theoretical consequences:

• The network, as a gestalt system, HAS to know where the destination of a transmission is (and this is true regardless of whether you're using packet technologies or not) because if it doesn't, it can't send the data where it has to be. Period. No known destination? No comms. Just a frownyface on your commlink's display. Bear in mind that if you have a small network of gear which talks to nothing else, this only applies within your mini-mesh.
• The proximal mesh node(s) to your device's location HAVE to know that you're there, otherwise they can't talk to you which means other nodes can't talk to you, which means nobody can talk to you. So anyone who has access to the information state of the mesh nodes proximal to you has a pretty good idea of where you are, within the limits of triangulation. (Corollary: If you're working through satellite only, and ignoring all other mesh nodes, your latency might be high but the satellite is not very helpful in pinpointing your location.)
• Distant (in networking terms) nodes which can reach your device don't know necessarily where you are (in fact it's demonstrably inefficient, in information theoretical terms, to the point of mathematical infeasibility as the network grows because of power law relationships between network size and communication overheads, compared to net communication capacity) but do know, or must be able to rapidly find out where to point to reach you; in other words, they have to be able to route to you.

These facts have some consequences. For instance, someone doesn't necessarily have to be able to reach your proximal networking environment. With an adequate (statistically speaking) insight into the behaviour and characteristics of backbone nodes they can (rapidly) infer your current networking context and establish which your proximal routing nodes are most likely to be. If they're determined, in Shadowrun terms, to get to you, a hacker/decker (version dependent) strike team can even try to get closer.

So what about proxies, as opposed to clear routing? Sure, a proxy can send encapsulated data to a range of its clients, and assuming functional encryption (excuse me while I point at the Shadowrun canon and laugh until I wet myself) one could possibly infer a range of possible destinations, but the more popular a proxy (assuming the proxy is, in security terms, honest and inviolate) the harder this process of inference becomes. If the proxy is compromised, it's no better than a regular routing node and possibly worse for the privacy of those with something to hide.

What about address hopping? Well, it turns out that if you're strictly a client node (i.e. establishing outbound data connections) that's fine. You can even use session persistence techniques (which are pretty much ubiquitous in synchronous, unstable network contexts anyway) to have your connection survive link drops and recreation. The downside is that your server side (which can be both ends, in peer to peer arrangements) needs a known address. Can you square this circle? Yes, you can, by privately arranging and communicating your next address before an address hop. Is this perfect? No, because someone who is close enough in networking terms to observe the traffic (such as someone controlling the building mesh nodes through which you're communicating, i.e. your target's spiders) can also observe the changing addresses and infer directly which continuing network connections are which.

The bottom line: if you don't want mesh networking to give away your location (and by cross-checking data, your identity) you need either:

• Rock solid, inviolate, utterly trustworthy encryption combined with a rock solid, inviolate, utterly trustworthy proxy of such popularity that the mere presence of its data is not an indicator of nefarious activity by itself.
• Communications working through proximal nodes of such a nature that the signal will not be observed by alternatives (think tight beam, laser, and so on), and where the proximal nodes do not usefully give location data through their activities (such as satellites).
• Rigidly enforce network isolation, combined with total out of band silence (such as an optic fibre between smart goggles and a smartlinked gun).
• Rigidly enforced comms silence.

Of course, some of these options are suspicious of themselves - if you're supposed to have a networking identity and there isn't one, or there are strange discontinuities, those are exactly the sort of things which would flag an event.

There are some ways of avoiding certain kinds of trouble. Example:

1. Shadowrunning team arrives at rendezvous point, in the clear, with networking IDs which are not suspicious.
2. Shadowrunning team leaves commlinks in place in circumstances which aren't suspicious - perhaps in an autopiloted van which cruises the highways while they get nefarious.
3. Shadowrunning team gets into their action gear, including their combat-ready electronics.
4. Shadowrunning team engages in ten minutes of sneaking, thirty seconds of mayhem then decamps.
5. Shadowrunning team goes through total radio silence including a shutdown and readdressing of all their (assumed compromised) work-related networked gear.
6. Shadowrunning team picks up their street electronics and rides off into the barrens.

Seems good, but don't trust that a satcom phone can't be located. A Satcom node needs a powerful signal to get to orbit, and can been seen by all the other sats in orbit. Like the NSA's ComInt birds that were used in the 70s to pick up mobile phone traffic in Russia. These sort of sats can RDF satcom (or, for that matter, any radio traffic) and locate it to a few meters, if you somehow manage to do something to make their priority collection schedule.

Oh yes, I'm well aware of a number of ways in which they can be located, but there are ways of mitigating those effects, at least (which reduces triangulation by multiple satellite). Granted, this rests on a whole bunch of assumptions, most of which are very questionable (your typical satellite-capable radio, as you point out, is very powerful which implies a lot of signal leakage in typical formats) but I was more pointing out the edges of where some normally valid ways of tracking down radios are less valid.

This will be my last post on the topic regardless of what you come back with so feel free to slam away. Yes, its nothing like the movies unless you enjoy spending thousands on your packet sniffer just to see pretty graphics. How would you handle looking past gateways or proxies? Where you tap the wire is probably the most critical point in the process. While pathping and traceroute dont do much in finding real intruders its still a valuable tool to see the hops, especially when the attacker shows up as on your subnet and you network has enough subnets to make your head spin. A database lookup with network maps is going to take alot longer than a traceroute.

I own that book (IMG:style_emoticons/default/smile.gif) Its a good book, little heavy on theory but most college books are. It sits inbetween my Unix Administrators Handbook and Data Abstraction and Problem Solving with C++. Its pretty much the standard for networking books much like Flyod is for Electrical Engineering. For a good intro I'm recommending Practical Packet Analysis by Chris Sanders, not because its great at intrusion detection but because it goes into real world scenarios of where you need to tap the wire. Which IMHO the hardest part.

...which is nice for network troubleshooting. We are not talking about customer support, we are talking about locating the person behind an IP address. And by "locating" I don't mean the "he's in Seattle" kind of output those geolocation toys provide by looking up the public information associated with an IP range. I mean an address to which a summons or SWAT can be sent.

What you are talking about is the equivalent of county/town codes in license plates -- it gives a general idea of where the car was registered (which in case of company cars may be far away from the actual driver's residence) but nothing more. Actually locating an IP address is the equivalent of looking up a license plate at the DMV to get the driver's name and address.

Except they don't work that way.

Remember when Southwest Airlines used to hand out reusable plastic boarding order tickets at the airport as you showed up for your fight, which they collected at the gate and gave out to the the people waiting for the next flight? The ticket is an IP address. It doesn't "belong" to anyone, it gets handed around to various people all the time. There is no DMV to go to. In order to find any more data you have to go to the people that run that particular network and ask them who was using that IP at a given moment. And they won't usually have a name associated with the IP, they will have a MAC address, which is trivially changeable by anyone who wants to. This assumes they have records at all, which is not a safe assumption.

So now you know that MAC 1234:5678:9ABC was associated to access point 245-4b-AP5 from 6:00pm to 6:15pm. Does that tell you anything about where the device with that MAC was? Not really, as all it means is that they had radio line of site to an antenna on that radio. That could be because they were sitting in the room with the AP (which again requires that someone running the network show you where that is, you won't find a DMV of AP locations) or it could be because they are using a Pringles can directional antenna from a km away.

Oh yes they do. They are not yet legally mandated to do so but all the big telcos do it anyway for a few weeks -- because it's not forbidden, either. Officially for "billing purposes" (because you pay per connection, don't you?), more realistically because won't somebody think of the RIAA children?!



More importantly, the MAC address only exists between two communicating devices, therefore retaining it would be completely useless in the age where everybody has a router between his PC and the ISP's network. The only place which stores MAC addresses are network switches, to determine which device is connected to which port.

(At least in the past, some ISPs also checked you only connected MACs belonging to their hardware to your line. Like you said, not a particularly effective effort)

I've got 5000 or so devices on my guest network on a normal day and there is no information on who this is other then what the DHCP server collects. Which is the MAC address and usually the device name. If you are billing them you might want more, but that isn't how ours works.

I'm making a couple assumptions here but how big is your area for these devices (in sq miles or what not) that talk to the same DHCP scope? (just curious) I'm assuming this is something like starbucks hotspots or something similar. Mostly I'm curious if the same scope handles different cities or even states.

I think part of the point ehre is the question of what happens when that database lookup, for one reason or another, cannot be achieved.

It's a chunk of a university campus. About 4 million square feet of buildings plus the outdoor areas between them. It's one MS DHCP server cluster (but not for long) and one huge IP block that gets cycled through with a really short lease time.

Of course, there will be a market for a provider that doesn't share their info with anyone. Please keep in mind that the Shadowrunning *and* high-profile/celebrity markets have a vested interest in making a trace of their commlink use as difficult as possible. Multiple providers will eventually offer this service and sooner or later it will become the expectation of the customer base.

To be honest, I really prefer this idea as it basically forces the issue of real-time tracing which really cuts down on the "from the comfort of my own conapt" for tracing activities at a hacker/spider's leisure.

As you might have noticed from the fact that I talked about ISPs, I was talking about locating a (public) IP. Because that is what the world (including Eve) sees. If that location turns out to be insufficient because it's just the gateway to a larger campus network, it obviously takes a bit of extra effort. In most cases, that extra effort would be a bit of packet sniffing to find the internal IP of the target and then check the RADIUS or other authentication service for an identity. Worst case would be a bit of manual scanning with an HF antenna, not exactly rocket science either (IMG:style_emoticons/default/wink.gif)

The thing is, in Shadowrun, I'm not sure if structurally that database is at all possible.

Good point. But if someone does coming sniffing from an outside party, the knowledge that the inquiring party will be told off is comforting.

Of course, there is a point to be made with the term "outside party" as I am quite sure that at least one team of 'Runners had thought of everything except their commlink subscriber being a subsidiary of the company they last ran an op against and woke up with a carbine barrel firmly pressing against their eye socket...

There's actually an MSP written up in Unwired where that's not at all a concern - Anarchist Black Something, I think.

Yes, there is a market for deep dark secrets that people think they are keeping only between themselves. Which is why it's actually, though multiple layers of cutouts, controlled by Aztechnology. (IMG:style_emoticons/default/wink.gif)

Shadowrun also assumes Megacorps dont work together... Which just goes to show reality != fun game.

but to your point, Sat link maybe, but encryption still sucks so... no

I don't think you're catching my point - what I'm getting at is that I'm not certain if such a database can ever exist in a ad hoc mesh network environment. Having that database would be based on the idea of assigning addresses to people, but if something can just pop up on the network without needing to be associated with any sort of advanced registration (see: ad hoc), I'm thinking that database is formally impossible.

You are right. It is formally impossible.

However, if you know enough about the backbone and you have multiple points of access to the network for generating test streams, you can perform pretty useful statistical analysis to find the likeliest locus for network access, which is a lot better than an atlas, a blindfold and a few darts.

Ahhh YES!!!! I keep forgetting Shadowrun is in love with Ad Hoc...

There has to be a database somewhere or there would be no way to route the calls, or perhaps more importantly the billing, to the right commlink out of the gazillions of connected devices.

Yes, essentially it's the NAT problem. So unless there is some sort of global database nobody can call you on your comlink. This might well be solved the same way nat is "solved" by malware, which is that the end device keeps recreating a tunnel out to some fixed site on the global network that allows people to reach the end device. The fixed site is your phone provider.

Actually, I can think of ways to solve that problem - for example, there could be a sort of call-response model, where your commlink (or whatever device) is listening for communications intended for it, and completes the connection when it picks up on it. In a decentralized global ad-hoc environment, a model like that would probably be required.

And when it comes to billing, you're not getting billed on a device level at this point, but an a grid-account level - the public grid is free, remember?

It is entirely possible to find items with known addresses across an ad hoc network.

If you want to think of it in terms of a global database (which is not an apt mental model), then the collective topological knowledge of all the nodes in your network constitute the database, and the problem reduces to remote information queries.

If you have communicated with your identity, then the information of your identity's location is cached by those nodes which conveyed the information.

I could go on for hours about it, but the basic is: it's possible, it's mathematically feasible, and it will work more or less as described.