Evening all,

Recently I had the fortune/misfortune (however you look at it) during a case to have to read-up on Remote Procedure Call (RPC from herein). Basically, RPC is a mechanism used by a system to find out what port the system it wants to communicate with, wants to listen on.

For example, If i want to talk to PC XYZ1, my PC would send an RPC GETPORT call to XYZ1:111 (:111 indicates port 111 on IP “XYZ”, its standard notation in most networking practices, i.e 192.168.1.1:80 is port 80 on 192.168.1.1 (Web Server typically)).

My PC would then receive a response back from XYZ:111 called a GETPORT REPLY, in which the field “PORT:” would have a value, i.e. “583”. This now tells my PC that XYZ wants to listen on 583. We would now initiate communications on the protocol we really want to use, i.e. NFS, TCP, UDP, etc.

A sample interaction can be seen below (tcpdump used for capture, Wireshark used for analysis):

11    4.735711   192.168.1.220    192.168.1.12    Portmap    V2 GETPORT Call (Reply In 13) YPSERV(100004) V:2 UDP

13    4.736711    192.168.1.12    192.168.1.220    Portmap    V2 GETPORT Reply (Call In 11) Port:583

Here we can see 192.168.1.220 asking 192.168.1.12 using Portmap what port they would like to be spoken to on; in packet 13, we can see that 192.168.1.12 replies with “GETPORT Reply: Port 583”.

Now, delving a little deeper. Obviously In real life environments, we arent using simple 192.168.1.0/24 subnets for the whole corporate network. We have many networks on many VLAN’s across many locations. So if 192.168.1.12 in Building-X, wants to communicate with 172.16.54.3 in Building-Y, then in theory the RPC/Portmap method should work correctly. However, in some programs and some vendor implementations, there are issues with RPC and network configurations which cause packets to go into one “black hole” and emerge from a different one. In TCP, as we know, this wouldnt work as we need to be using socket based implementation, i.e. 192.168.1.10:6000 <—–> 192.168.1.1:80 is a Socket to Socket connection which we refer to as a “Flow”. 1.10 will send 1.1, and expect a response back, if it doesnt receive one, or it receives one from an IP of 192.168.1.2 which it has no knowledge of, it will retransmit due to time out and discard the 1.2 packet.

In RPC, as it uses UDP, it is a little more robust. UDP by design is set so that a single UDP datagram can convey a whole “story” without requiring other packets to complete it, i.e. one UDP datagram is a book, not a chapter. It is explained in RFC 768 as:

One possible  UDP/IP  interface  would return  the whole  internet  datagram including all of the internet header in response to a receive operation. Such an interface  would  also allow  the UDP to pass  a  full  internet datagram  complete  with header  to the IP to send.

So in theory, If I sent a GETPORT Call to XYZ:111, and I get a GETPORT REPLY (Port: 583) from ABC:111, The transaction is still “successfully complete”. How you ask? Well, if you do happen to look at an RPC packet in Wireshark, you will see that the first field is called “XID: 0x…”. This is your unique ID for tracking the connection – something which is necessary in nearly all communications. Providing the i get a reply back from ABC:111 with the same XID value i sent OUT to XYZ with, I will be able to understand the reply and not discard/retransmit as below:

10    4.735711    187.31.86.220    187.31.108.2    Portmap    V2 GETPORT Call (Reply In 12) YPSERV(100004) V:2 UDP

12    4.736711    187.31.98.185    187.31.86.220    Portmap    V2 GETPORT Reply (Call In 10) Port:536

In this particular example we are trying to bind NIS to a server, however this RPC GETPORT Call/Reply is the premise for most if not all communications. Providing software implementations are done so to track using the XID field in RPC, and not the IP address sent to, then this is a fairly robust system indeed. I would encourage you all to try this at home if you are interested in networking by downloading wireshark; capturing on your NIC i.e. your wifi card, your physical network card, etc and then in the filter box type “rpc.program”. This will filter all the “rubbish” and leave you with just the RPC you are interested in.

Sam