[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ISSForum] Taps supporting traffic aggregation



Now, they do ....
The goal with taps supporting traffic aggregation is to consolidate traffic ( have a look here: http://www.netoptics.com/products/application.asp?ts_id=&cid=4&pid=3&Section=products&menuitem=4)

Thierry


Stephen Cooper wrote:

Taps dont consolidate, switches do. You need both.

We are using Finisar Taps successfully with Cisco 2900 series switches dedicated to traffic consolidation.

Stephen


Thierry Bôle <tbole@xxxxxxxxx> Tuesday 27, January, 2004 17:46:47 >>>

1)Taps are not single point of failure and does no impact traffic flow, indeed, they are by design fault-tolerant (the IDS Taps have proprietary circuitry pre-process that closes the circuit when power fails, maintaining the network link), so there is no problem with my networking team and they prefer taps instead of span ports on their switches (overload of the span port and of the switch) ...

2) Mosts of taps are bi-directional traffic, the IDS taps allow the IDS to transparently inject TCP reset into the stream.


IMHO, taps are the relevant components to provide you transparency for your network ans scalability for your IDS architecture (and not only a cost concern)

regards

Thierry



Ken Kempster wrote:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

IMO the big problem with any device that sits in line of the traffic
is there is always the concern of it being a single point of failure.
Selling to your networking
team that the device will not become a bottle neck or failure point is
difficult at best.
Also, if you're looking to do RS kills,  you will need another
physical path to send them
when using taps.  When  you're comparing the pros and cons of
deploying them,  you need to factor in
the criticality of the network you will be tapping into.

If cost is a concern,  then taps are probably a good approach but I
would confirm that
the physical infrastructure is designed so that a physical failure of
the tap does not affect
traffic flow; multi-path.

It has been my experience that the best approach is to design your
security infrastructure
so that if there were a total failure of your monitoring environment,
it will not impact production networking/traffic flow.
This is typically the more expensive approach but the safest one.

Ken.


Thierry Bôle wrote:

| Hi Ken,
|
| I guess you speak about the IDS Balancer because Toplayer don't
| have taps supporting traffic aggregation ( maybe they will ...) but
| I'm not interested in load-balancing traffic between multiple
| sensor.
|
| The goal with taps supporting traffic aggregation is to simplify
| IDS architecture and to save cost:
|
| With normal taps, you need to use Network Sensor with integrated
| full-duplex segment monitoring or to use layer 7 switches (IDS
| balancer for example) to aggregage traffic for your Network Sensor.
|  Now, you can connect your Network Sensor directly to the port
| aggregator tap.
|
| I would be interested to have your feedback on using such devices
| and especially if they really deconflict collisions as it can be
| described in the datasheets (taps are normally passive devices)
|
| Thierry
|
|
|
| Ken Kempster wrote:
|

| Have you looked at TopLayer?  I've tested the product a few years
| ago and it looked good for aggregating ports/traffic, load balance
| between multiple sensors and still retain an aggregated port for
| your sniffer.
|
| Ken.
|
| Thierry Bôle wrote:
|
| | Hello, | | Has anyone tested taps supporting traffic aggregation
| with ISS | products (with the capability to mirror the traffic only
| on one | link) ? | | I'm aware of the bandwidth limitations we can
| have: if the 2 | network ports are operating at 100mbps and the IDS
| port is | operating at 100mbps as well, then under sustained
| aggregate | bandwidth of greater than 100mbps, packets will get
| dropped. | | I guess it should cause no problems with dropped
| packets if I'm | monitoring internet links with low utilisation. |
| | Any feedback appreciated. | | Thierry | |
| _______________________________________________ ISSForum mailing |
| list ISSForum@xxxxxxx | | TO UNSUBSCRIBE OR CHANGE YOUR
| SUBSCRIPTION, go to | https://atla-mm1.iss.net/mailman/listinfo
|>
|>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAFpDSn19jIc8Mw3IRAs0WAKDmIYZ1ZFqOv359dXI/UEiLKCpGgACglYRY
AawNFxLS06rXnfPvcmkKb5w=
=OD1P
-----END PGP SIGNATURE-----






_______________________________________________
ISSForum mailing list
ISSForum@xxxxxxx
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo


Disclaimer

This e-mail message shall not be construed as legally binding on the Bank for International Settlements (BIS). As internet communications are not secure, the BIS does not accept responsibility for the content of this message.

This message is intended only for the recipient(s) named above. Any unauthorized disclosure, use or dissemination, either in whole or in part, of this message is prohibited. If you have received this message in error, please inform the sender immediately by return e-mail and delete this message and any attachments thereto from your system. Thank you for your co-operation.


_______________________________________________
ISSForum mailing list
ISSForum@xxxxxxx

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo


--
________________________________________________
 Thierry BOLE
 Technical Support - Security Division
 Telecom Systems SA
 Une societe de Groupe Silicomp
 En Budron E7
 1052 Le Mont/Lausanne
 Switzerland
 Tel : +41 21 651 42 51 - Fax : +41 21 652 39 10
 mailto:tbole@xxxxxxxxx - http://www.telsys.ch
 _________________________________________________

_______________________________________________
ISSForum mailing list
ISSForum@xxxxxxx

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo