RPC & TCP Behavior

Question

Can someone describe from a network point of view what RPC (SUN and/or DCE) is and why it deviates from standard TCP behavior?

The way that I understand it is a client reaches out to a server with a unique source port and then switches the source port after the TCP three way handshake finishes. I work with ASA firewalls so this behavior becomes very apparent when the inspection of DCE RPC is not enabled since the firewall will block it because it sees it as a threat. I have read a few MS TechNet articles and other website definitions to include watching about five Youtube videos which all seem to explain it from a programmers perspective but I have yet to fully understand this concept since I am not a programmer.

Answer 1

Note that there is nothing that deviates from standard TCP regarding the RPC protocols.

SunRPC or DCE RPC works on top of UDP(at least SunRPC can use UDP) or on top of TCP.

Typically in order for an RPC client to contact/call an RPCserver, it first contacts some sort of lookup server (called portmapper or rpcbind in the case of SunRPC), which replies with the location (IP address and port number) of where the actual server is running.

So from a networking perspective:

• RPC Servers listens on a random port number, which may change each time that server program is (re)started.
• At startup the RPC server connects to the portmapper, which runs on a well known port and register itself with which IP address and port number it's listening on.

Normally the portmapper service runs on the same machine as the RPC server programs.

When a client wants to connect to or call an RPC service it performs these actions:

• Connects to the portmapper, on a well known/standard destination port and asks it where the particular service it wants to connect to is.
• portmapper replies with the IP address and port number of the service the client asked for.
• client tears down the connection to the portmapper
• client establishes a new connection to the service using the IP address and port number that pormapper gave it.
• client calls the RPC service over this new connection, which the client may use for multiple RPC calls.
• These RPC calls are just application message exchanged on top of a TCP connection.

(In the case UDP is used instead of TCP, it works much the same, but there's no naturally no connection setup/teardown being performed over the network)

This presents a problem for firewalls, since the servers listens on randomly chosen port numbers, one cannot administratively allow access to a particular port number. Instead a firewall wanting to support this kind of setup would need to open up the portmapper port, catch the RPC messages going to that well known port of portmapper, inspect the message content exchanged with the portmapper to extract the IP address and port number from the RPC messages(the portmapper is itself implemented as an RPC server) in order to dynamically open a port between the RPC server and client.