Network Working Group D. Zimmerman Request for Comments: 1288 Center for Discrete Mathematics and Obsoletes: RFCs 1196, 1194, 742 Theoretical Computer Science December 1991 Il protocollo di informazioni utente Finger Traduzione a cura di ComiSAT Brescia, Gen. 2008 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di questo Documento Il presente documento definisce un protocollo per l'interscambio di informazioni utente. Questo RFC specifica una traccia standard IAB di protocollo per la comunita' Internet, e richiede discussioni e suggerimenti per migliorie. Per lo stato di standardizzazione e lo status di questo protocollo, si faccia riferimento all'edizione corrente dell'"IAB Official Protocol Standards". La distribuzione di questo documento non e' soggetta a limitazioni. Sunto Questo documento descrive il protocollo di informazione sull'utente Finger. Si tratta di un semplice protocollo che fornisce un'interfaccia ad un programma di informazione di un utente remoto. Basato sull'RFC 742, una descrizione del protocollo Finger originale, questo documento cerca di chiarire la fase di comunicazione tra i due host di una connessione Finger. Non tenta invence di invalidare le molteplici implementazioni esistenti o di aggiungere restrizioni non necessarie alla definizione originale del protocollo. La presente edizione corregge e chiarisce l'RFC 1196. Tavola dei Contenuti 1. Introduzione ............................................. 2 1.1. Intento ................................................ 2 1.2. Storia ................................................. 3 1.3. Requisiti .............................................. 3 1.4. Aggiornamenti .......................................... 3 2. Uso del Protocollo ....................................... 4 2.1. Flusso di eventi ....................................... 4 2.2. Formato dei dati ....................................... 4 2.3. Specifiche della richiesta ............................. 4 2.4. Comportamento RUIP {Q2} ................................ 5 2.5. Risposta RUIP attesa ................................... 6 2.5.1. Richiesta {C} ........................................ 6 2.5.2. Richiesta {U}{C} ..................................... 6 2.5.3. Ambiguita' {U} ....................................... 7 2.5.4. Segno /W nella richiesta ............................. 7 Zimmerman [Page 1] RFC 1288 Finger December 1991 2.5.5. Distributori automatici .............................. 7 3. Sicurezza ................................................ 7 3.1. Sicurezza nell'implementazione ......................... 7 3.2. Sicurezza del RUIP ..................................... 8 3.2.1. Rifiuto della {Q2} ................................... 8 3.2.2. Rifiuto della {C} .................................... 8 3.2.3. Informazioni ritornate ............................... 8 3.2.4. File di informazione utente .......................... 9 3.2.5. Esecuzione di programmi utente ....................... 9 3.2.6. Ambiguita' {U} ....................................... 9 3.2.7. Tracce di verifica ................................... 9 3.3. Sicurezza del client ................................... 9 4. Esempi ................................................... 10 4.1. Esempio di una linea di comando nulla ({C}) ............ 10 4.2. Esempio di un nome specificato ({U}{C}) ................ 10 4.3. Esempio di un nome specificato in modo ambiguo ({U}{C}) . 11 4.4. Esempio di un tipo di richiesta {Q2} ({U}{H}{H}{C}) .... 11 5. Ringraziamenti ........................................... 12 6. Considerazioni sulla Sicurezza ........................... 12 7. Indirizzo dell'Autore .................................... 12 1. Introduzione 1.1. Intento Questo documento descrive il protocollo di informazione sull'utente Finger. Si tratta di un semplice protocollo che fornisce un'interfaccia ad un programma di informazione di un utente remoto (RUIP). Basato sull'RFC 742, una descrizione del protocollo Finger originale, questo documento cerca di chiarire la fase di comunicazione tra i due host di una connessione Finger. Non tenta invence di invalidare le molteplici implementazioni esistenti o di aggiungere restrizioni non necessarie alla definizione originale del protocollo. Le implementazioni di Finger oggi prevalenti sembrano essere derivate soprattutto dal BSD UNIX dell'Universita' della California Berkeley. Questo documento si basa dunque sul comportamento della versione BSD Ad ogni modo, la versione BSD fornisce poche opzioni per adattare il Finger RUIP (N.d.T. - Remote User Informative Program) ad una particolare politica di sicurezza di un sito, o per proteggere l'utente da dati pericolosi. In piu', vi sono MOLTI potenziali buchi di sicurezza cui devono porre attenzione implementatori e amministratori, in particolar modo dal momento che l'obiettivo di questo protocollo e' di restituire informazioni sugli utenti di un sistema, un aspetto sensibile nel migliore dei casi. Per tali motivi, questo documento riporta un certo numero di commenti e raccomandazioni importanti ai fini della sicurezza. Zimmerman [Page 2] RFC 1288 Finger December 1991 1.2. Storia Il programma FINGER al SAIL, scritto da Les Earnest, fu l'ispirazione per il programma NAME all'ITS. Earl Killian al MIT e Brian Harvey al SAIL furno insieme i responsabili dell'implementazione del protocollo originale. Ken Harrenstien e' l'autore dell'RFC 742, "Name/Finger", dalla quale deriva il presente documento. 1.3. Requisiti Nel presente documento, le parole utilizzate per definire il significato di ogni requisito particolare sono scritte in maiuscolo. Queste parole sono: * "DEVE" Questa parola o l'aggettivo "RICHIESTO" indicano che l'oggetto e' un requisito assoluto della specifica. * "DOVREBBE" Questa parola o l'aggettivo "RACCOMANDATO" indicano che vi possono essere validi motivi in circostanze particolari per ignorare l'oggetto in questione, ma le implicazioni complete dovrebbero essere comprese e il caso essere ponderato con cura prima di scegliere vie alternative. * "PUO'" Questa parola o l'aggettivo "FACOLTATIVO" indicano che l'oggetto in questione e' liberamente facoltativo. Un implementatore puo' scegliere se includere l'oggetto per motivi di richiesta di mercato o per fornire un prodotto piu' completo, rispetto magari ad un altro produttore che non include il medesimo oggetto. Un'implementazione non e' conforme se non soddisfa uno o piu' dei requisiti DEVE. Un'implementazione che soddisfa tutti i requisiti DEVE e tutti i requisiti DOVREBBE si definisce "conforme senza condizioni"; una invece che soddisfa tutti i requisiti DEVE ma non tutti quelli DOVREBBE viene detta "conforme con condizione". 1.4. Aggiornamenti Le differenze di nota tra l'RFC 1196 e la presente sono: o lo switch /W opzionale nella specifica della richiesta Finger fu erroneamente inserito alla fine della linea. La specifica Finger 4.3BSD lo pone all'inizio, allo stesso modo di quanto fa ora il presente documento. Zimmerman [Page 3] RFC 1288 Finger December 1991 o la BNF nella specifica di richiesta Finger non era chiara su come trattare gli spazi bianchi, Il presente documento e' piu' esigente, includendo un segno esplicito per essi. o Il flusso di eventi in una connessione Finger e' ora meglio definito sul soggetto della chiusura di una connessione Finger. 2. Uso del Protocollo 2.1. Flusso di eventi Il Finger e' basato sul TCP, e utilizza la porta TCP 79 decimale (117 ottale). L'host locale apre una connessione TCP verso un host remoto sulla porta Finger. Un RUIP si rende disponibile sull'altro lato della connessione per processare la richiesta. Il local host invia al RUIP una richiesta a linea singola basata sulla specifica della richiesta Finger, e attende che il RUIP risponda. Il RUIP riceve e processa la richiesta, ritorna la risposta, ed inizia la chiusura della connessione. L'host locale riceve la risposta e il segnale di chiusura, dopodiche' chiude la sua connessione. 2.2. Formato dei dati Qualsiasi dato trasferito DEVE essere in formato ASCII, con nessuna parita', e con linee concluse dal CRLF (ASCII 13 seguito da ASCII 10). Questo esclude qualsiasi altro formato di caratteri come l'EBCDIC, ecc. Questo significa inoltre che qualsiasi carattere tra l'ASCII 128 e l'ASCII 255 dovrebbe essere realmente un dato internazionale, e non un ASCII a 7-bit con il bit di parita' impostato. 2.3. Specifiche della richiesta Un RUIP DEVE accettare l'intera specifica di richiesta Finger. La specifica della richiesta Finger e' definita: {Q1} ::= [{W}|{W}{S}{U}]{C} {Q2} ::= [{W}{S}][{U}]{H}{C} {U} ::= username {H} ::= @hostname | @hostname{H} {W} ::= /W {S} ::= | {S} {C} ::= Zimmerman [Page 4] RFC 1288 Finger December 1991 {H}, essendo ricorsivo, indica che non vi e' limite arbitrario al numero di campi @hostname nella richiesta. Nell'esempio della richiesta {Q2}, il numero di @hostname e' limitato a due, ma semplicemente per una questione di brevita'. Si faccia attenzione che {Q1} e {Q2} non si riferiscono ad una battitura dell'utente "finger user@host" dal prompt di un sistema operativo. Si riferiscono alla linea che un RUIP riceve al momento. Percio', se un utente scrive "finger user@host", il RUIP sull'host remoto riceve "user", che corrisponde a {Q1}. Come in qualsiasi protocollo della suite IP, "siate aperti in cio' che accettate". 2.4. Comportamento RUIP {Q2} Una richiesta di {Q2} e' una richiesta di inoltro di una richiesta ad un altro RUIP. Un RUIP DEVE fornire il servizio o rifiutare in modo esplicito l'inoltro (si veda la sezione 3.2.1). Se un RUIP fornisce il servizio, questo DEVE essere conforme a quanto segue: Dato che: L'host

