[Xorp-hackers] XRL IPC questions

[Orion Hodson]

On Mar 13, 2006, at 10:04 AM, Dave Roberts wrote:

> 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?

The core XRL interface exported by the Finder is defined in xorp/xrl/ 
interfaces.xif.  If you look at it you'll see the add_xrl call that  
clients call to register XRLs and resolve_xrl to lookup XRL resolutions.

The connection to the Finder is a tcp connection, but it does not use  
the simple-tcp XRL protocol family that applications use.  This is  
because the XRL protocol families know things about their caller and  
the classes used by their caller have semantics that doesn't map  
cleanly into the Finder semantics.

An XRL request to the Finder is currently a 4 byte binary length  
indicator followed by an ascii message header and then the ASCII  
encoded XRL request.  It looks something like:

nnnn "Finder 0.2\n" "MsgType x\n" "SeqNo nnnn\n" ascii_xrl

Having the length field where it is and in binary is bit cruddy. This  
comes to pass because the length field is not known in the code path  
until the ascii header has been generated.  I'd forgotten the version  
number and other pieces were here since it's been a couple of years  
since I worked on the code.  You can find the code in libxipc/ 
finder_msgs.{hh,cc}.

If you want to see it in action you could run a packet sniffer, like  
ethereal, and inspect the packet contents.

>> 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" ?

Oops, 'invocable'.

>
>> 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.

Just to clarify again, there are no special cases - all interactions  
that processes have with the Finder are through XRL interfaces on the  
Finder.  The FinderClient (libxipc/finder_client.{hh,cc}) is the  
class in processes responsible for interacting with the Finder and  
all the calls it makes are through the same generated XRL sender code  
that the processes use to talk to each other.

>
>> 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.

We definitely need to do something.  I'm not familiar enough with  
Kerberos to say whether it would be a good fit or not.  I suggested  
an approach to the core xorp devs using the OpenSSL crypto routines  
as the binaries already link against the library.  This is an area  
where someone could get involved with the project and make a really  
valuable contribution.

The protocols have validation routines that should hopefully deal  
with random spew connections from aotherwise trusted hosts.  There  
are unit tests in the regression suite that corrupt messages and try  
to test the validation paths, but there may well be holes.  BMS found  
a check missing in the Finder protocol for the field length, which  
when prodded could crash the Finder.

All the best
- Orion