CIFS Internals

In a nutshell, the Common Internet File System (CIFS) is a network protocol that allows file sharing between network nodes. The protocol is based around a client server design where the client sends request packets to the server, and the server responds back to the client with response packets. Each packet that is sent contains a standard header, plus two variable length fields that are used for packet specific information. Each packet also contains a command field that indicates the general purpose the packet is trying to accomplish. Common command fields indicate that the packet’s purpose is to login, open a file, read from a file, or write to a file.
To gain a more in-depth understanding of the protocol, there are three detailed sections on CIFS below. The first section covers major protocol properties. The second section introduces the CIFS standard packet header by diagramming the various fields and defining their purpose. The final section has two typical packet sequence walkthroughs: logging into a server and a file open/read.

Protocol Properties:
Client/server + request/response: As mentioned above, the CIFS architecture is based upon a client sending requests and a server replying to each request sent5. The protocol is capable of having multiple simultaneous requests outstanding. This is accomplished through the use of a multiplex id (MID). The client insures that every request that is sent to the server has a unique MID. When the server replies to a given request, the response contains the same MID. In this way, multiple requests can be sent to the server, and the client can simply match the response MID with the MID it generated to know which request has just been replied to.

Command based: Each CIFS packet contains a 1-byte command field. There are currently 100+ commands available and the core functionality of each packet revolves around the specified command. Responses to the client always have the same command code as the request. A list of common command codes is available within the CIFS1.0 draft specification.

Protocol dialects/negotiation: There have been many versions of the CIFS protocol since its inception in the 1980’s. Each protocol version is referred to as a dialect and is assigned a unique string to identify the dialect such as “PC NETWORK PROGRAM 1.0” or “NT LM 0.12”. When a client wishes to access files on a remote server, the first CIFS packet that is sent is a negotiate protocol packet. In this CIFS packet, the client lists all of the dialect strings that it is capable of understanding. In the response packet, the server indicates which dialect it wishes to communicate in, or indicates that the server understood no dialects. In this way, the client and server can negotiate which dialect to use for a particular CIFS session.
User/share level security: A share is a server entity (typically a file folder or printer) that is tagged as available to CIFS clients for network sharing. Restricted access to the share is brought about in one of two ways:
1. User level security: Indicates that a client wishing to access the share must provide a username and a password for access. This provides the server administrator fine grain control over who has access to the share. This type of security is used in Windows NT and Windows 2000.
2. Share level security: Indicates that the share itself requires a password to access, but no username is required and no user identity is established. For example, a password X could be assigned to a certain share. Any user knowing password X can then gain access to the share. There is no fine grain control because there is no concept of individual users and their rights. This type of security is used in Windows 95 and 98.
Encryption: For either of the two security methods above, the actual password is sent in an encrypted format to the server6. There are two encryption methods that are commonly used: the newer NT style and the older LAN Manager style. Both encryption methods use challenge-response authentication, where the server sends the client a random string and expects a response that proves the client knows both the random string and the user password.
Command batching: Many CIFS packets are capable of piggybacking other CIFS packets in order to reduce response latency and better utilize network bandwidth. This technique is referred to as ANDX batching.
Opportunistic locking: When a CIFS packet specifies to open a file, an opportunistic lock (oplock) can be requested. If granted by the server, the oplock indicates to the client that no other entities are accessing the file. This allows the client to make any modifications to the file that it wants and not have to write them all to the server immediately. There are multiple types of oplocks and many nuances to them. See the CIFS1.0 draft specification for more information.