How to Save on High Speed Cable Modem Rental Fee from Comcast

Leave a reply
  1. You will need to purchase a high speed modem. There are many options available but make sure that the one you choose is compatible with your required speed and provider’s network. I chose Motorola SB6121 SURFboard DOCSIS 3.0. Make sure you also have the following information available:
    1. Your Comcast account number and account phone number (write these down since you cannot access them if you are on online billing and your Internet goes down)
    2. Other account information such as the last bill date and amount and other personal information
    3. New modem’s serial and MAC ID
  2. You will need to contact your service provider to update your billing and modem information. I used the Internet technical support online chat option with Comcast and I am guessing it would be similar on the phone. Here are the detailed steps of the chat:
    1. I was asked to provide 3 pieces of personal information.
    2. The person asked for the modem information and had a problem with changing my modem. So I was transferred to the billing department. The transfers are smooth and one person leaves the online chat room and another person comes in.
    3. The other person asked for 3 pieces of information as well and updated my modem from renting to own.
    4. I was transferred back to Internet technical support and my modem information was updated.
    5. I was told that they were having a problem with the provisioning department and I had to wait a few minutes. Eventually, my connection went down. I figured that the old modem was removed from the system.
    6. I connected the new modem and tried to access the network. Here was my problem:
      1. New modem kept receiving RESET packets as soon as it would connect to the Internet. I tried to unplug/plug it multiple times but didn’t work.
      2. After around 30 minutes, I connected the old modem in parallel to my new modem and attached it to my PC to connect to the web.
      3. I was transferred to an activate modem page from Comcast (after opening the browser). I had to verify my account number and phone number and then I was taken to the next page.
      4. I started a technical support chat from the new page and asked the person to select the Motorola as my main modem. The Motorolla modem got a RESET packet and when it came back on it was connected to the Internet with no problems.
    7. I just unplugged the old modem and sent it back to Comcast.
    8. Note that you cannot have two modems connected to the system.
  3. I was renting a Ubee DOCSIS 3.0 modem. By upgrading to Motorola, my ping rate dropped by 30% (10 to 7 ms) and Internet upload/download speed went up by around 10-15%.
Share

How to detect/block SkypeOut Phone calls

Leave a reply

In this post we want to consider various ways in which we can detect SkypeOut phone calls from normal E2E calls. As mentioned before, SkypeOut calls use a gateway to connect the Skype client to the public switched telephone network (PSTN). There are multiple ways in which SkypeOut calls differ from E2E calls.

  1. One of the main features which we can use is the gateway port number (12340) for UDP SkypeOut calls since all of the gateways have been using the same port number in our experiments. Well, what if some poor user is makign E2E calls using the same port value. In that case, we will be making a wrong assumption.
  2. The second way to do this is to gather all the gateways for SkypeOut and mark all the calls to those servers as SkypeOut. This is neither easy nor it is cheap and requires an application constantly updating the list of gateways. The other amazing thing is that by blocking the gateways, it seems that Skype cannot relay SkypeOut calls through the super node but it can still make E2E calls when the other side is not blocked. To confirm this, I ran an experiment in which I blocked all the connections except the connection to the super node and another Skype user using Ubuntu’s firewall and then tried to make E2E and SkypeOut calls. In this case, the E2E calls went through but the SkypeOut calls failed.
  3. The third way suggested by [1] is to check if the SoM is deterministic or not. I did not verify this technique but from the results in the paper, this seems to be the easiest and the most promising solution.

References:
[1] D. Bonfiglio, M. Mellia, M. Meo, D. Rossi, and P. Tofanelli, “Revealing skype traffic: when randomness plays with you,” ACM SIGCOMM Computer Communication Review, vol. 37, 2007, p. 48.

Share

Real-time Packet Type Detection Using Port Scanning

1 Reply

Packet type detection is a crucial part of any traffic shaping technique. Traffic shaping is an essential part of the network traffic which allows time-sensitive packets meet their performance goals. Determining packet types is quite straightforward when the contents are not encrypted and the applications follow a certain pattern generating data packets. But things get much harder when we have to deal with an application which communicates in an encrypted manner and tries to hide from being detected by generating random pattern of packets (For example, Skype and Bit torrent clients are trying hard to avoid detection, because many service providers may benefit compromising their traffic).

There are many approaches to detect traffic such as Statistical Classification methods or Regular Expression pattern matching but these techniques can be fooled when newer version of the software reaches market and the traffic changes. These techniques also need time and human interference and may not necessarily work well with the newer versions of the software.

