Re: [fw-wiz] i-cap proposals

From: ArkanoiD (ark_at_eltex.net)
Date: 02/13/05

  • Next message: tone_at_teletech.si: "[fw-wiz] Cisco Concentrator - pix515 Lan-to-Lan" 
    To: lordchariot@earthlink.net
Date: Sun, 13 Feb 2005 12:10:58 +0300

    nuqneH,

    On Sat, Feb 12, 2005 at 02:43:41AM -0500, lordchariot@earthlink.net wrote:
    >
    > 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.

    Yep, that's right, but the way icap servers tells the proxy wich content is
    to be scanned definitely deals with those ridiculous "filename extensions"
    anyways :-(

    > We use ICAP for all of the aforementioned filtering and more with HTTP, SSL,

    Could you please describe exactly how SMTP session data are passed to icap
    server? The standard does not specify it - so it is implementation dependant.
    We definitely need a separate document to standardize non-http protocol
    handling.

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

    Yes, IMAP is a content inspection nightmare - it was really insane to deisgn
    it the way each one of zillion ways to get an email sliced to little pieces
    and sucked down is mandatory to be implemented on server and, thus, on
    the proxy!

    I successfully use milter filtering with pop3, though, and it is more easy
    to use inspect IMAP subset most common clients utilize rather than do
    full imap implementation on the proxy.

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

    That would be nice. I'd like to share my ideas with them and to have things
    fixed and improved in the next protocol revision.

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

    Qapla'

        ArkanoiD (ADVA technologies ltd)
    >
    >
    > -----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
    >
    >
    >
    > email protected and scanned by AdvascanTM - keeping email useful - www.advascan.com
    >
    > [host=TEST]

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

  • Next message: tone_at_teletech.si: "[fw-wiz] Cisco Concentrator - pix515 Lan-to-Lan"