Millennium standards compliance and firewalls

["Steve Waage" <waage at macalester dot edu>]

IUGs,
	We are having problems with Millennium client connections 
that have to run through firewalls upgraded to the latest 
software/firmware available.  The following is an example of an 
exchange I recently had with an IT director after he and his firewall 
vendor did some packet dumping on Millennium traffic.  
(Note:  I've obscured the firewall vendor's name to "protect the 
vigilant")
--------------------------------snip-------------------------------------------
Here is the problem in a nutshell: When attempting to make a client 
connection with the CLIC system the client will not even start up to 
the point that you see any entries in the "DOS"screen. In fact, in 
putting a packet sniffer on, we discovered there was a problem with 
the 3rd or 4th packet in the initial exchange. We submitted all of 
this to [FIREWALL VENDOR] over a period of time and Here is 
the response from the engineering department: 

Returned call to customer asked him to call me. I briefly explained 
the reason for us dropping packets. Packet traces show that the 
application is not rfc1945 and rfc2616 compliant. According to the 
RFCs HTTP client should send packet where GET line ends with 
0D 0A (CRLF): 47 45 54 20 2F 49 4E 49 54 41 50 50 GET 
/INITAPP 20 48 54 54 50 2F 31 2E 30 0D 0A HTTP/1.0... But this 
client sends packet where GET line ends with 0A 0A 0A (CRCRCR) 
instead of 0D 0A (CRLF): 47 45 54 20 2F 49 4E 49 54 41 50 50 
GET /INITAPP 20 48 54 54 50 2F 31 2E 30 0A 0A 0A HTTP/1.0... 

Again, this is a [FIREWALL VENDOR]  Firewall running the 
advanced 3.0.x.x firmware. We have had issues with our 
[FIREWALL VENDOR] dropping the connection every 5 minutes 
when we tried moving up from their firmware version 2.5.0.1, but at 
that point we were atleast making a successful connection with the 
client..... 
------------------------------snip-----------------------------------------------

	I'm expecting more of this kind of problem as network 
security concerns and attendant power and sophistication of 
security hardware and software are on the rise.  

	Any suggestions on getting III to remedy this problem are 
appreciated.

Thanks,
Steve
-- 
Steve Waage, Cooperating Libraries In Consortium
mailto: waage at macalester dot edu, office phone 651.644.3878, 
cellphone 651.208.2462