RE: i-cap proposals

[<lordchariot () earthlink net>]

ICAP does appear to be HTTP-centric, but that's somewhat deceiving. It is a
little more flexible than you may think. Much of the HTTP-like impression
you have could be due to the protocol resembling HTTP itself, but there are
design considerations for extensibility (so I am told).

You are describing the REQMOD method that is used in basic URL, filename,
mime-type and basic header filtering. Great for speed and can make many
policy decisions from header data provided it via caches, proxies or
firewalls.

The RESPMOD method is more complex and provides the ability to take chunks,
trickles or streams of data from a gateway device and pass it to a robust
content scanning engine for AV, mobile malicious code determination, magic
byte validation or even animated gif detection for ad blocking.

We use ICAP for all of the aforementioned filtering and more with HTTP, SSL,
FTP and SMTP. POP3/IMAP would be really nice. I think the challenge is
decoding those protocols and extracting the relevant data for presentation
to ICAP and re-inserting them so as not to break the email protocol itself.
There's little tolerance in some areas that make it difficult to be
transparent between the client/server.

I don't claim to be an expert on ICAP itself, but many of the original
contributors to the protocol work for us and continue to refine the protocol
for use with our ICAP products and the rest of the community. If you have
some specific questions, I can _try_ to get answers from them directly.

Qapla'
erik
_________________________________________________
Erik Elsasser                  System Engineering
CyberGuard Worldwide             Northeast Region


 

-----Original Message-----
From: firewall-wizards-admin () honor icsalabs com
[mailto:firewall-wizards-admin () honor icsalabs com] On Behalf Of ArkanoiD
Sent: Friday, February 11, 2005 11:33 AM
To: firewall-wizards () honor icsalabs com
Cc: jmartin () netapp com; danzig () akamai com
Subject: [fw-wiz] i-cap proposals

Shame on me, though i joined i-cap mailing list quite early looking for
universal content inspection protocol, i found it too http-bound for general
use and seeing no live code for a long period of time somehow lost 
interest. I underestimated the project's future and thus made no
contributions.
It is late now, but there are some major design problems:

1) response content entities icap deals with defining inspection policy
are..
surprise, "filenames with given extensions". (Transfer-* headers)
Wait, there is no such thing when we are not dealing with local storage! 
There are content types! And those may be multipart of various types
(real pain for inspection proxies to deal) and so on.

2) It is still HTTP-bound. There should be recommendations on how to deal
with SMTP, POP3, IMAP, FTP and other - we should standardize how those
requests are being presented to ICAP.

Any ideas what to do now? ;-)

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards