Q&A
From SUMIWiki
How does SUMI work?
SUMI uses a covert channel for client-to-server communication to keep the address of the server secret (on, for example, IRC), and a faster spoofed UDP channel for server-to-client data transfer. Both channels are required to successfully transmit data with flow control and retransmissions. It should also be possible in the future to use other transmission mechanisms.
Compatibility
What OS do I have to have to run SUMI?
For a client, any common OS should be sufficient. I test on Windows and Unix.
For a server, 0.8.9 supports the following operating systems in the following data channel modes:
| dchanmode | Unix | Windows 95/98/Me | Windows NT/XP/2K+ |
|---|---|---|---|
| debug | supported0 | supported0 | supported0 |
| raw | supported1 | - | supported2 |
| pcap | supported3 | supported4 | supported4 |
| libnet | - | - | - |
0 Not anonymous--only intended for debugging.
1 Requires root access or setuid root bit on launch
2 May require administrator access if using SP2
3 Requires a libpcap (http://tcpdump.org/) with pcap_sendpacket
4 Requires WinPcap (http://www.winpcap.org/), Windows 95 requires WinSock 2 Update (http://www.microsoft.com/windows95/downloads/contents/WUAdminTools/S_WUNetworkingTools/W95Sockets2/Default.asp)
Raw sockets allow IP source address spoofing, and it is suited well for Unix or Windows XP/2000 platforms. Raw sockets are not supported on Windows 95/98/Me. Also, Windows XP Service Pack 2 blocks UDP spoofing and sending TCP data over raw sockets, so to use the "raw" mode under XP you must not have SP2. From Microsoft's release notes:
- A very small number of Windows applications make use of raw IP sockets, which provide an industry-standard way for applications to create TCP/IP packets with fewer integrity and security checks by the TCP/IP stack. The Windows implementation of TCP/IP still supports receiving traffic on raw IP sockets. However, the ability to send traffic over raw sockets has been restricted in two ways: TCP data cannot be sent over raw sockets. UDP datagrams with invalid source addresses cannot be sent over raw sockets. The IP source address for any outgoing UDP datagram must exist on a network interface or the datagram is dropped.
Note: setup dummy interfaces?
If this affects your setup, look into using "pcap" mode. This lower-level access should work even on SP2.
With Unix, if your sysadmin is kind enough to set the setuid bit on "launch" and change ownership to root, you should be able to run SUMI by typing this command as a normal user:
launch ./sumiserv
This is recommended for security purposes, as the actual sumiserv will not be run as root; rather launch will create a raw socket, and pass it to sumiserv. (launch is unavailable on Win32 because of the lack of socket.fromfd.) On some systems, you may be able to allow certain non-root users to create raw sockets, which is even better.
As of 0.8.10, a data channel mode of pcap should work on Windows Me, 98, and 95 (Windows 95 users will need a WinSock 95 WinSock 2 Update from Microsoft), 2000, XP, and Unix's with pcap_sendpacket (if your Unix doesn't have this function in libpcap, upgrade to tcpdump's libpcap) and allows both IP and MAC address spoofing. However, pcap mode is currently experimental, and your default gateway's MAC address has to be specified manually.
Does SUMI work with firewalls?
Some. You must forward a port. The port you use is configurable under "Client", currently it defaults to 3490. Firewalls might block the spoofed packets. Firewalls reported to work:
- Windows firewall
Might have problems:
- Kerio Personal Firewall - blocks spoofing?
Can I use SUMI with a NAT Cable/DSL Router?
For downloading: yes. All you need to do is forward the UDP port specified under the "Client" tab of sumigetw in your router (by default, 3490).
Serving (using sumiserv) behind a NAT is more problematic, but not impossible. See rawproxd.
Can I use SUMI with IRC without mIRC or xchat?
Yes, you can use the irclib transport. First install irclib (http://python-irclib.sourceforge.net/). Then on Windows, Start->Run->cmd, then at the command prompt:
C:\>cd "\Program Files\SUMI" C:\Program Files\SUMI\> sumigetw irclib sumi-00 #3
The disadvantage of using irclib is that you lose control; you can't chat, can't connect to custom servers or channels (yet), and so on. The mIRC or xchat transport is recommended, but if you don't want to bother with an IRC client, irclib is an option.
If you plan on downloading multiple files, remember to keep the client open; otherwise you will disconnect and reconnect and possibly be throttled by the IRC server. Run the sumigetw command from another command prompt and it will be passed to the existing instance.
Technical Questions
Why does SUMI use UDP by default, instead of another protocol such as ICMP?
ICMP offers a distinct advantage over all other protocols: an ICMP echo request can be sent with a spoofed source address to any pingable host on the Internet, and an echo reply will be forwarded, with the original data, back to the spoofed source address. ICMP allows nearly any host to be a proxy. Win32 raw sockets allow receiving echo replies.
UDP will be dropped by some routers under heavy load in favor of TCP packets. Routers may form TCP "aggregates" and forward them, which may or may not be possible with UDP. (?)
However, using UDP has several advantages over any other protocol. Systems not able to handle raw sockets (Windows Me, 98, 95, NT, 3.11) or users not able to create raw sockets (anything but root on normal Unix systems) can still receive the packets. Most TCP/IP stacks can only receive TCP or UDP without special priviledges (the exception is WinXP/2K). Portability is important; anyone should be able to receive these packets.
If desired, the client can be configured to request data packets to be sent using an arbitrary ICMP packet type, or an ICMP ping proxy.
Receiving TCP packets will require libcap, and care has to be taken to not have the OS interfere with attempting to establish a TCP connection. (SUMI can't use TCP provided by the OS because TCP is a connection-oriented service.)
What is the "ICMP Echo" data channel type?
An ICMP echo request is sent (by the server) from a source address of the client, to a random pingable host. The host's kernel receives the ping, swaps the source and destination, and sends an echo reply with the same payload. Therefore the client receives an ICMP echo reply from the gateway with the server's data in it.
However, ICMP echo mode is often slow and inefficient. An extraordinarly small MSS may have to be used, and the extra host introduces more latency and packet losses. You're better off using a more direct data channel type.
What does SUMI use to ensure file transfers are not corrupted?
As of 0.8.9, all UDP packets SUMI sends include a UDP checksum. If the data is corrupted, the checksums won't match, the packet will be discarded by the OS, and the SUMI transfer protocol will request retransmission. This doesn't apply to the other data channel types (ICMP, etc.) but those are rarely used.
As of 0.8.14, all SUMI packets include a CRC-32 checksum. Corrupted data packets are re-requested just like lost packets.
How does SUMI differ from TCP?
SUMI's file transfer protocol and TCP have much the same goal: reliability, guaranteed order, retransmissions. However, there are some subtle differences. Of course, SUMI's data packets can be spoofed which is not possible with TCP.
In SUMI, client-to-server messages have high-latency. The message has to travel to the IRC server, and the IRC server has to send it to the final destination. For this reason, client-to-server acknowledgements must be minimized as much as possible; and therefore a acknowledgement mechanism similar to TCP's own selective acknowledgements (see RFC2018 (http://www.ietf.org/rfc/rfc2018.txt)) and negative acknowledgements are used. Only the sequence numbers of missing packets are transmitted. Additionally, the window size is transmitted with each acknowledgement, implicitedly acknowledging all packets not listed as successfully received. SUMI has a window, although it does not (yet) "slide" as TCP's does.
Fortunately, the server-to-client channel has about the same bandwidth and latency as it would with TCP. In this regard, SUMI is asymmetric. TCP uses the same channel for both directions, SUMI uses a data channel (such as UDP) for data (server to client) and a transport for error control (client to server).
SUMI has some advantages, however. TCP is and has always been a stream protocol. SUMI is not. Thousands of packets can be sent; and any one can be missed and data can continue flowing. The missed packets can be resent later. The file doesn't have to be received as one contigious whole, although it must be in order. Sequence numbers take care of that.
Is SUMI more efficient than TCP?
Probably not. Its true that SUMI allows 6 bytes more of payload (due to IP's header of 20, TCP's header of 20, UDP's header of 8, and SUMI's header of 6), but this is hardly significant. TCP has been highly optimized over the years and sophisticated algorithms have been developed including Nagle's algorithm, slow start, silly window avoidance, Van Jacobson algorithm, and others. SUMI does not have this maturity, although it doesn't try to be less efficient than TCP.
However, SUMI does have the advantage that it concentrates on bulk data transfer, instead of in-order streaming. SUMI accepts out-of-order data: if a packet is lost, the transfer can continue at the same rate; there is no hurry to resend the lost packet as long as it gets there.
Are there any file size limits?
As of 0.8.14, the limit is approximately 5 terabytes. The maximum file size varies slightly depending on your MTU; it can be calculated by (MTU - 40) * 0xffff_ffff. 40 bytes is the header which doesn't include the data: 20 for IP + 8 for UDP + 12 for SUMI. 0xffff_ffff or 232-1 is the maximum sequence number (32 bits). MTU - 40 is the packet size, and multiplying this by the maximum number of packets gives the largest file size in bytes. In the client this value is shown on startup:
Maximum file size (over UDP): 5.6TB
Note, however, the size can also be limited by the MTU of the server if it is less than that of the client.
(0.8.13 and prior used a 24-bit sequence number, which limits the size to many gigabytes. It can be calculated as follows: (MTU - 34) * 16777216.)
Usage
How do I run sumigetw?
Perhaps the easiest way, supported in 0.8.13 or newer, is to open a .sumi file. Links to these files can be placed on World Wide Web sites, emailed, posted to newsgroup, or distributed via other means.
There are also a number of client-side scripts that can be installed in order to invoke SUMI within another application. Notably, mIRC and xchat have client-side scripts. The mIRC script and xchat scripts can be invoked by typing /sumi get nickname filename in the IRC client.
Finally, sumigetw can be invoked manually, but this should rarely be required. A single argument is taken as a .sumi filename, and three arguments are taken as the transport, nickname, and filename.
Does SUMI support resuming? What is this .sumi file?
Yes, as of 0.8.5 resuming works. Unlike stream-based file transfer programs where the file size is sufficient information to resume, incomplete files transferred over SUMI may contain gaps. The .sumi file keeps track of these gaps so they can be filled in during resuming, in addition to an offset. You can delete the .sumi files after finishing downloading.
.sumi files may also contain information on how to locate a file. In Windows, they can be loaded by opening them, and in all OS's, by running sumigetw filename.sumi.
The consistency of the gap information in a .sumi file can be checked with scan.py included in the source distribution.
How can I determine if I can spoof my source address (to serve anonymously with SUMI)?
MIT has an excellent project, the ANA Spoofer Project (http://spoofer.csail.mit.edu/#intro). You can run their spoofer test program to see if you can spoof from a variety of netblocks. The results will also be aggregated for research purposes.
The spoof testing program integrated into the old zpn News bot on irc.p2pchat.org (which handled the !news (http://www.zeropaid.com/bbs/the-lounge/t-zpchat-program-dead-and-buried-8886.html) command) is no longer supported or preferred. Please use the MIT ANA Spoofer Project instead.
Can I still serve if I can't spoof my IP?
RFC2827 (ftp://ftp.ietf.org/rfc/rfc2827.txt) describes egress and ingress filtering suggested as the way to stop IP spoofing. The most legitimate concern for stopping IP spoofing is to stop DoS attacks. However, this also influences SUMI because SUMI servers spoof their source address to remain more anonymous. You may still be in luck.
Dial-in users and other point-to-point users most likely cannot spoof their IP. Its easy to verify at the dial-up point. Cable and DSL users may have an easier time. You may be able to spoof your IP to have a valid prefix (the same as your real IP), but a ever-changing unique host number. This varies depending on the size of your subnet, but RFC2827 says it well:
- As mentioned previously, while ingress traffic filtering drastically reduces the success of source address spoofing, it does not preclude an attacker using a forged source address of another host within the permitted prefix filter range. It does, however, ensure that when an attack of this nature does indeed occur, a network administrator can be sure that the attack is actually originating from within the known prefixes that are being advertised. This simplifies tracking down the culprit, and at worst, the administrator can block a range of source addresses until the problem is resolved.
An example would be 204.69.207.0/24. You could spoof the last octet to help obfuscate your source. (Note that this RFC is directed towards preventing IP spoofing attacks. SUMI is not an attack.)
ICMP proxying can help obfuscate your source further in face of egress filtering, although it is can be inefficient.
Another filter ISPs may impose is blocking internal address they own coming in to their network. The server can easily circumvent this by not spoofing the IP to have the prefix as the client. If the client and server are within the same prefix, behind the filtering router, any spoofing may occur.
Other spoofing prevention techniques (http://www.xs4all.nl/~rmeijer/spoofing.html) exist, although some are impractical.
CERT says this in CA-1998-01 (http://www.cert.org/advisories/CA-1998-01.html):
- Attacks like the smurf attack rely on the use of forged packets, that is, packets for which the attacker deliberately falsifies the origin address. With the current IP protocol technology, it is impossible to eliminate IP-spoofed packets. However, you can use filtering to reduce the likelihood of your site's networks being used to initiate forged packets.
In spite of all this, plenty of ISPs still allow source address spoofing, using any source address. (Private IP addresses may be dropped by other routers, however.) One way to find out is to try running a SUMI server and having your friend connect using the SUMI recipient software. If you get a warning saying possible IP spoofing failure, your ISP may filter. Many still do not however.
If you have hping (http://www.hping.org/) and netcat you can easily test if you can spoof. On a remote machine, type:
nc -vvnulp 3490
On the machine to test spoofing, type:
hping dest_ip -p 3490 -2 -n -d 100 -a source_ip
If it works, netcat will output a 100 X's on the remote machine. Use source addresses near your IP address and gradually move to more liberal addresses to find an appropriate Server Configuration#src_allow.
TODO: make SUMI be able to test spoofing directly
Assuming I can spoof any address, what addresses should I not spoof?
RFC1918 (http://www.isi.edu/in-notes/rfc1918.txt) says:
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
An ipfilter tutorial (http://minwoo.jeong.or.kr/openbsd/securing_small_networks_with_OBSD.html) blocks these addresses outgoing:
block out quick on tun0 from any to 192.168.0.0/16 block out quick on tun0 from any to 172.16.0.0/12 block out quick on tun0 from any to 127.0.0.0/8 block out quick on tun0 from any to 10.0.0.0/8 block out quick on tun0 from any to 0.0.0.0/8 block out quick on tun0 from any to 169.254.0.0/16 block out quick on tun0 from any to 192.0.2.0/24 block out quick on tun0 from any to 204.152.64.0/23 block out quick on tun0 from any to 224.0.0.0/3
127/8 is the loopback, 0/8 is used to refer to "this" network, 169.254/16 is the link-local block, 192.0.2/24 is "TEST-NET", 204.152.64/23 is reserved for private Sun servers, and 224/3 is Class D and Class E. SUMI has the is_nonroutable function to test for these addresses and discards them. (XXX: latest version doesn't discard them.)
How can I be anonymous on my covert channel?
Anonymity on Tor (or, does the Tor transpot leak DNS requests?)
Applicable transports: modtor
No special action is required to be fairly anonymous on Tor. Servers should keep their private key private, and all users should not have a global adversary that can use traffic analysis to discover the true identity of someone.
The Tor transport does not leak DNS requests, see SOCKS and DNS (http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#SOCKSAndDNS) for information on DNS leaks in Tor. SOCKS5 has the capability to send DNS names, IPv4, or IPv6 addresses, and the socks5 module always sends DNS names. SOCKS4A is not required. Furthermore, only .onion hostnames should be passed to modtor, so modtor couldn't leak DNS names if it wanted to.
Anonymity on AIM
Applicable transports: modaim
AIM allows using a wide variety of proxy types to connect. SOCKS, HTTPS, and HTTP. It seems AIM will even allow connecting through an HTTP proxy that only allows GET requests. However, the proxy will know your address. AIM clients cannot (as far as I know) obtain addresses of other clients through AIM without making a direct connection.
Anonymity on IRC
Applicable transports: modxchat, modmirc, modirclib
For IRC, you have several options:
Use a network that supports the +x mask, or automatically provides hostname masking. The major networks do not usually provide this but the smaller ones may. Note that there are several levels of masking; the best replace your host with a seemingly-random series of characters (a hash, actually) not revealing any information about you; next best masks all but your last two domains (thus revealing your ISP); next best mask only the first domain, revealing your ISP and possibly location (if your ISP encodes that in their client's hostnames). The worst IRC networks, anonymity-wise, reveal your full hostname, leaving you vulnerable to IRC viruses as well as defeating the purpose of SUMI.
A few networks let you create a "virtual host" or vhost, that replaces your real mask. Some networks require an administrator to create one for you, which they may not be willing to do; it is also cumbersome especially for your users. Better networks provide an automated or semi-automated vhost registration system, possibly available from NickServ or #vhost.
A bouncer is also an option but provides less security if your bnc host is not trustworthy. Bouncer shell operators may be susceptable to social engineering even if their box is completely secure.
An option not available to most is changing your reverse DNS after connecting. The majority of clients most likely will not be able to do this, but in some situations it could be useful. Change your reverse DNS to something bogus, connect, and then change it again if desired.
As always, the IRC network administrators will be able to see your address. An exception is with the newer anonymous IRC networks, such as IIP, the Invisible IRC Project. (Note: IIP is now I2P)
See also: Host Masking on Internet Relay Chat
Troubleshooting
Why do I always get a "Timeout" error on every download?
You're not receiving the authentication packet for one reason or another. Check to make sure that your IP address is being sent correctly. In particular, if you have a private IP (192.168.x.x, 10.x.x.x, etc.) you will need to set your and set "IP Address" (under the "Client" tab) to your IP. See http://whatismyip.com/. Also make sure that the selected port (UDP 3490 by default) is forwarded (http://www.portforward.com/) to your computer if you are behind a NAT.
Also, there is a possibility that the server you are trying to download from is incorrectly configured.
On Windows 95/98/Me, I get the error ImportError: DLL load failed: One of the library files needed to run this application cannot be found. when running sumiserv using dchan_mode of "pcap", why?
This cryptic error most likely means sumiserv is using the wrong versions of one or more of npptools.dll, packet.dll, wpcap.dll, or wanpacket.dll (part of WinPcap), particularly, Unicode DLLs. NPPTools.dll depends on mfc42u.dll, which is not available for Windows Me. (Unicode is not supported.)
To fix this problem, ensure npptools.dll, packet.dll, wpcap.dll, and wanpacket.dll are not in C:\Program Files\SUMI. Try re-running sumiserv, and if the same error occurs, reinstall WinPcap.
When requesting a file with the xchat transport, xchat says "SIGUSR2 :Unknown command", why?
First, make sure you have xchat 2 or better. Previously, SUMI included a patch to allow using xchat 1.8, but this patch is no longer included. Next, load client-side/xchat.pl into xchat using /load followed by the filename, or X-Chat -> Load Plugin or Script. If xchat says:
- Unknown file type sumi/client-side/xchat.pl. Maybe you need to install the Perl or Python plugin?
Then your xchat does not support Perl, so you need to enable it in xchat and reload the script.
When I type /sumi in mIRC, I get "Unknown command: SUMI", why?
For some reason, the SUMI installer didn't add the /sumi command to your aliases.ini. Its supposed to do this automatically, but sometimes things don't work correctly with mIRC add-ons or strange configurations, or if you installed mIRC after SUMI. You'll have to do it manually: read client-side/mirc.txt and add it to your aliases.ini (Alt-R, then go to the "Aliases" tab). /sumi commands should now be recognized.
When I type /sumi in mIRC, mIRC crashes with "An error has occured and mIRC needs to close", why?
You are using an older version of mIRC. 6.01 doesn't work, but I've tested SUMI with 6.16. Versions in between and newer should work.
The reason is modmirc uses shared memory and a custom windows message to communicate with mIRC, which presumably was not supported in mIRC 6.01.
Developing SUMI
How do I check out the latest source code?
The latest code is in the Subversion (http://subversion.tigris.org/) source code repository. See the instructions (http://developer.berlios.de/svn/?group_id=4611) for how to checkout.
What other software should I install?
See Development Environment for all the prequisites and libraries.
Who should I contact for questions/suggestions/comments about SUMI?
You can email me at jeffconnelly [AT] users.sourceforge.net, but you can also edit this Wiki. Simply add your question to this page.
Where can I view the history of SUMI?
See History.
Politics
What countries is SUMI useful in?
See the 13 Internet enemies of 2006 (http://www.rsf.org/article.php3?id_article=19603) article by Reporters Without Borders (http://www.rsf.org/).