apre una connessione Finger verso un RUIP sull'host

.

da' al RUIP sull'host

una richiesta di tipo {Q2} (ad es.: FOO@HOST1@HOST2). Ne deriva che: L'host

e' l'host piu' a destra in (ad es.: HOST2) La richiesta e' la rimanenza di dopo la rimozione del campo "@hostname" piu' a destra nella richiesta (ad es.: FOO@HOST1) E dunque: Il RUIP

deve essostesso aprire una connessione verso

, usando . Il RUIP

deve ritornare qualsiasi informazione ricevuta da a

attraverso . Il RUIP

deve chiudere in circostanze normali solamente quando il RUIP

chiude . Zimmerman [Page 5] RFC 1288 Finger December 1991 2.5. Risposta RUIP attesa Per la maggior parte, l'output di un RUIP non segue una specifica restrittiva, dal momento che viene progettato per essere leggibile dall'utente anziche' da un programma. Esso dovrebbe sforzarsi principalmente ad essere informativo. L'output di una QUALSIASI richiesta e' oggetto di discussione nella sezione relativa alla sicurezza. 2.5.1. Richiesta {C} Una richiesta {C} e' una richiesta per una lista di tutti gli utenti online. Un RUIP DEVE o rispondere o rifiutare in modo esplicito la richiesta (si veda la sezione 3.2.2). Se risponde, DEVE allora fornire perlomeno il nome completo dell'utente. L'amministratore di sistema DOVREBBE essere in grado di includere altre informazioni utili (si veda la sezione 3.2.3), quali per esempio: - localizzazione del terminale - localizzazione dell'ufficio - numero di telefono dell'ufficio - nome del lavoro - tempo di inoperosita' (numero di minuti dall'ultimo input o dall'ultima attivita' di lavoro). 2.5.2. Richiesta {U}{C} Una richiesta {U} {C} e' una richiesta di informazioni approfondite di un utente specifico {U}. Se volete davvero rifiutare questo servizio, probabilmente non avete proprio intenzione di far girare il Finger. Una risposta DEVE includere almeno il nome completo dell'utente. Se l'utente e' loggato, DEVONO essere ritornate da {U} {C} perlomeno le medesime informazioni tornate da {C}. Dal momento che questa e' una richeista di informazioni su un utente specifico, l'amministratore di sistema DOVREBBE essere in grado di scegliere quali informazioni aggiuntive tornare (si veda la sezione 3.2.3), come ad esempio: - localizzazione dell'ufficio - numero di telefono dell'ufficio - numero di telefono di casa - stato di login (non loggato, tempo di logout, ecc.) - file d'informazione utente Un file d'informazione utente e' una feature in cui un utente puo' lasciare un breve messaggio che verra' incluso nella risposta ad una richiesta Finger. (Questo viene tavolta chiamato come "plan" file). Questo e' facilmente implementabile facendo si' (per esempio) che il Zimmerman [Page 6] RFC 1288 Finger December 1991 programma cerchi un file di testo dal nome speciale nella cartella home dell'utente o in qualche settore comune; il metodo esatto viene lasciato all'implementatore. L'amministratore di sistema DOVREBBE poter essere messo nella condizione di abilitare o disabilitare in modo esplicito questa feature. Per ulteriori dettagli si veda la sezione 3.2.4. Vi POTREBBE essere una modalita' utente di avviare un programma in risposta ad una richiesta Finger. Se questa feature esiste, l'amministratore di sistema DOVREBBE esser messo nelle condizioni di abilitarla/disabilitarla facilmente. Si veda sempre la sezione 3.2.4. 2.5.3. Ambiguita' {U} I "nomi" consentibili nella linea di comando DEVONO includere "user name" o "login name" cosi' come definito dal sistema. Se un nome risulta ambiguo, l'amministratore di sistema DOVREBBE poter essere messo nelle condizioni di scegliere tutte le possibili derivazioni che dovrebbero in qualche modo essere ritornate (si veda la sezione 3.2.6). 2.5.4. Segno /W nella richiesta Il segno /w nei tipi di richiesta {Q1} o {Q2} DOVREBBE nel migliore dei casi venire interpretato all'ultimo RUIP per indicare un livello maggiore di verbosita' nell'output d'informazione sull' utente, o al peggio venire ignorato. 2.5.5. Distributori automatici I distributori automatici DOVREBBERO rispondere ad una richiesta {C} con un elenco di tutti gli articoli al momento disponibili per l' acquisto e il possibile consumo. I distributori automatici DOVREBBERO rispondere ad una richiesta {U}{C} con un conteggio dettagliato o una lista del particolare prodotto o slot del prodotto. I distributori automatici non dovrebbero MAI MAI MAI mangiare i soldi. 3. Sicurezza 3.1. Sicurezza nell'implementazione Una corretta implementazione del Finger e' una delle cose di massima importanza. Le implementazioni dovrebbero essere testate contro svariate forme di attacco. In particolare, un RUIP DOVREBBE essere protetto contro forme anomale di input. I fornitori che distribuiscono il Finger insieme al sistema operativo o al software di rete dovrebbero porre le loro implementazioni a test di penetrazione. Il Finger e' una delle strade per la penetrazione diretta, come dimostrato vivamente dal worm Morris. Come il Telnet, l'FTP e l'SMTP, il Finger e' uno dei protocolli a perimetro nella sicurezza di un host. Ne consegue che la solidita' di un'implementazione e' un fattore fondamentale. L'implementazione dovrebbe ricevere degli accurati esami di sicurezza durante la progettazione, l'implementazione e il testing, alla stregua del Telnet, FTP o SMTP. Zimmerman [Page 7] RFC 1288 Finger December 1991 3.2. Sicurezza del RUIP Attenzione!! Il Finger rivela informazioni sugli utenti; tali informazioni possono inoltre essere considerate sensibili. Gli amministratori della sicurezza dovrebbero prendere decisioni esplicite sul far girare il Finger e su che tipo di informazioni questo debba ritornare. Una implementazione esistente fornisce l'ora dell'ultimo login dell'utente, l'ora dell'ultima volta che egli ha letto la posta, se vi e' posta non letta che lo attende, e da chi ha ricevuto l'ultima posta piu' recente non letta! Questo rende possibile tracciare conversazioni in corso e vedere dove viene posta l'attenzione di qualcuno. I siti che hanno coscienza della sicurezza d'informazione non dovrebbero far girare il Finger senza una chiara comprensione di quali e quante informazioni esso metta a disposizione. 3.2.1. Rifiuto della {Q2} Per motivi di sicurezza propri del sito, all'amministratore di sistema DOVREBBE essere data un'opzione per abilitare/disabilitare individualmente l'elaborazione delle {Q2} da parte del RUIP. Se la possibilita' di processare una {Q2} e' disabilitata, il RUIP DEVE ritornare un messaggio di servizio negato di qualsiasi sorta. "Finger forwarding service denied" e' un messaggio adeguato. Lo scopo di questo e' di consentire ai singoli host di scegliere di non inoltrare le richieste di Finger, ma permetterlo qualora essi lo vogliano. In generale, vi sono pochi casi nei quali sarebbe gradito garantire l'elaborazione delle {Q2}, ed essi sono di gran lunga superati dal numero dei casi in cui si vuole negare il servizio. In particolare, si sappia che se una macchina e' parte di un perimetro di sicurezza (ad esempio un gateway che collega il mondo esterno con un insieme di macchine interne) l'abilitazione delle {Q2} fornisce un percorso di ingresso oltre tale perimetro di sicurezza. Si RACCOMANDA dunque che l'opzione di elaborazione delle {Q2} sia la negazione per default. Essa non dovrebbe certamente venire abilitata in un gateway senza accorte considerazioni sulle implicazioni che ne derivano a livello di sicurezza. 3.2.2. Rifiuto della {C} Per motivi di sicurezza propri del sito, all'amministratore di sistema DOVREBBE essere data un'opzione per abilitare/disabilitare individualmente l'accettazione delle {C} da parte del RUIP. Se la possibilita' di processare una {C} e' disabilitata, il RUIP DEVE ritornare un messaggio di servizio negato di qualche sorta. "Finger online user list denied" e' un messaggio adeguato. Lo scopo di questo e' di consentire ai singoli host di scegliere di non elencare gli utenti attualmente online. 3.2.3. Informazioni ritornate Tutte le implementazioni del Finger DOVREBBERO permettere ai singoli amministratori di stabilire i pezzi di informazione da ritornare ad una richiesta. Ad esempio: Zimmerman [Page 8] RFC 1288 Finger December 1991 - L'amministratore A dovrebbe poter essere in grado di scegliere specificatamente di ritornare la localizzazione dell'ufficio, il numero di telefono dell'ufficio, quello di casa, e l'ora di login/logout - L'amministratore B dovrebbe poter essere in grado di scegliere specificatamente di ritornare solamente la localizzazione dell' ufficio e il numero di telefono dell'ufficio - L'amministratore C dovrebbe poter essere in grado di scegliere di ritornare solamente le informazioni minime richieste, ovvero il nome completo dell'utente. 3.2.4. File di informazione utente Consentire ad un RUIP di ritornare le informazioni di un file modificabile dall'utente dovrebbe essere valutato come equivalente a consentire che qualsiasi informazioni sul sistema possa essere liberamente distribuita. Di fatto, e' potenzialmente la stessa cosa che abilitare tutte le opzioni facoltative. Tale frattura di sicurezza di informazione puo' essere determinata in diversi modi, alcune volte in modo intelligente, altre in modo semplicistico. Questo potrebbe disturbare il sonno di quegli amministratori di sistema che desiderano controllare le informazioni date all'esterno. 3.2.5. Esecuzione di programmi utente Consentire ad un RUIP di eseguire un programma utente in risposta ad una richiesta Finger e' potenzialmente pericoloso. FATE ATTENZIONE!! Il RUIP NON DEVE permettere che la sicurezza del sistema venga compromessa da quel programma. L'implementazione di tale feature puo' essere piu' un problema che un valore aggiunto, dal momento che vi sono sempre bugs nel sistema operativo che potrebbero essere sfruttati tramite questo genere di meccanismo. 3.2.6. Ambiguita' {U} Sappiate che l'intelligenza di un utente malintenzionato e/o l'uso persistente di questa feature puo' fare in modo di restituire una lista molto ampia degli username degli utenti di un sistema. Il rifiuto dell'ambiguita' {U} dovrebbe essere assunto allo stesso modo del rifiuto di richieste {C} (si veda la sezione 3.2.2). 3.2.7. Tracce di verifica Le implementazioni DOVREBBERO consentire agli amministratori di sistema di loggare le richieste Finger. 3.3. Sicurezza del client E' attendibile che solitamente vi sara' qualche client che l'utente utilizza per interrogare il RUIP iniziale. Di default, questo programma DOVREBBE filtrare qualsiasi dato non stampabile, lasciando solamente i caratteri a 7-bit stampabili (ASCII da 32 a 126), i tabs (ASCII 9) e i CRLF. Zimmerman [Page 9] RFC 1288 Finger December 1991 Questo protegge da colori che smanettano con i codici di escape del terminale, modificando i nomi X window degli altri, o commettere altre azioni ignobili o confusionarie. Due opzioni utente separate DOVREBBERO essere prese in considerazione per modificare tale comportamento, cosi' che gli utenti possano scegliere di visualizzare i caratteri di controllo o gli internazionali: - una che consenta tutti i caratteri inferiori all'ASCII 32 - un'altra che consenta tutti i caratteri superiori all'ASCII 126 Per quegli ambienti che vivono e respirano sui dati internazionali, l'amministrazione di sistema DOVREBBE poter avere un meccanismo per abilitare l'ultima opzione di default per tutti gli utenti di un particolare sistema. Questo puo' essere fatto mediante una variabile di ambiente globale o simili meccanismi. 4. Esempi 4.1. Esempio di una linea di comando nulla ({C}) Sito: elbereth.rutgers.edu Linea di comando: Login Name TTY Idle When Office rinehart Mark J. Rinehart p0 1:11 Mon 12:15 019 Hill x3166 greenfie Stephen J. Greenfiel p1 Mon 15:46 542 Hill x3074 rapatel Rocky - Rakesh Patel p3 4d Thu 00:58 028 Hill x2287 pleasant Mel Pleasant p4 3d Thu 21:32 019 Hill 908-932- dphillip Dave Phillips p5 021: Sun 18:24 265 Hill x3792 dmk David Katinsky p6 2d Thu 14:11 028 Hill x2492 cherniss Cary Cherniss p7 5 Mon 15:42 127 Psychol x2008 harnaga Doug Harnaga p8 2:01 Mon 10:15 055 Hill x2351 brisco Thomas P. Brisco pe 2:09 Mon 13:37 h055 x2351 laidlaw Angus Laidlaw q0 1:55 Mon 11:26 E313C 648-5592 cje Chris Jarocha-Ernst q1 8 Mon 13:43 259 Hill x2413 4.2. Esempio di un nome specificato ({U}{C}) Sito: dimacs.rutgers.edu Linea di comando: pirmann Login name: pirmann In real life: David Pirmann Office: 016 Hill, x2443 Home phone: 989-8482 Directory: /dimacs/u1/pirmann Shell: /bin/tcsh Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers. No unread mail Project: Plan: Work Schedule, Summer 1990 Rutgers LCSR Operations, 908-932-2443 Zimmerman [Page 10] RFC 1288 Finger December 1991 Monday 5pm - 12am Tuesday 5pm - 12am Wednesday 9am - 5pm Thursday 9am - 5pm Saturday 9am - 5pm larf larf hoo hoo 4.3. Esempio di un nome specificato in modo ambiguo ({U}{C}) Sito: elbereth.rutgers.edu Linea di comando: ron Login name: spinner In real life: Ron Spinner Office: Ops Cubby, x2443 Home phone: 463-7358 Directory: /u1/spinner Shell: /bin/tcsh Last login Mon May 7 16:38 on ttyq7 Plan: ught i ca n m a ' ... t I . . i ! m ! ! e p !pool l e H Login name: surak In real life: Ron Surak Office: 000 OMB Dou, x9256 Directory: /u2/surak Shell: /bin/tcsh Last login Fri Jul 27 09:55 on ttyq3 No Plan. Login name: etter In real life: Ron Etter Directory: /u2/etter Shell: /bin/tcsh Never logged in. No Plan. 4.4. Esempio di un tipo di richiesta {Q2} ({U}{H}{H}{C}) Sito: dimacs.rutgers.edu Linea di comando: hedrick@math.rutgers.edu@pilot.njin.net [pilot.njin.net] [math.rutgers.edu] Login name: hedrick In real life: Charles Hedrick Office: 484 Hill, x3088 Zimmerman [Page 11] RFC 1288 Finger December 1991 Directory: /math/u2/hedrick Shell: /bin/tcsh Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge No unread mail No Plan. 5. Ringraziamenti Grazie a tutti i membri dell'IETF per i loro commenti. Un grazie speciale a Steve Crocker per le sue raccomandazioni e discussioni sulla sicurezza. 6. Considerazioni sulla Sicurezza Considerazioni sulla sicurezza sono discusse nella Sezione 3. 7. Indirizzo dell'Autore David Paul Zimmerman Center for Discrete Mathematics and Theoretical Computer Science (DIMACS) Rutgers University P.O. Box 1179 Piscataway, NJ 08855-1179 Phone: (908)932-4592 EMail: dpz@dimacs.rutgers.edu Zimmerman [Page 12]