[Xorp-hackers] XRL IPC questions

[Dave Roberts]

Orion, this was great. Thanks. A few follow-ups and clarifications below...

Orion Hodson wrote:
> You are on the right lines.  I've attempt to clarify a few points below 
> as I am responsible for this portion of the code and the lousy 
> documentation.

BTW, the docs were great as far as they went. I would just request more 
examples, particularly of the major processes in the system. The 
detailed questions I'm asking I would expect to find documented only in 
the code.

> 1. How do processes interact with the Finder?
> 
> The Finder is the resolver process.  There is one Finder per XORP router 
> instantiation.  The address and port of the Finder are configurable (via 
> XRL_FINDER_SERVER_ADDRESS and XRL_FINDER_SERVER_PORT environment 
> variables).  The default is 127.0.0.1/19999 and no DNS resolution is 
> done in the default case since a router can't depend on DNS to function.
> 
> When a process starts it connects to the Finder and informs it of all 
> the XRLs it supports and how they resolve into something the XRL library 
> can invoke - a transport type, an transport specific address, and a 
> string identifying the method.  For each XRL registered the Finder 
> provides the client with a strong name for the method supplied.  The 
> registering will only respond to invocations that use the  transport, 
> transport address, and the strong name.  The strong name is one piece in 
> making network attacks harder, otherwise it'd be trivial to craft XRLs 
> remotely and direct them at a XORP router.

Can you give an example here? I'm having trouble understand what this 
looks like in terms of XRLs/PDUs crossing between the two processes. In 
particular, it seems like the first connection to the finder is 
dedicated to doing resolutions, so when you say "it connects to the 
Finder and informs it of all the XRLs it supports," are you saying this 
happens on the first connection to 127.0.0.1/19999, or does the process 
invoke finder XRLs on a separate connection (an stcp://127.0.0.1:<finder 
port>/...) ?

Does that make sense?

If both functions, resolution and registration (and others, I suppose) 
share the 127.0.0.1/19999 connection, how does the finder discriminate 
between a client requesting a resolution and another XRL invocation 
specific to the Finder?

> Arguments are marshalled in XRLs according to the transport type.  Each 
> argument is represented by an XrlAtom.  For the most commonly used 
> transport, simple TCP (stcp), marshalling consists of rendering the atom 
> into a host-independent binary format.  Library support exists for 
> rendering to ASCII.  In the examples, we present the ASCII rendering 
> since it's easier to follow.

This is helpful, BTW.

> 2. How does a process register with the Finder?
> 
> The basic process is hopefully outlined in above.
> 
> One interesting point to note is that the Finder itself is an XRL 
> dispatcher just like other XORP processes.  When a process makes a 
> request to the Finder, such as registering an XRL, it sends the request 
> as an XRL to the Finder and the finder responds in the usual manner - an 
> error code plus result in the form of a list of XrlAtoms.

Got it.

> The transport for the Finder is handled as a special case as trying to 
> do otherwise made portions of the code hard to reason about.  The 
> protocol used to transport XRLs to the Finder is simply "finder" and 
> translates into a TCP connection to the known Finder host and port.
> 
> There is no strong-name mapping with Finder XRLs.  The method name sent 
> over the wire corresponds to code incable on the finder.  Otherwise we'd 
> have to deal with how to resolve Finder XRLs.

Having trouble parsing that. "incable" ?

> The first incarnation of the Finder used a totally disjoint 
> communication mechanism, but this went against the goal of 
> extensibility.  Having the Finder export XRL interfaces makes it easier 
> to extend.  We added the Finder Event Notifier interface pretty 
> trivially once we'd gotten the basic process-to-Finder communication 
> over XRLs.

Got it. So the resolution interface is really a special case, with 
everything else implemented as standard XRL interfaces, including 
registration and all other non-resolution functions of the Finder.

> 6. What about Finder security?
> 
> By default the Finder only accepts connections from the IP addresses 
> associated with the host it is running on, ie no external connections.  
> Additional addresses can be added at the command-line.
> 
> By dumping packets on the localhost (or local network for a distributed 
> XORP router) a hacker could determine the resolutions of XRLs and send 
> malicious messages to the XORP processes.  Adding encryption to the 
> Finder protocol would raise the bar to this attack.
> 
> The Finder XRL transport currently uses a naive packet encoding and it 
> is possible to crash the finder by connecting to it and sending it 
> junk.  This needs to be addressed and should happen at the same time 
> encryption goes in since it touches the same code paths.

This probably needs to be improved. Right now, the system relies on 
every on-box process being friendly. If an attacker can "get on the 
box", the whole system can be corrupted quite easily. In fact, with a 
simple client process, I can scan all open ports on the box and spew 
junk at them.

You probably want to end up with a Kerberos-like ticket granting scheme 
to verify that clients really are authorized to connect. In fact, why 
not just Kerberos itself? Seems like it does everything you want, 
including handle the distributed cases. It's probably more heavyweight 
than you'd like for the simple case, but it works and it has been tested 
for years for threats.

-- Dave