14 Jun
2015
14 Jun
'15
2:39 a.m.
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
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
14 Jun
14 Jun
3:57 a.m.
On 6/13/15 6:39 PM, Jann Traschewski wrote:
(Please trim inclusions from previous messages)
_______________________________________________
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?
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).
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?
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
8:13 a.m.
On 14.06.2015 04:57, Richard Chycoski wrote:
I never said I don't want to expose it to the world.
73,
Jann
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
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?
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). 
4:57 p.m.
On 6/13/15 9:39 PM, Jann Traschewski wrote:
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?
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.
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?
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
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
15 Jun
15 Jun
7:28 a.m.
On 14.06.2015 17:57, Bryan Fields wrote:
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."
It is the gateway to the Internet. End-to-End-communication will break
due to NAT at the ISP.
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?
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.
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.
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?
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?
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
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
14 Jun
14 Jun
6:03 p.m.
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(a)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?
(...)
6:07 p.m.
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(a)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.
(...)
6:31 p.m.
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(a)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.
7:20 p.m.
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(a)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(a)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.
8:10 p.m.
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
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
10:37 p.m.
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
15 Jun
15 Jun
7:31 a.m.
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
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
14 Jun
14 Jun
8:14 p.m.
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(a)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.
3257
days inactive
3258
days old
12 comments
6 participants
participants (6)
-
Boudewijn (Bob) Tenty -
Bryan Fields -
Cory (NQ1E) -
Jann Traschewski -
Marius Petrescu -
Richard Chycoski