From: richard <richard@pacdat.net>
To: bloat@lists.bufferbloat.net
Subject: [Bloat] Interesting new study of wireless carrier "middle box" characteristics - buffering and strange TCP activities
Date: Fri, 26 Aug 2011 13:41:29 -0700 [thread overview]
Message-ID: <1314391289.22760.48.camel@adm.pacdat.net> (raw)
http://www.eecs.umich.edu/~qiangxu/paper/sigcomm11_wang.pdf
includes creation of Android app "NetPiculet" to analyze this activity.
sample:
We released NetPiculet on Android Market in January 2011 and
attracted 393 unique mobile users within merely two weeks. Leveraging
the data from these users, we report our findings from 10 7
cellular carriers around the world. In particular, we studied the
policies of two large nation-wide U.S. carriers in more depth and
corroborated our findings carefully with controlled experi ments.
Due to security and privacy concerns, we anonymize their names
and label them as Carrier A and Carrier B. We summarize our key
findings as follows:
• In some cellular networks, a single mobile device can encounter more
than one type of NAT, likely due to load balancing. We also discovered
some NAT mappings increment
external port number with time which was not documented
in any prior NAT study. Accordingly, we develop new NAT
traversal techniques to handle both cases.
• Four cellular networks are found to allow IP spoofing, which
provides attack opportunities by punching holes on NATs
and firewalls “on behalf of” a victim from inside the networks, and thus
directly exposing the victim to further attacks from the Internet.
• Eleven carriers are found to impose a quite aggressive timeout value
of less than 10 minutes for idle TCP connections,
potentially frequently disrupting long-lived connections maintained by
applications such as push-based email. The resulting extra radio
activities on a mobile device could use more
than 10% of battery per day compared to those under a more
conservative timeout value (e.g., 30 minutes).
• One of the largest U.S. carriers is found to configure firewalls to
buffer out-of-order TCP packets for a long time,
likely for the purpose of deep packet inspection. This unexpectedly
interferes with TCP Fast Retransmit and Forward
RTO-Recovery, severely degrading TCP performance triggered merely by a
single packet loss.
• At least one firewall of a major cellular ISP liberally accept s
TCP packets within a very large window of sequence numbers, greatly
facilitating the traditional blind data injection attacks, endangering
connections that transfer relatively large
amount of data (e.g., streaming applications).
• Some cellular network firewalls do not immediately remove
the TCP connection state after a connection is closed, allowing
attackers to extend his attack on a victim even after the
victim has closed the connection to a malicious server. This
also dramatically lengthens the NAT traversal time to a few
minutes, given that the same TCP five tuple cannot be reused
quickly.
original pointer from
http://www.technologyreview.com/communications/38435/page1/
richard
--
Richard C. Pitt Pacific Data Capture
rcpitt@pacdat.net 604-644-9265
http://digital-rag.com www.pacdat.net
PGP Fingerprint: FCEF 167D 151B 64C4 3333 57F0 4F18 AF98 9F59 DD73
reply other threads:[~2011-08-26 19:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1314391289.22760.48.camel@adm.pacdat.net \
--to=richard@pacdat.net \
--cc=bloat@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox