Re: Secure voice app: FEATURE REQUEST: RECORD IPs
On Mon, Jan 27, 2003 at 08:23:15AM -0800, Major Variola (ret) wrote: The versions of all the secure phones I've evaluated needed this feature: a minimal answering machine. With just the ability to record IPs of While it's nice to have it built into the phone's user interface, you can always do the tool-based thing and use a separate sniffer program to watch who's calling you, and it's also helpful if somebody's trying to call you with a program your phone doesn't grok. If you're on a Unix system, tcpdump is ok, or you can use newer solutions like snort, or pick your favorite Windows equivalent. Either way, if you know the range of ports on your system they're calling, set up the sniffer to record those and output them in some friendly manner; otherwise sniff everything and grep out the familiar ones that you know aren't phone calls.
Secure voice app: FEATURE REQUEST: RECORD IPs
I am elated that the development of Speak Freely is continuing. I think it The versions of all the secure phones I've evaluated needed this feature: a minimal answering machine. With just the ability to record IPs of hosts that tried to call. (A local table can map these to your friends or their faces. Of course, this table should be encrypted when not in use.) Heck, you could even have an option to send email --or I suppose use that instant-messaging stuff that teenagers are fond of-- from the secure IP phone to you, when that phone rings but is not answered.
Re: Secure voice app: FEATURE REQUEST: RECORD IPs
On Mon, Jan 27, 2003 at 08:23:15AM -0800, Major Variola (ret) wrote: I am elated that the development of Speak Freely is continuing. I think it The versions of all the secure phones I've evaluated needed this feature: a minimal answering machine. With just the ability to record IPs of hosts that tried to call. (A local table can map these to your friends or their faces. Of course, this table should be encrypted when not in use.) Pretty hard to do if people are using dialup. Or even dsl, unless they run a linux box they don't ever reboot -- although I've found my dsl ip changing sometimes on it's own, and with no rhyme or reason. Cable is a little more stable, when I had a cable modem it didn't change ip unless I shut off the modem for awhile, and not even always then. (snip) -- Harmon Seaver CyberShamanix http://www.cybershamanix.com
Re: Secure voice app: FEATURE REQUEST: RECORD IPs
On Mon, Jan 27, 2003 at 07:06:24PM +0100, Thomas Shaddack wrote: Pretty hard to do if people are using dialup. Or even dsl, unless they run a linux box they don't ever reboot -- although I've found my dsl ip changing sometimes on it's own, and with no rhyme or reason. DSL lease timeout. A feature of DHCP-based dynamic IP addresses over permanent connections. Similar for cable, though the differences yo observed seem to be rather implementation-dependent than principial. No, not really. It's far too irregular for that, sometimes goes for over a month, then sometimes 2-3 times in a week. More like them doing work on the system. Not really dhcp anyway, it's Eoppp. Cable is usally dhcp, and is better because it authenticates on the mac address of the cable modem. And dhcp can be set up to always give the same ip to a certain mac address, but I don't think the eoppp can, or at least they don't -- it always has to negotiate a challange/passwd response which can be quite problematic -- sometimes the only way to get it to work again is to unplug the modem for 30 seconds or so, which, of course, frustrates any script you have to automagically reset dns for your domainname, or even just keep you online. Cable is a little more stable, when I had a cable modem it didn't change ip unless I shut off the modem for awhile, and not even always then. Idea: What about a caller ID system, based on eg. SSL certificates or PGP signed challenge-response? This would probably work okay, even ssh works despite ip changes, although it stops to ask. -- Harmon Seaver CyberShamanix http://www.cybershamanix.com
Re: Secure voice app: FEATURE REQUEST: RECORD IPs
Pretty hard to do if people are using dialup. Or even dsl, unless they run a linux box they don't ever reboot -- although I've found my dsl ip changing sometimes on it's own, and with no rhyme or reason. DSL lease timeout. A feature of DHCP-based dynamic IP addresses over permanent connections. Similar for cable, though the differences yo observed seem to be rather implementation-dependent than principial. Cable is a little more stable, when I had a cable modem it didn't change ip unless I shut off the modem for awhile, and not even always then. Idea: What about a caller ID system, based on eg. SSL certificates or PGP signed challenge-response?
Re: Secure voice app: FEATURE REQUEST: RECORD IPs
Harmon Seaver [EMAIL PROTECTED] On Mon, Jan 27, 2003 at 07:06:24PM +0100, Thomas Shaddack wrote: DSL lease timeout. A feature of DHCP-based dynamic IP addresses over permanent connections. Similar for cable, though the differences yo observed seem to be rather implementation-dependent than principial. No, not really. It's far too irregular for that, sometimes goes for over a month, then sometimes 2-3 times in a week. More like them doing work on the system. That's about what I've seen. Not really dhcp anyway, it's Eoppp. Cable is usally dhcp, and is better because it authenticates on the mac address of the cable modem. And dhcp can be set up to always give the same ip to a certain mac address, but I don't think the eoppp can, or at least they don't -- it always has to negotiate a challange/passwd response which can be quite problematic -- sometimes the only way to get it to work again is to unplug the modem for 30 seconds or so, which, of course, frustrates any script you have to automagically reset dns for your domainname, or even just keep you online. Harmon Seaver There's probably an X10 module that would let your Linux box cycle the power on your modem/router/switch. try $50 : http://www.x10.com/automation/x10_ck11a.htm If you're not using a domain name then your script could publish your IP address on your home page ( in the clear or not as you choose ). Mike
Re: Secure voice app: FEATURE REQUEST: RECORD IPs
On Mon, 27 Jan 2003, Michael Motyka wrote:
If you're not using a domain name then your script could publish your
IP address on your home page ( in the clear or not as you choose ).
The local friendly telco monopoly (~97% of all DSL connections in
Krautland) separates the PPPoE modems at least once in 24 h.
Unfortunately, the provider collaborates with the feds, and retain the
connection info: http://www.heise.de/ct/aktuell/data/hob-14.01.03-000/
http://www.heise.de/bin/nt.print/newsticker/data/hob-14.01.03-001/?id=f8097b7ftodo=print
I used to run a crontabbed script that queried a cgi-bin giving back the
remote address
#!/usr/bin/perl -w
#
# get own ip addres in plain text
print Content-type: text/plain\n\n;
print $ENV{REMOTE_ADDR};
which got parsed and uploaded as a HTML page to a fixed point in address
space. However, thanks to dyndns.org and router with dyndns clients
built-in this is now much more painless (no need to hack ddclient to parse
your router's status page). More interesting, current wireless routers
seem to support VPN tunnelling (IPsec, specifically). Given the
capabilities, it would be a piece of cake to slip a VoIP package such as
Speak Freely into it. With a headset/USB connection and a web interface to
control the app it would certainly provide some added value and be immune
to firewalling woes.
Speaking of which, has anyone tried Tarzan
http://www.pdos.lcs.mit.edu/tarzan/download.html?
If yes, what is your opinion of it?
Re: Secure voice app: FEATURE REQUEST: RECORD IPs
I used to run a crontabbed script that queried a cgi-bin giving back the remote address I use a very similar system (in PHP), activated by a wget request from /etc/ppp/ip-up.local (Linux). Another tactics I use occassionally when having to improvise is a remote syslog and a crontab entry that each 5 minutes spits a heartbeat message into the log (so each 5 minutes I get an UDP packet telling me the address on which the machine currently is; brute force, reliable, small overhead, abuse-resistant). built-in this is now much more painless (no need to hack ddclient to parse your router's status page). More interesting, current wireless routers seem to support VPN tunnelling (IPsec, specifically). Given the capabilities, it would be a piece of cake to slip a VoIP package such as Speak Freely into it. With a headset/USB connection and a web interface to control the app it would certainly provide some added value and be immune to firewalling woes. Works, proven experimentally. One fateful day my ISP cut off all UDP traffic above and including port 1024 (they reinstated it two days later, so I suppose it was a hasty defense against a DDoS attack). I had a VPN connection to my office LAN, so I opened the two UDP ports on the firewall and set up portforwarding in iptables, and after some wrestling caused by my relative inexperience I got it working. Was surprisingly reliable. By the way - thought a bit about the ringing and authentication. Why we have to unite the call request system with the rest of the IP phone application? Couldn't we use it as an entirely separate process, maybe something simple based on eg. SSL or HTTPS, employing client certificates? This way we reduce the modifications of the VoIP component itself to bare minimum or perhaps none at all. Maybe it could be as simple as a perl or PHP script on the listening side, and a script calling curl on the other side.
Re: Secure voice app: FEATURE REQUEST: RECORD IPs
At 11:25 AM 1/27/03 -0600, Harmon Seaver wrote: On Mon, Jan 27, 2003 at 08:23:15AM -0800, Major Variola (ret) wrote: The versions of all the secure phones I've evaluated needed this feature: a minimal answering machine. With just the ability to record IPs of Pretty hard to do if people are using dialup. Or even dsl, unless they run a linux box they don't ever reboot -- although I've found my dsl ip changing sometimes on it's own, and with no rhyme or reason. Merely notifying me that someone called is useful. It wouldn't require rocket science to recognize an entire class C address as a friend. And remember this proposal is fully back compatible with earlier versions of a sec phone. If you wanted to mess with the protocol, you could obviously add an identifier exchange component. I am not familiar with SpeakFreely's protocol so I don't know if it can be extended without breaking compatability.