Therefore, we decided to introduce a new technique to detect packets in real-time. This technique uses the port scanning technique to communicate with the sender and the receiver of the packet flow and detect their services by trying to match a signature to their response. If the services are known then the types of the packet can be detected much easier. We tested our approach to detect HTTP, FTP and Skype packets as a course project and the results were very promising.

We created an application similar to nmap in Python which sends some packets to the sender and the receiver of each packet and tries to match their response to one of the signatures we created for the applications mentioned above and based on the matching we were able to output the packet type. Note that there are many nmap scripts available which can be used to detect many more types of service running on the servers.

The main advantages of this approach:

  1. If the software remains backward compatible, our application will still be able to detect the packet type without the need for an update.
  2. This approach works in both cases when the host’s connection is symmetric or asymmetric because at least one side of the connection should be active and respond to our request.
  3. This technique will work when the source or destination are behind a port-restricted NAT because the port is already forwarded properly.

The disadvantages are as below:

  1. The packets generated by our application adds to the network traffic and repeating the task for each flow on the network can be costly.
  2. If the software refuses to communicate with our application or the response does not match our signature then this approach will be useless.
  3. If the new version of the software is not backward compatible then the new signature will require human interference and automating this task is almost impossible.

I worked on this project with Mike Conley and he described the steps we had to follow to generate the signature for Skype here on his blog.

Share

Skype 101 – Skype Architecture

4 Replies

Skype is one of the largest VoIP providers with over 500 million users. Skype was created by the developers of KaZaa and unlike many of its competition; it operates on a P2P overlay network (It is not using the IETF Session Initiation Protocol (SIP)). Because of its popularity and proprietary design, there has been a surge in the research community and the industry to understand its architecture and network traffic.

From these research, we know that Skype uses wide-band codec (iLBC, iSAC and iPCM developed by GlobalIPSound) which allows it to maintain reasonable call quality at an available bandwidth of 32 kb/s (The Skype claimed bandwidth usage of 3-16 kilobytes/s) and the minimum and maximum audible frequency Skype codec allowed to pass-through are 50 Hz and 8,000 Hz respectively. Note that Codecs are automatically selected. However, as described in [1], it is possible to force Codec selection enclosing the list of disabled Codecs between the tag <\DisableCodecs> in the config.xml file.

In addition, Skype uses TCP for call signalling, and both UDP and TCP for transporting media traffic. Moreover, Skype uses 256-bit AES (Advanced Encryption Standard) encryption and 1024 bit RSA to negotiate symmetric AES keys. User public keys are certified by the Skype server at login using 1536 or 2048-bit RSA certificates.

In this article, I describe the key features of this software.

Skype

There are common terms which are used in the Skype literature and I would like to define them before we start:

Skype Client (SC): Skype application which can be used to place calls, send messages and etc. The Skype network is an overlay network and thus each SC needs to build and refresh a table of reachable nodes. In Skype, this table is called host cache (HC) and it contains IP address and port number of super nodes. This host cache is stored in an XML file called “shared.xml”.  Also, NAT and firewall information is stored in “shared.xml”. If this file is not present, SC tries to establish a TCP connection with each of the seven Skype maintained default SNs IP address on port 33033.

Super Node (SN): Super nodes are the end points where Skype clients connect to. Any node with a public IP address having sufficient CPU, memory, and network bandwidth is a candidate to become a super node and a Skype client cannot prevent itself from becoming a super node. Also, if a SC cannot establish a TCP connection with a SN then it will report a login failure.

Skype Authentication Server: This is the only centralized Skype server which is used to authenticate Skype users. An authenticated user is then announced to other peers and buddies. If the user saves his/her credentials, authentication will not be necessary. This server (IP address: 212.72.49.141 [Buddy list] or 195.215.8.141) also stores the buddy list for each user. Note that the buddy list is also stored locally in an unencrypted file called “config.xml”. In addition, if two SCs have the same buddy, their corresponding config.xml files have a different four-byte number for the same buddy. Finally, it has been shown that Skype routes login messages through SNs if the authentication server is blocked. [Refer to [3] for more details]

Start of Message (SoM) Structure: Skype uses the same port to communicate with the outside world. Therefore, it needs an unencrypted structure in the beginning of each UDP packet to analyze the sequence and the flows at the application layer. This structure is called SoM.

Now let’s analyze the services offered by Skype and its network traffic.

Types of Skype Connections

Skype to Skype (End to End) (E2E)

