Hi!
I have two questions:
1. Around 99% of all webcams on the HAMNET are *only* reachable if you establish the connection using a *source-44* ip address. Do you think this restriction is enough if you don't want to expose the webcam to the internet but want to share with other AMPRNet users?
2. We tell our HAMNET users to put the route 44.0.0.0/8 via <wireless router to HAMNET access point> into their DSL/cable routers. Some well-known internet services for radio amateurs are nowadays hosted on the internet using network44 addresses. Who needs to be blamed if the connection from the HAMNET user to the well-known internet service is not as stable as expected by the user?
73, Jann
On 6/13/15 6:39 PM, Jann Traschewski wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi!
I have two questions:
- Around 99% of all webcams on the HAMNET are *only* reachable if you
establish the connection using a *source-44* ip address. Do you think this restriction is enough if you don't want to expose the webcam to the internet but want to share with other AMPRNet users?
If you don't want your webcam exposed to the world, don't expose it to 44.x (really, don't expose it at all).
- We tell our HAMNET users to put the route 44.0.0.0/8 via <wireless
router to HAMNET access point> into their DSL/cable routers. Some well-known internet services for radio amateurs are nowadays hosted on the internet using network44 addresses. Who needs to be blamed if the connection from the HAMNET user to the well-known internet service is not as stable as expected by the user?
Big, acrimonious discussion going on related to issues like this on this list. Staying away as far as I can. :-)
73, Jann
73, Richard - VE7CVS
On 14.06.2015 04:57, Richard Chycoski wrote:
- Around 99% of all webcams on the HAMNET are *only* reachable if you
establish the connection using a *source-44* ip address. Do you think this restriction is enough if you don't want to expose the webcam to the internet but want to share with other AMPRNet users?
If you don't want your webcam exposed to the world, don't expose it to 44.x (really, don't expose it at all).
I never said I don't want to expose it to the world.
73, Jann
On 6/13/15 9:39 PM, Jann Traschewski wrote:
- Around 99% of all webcams on the HAMNET are *only* reachable if you
establish the connection using a *source-44* ip address. Do you think this restriction is enough if you don't want to expose the webcam to the internet but want to share with other AMPRNet users?
No. There is no guarantee that a 44/8 source IP is a ham. There is no guarantee that a 44/8 sourced packet will comply with $REGULATORY restrictions as they differ across the world.
There is a large chance that a 44/8 source address is a licensed ham, but it's not enforced (and shouldn't be).
If you want to restrict it to licensed ham radio operators you will need a different AAA method.
The other issue here is if you're using the UCSD gw for providing access from the internet, there will be a number of directly attached 44 networks who use BGP that will be unable to view your cams.
- We tell our HAMNET users to put the route 44.0.0.0/8 via <wireless
router to HAMNET access point> into their DSL/cable routers. Some well-known internet services for radio amateurs are nowadays hosted on the internet using network44 addresses. Who needs to be blamed if the connection from the HAMNET user to the well-known internet service is not as stable as expected by the user?
Well this depends, is the route via the cable/dsl router for 44net through your gateway to the internet or via the UCSD gw?
What is the faster connection? Here in the US most HamWAN are able to do 20+mbit, while DSL is going to top at 8/1.5 mbit down. Cable will be faster, but the upstream will be limited to 1 or 2mbit/s in most areas.
My preference is to use the wireless connection for the HamWAN connection with a tunnel for backup. This tunnel is built to the edge routers, not the AMPRNET IPIP tunnels.
BTW, I'm thinking of going to the HAMRADIO hamfest in Germany in a few weeks, will you be there? Looks like I might be flying into Zurich and driving up, got some friends in northern Germany I'd like to visit too.
73's
On 14.06.2015 17:57, Bryan Fields wrote:
- Around 99% of all webcams on the HAMNET are *only* reachable if you
establish the connection using a *source-44* ip address. Do you think this restriction is enough if you don't want to expose the webcam to the internet but want to share with other AMPRNet users?
No. There is no guarantee that a 44/8 source IP is a ham. There is no guarantee that a 44/8 sourced packet will comply with $REGULATORY restrictions as they differ across the world.
There is a large chance that a 44/8 source address is a licensed ham, but it's not enforced (and shouldn't be).
Are you talking about the "special uses" (http://www.ampr.org/tos.txt) ?
"4. What You may do
Your license permits You to use certain addresses exclusively for the purpose of Amateur Radio communications and experimentation, or other special uses as may be agreed to by ARDC."
If you want to restrict it to licensed ham radio operators you will need a different AAA method.
It is not about regulatory restrictions. It is about to whom we want to give access. I think most webcam operators are fine if connections are established from Net44 even if there is a small overlap from these "special uses" (and even small overlap from hijacked networks or spoofed traffic).
The other issue here is if you're using the UCSD gw for providing access from the internet, there will be a number of directly attached 44 networks who use BGP that will be unable to view your cams.
No, we don't use UCSD gw for providing access from the internet. A typical setup of a source-route filtered HAMNET gateway looks like this: 0.0.0.0/0 via ISP (NAT) 44.0.0.0/8 via Radio (IPIP-Mesh included here)
The webcam is hooked up to network44. If we want to provide access from the Internet, Port-Forwarding needs to be setup... If your connection is coming from the IPIP-Mesh, it will work without anything to do...
Directly attached 44 networks currently can't "ping" these webcams. My response to Tim Osburns message in the other thread explains possible workarounds.
- We tell our HAMNET users to put the route 44.0.0.0/8 via <wireless
router to HAMNET access point> into their DSL/cable routers. Some well-known internet services for radio amateurs are nowadays hosted on the internet using network44 addresses. Who needs to be blamed if the connection from the HAMNET user to the well-known internet service is not as stable as expected by the user?
Well this depends, is the route via the cable/dsl router for 44net through your gateway to the internet or via the UCSD gw?
It is the gateway to the Internet. End-to-End-communication will break due to NAT at the ISP.
What is the faster connection?
Cable/dsl is faster.
BTW, I'm thinking of going to the HAMRADIO hamfest in Germany in a few weeks, will you be there? Looks like I might be flying into Zurich and driving up, got some friends in northern Germany I'd like to visit too.
Yes, I will be there from Thursday to Sunday and would be happy to give more in depth information about our real world situation with network44.
73, Jann
I want to comment on this first point.
Of course assuming 44/8 to be 100% ham radio access is overstated. But if one uses only IPIP/tunnels for 44 traffic, you can safely assume it to hold true, because: - even if it could be a spoofed address, the return path will go via a tunnel if a tunnel for that subnet exists - if there is no tunnel for that, reply traffic it will go via ampr-gw via its internet if and will be dropped, since packets with source 44 from the internet are filtered because of that 44/8 routing rule some talked about.
So basically the only traffic from a 44 to another 44 subnet can work bidirectionally only via IPIP mesh or private tunnels. If there is a ilegitimate traffic there, it can be only by accidental or intentional misconfiguration at one of the IPIP/tunnel partners.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Jann Traschewski Sent: Sunday, June 14, 2015 04:39 To: AMPRNet working group Subject: [44net] Two questions
1. Around 99% of all webcams on the HAMNET are *only* reachable if you establish the connection using a *source-44* ip address. Do you think this restriction is enough if you don't want to expose the webcam to the internet but want to share with other AMPRNet users?
(...)
Ah, I forgot...
This of course doesn't hold true for BGP announced subnets, if both subnets involved are BGP announced.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Marius Petrescu Sent: Sunday, June 14, 2015 20:04 To: 'AMPRNet working group' Subject: Re: [44net] Two questions
(Please trim inclusions from previous messages) _______________________________________________ I want to comment on this first point.
(...)
packets with source 44 from the internet are filtered because of that 44/8 routing rule some talked about.
It's also not true of the IPIP-only connected networks. The gateway at UCSD only blackholes 44/8 packets from IPIP nets toward the internet, not from it (as long as the IPIP destination is valid). This means, BGP nets (and spoofed internet traffic) can send packets to IPIP nets though the gateway just fine. It's the return path that is broken.
As a result, if you use TCP you can filter out most unwanted internet users (until the gateway gets fixed). But similar to what Bryan said, this does not give you any assurance that the traffic is from the direct actions of a licensed amateur.
On Sun, Jun 14, 2015 at 10:07 AM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Ah, I forgot...
This of course doesn't hold true for BGP announced subnets, if both subnets involved are BGP announced.
Sorry to say but this is not entirely correct.
ampr-gw does not black hole packets from 44/8 to the internet. This is the whole purpose of that gateway: To permit 44/8 traffic to the internet and back. The 44 to 44 traffic is supposed to go via IPIP directly, so that one is dropped correctly.
So no traffic can originate from an IPIP 44 address towards an 44/8 located in the internet, and, as you correctly said, no reply can go out. And this is valid not only for TCP, but for any protocol. One can hardly compromise a host without replies reaching the originator. Of course, some ddos is possible...
Regarding BGP announced subnets: If they like, they can set up an IPIP endpoint, if not, that's it, they will be treated as spoofed IPs at the moment and dropped. It's their personal choice.
IMHO the biggest enemy in this case is illegitimate traffic being NATed to a 44 IP in a ham environment by bad routing, allowing external internet traffic to the 44net. And there is nothing one can do to prevent it on the service provider side except some kind of authentication.
Marius
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Cory (NQ1E) Sent: Sunday, June 14, 2015 20:31 To: AMPRNet working group Subject: Re: [44net] Two questions
(Please trim inclusions from previous messages) _______________________________________________
packets with source 44 from the internet are filtered because of that 44/8 routing rule some talked about.
It's also not true of the IPIP-only connected networks. The gateway at UCSD only blackholes 44/8 packets from IPIP nets toward the internet, not from it (as long as the IPIP destination is valid). This means, BGP nets (and spoofed internet traffic) can send packets to IPIP nets though the gateway just fine. It's the return path that is broken.
As a result, if you use TCP you can filter out most unwanted internet users (until the gateway gets fixed). But similar to what Bryan said, this does not give you any assurance that the traffic is from the direct actions of a licensed amateur.
On Sun, Jun 14, 2015 at 10:07 AM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Ah, I forgot...
This of course doesn't hold true for BGP announced subnets, if both
subnets
involved are BGP announced.
On 6/14/15 2:20 PM, Marius Petrescu wrote:
ampr-gw does not black hole packets from 44/8 to the internet. This is the whole purpose of that gateway: To permit 44/8 traffic to the internet and back.
Then why is it broken?
The 44 to 44 traffic is supposed to go via IPIP directly, so that one is dropped correctly.
No. I can contact the hamwan seattle just fine from my 44net space.
bryan@MrPickles:~$ traceroute -s 44.98.254.1 44.24.241.98 traceroute to 44.24.241.98 (44.24.241.98), 30 hops max, 60 byte packets 1 208.38.136.2 (208.38.136.2) 1.499 ms 1.268 ms 1.527 ms 2 gi2-4.border4.esnet.com (216.139.207.25) 1.725 ms 2.093 ms 2.094 ms 3 xe-10-2-2.bar1.Tampa1.Level3.net (4.53.172.41) 1.560 ms 1.563 ms 1.557 ms 4 ae-2-70.edge2.SanJose3.Level3.net (4.69.152.81) 67.321 ms ae-4-90.edge2.SanJose3.Level3.net (4.69.152.209) 67.712 ms 66.815 ms 5 ae-2-70.edge2.SanJose3.Level3.net (4.69.152.81) 66.781 ms ae-3-80.edge2.SanJose3.Level3.net (4.69.152.145) 72.565 ms * 6 4.68.71.94 (4.68.71.94) 67.288 ms 67.268 ms 67.539 ms 7 35.248.3.102 (35.248.3.102) 79.733 ms 79.714 ms 79.671 ms 8 66-193-43-154.static.twtelecom.net (66.193.43.154) 85.060 ms 84.562 ms 84.530 ms 9 ge0-0-0-1-sea4.threshinc.net (209.189.202.214) 80.159 ms ge0-0-0-0-sea4.threshinc.net (209.189.201.214) 79.344 ms ge0-0-0-1-sea3.threshinc.net (209.189.202.213) 84.855 ms 10 seattle-er1.hamwan.net (209.189.196.68) 84.161 ms 84.131 ms 84.014 ms 11 eth0.seattle-srv1.hamwan.net (44.24.241.98) 78.655 ms 78.350 ms 78.380 ms
Regarding BGP announced subnets: If they like, they can set up an IPIP endpoint, if not, that's it, they will be treated as spoofed IPs at the moment and dropped. It's their personal choice.
No, the issue is the _broken_ routing at UCSD.
ARDC does not announce the 44/8, UCSD does it for them and has a static route for 44/8 pointing at the gateway box. This is broken routing since the gateway is unaware of the more specific networks.
What needs to be done is the UCSD gateway needs to be made aware of the subnets in the global table and only announce the subnets it knows about. There are routing protocols that would make this easy.
<tangent> I'd argue the BGP networks would be better if 44/8 was split up in such a way set aside a /12 (for example!) for BGP subnets and a /12 for the IPIP users. This makes the routing much easier to configure on a IPIP encap gateway. The present geographic area way of doing it leads to routing table bloat. </tangent>
All space that's not used for legit 44/8 use (so like 98% of the /8 or so) is used for darknet "research". Lets not get into the conflict of interest/private inurement this presents.
IMHO the biggest enemy in this case is illegitimate traffic being NATed to a 44 IP in a ham environment by bad routing, allowing external internet traffic to the 44net.
I have no idea what sort of NAT configuration this is. Can you define the flows of traffic here and where the NAT is happening? Bad routing will not cause NAT, NAT must be configured.
And there is nothing one can do to prevent it on the service provider side except some kind of authentication.
Exactly, 44net has no guarantee about the traffic. Even if we did, it's still a poor security model.
73's
You are sure that you are not masquerading 44.98.254.1 in your firewall?
masquerading overrides what you set have as source address and you will see that it goes out with your commercial address as source.
At least when I monitored with tcpdump in Ubuntu.
I can't reach them from Canada when masquerading is switched off.
Those BGP announced subnets are a blackhole from here except when they have a working IPIP entry or that a gateway is setup that can route to them.
73,
Bob VE3TOK
On 15-06-14 03:10 PM, Bryan Fields wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 6/14/15 2:20 PM, Marius Petrescu wrote:
ampr-gw does not black hole packets from 44/8 to the internet. This is the whole purpose of that gateway: To permit 44/8 traffic to the internet and back.
Then why is it broken?
The 44 to 44 traffic is supposed to go via IPIP directly, so that one is dropped correctly.
No. I can contact the hamwan seattle just fine from my 44net space.
bryan@MrPickles:~$ traceroute -s 44.98.254.1 44.24.241.98 traceroute to 44.24.241.98 (44.24.241.98), 30 hops max, 60 byte packets 1 208.38.136.2 (208.38.136.2) 1.499 ms 1.268 ms 1.527 ms 2 gi2-4.border4.esnet.com (216.139.207.25) 1.725 ms 2.093 ms 2.094 ms 3 xe-10-2-2.bar1.Tampa1.Level3.net (4.53.172.41) 1.560 ms 1.563 ms 1.557 ms 4 ae-2-70.edge2.SanJose3.Level3.net (4.69.152.81) 67.321 ms ae-4-90.edge2.SanJose3.Level3.net (4.69.152.209) 67.712 ms 66.815 ms 5 ae-2-70.edge2.SanJose3.Level3.net (4.69.152.81) 66.781 ms ae-3-80.edge2.SanJose3.Level3.net (4.69.152.145) 72.565 ms * 6 4.68.71.94 (4.68.71.94) 67.288 ms 67.268 ms 67.539 ms 7 35.248.3.102 (35.248.3.102) 79.733 ms 79.714 ms 79.671 ms 8 66-193-43-154.static.twtelecom.net (66.193.43.154) 85.060 ms 84.562 ms 84.530 ms 9 ge0-0-0-1-sea4.threshinc.net (209.189.202.214) 80.159 ms ge0-0-0-0-sea4.threshinc.net (209.189.201.214) 79.344 ms ge0-0-0-1-sea3.threshinc.net (209.189.202.213) 84.855 ms 10 seattle-er1.hamwan.net (209.189.196.68) 84.161 ms 84.131 ms 84.014 ms 11 eth0.seattle-srv1.hamwan.net (44.24.241.98) 78.655 ms 78.350 ms 78.380 ms
Regarding BGP announced subnets: If they like, they can set up an IPIP endpoint, if not, that's it, they will be treated as spoofed IPs at the moment and dropped. It's their personal choice.
No, the issue is the _broken_ routing at UCSD.
ARDC does not announce the 44/8, UCSD does it for them and has a static route for 44/8 pointing at the gateway box. This is broken routing since the gateway is unaware of the more specific networks.
What needs to be done is the UCSD gateway needs to be made aware of the subnets in the global table and only announce the subnets it knows about. There are routing protocols that would make this easy.
<tangent> I'd argue the BGP networks would be better if 44/8 was split up in such a way set aside a /12 (for example!) for BGP subnets and a /12 for the IPIP users. This makes the routing much easier to configure on a IPIP encap gateway. The present geographic area way of doing it leads to routing table bloat. </tangent>
All space that's not used for legit 44/8 use (so like 98% of the /8 or so) is used for darknet "research". Lets not get into the conflict of interest/private inurement this presents.
IMHO the biggest enemy in this case is illegitimate traffic being NATed to a 44 IP in a ham environment by bad routing, allowing external internet traffic to the 44net.
I have no idea what sort of NAT configuration this is. Can you define the flows of traffic here and where the NAT is happening? Bad routing will not cause NAT, NAT must be configured.
And there is nothing one can do to prevent it on the service provider side except some kind of authentication.
Exactly, 44net has no guarantee about the traffic. Even if we did, it's still a poor security model.
73's
On 14.06.2015 21:10, Bryan Fields wrote:
<tangent> I'd argue the BGP networks would be better if 44/8 was split up in such a way set aside a /12 (for example!) for BGP subnets and a /12 for the IPIP users. This makes the routing much easier to configure on a IPIP encap gateway. The present geographic area way of doing it leads to routing table bloat. </tangent>
+1
It even would solve a lot of other problems we currently have! I wrote down already a lot of use cases which I'm happy to discuss in Friedrichshafen...
73, Jann
Marius,
You seem to have misunderstood my statement. I didn't mean to imply that the gateway drops all traffic to the internet. It blackholes packets with a 44/8 destination that is directly connected to the internet instead of participating in the IPIP mesh. It doesn't do this intentionally as you seem to believe. It does this because the gateway's upstream network at UCSD has a static 44/8 catch-all route without being aware of the more specific 44/8 routes on the global internet, creating a loop for those packets. Incoming packets from those networks are not treated as spoofs, unlike what you said.
The catch-all route is needed because most of the IPIP-connected networks are too small to be routed on the internet directly, so it's necessary for the gateway to be the default for all internet traffic where a more specific internet route doesn't exist. Unlike what some others have implied, this is a perfectly standard way for BGP networks to operate on the internet.
It seems like some people may be under the impression that anyone who uses 44/8 addresses should be required to participate in the IPIP mesh and that is definitely not true. IPIP is just a workaround for connecting 44 networks to the larger global network since most of them are either too small or lack the resources to make those connections using standard methods. It's important not to confuse this workaround with a VPN that would provide authenticated tunnels, or a private network where you can implicitly trust all of your local traffic.
44-net shouldn't be treated like another radio mode of operation where we can all make contacts with each other using IP packets. It's just a valuable resource that allows us to easily participate in the global network and share our actual ham related resources.
On Sun, Jun 14, 2015 at 11:20 AM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Sorry to say but this is not entirely correct.
ampr-gw does not black hole packets from 44/8 to the internet. This is the whole purpose of that gateway: To permit 44/8 traffic to the internet and back. The 44 to 44 traffic is supposed to go via IPIP directly, so that one is dropped correctly.
-
Boudewijn (Bob) Tenty -
Bryan Fields -
Cory (NQ1E) -
Jann Traschewski -
Marius Petrescu -
Richard Chycoski