Posted: 12/19/2013 8:25:36 AM EDT
|
First and foremost, I don’t have my ticket…and I have never used DSTAR. I am an RTO from the Army however, and used to be the military liaison for the Eastern Area Gateway for MARS (AAA3USA). The hams that ran AAA3USA were so freaking impressive in their body of knowledge. Anyhow, since I was just a military RTO I never had direct experience with much amateur radio until they showed me. They were always very good at relating what I knew, to what they used; like comparing RTTY to PSK31.
This was all back in 2003-2004. Back then they were telling me about a new (at the time) data mode called DSTAR and explained it to me, but we didn’t have any actual equipment to experiment with then. Fast forward to now (9y later) I am kicking myself for not getting my license back then but am going to take my test in 2 days. As such I’m looking at radios and stumbled back across DSTAR. So in my reading on DSTAR I found that it supports TCP/IP, and it only took me about 10sec to ask how can that be allowed on the Ham bands. Ham’s aren’t allowed to encrypt their transmissions that go over the airwaves. But if I use DSTAR, and use the TCP/IP functionality to browse the internet via a gateway enabled repeater…and I go to a website that uses SSL, then once that SSL encryption encrypts my TCP/IP packets, that effectively encrypts my over the air transmission putting me in violation of FCC rules. How is this allowed? |
|
DSTAR, like APCO25, Moto TRBO or NEXEGE etc are all digital/data communication standard protocols. it's the same thing as using PSK31 or Olivia or what have you.....back in the early days of Digital (Motorola VSELP, precursor to APCO25/P25) circa 1996, we started using it under the "experimental" clause in the Amateur Radio Charter. it did raise some suspicions & a little anal retentiveness ensued but was quickly quashed by it being a new technology & HAMS are supposed to be driving technology (which is no longer true) & promoting the art of new technology. It was soon after the adoption of P25 as a public safety digital standard that the FCC OK'd it for HAM under data transmissions.
So, with that said, it's a digital standard. As far as TCP/IP is concerned, from what I know, it's only used in linking the DSTAR gateways together over the internet. it isn't encapsulated over the DSTAR protocol over RF. However, I don't know that much about DSTAR because I'm a Motorola/P25 person myself & have been for over 15 years. So, it could very well be used over the air but I'm not one to accurately tell you of the intrinsic workings of DSTAR..... |
|
Quoted: First and foremost, I don’t have my ticket…and I have never used DSTAR. I am an RTO from the Army however, and used to be the military liaison for the Eastern Area Gateway for MARS (AAA3USA). The hams that ran AAA3USA were so freaking impressive in their body of knowledge. Anyhow, since I was just a military RTO I never had direct experience with much amateur radio until they showed me. They were always very good at relating what I knew, to what they used; like comparing RTTY to PSK31. This was all back in 2003-2004. Back then they were telling me about a new (at the time) data mode called DSTAR and explained it to me, but we didn’t have any actual equipment to experiment with then. Fast forward to now (9y later) I am kicking myself for not getting my license back then but am going to take my test in 2 days. As such I’m looking at radios and stumbled back across DSTAR. So in my reading on DSTAR I found that it supports TCP/IP, and it only took me about 10sec to ask how can that be allowed on the Ham bands. Ham’s aren’t allowed to encrypt their transmissions that go over the airwaves. But if I use DSTAR, and use the TCP/IP functionality to browse the internet via a gateway enabled repeater…and I go to a website that uses SSL, then once that SSL encryption encrypts my TCP/IP packets, that effectively encrypts my over the air transmission putting me in violation of FCC rules. How is this allowed? As was said, its not encrypted. The decoder is publicly available and it does not hide the meaning of the transmission. Forget about TCPIP. It has nothing to do with the DSTAR digital mode. The Gateway is simply a way for the VOIP system to transmit the packets over ther internet and via tcpip. It's again not encrypted either in this format as the contents of the transmission is not being hidden. If this was the standard, then no digital modes including PSK packet and APRS would be 'encrypted' as you are interpreting this. Read the FCC rules on encryption and you will see what I mean. A bunch of us in here use DSTAR if you have questions on it though otherwise. Good luck getting your license, its not hard. |
|
Quoted: As was said, its not encrypted. The decoder is publicly available and it does not hide the meaning of the transmission. Forget about TCPIP. It has nothing to do with the DSTAR digital mode. The Gateway is simply a way for the VOIP system to transmit the packets over ther internet and via tcpip. It's again not encrypted either in this format as the contents of the transmission is not being hidden. If this was the standard, then no digital modes including PSK packet and APRS would be 'encrypted' as you are interpreting this. Read the FCC rules on encryption and you will see what I mean. A bunch of us in here use DSTAR if you have questions on it though otherwise. Good luck getting your license, its not hard. I think what he is getting at is http://www.dstarinfo.com/Data/Sites/1/SharedFiles/presentations/dstarinfocon2011/infocon-23cmhighspeeddata.pdf -- the Icom DSTAR radios support sending data at 128kbps and *could* access the public Internet over the radio. Then, say you to Facebook.com and it automatically forwards you to https://facebook.com, THAT traffic is SSL encrypted, thus a violation of FCC rules.
|
|
Quoted: I think what he is getting at is http://www.dstarinfo.com/Data/Sites/1/SharedFiles/presentations/dstarinfocon2011/infocon-23cmhighspeeddata.pdf -- the Icom DSTAR radios support sending data at 128kbps and *could* access the public Internet over the radio. Then, say you to Facebook.com and it automatically forwards you to https://facebook.com, THAT traffic is SSL encrypted, thus a violation of FCC rules. Yup. If you are going to have a direct connection to the internet, best have a strict firewall. Similar issue to what goes on with mesh nodes. I wouldn't set one up with actual internet access from the RF side, just linking specific services for what the system is setup for. Not sure how it works with the D-Star stuff, but the 1.2 gig data radio isn't exactly common anyway. |
|
Also, if you load just about any website and advertising is transmitted over the stream, you are also violating FCC rules.
The answer to your question is that no one is looking to hard (if at all). Granted, that doesn't make it OK, but I'm aware of no clear answer to this problem other than don't surf over high speed DD. |
Now I see what your saying. I dont believe its a violation at all. A simple bridge to the internet to feed TCP-IP to a computer is not a violation of the rules the way I read the regulations on for-profit use of amateur bands. Same as sending and receiving e-mail to/from an APRS enabled radio via packet radio. I would be surprised if ICOM and their software makers would promote an RF link like this if it was not a legal method. Are they only saying it should be used for a network connection to transfer files between two computers? Not really, no. They are referencing uploading photos to the internet. The only violation I could ever see here is if someone was using this Amateur radio for an RF link between two computers for a commercial internet data feed. Personal use is fair game the way I see it, even if I go to ebay and buy something. I've thought about doing it myself in the past. An RF data link between two points would be a lot of fun to experiment with, and your damn right I would surf all the same stuff I do now. Especially GUN PORN. The only reason why not is the 1.2 gig radios are really expensive still. You guys say FCC rules violation. Can someone point me to the paragraph where it addresses this? HAs someone contacted ICOM and asked if they have inquired to FCC about this? |
|
Quoted:
Yup. If you are going to have a direct connection to the internet, best have a strict firewall. Similar issue to what goes on with mesh nodes. I wouldn't set one up with actual internet access from the RF side, just linking specific services for what the system is setup for. Not sure how it works with the D-Star stuff, but the 1.2 gig data radio isn't exactly common anyway. Quoted:
Quoted:
I think what he is getting at is http://www.dstarinfo.com/Data/Sites/1/SharedFiles/presentations/dstarinfocon2011/infocon-23cmhighspeeddata.pdf -- the Icom DSTAR radios support sending data at 128kbps and *could* access the public Internet over the radio. Then, say you to Facebook.com and it automatically forwards you to https://facebook.com, THAT traffic is SSL encrypted, thus a violation of FCC rules. Yup. If you are going to have a direct connection to the internet, best have a strict firewall. Similar issue to what goes on with mesh nodes. I wouldn't set one up with actual internet access from the RF side, just linking specific services for what the system is setup for. Not sure how it works with the D-Star stuff, but the 1.2 gig data radio isn't exactly common anyway. Yea...this is what I was getting at. Although the TCP/IP link itself isn't encryption (though it is severe obscurification), if the operator enabled an SSL encrypted link (generally HTTPS) over that TCP/IP bridge then that segment of the communication stream would be encrypted. I'm guessing that the FCC is relying on the operator to know better than to initiate a secure link. Just because a person in a Bentley Continental GT can go 189mph on a public road, they know better than to do that. |
|
Quoted:
***SNIP*** You guys say FCC rules violation. Can someone point me to the paragraph where it addresses this? HAs someone contacted ICOM and asked if they have inquired to FCC about this? The TCP/IP link itself isn't the problem. Initiating an SSL link over a TCP/IP connection is encryption. http://hams.com/encryption/ |
|
Quoted:
Yall lost me  I'll see what I can do to help. Here is a picture of the Icom ID-1 1200MHz radio. In this picture Icom has identified the actual eathernet connector that is used to connect a computer to this radio. In that configuration, this DSTAR radio becomes essentially a modem/NIC for the computer. The computer will use the radio to connect to the internet. There are other radios that allow this ability over other bands too, 2m and 70cm are popular with DSTAR: 
Once your computer is hooked to the ID-1, you can tune the ID-1 into a Gateway enabled DSTAR repeater giving your radio a link to the internet through the gateway. Here are a list of these repeaters: http://www.dstarusers.org/repeaters.php With that setup you can now browse the internet over the HAM band you are connected to. For a video of this here skip to 4m 35sec on this vid: 
Now browsing the internet over TCP/IP just encapsulates your digital communication in TCP/IP packets. This isn't itself encryption, you can open these packets fairly easily with free software available all over the place. The problem is you'd need to splice together thousands of these packets to be able to read the message. And then what you would see would likely be HTML code. Where the problem begins is if you go to a *secure* website, such as https://www.facebook.com. Once you initiate an HTTPS connection over TCP/IP then an SSL certificate is used to encrypt the TCP/IP packet. You can no longer open those packets to read the message. At this point, your transmission has just broken an FCC rule. |
|
Quoted:
I'll see what I can do to help. Here is a picture of the Icom ID-1 1200MHz radio. In this picture Icom has identified the actual eathernet connector that is used to connect a computer to this radio. In that configuration, this DSTAR radio becomes essentially a modem/NIC for the computer. The computer will use the radio to connect to the internet. There are other radios that allow this ability over other bands too, 2m and 70cm are popular with DSTAR: http://www.icomamerica.com/en/products/id1/rearview.jpg Once your computer is hooked to the ID-1, you can tune the ID-1 into a Gateway enabled DSTAR repeater giving your radio a link to the internet through the gateway. Here are a list of these repeaters: http://www.dstarusers.org/repeaters.php With that setup you can now browse the internet over the HAM band you are connected to. For a video of this here skip to 4m 35sec on this vid:  http://www.youtube.com/watch?v=J8PYZOc9L9o
Now browsing the internet over TCP/IP just encapsulates your digital communication in TCP/IP packets. This isn't itself encryption, you can open these packets fairly easily with free software available all over the place. The problem is you'd need to splice together thousands of these packets to be able to read the message. And then what you would see would likely be HTML code. Where the problem begins is if you go to a *secure* website, such as https://www.facebook.com. Once you initiate an HTTPS connection over TCP/IP then an SSL certificate is used to encrypt the TCP/IP packet. You can no longer open those packets to read the message. At this point, your transmission has just broken an FCC rule. Quoted:
Quoted:
Yall lost me I'll see what I can do to help. Here is a picture of the Icom ID-1 1200MHz radio. In this picture Icom has identified the actual eathernet connector that is used to connect a computer to this radio. In that configuration, this DSTAR radio becomes essentially a modem/NIC for the computer. The computer will use the radio to connect to the internet. There are other radios that allow this ability over other bands too, 2m and 70cm are popular with DSTAR: http://www.icomamerica.com/en/products/id1/rearview.jpg Once your computer is hooked to the ID-1, you can tune the ID-1 into a Gateway enabled DSTAR repeater giving your radio a link to the internet through the gateway. Here are a list of these repeaters: http://www.dstarusers.org/repeaters.php With that setup you can now browse the internet over the HAM band you are connected to. For a video of this here skip to 4m 35sec on this vid: http://www.youtube.com/watch?v=J8PYZOc9L9o
Now browsing the internet over TCP/IP just encapsulates your digital communication in TCP/IP packets. This isn't itself encryption, you can open these packets fairly easily with free software available all over the place. The problem is you'd need to splice together thousands of these packets to be able to read the message. And then what you would see would likely be HTML code. Where the problem begins is if you go to a *secure* website, such as https://www.facebook.com. Once you initiate an HTTPS connection over TCP/IP then an SSL certificate is used to encrypt the TCP/IP packet. You can no longer open those packets to read the message. At this point, your transmission has just broken an FCC rule. http://www.ampr.org OP this is nothing new. The old guys around here where able to send email and surf the "web" in the 80s using AMPR. In fact the entire class A block for 44.0.0.0 is set aside for ham radio operators. Think of the money that is worth now. Also check out http://www.broadband-hamnet.org/ The built their routers not to use encryption as far as access goes. But neither system has fail safes for encrypted traffic. There was huge outrage a few months ago when the FCC considered allowing encryption. It is cases like this that no one wanted to listen to. They were afraid that there would be a huge flood of drug cartels using encrypted voice over their repeaters and there would be nothing they can do 
Some have made the argument that DStar itself is encryption. France doesn't allow it for that reason. But we already have a couple threads on that topic. |
|
Quoted:
***SNIP*** Some have made the argument that DStar itself is encryption. France doesn't allow it for that reason. But we already have a couple threads on that topic. Thanks for all that, very cool information. But DStar isn't encryption. I can go with someone if they say that it is severe obscurification, but it isn't encryption. If they think TCP/IP is encryption then they need to explain why TCP/IP needs SSL layers on top of it for them to log into their bank accounts. If they still don't get it, perhaps they should pass a law that states all online banking should be done through raw TCP/IP because it is encryption in itself...see how long their money lasts and how long they keep thinking TCP/IP is encryption   !
|
|
Quoted:
Thanks for all that, very cool information. But DStar isn't encryption. I can go with someone if they say that it is severe obscurification, but it isn't encryption. If they think TCP/IP is encryption then they need to explain why TCP/IP needs SSL layers on top of it for them to log into their bank accounts. If they still don't get it, perhaps they should pass a law that states all online banking should be done through raw TCP/IP because it is encryption in itself...see how long their money lasts and how long they keep thinking TCP/IP is encryption !So where does severe obscuration end and encryption begins? A ceaser cipher is encryption, but today is hardly obscuration. If you want a solution to the dstar problem use ssl strip on the internet to RF device and problem solved. as far as client side just use the opposite of https everywhere. |
|
Quoted:
So where does severe obscuration end and encryption begins? A ceaser cipher is encryption, but today is hardly obscuration. If you want a solution to the dstar problem use ssl strip on the internet to RF device and problem solved. as far as client side just use the opposite of https everywhere. Quoted:
Quoted:
Thanks for all that, very cool information. But DStar isn't encryption. I can go with someone if they say that it is severe obscurification, but it isn't encryption. If they think TCP/IP is encryption then they need to explain why TCP/IP needs SSL layers on top of it for them to log into their bank accounts. If they still don't get it, perhaps they should pass a law that states all online banking should be done through raw TCP/IP because it is encryption in itself...see how long their money lasts and how long they keep thinking TCP/IP is encryption !So where does severe obscuration end and encryption begins? A ceaser cipher is encryption, but today is hardly obscuration. If you want a solution to the dstar problem use ssl strip on the internet to RF device and problem solved. as far as client side just use the opposite of https everywhere. In my world obscurification ends and encryption begins when you determine who can see the information (even if it is difficult to see). With TCP/IP anyone can see the information, although it will take some effort. If there is open source knowledge out there on how to break down the message, and see the true meaning, then it is obscurification. If however the only people who can see the message are the sender and receiver, that is encryption. No matter what you do, an SSL encapsulated TCP/IP transmission will not be able to be seen by anyone other than the sender and receiver. I'm not sure if your solution doesn't already exist though, that's why I started the thread. ICOM and Motorola may have already done what you just said on their gateway repeaters. |
|
Quoted:
In my world obscuration ends and encryption begins when you determine who can see the information (even if it is difficult to see). With TCP/IP anyone can see the information, although it will take some effort. If there is open source knowledge out there on how to break down the message, and see the true meaning, then it is obscurification. If however the only people who can see the message are the sender and receiver, that is encryption. No matter what you do, an SSL encapsulated TCP/IP transmission will not be able to be seen by anyone other than the sender and receiver. I'm not sure if your solution doesn't already exist though, that's why I started the thread. ICOM and Motorola may have already done what you just said on their gateway repeaters. Quoted:
Quoted:
Quoted:
Thanks for all that, very cool information. But DStar isn't encryption. I can go with someone if they say that it is severe obscurification, but it isn't encryption. If they think TCP/IP is encryption then they need to explain why TCP/IP needs SSL layers on top of it for them to log into their bank accounts. If they still don't get it, perhaps they should pass a law that states all online banking should be done through raw TCP/IP because it is encryption in itself...see how long their money lasts and how long they keep thinking TCP/IP is encryption !So where does severe obscuration end and encryption begins? A ceaser cipher is encryption, but today is hardly obscuration. If you want a solution to the dstar problem use ssl strip on the internet to RF device and problem solved. as far as client side just use the opposite of https everywhere. In my world obscuration ends and encryption begins when you determine who can see the information (even if it is difficult to see). With TCP/IP anyone can see the information, although it will take some effort. If there is open source knowledge out there on how to break down the message, and see the true meaning, then it is obscurification. If however the only people who can see the message are the sender and receiver, that is encryption. No matter what you do, an SSL encapsulated TCP/IP transmission will not be able to be seen by anyone other than the sender and receiver. I'm not sure if your solution doesn't already exist though, that's why I started the thread. ICOM and Motorola may have already done what you just said on their gateway repeaters. You are making my point. Is SSL security if I am on the network? No it is not, as proven by all the MiTM attacks it is vulnerable to. With open source tools and just about any computer I wouldn't have a problem. That is the argument you make for tcp/ip. With the right tools it can be seen. Wireshark and you are done. But that requires knowledge. You mentioned RTTY and PSK. If I sent a contestia signal over ssb in 2m with 256 tones and a bandwidth of 100, how long would it take you do be able to read it? It is a mode recognized by the FCC and would fit in all the rules but I guarantee if you heard it over the repeater you would be clueless. That could be called obscuration or encryption. Personally I think you should send whatever you want and just tail it with your call in morse code at 10-15 WPM |
|
Quoted: The TCP/IP link itself isn't the problem. Initiating an SSL link over a TCP/IP connection is encryption. http://hams.com/encryption/ Quoted: Quoted: ***SNIP*** You guys say FCC rules violation. Can someone point me to the paragraph where it addresses this? HAs someone contacted ICOM and asked if they have inquired to FCC about this? The TCP/IP link itself isn't the problem. Initiating an SSL link over a TCP/IP connection is encryption. http://hams.com/encryption/ I get what you are saying. But personally I don't have any problem with it. Sending packets of data over 900mhz which contain packets of SSL encrypted data between my bank, and my computer is 'acceptable'. With DSTAR, every transmission has the amature radio call sign of the sender, so its no secret who is transmitting. I think theres a place for some encryption in the ham bands and see no need to sound the alarm as the author of the link you posted does. But, I still am not sure its as simple as you are saying here. It would be interesting to get an FCC opinion on it though. And I wonder if it has not allready been addressed. I think just as some other 'rules' have been modified to keep up with the times, I Think this could be one that needs to be adjusted to take into consideration the internet based ham stations and RF computer linking that is possible now. |