On Sun, May 4, 2014 at 7:00 AM, <44net-request(a)hamradio.ucsd.edu> wrote:
> During some cell site work last night, I seem to have experienced
> Comcast dropping packets from point A to point B simply based on the
> fact that their IP protocol was GRE (IP protocol 47). I also found some
> posts on the Internet that claim Comcast wishes to charge more money to
> transport GRE packets. I'm not sure if this is true, or if I made a
> mistake somehow in my traffic handling. Therefore...
If you really WERE working in a professional role on such equipment, and
you ACTUALLY DID notice GRE packets missing, I would hazard a guess that
you were perfectly capable of scripting up nc, nmap etc, with some bash or
python to do as you ask, instead of trolling this networking group with
your political goals.
On topic though, I do recall some recent amendments to law (actually rules
of a corporation, not real law) where it was specifically forbidden that
any ISP rate-limit any service whatsoever, and then charge to un-limit it,
so likely the govt is ahead of you on this one. Perhaps an email to the
company concerned with a polite request for the same information, and an
implied threat to write some network discovery tool might net you dividends
you seek, or at least a straight answer - rare as they are.
Hi,
During some cell site work last night, I seem to have experienced
Comcast dropping packets from point A to point B simply based on the
fact that their IP protocol was GRE (IP protocol 47). I also found some
posts on the Internet that claim Comcast wishes to charge more money to
transport GRE packets. I'm not sure if this is true, or if I made a
mistake somehow in my traffic handling. Therefore...
Would someone be willing to create software instruments to measure this
claim in general? I'd like to see a transmitter and a receiver piece of
software that can run on Linux to generate and record a sweep of IP
packets carrying all possible protocol numbers (0-255). The protocol
payloads themselves don't need to be well-formatted, just the protocol
number in the IP header needs to be set. Your software will be
considered successful if it measures 100% of all protocols as available
over an unfiltered (eg: LAN) link.
The results of such a measurement would be useful in gauging the ISP
quality of any given carrier. It seems we're moving closer to Selective
Protocol Service Providers (SPSP) and away from true Internet Service
Providers (ISP) if this GRE finding turns out to be right.
--Bart
> On Mon, Apr 28, 2014 at 7:00 AM, <44net-request(a)hamradio.ucsd.edu> wrote:
>
> BTW, your emails trigger gmail's spam filter --
I'm surprised any of this weeks' postings got past the spam filter
whatsoever....
Can we get some tech content please, people? Enough of this rules and
politics crap.
You should check to make sure that you have the 'chargen' service
disabled on your hosts, and block it in your routers if you can.
I've already contacted the people whose system was involved in this attack.
- Brian
----- Forwarded message -----
Subject: Exploitable chargen service used for an attack: 44.x.x.x.
It appears that a public "chargen" service on your network, running
on IP address 44.x.x.x, participated in a large-scale attack against a
customer of ours today, generating large UDP responses to spoofed probes
that claimed to be from the attack target.
chargen is an old testing service that generates large quantities of
traffic with only a small request required. It is commonly enabled by
default on old printers and other connected appliances, but it has no
useful purpose over the open internet.
Please block UDP port 19 (inbound and outbound) at your network
edge, as this should stop these chargen attacks without blocking
legitimate traffic. If the endpoint device that generated this traffic
is configurable, please further investigate whether it is running a
chargen service (and disable it, if so) -- commonly exploited devices
include Cisco hardware that has "udp small servers" mistakenly enabled,
old printers, old UNIX boxes with "chargen" running under inetd, and
Windows boxes with the "Simple TCP/IP services" package installed. Also,
it is worth checking if it is a machine that has been compromised, as
some malware directly generates port 19 traffic, simulating chargen,
and in this way masks its presence.
If you are an ISP, please also look at your network configuration and
make sure that you do not allow spoofed traffic (that pretends to be from
external IP addresses) to leave the network. Hosts that allow spoofed
traffic make possible this type of attack.
----- End forwarded message -----
Brian. Can u tell me how. Been having some kind of issues here. Also think my router it sick. Have a new one on way. Buffalo wzr-600dhp running dd-wrt latest .. Non beta..
73 jerry
On Apr 29, 2014 1:34 PM, Brian Kantor <Brian(a)UCSD.Edu> wrote:
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> You should check to make sure that you have the 'chargen' service
> disabled on your hosts, and block it in your routers if you can.
>
> I've already contacted the people whose system was involved in this attack.
> - Brian
>
>
> ----- Forwarded message -----
>
> Subject: Exploitable chargen service used for an attack: 44.x.x.x.
>
> It appears that a public "chargen" service on your network, running
> on IP address 44.x.x.x, participated in a large-scale attack against a
> customer of ours today, generating large UDP responses to spoofed probes
> that claimed to be from the attack target.
>
> chargen is an old testing service that generates large quantities of
> traffic with only a small request required. It is commonly enabled by
> default on old printers and other connected appliances, but it has no
> useful purpose over the open internet.
>
> Please block UDP port 19 (inbound and outbound) at your network
> edge, as this should stop these chargen attacks without blocking
> legitimate traffic. If the endpoint device that generated this traffic
> is configurable, please further investigate whether it is running a
> chargen service (and disable it, if so) -- commonly exploited devices
> include Cisco hardware that has "udp small servers" mistakenly enabled,
> old printers, old UNIX boxes with "chargen" running under inetd, and
> Windows boxes with the "Simple TCP/IP services" package installed. Also,
> it is worth checking if it is a machine that has been compromised, as
> some malware directly generates port 19 traffic, simulating chargen,
> and in this way masks its presence.
>
> If you are an ISP, please also look at your network configuration and
> make sure that you do not allow spoofed traffic (that pretends to be from
> external IP addresses) to leave the network. Hosts that allow spoofed
> traffic make possible this type of attack.
>
> ----- End forwarded message -----
>
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
Ok, so I am a licensed HAM, an amateur that has no formal education or job
experience regarding networking. However, I believe I have a better handle
on IT than most hams in general, present company excluded. (Anything I can
do to help)
I am assisting the Penn State Amateur Radio Club, a student organization,
to get a couple of 1Gb network backbone connections lit up. One is
dedicated to a D-star gateway (K3CR). The other location is the ham shack,
for web browsing and other future uses, such as APRS Igate, IRLP or
Asterisk.
We will have a /29 assigned by the University. The two Microtik routers we
have purchased are capable of BGP. The university will not advertise 44net,
or allow me to announce BGP. sigh.
Does anyone have any suggestions?
Another regional resource we have in the state of Pennsylvania is PennREN.
It is a partnership that built out fiber optics in a figure-eight footprint
all around the state. They can provide connectivity (I would like to get a
VPN server co-located in their facilities), but they also have dark fiber
available.
My long-term vision is to have a 501c(3) organized by hams light up a
couple of those strands to create a regional 44net. Local hams/clubs would
each have to provide their own 'last mile'
I believe there is a group in Pittsburgh already doing something similar.
I want to learn enough to understand the conversation. Thanks for the video!
Jim Alles, KB3TBX
On 4/24/14, 6:54 PM, K7VE - John wrote:
> I think the better model is BGP "nodes" which provide VPN to subnets.
> The BGP node admins would provide the VPN authentication to know what
> subnets were attaching and BGP would provide Internet connectivity
> (including subnets).
+1
I trust my VPN users and announce via BGP to the global routing table. If you
want to trust my routes cool, if not that's cool too.
I think everyone is over-thinking this. It does no good if the majority of
traffic over 44net allocations is ping and traceroute. Let shit flow and see
what happens.
IF some one starts abusing it, shut it down and fix it. It's like a repeater
when there is a jammer. Once you're aware of it, you shut it down till they
go away and you're not liable for it.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
