Hi All,
I don't want to get into any marketing spiel here, but let me take a few
baud to explain Cut-through Proxies.
In a normal proxy firewall, the machine has an awareness of the protocol to
such a high degree that it completes the sessions to find out what you want
to do. As an example, when using a proxy firewall, you telnet to the
firewall and authenticate yourself there. The firewall terminates (as in
comletes) the other end of the session and you have to login. When properly
authenticated, the machine will ask you where you _really_ want to go to.
It will then form a new session from itself to your destination. You will
have two separate sessions.
Cut-through Proxies on the PIX appear to the user to work in a somewhat
similar way. When the PIX detects a new session starting of a protocol
which is knows about, it will complete the session and ask for proper
authentication. The protocols which we currently support are telnet, ftp,
and http. So, as the same example, when you telnet to something on the
Internet (unlike the typical proxy firewalls, you will use the IP address of
the actual device you want to get to; not the address of the PIX), the PIX
will get in the way of the session and ask for authentication
(username/password). This must be used with a TACACS or Radius server since
the PIX does not maintain user information on itself. If you get the right
username/password, then the PIX completes the session to your original
destination and drops out of the conversation - it goes back to being a
single session. In the case of http, the PIX will display a typical
fill-in-the-blank window for you to enter your username/password.
Hope this helps.
Chris Lonvick
Cisco Systems
Consulting Engineering
Houston, TX, USA
+1-713-778-5663 but on vacation till Monday - well... sort of...
At 06:21 PM 11/26/96 -0500, Craig I. Hagan wrote:
>[nat comments deleted]
>
>> Filtering is something akin to what a proxy would do. If a packet
>> comes in, it's matched against the network objects (dynamic and static) which
>> are complete stateful sessions (UDP is another matter - supprise). No match,
>> it's dropped. If it's matched, then it's translated according to the state
>> of the network object it's matched against. Sessions all have dynamic
>
>the problem here is that the filter doesn't fully understand the
>application protocal that you are firewalling. an example is http.
>could the PIX firewall prevent a java or activeX connection should
>my security policy require that i do so?
>
>> Another neat trick is in some load leveling stuff they've got in
>> there. Got a heavily loaded web server? It can load level between several
>> servers for you and the outside network won't even know the difference.
>
>You can do this stuff with DNS if you are sneaky....you can even have a
>DNS server remove machines from the pool if they go down for some reason,
>again, if you are sneaky :)
>
>> like cookies and stateful CGI from breaking). Got three different
>> algorithms for load level. Will load level based on equal number of
requests,
>> amount of data traffic, and request-to-response time. Some packet filter...
>
>using DNS gives you the above thanx to host caching. you set
>your cache timeout and *poof* request affinity.
>
>> > Their biggest selling pt. is that they use a "cut through" proxy
(read
>> > packet filter rulebase) that processes packet while it is being
>> > received. Do not ask me what this means :) I rephrase their sales ppl.
>
>I've only heard cut through in terms of switches (versus store and
>forward). If i remember correctly, a cut through switch started switching
>the packet while it was still being received. A store and forward would
>receive the SOB, then take a checksum and, perhaps, apply some minimal
>routing/whatever against it. the latter has marginally higher latency
>(measured in micro-seconds) but keeps garbled packets off of your net.
>
>in this instance, i'd bet that they *don't* start operating on the packet
>until at least the headers were received, so that they can start computing
>where it will go. If they don't look at the payload, though, i,
>personally, will be kinda nervous. One never knows whether that there
>packet contains a bomb instead of the 'research material' it should have.
>Am i wrong? is a firewall not something akin to the bomb detectors at an
>airport terminal? Shouldn't the luggage be xrayed and the electronics
>inspected?
>
>-- craig
>
>-------------------------------------------------------------------------------
>Craig I. Hagan "It's a small world, but I wouldn't want to back it up"
>hagan @
cih .
com "True hackers don't die, their ttl expires"
>
>
>
>
>
>
>
>
Follow-Ups:
|
|