Call signalling and media transfer

  1. If both caller and receiver are on public IPs and receiver is in the buddy list of the caller, then they establish a call through a direct TCP connection with each other and transfer media using UDP.
  2. If the caller or receiver is behind a port-restricted NAT then they establish a call through a few packets initially transferred between caller, receiver , SN and other hosts [Refer to [3] for more details] and a UDP connection is established between the caller and receiver which is used to transfer media as well.
  3. If caller and receiver are behind a UDP-restricted firewall they will need a relay (node) in between to establish TCP connection to and then the traffic (including media) will go through from one side to the other.

For users that are not present in the buddy list, call placement is equal to user search plus call signalling.

The media structure for E2E is as follows:

  1. SoM
    1. First 16 bits are the message identifier which is chosen similar to TCP (random and confirmed by the receiver).
    2. Function byte (3 random bits + 5 bits) which defines the payload.  The random bits can be removed by applying ox8F bit mask.
    3. Skype login phase or connection management
      1. 0x02: Skype UDP Ping is carried out periodically by all the SCs which consist of two keep-alive messages.
      2. 0x03
      3. 0x07
      4. 0x0f
    4. 0x0d indicates a DATA message.
  2. Frame ( Encrypted )

Skype to PSTN (Public Switched Telephone Network) (SkypeOut)

For Skype out, the application initially contacts the SN and then the PSTN gateway at port 12340. The gateway servers are a separate part of the architecture and not a part of the overlay network. In addition, host servers 195.215.8.140 and 212.72.49.155 are only connected when a user tries to call another user in the PSTN network; therefore, we assume these servers to be Skype-to-PSTN gateways (SkypeOut) [4]. Also, in [1], it is described that G.729 Codec is the preferred codec for E2O (Skypeout) calls.

  1. SoM
    1. The first 4 bytes seems to be a unique Connection IDentifier (CID).
  2. Frame ( Encrypted )

PSTN to Skype (SkypeIn)

Skype Network Traffic

Skype UDP Ping

Skype UDP Ping is carried out periodically by all the SCs which consist of two keep-alive messages.

Skype UDP Probe

Message exchange is used when the Skype is launched and it is used to discover available SNs and network characteristics such as NAT and firewalls. [Refer to [2] [3] for more details]

Skype TCP Handshake

After finding an available SN, SC opens a new port and creates a TCP connection to the SN (On the same port number as the Probe was sent). If an arbitrary port will not be able to go through the NAT or firewall, then SC will use port 80 (Proprietary HTTP protocol handshake) or port 443 (Transport Layer Security [TLS] HTTPS protocol handshake) to connect to the SN. [Refer to [2] for more details]

Skype TCP Authentication

After setting up the connection, a SC connects to the Authentication Server to authenticate itself. [Refer to [2] for more details]

Skype HTTP Communication

On the first execution, it sends an HTTP request to skype.com with the keyword “installed” in it. Also, this is used to retrieve software updates with keyword “getlatestversion”. [Refer to [2] [3] for more details]

Skype User Search

Skype uses its Global Index (GI) technology to search for a user. Skype claims that search is distributed and is guaranteed to find a user if it exists and has logged in during the last 72 hours. Due to the fact that the search messages between the SC and SNs are encrypted and the protocol is not open, it is not possible to make any conclusion about the search techniques used by Skype. But from the response time for each search, we can conclude that there is some sort of user information caching in SNs.

Skype Silence Suppression and Call Hold

Skype does not any sort of Silence Suppression and continues sending silent packets and keep-alive messages during a call hold. Note that this will maintain the UDP binding at NAT, provide some background noise during silence and avoid the drop in TCP congestion window size (when a TCP connection was made between caller and receiver).

Skype Conference Calling

Skype

During a conference call, the most powerful machine always gets elected as a conference host and the other two clients send their data to that host as depicted in the diagram.

References:

  1. Bonfiglio, D., Mellia, M., Meo, M., Rossi, D., Tofanelli, P.: Revealing skype traffic: when randomness plays with you. SIGCOMM Comput. Commun. Rev. 37(4), 37–48 (2007)
  2. D. Adami,C. Callegari,S. Giordano,M. Pagano,T. Pepe – A Real-Time Algorithm for Skype Traffic Detection and Classification – S. Balandin et al. (Eds.): NEW2AN/ruSMART 2009, LNCS 5764, pp. 168–179, 2009.
  3. Baset, S.A., Schulzrinne, H.G.: An analysis of the skype peer-to-peer internet telephony protocol. In: INFOCOM 2006. 25th IEEE International Conference on Computer Communications, pp. 1–11 (2006)
  4. S. Ehlert, S. Petgang, T. Magedanz, and D. Sisalem, “Analysis and signature of Skype VoIP session traffic”, CIIT 2006: 4th IASTED International Conference on Communications, Internet, and Information Technology, 2006, pp. 83–89.
Share