| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1149.1 | It's in there... | LEVERS::PAGLIARO | Rich Pagliaro, Hub Products Group | Thu Jun 23 1994 11:59 | 48 |
| Burance,
>> From notes 356.1, knowing that DR900TM can setup the port privacy and
>> also prevent from eavesdrop.
Port privacy and eavesdrop protection are the same thing. The
DECrepeaters support eavesdrop/privacy protection and intrustion
protection.
>> After I enter an authorized address to a port, lets say PORT 2A,
>> any station other than that address cannot connect to the network,
>> that's nice and what I want.
What you describe here is intrusion protection. That is, the port is
automatically disabled when an intrusion is detected. This is enabled
by selecting the "Disable Port On Intrusion" Intrusion Mode in the
HUBwatch repeater security screen.
>> What I assume is once the privacy feature is turn, only the
>> packet with the destination address same as the authorized can
>> go through the port and then to the station.
Packets whose unicast destination addresses do not match a port's
authorized address are still trasnsmitted out that port, but they are
garbled. Broadcast/multicast packets and packets with authorized
unicast destination addresses are transmitted in the clear.
>> So my question is can 900TM support eavesdrop capability ? If not,
>> when ? Of if yes, how can I trun it on ?
The DECrepeater 900TM supports eavesdrop protection now. You can enable
eavesdrop protection on a port by simply "pressing" the Enforce Privacy
button in the HUBwatch repeater security view.
>> Besides the function "Jam unauthorized packet" function within
>> the screen which setup the authorized dim out. Is it not
>> supported in this version ?
"Jam unauthorized packets" is an alternate mode of intrusion protection
which is not and will *NEVER* be supported on the DECrepeater
900TM/900GM/900FP/90TS/90FS due to HARDWARE restrictions. Future
per-port switching repeaters will support this function.
Regards,
Rich
|
| 1149.2 | In and OUt | HGOVC::BURANCELEUNG | | Thu Jun 23 1994 14:13 | 34 |
| Hi Rich,
Thanks for your reply in .-1.
Now I understand the term "instrusion protection". But for the
eavesdrop, I still have query because I have problem to define
in and out.
As shown in the diagram :
<-- IN
+---------------- Station 1 (S1)
| ---> OUT
+---+--------------------------------------+
| A1 ..... |
| D1 ...... |
+------------------------------------------+
DR900TM is now attached to the DEChub900. Port A1 is registered with
address S1 in its authorized list.
I have tried that if S1 executes the lan analyzer software, it can
see all the packets run "OUT" from the port. And I have turned on
the "ENFORECED PRIVACY".
I don't konw what my interpretation is right or wrong. Is it true
that when the "ENFORCED PRIVACY" is enabled, only the packets with
destination address S1 and Broadcast/multicast address can go
"OUT" and then listened by the station;
other packets with destination address other than S1 is FILTERED out
by the port ??
Thanks again !
Burance.
|
| 1149.3 | More details... | LEVERS::PAGLIARO | Rich Pagliaro, Hub Products Group | Thu Jun 23 1994 17:02 | 120 |
| Burance,
If you have eavesdrop/privacy set up correctly, S1 (which I assume is
running in promiscuous mode) should be receiving frames with destination
addresses equal to S1 or some broadcast/multicast address. It should also
be receiving many frames with CRC/Frame Check Sequence errors. These would
correspond to frames with unicast destination addresses NOT equal to S1,
which have been garbled.That is, these unauthorized frames are NOT FILTERED
out, per se, in a manner similar to how a bridge might work.
In the currently shipping version of the DECrepeater 900TM firmware (V1.0G)
eavesdrop/privacy will only be enabled on a port if you have selected
"Enforce Privacy" in the HUBwatch repeater security view AND manually
assigned at least one authorized address to that port.
In a soon to be released upgrade, the 900TM & 900GM will be able to
enforce eavesdrop protection based upon the dynamically changing last source
address seen on a port. This mode is enabled on a given port when "Enforce
Privacy" is selected in the HUBwatch repeater security screen but no
authorized addresses are assigned to a port. This eavesdrop security mode
is supported in the currently shipping version of the DECrepeater
900FP/90FS/90TS.
One way to tell if eavesdrop and/or instrusion security are active is to
observe the "Security Status" field in the upper right corner of the
HUBwatch repeater security window. If it reads "Enabled" then eavedrop aand
or intrusion security are operational.
Attached is an excerpt from Digital's repeater MIB extension which
graphically describes repeater security functions.
Regards,
Rich
-- +
--
-- The Security Package
--
-- Implementation of the Security Package group is optional
--
--
-- This group contains objects for managing security functions on all
-- repeater ports. To enforce security, a repeater port should be assigned
-- a list of MAC addresses belonging to stations authorized to use that
-- port. The Security Address Table performs this mapping of authorized
-- addresses to repeater ports. The maximum number of addresses which can
-- be assigned to each port is implementation dependent.
--
-- The group defines two distinct types of security capabilities,
-- intrusion detection/protection and eavesdrop prevention, each of which
-- can be enabled/disabled on a per port basis. The Security Control Table
-- manages the selection of these security features.
--
-- ____________
-- | Repeater |
-- | | ___ ___ ______
-- | Authorized | | B | A | DATA |
-- | Addresses | |___|___|______| _________
-- | __________ | <============ | Station |
-- | A []=================[] A |
-- ___ ___ ______ | | |_________|
-- | B | A | DATA | |_ _ _ _ _ _ |
-- _________ |___|___|______| | |
-- | Station | <============= | |
-- | B []=================[] B | Eavesdrop Prevention
-- |_________| | | _____________
-- |_ _ _ _ _ _ | | garbled pkt |
-- | | |_____________| _________
-- | | +++++++++++++> | Station |
-- Eavesdrop Prevention | C []=================[] C |
-- _____________ | | |_________|
-- | garbled pkt | |_ _ _ _ _ _ |
-- _________ |_____________| | |
-- | Station | <++++++++++++ | |
-- | X []================[] D |
-- |_________| ==============> |____________|
-- ___ ___ ______
-- | C | X | DATA |
-- |___|___|______|
-- !! INTRUSION SECURITY VIOLATION !!
--
--
--
-- Intrusion detection/protection prevents a station from transmitting
-- data to any other station from a repeater port it is not authorized to
-- use. To enforce intrusion protection, the repeater compares the source
-- addresses of packets received from a given port with the address(es) in
-- that port's authorized address list. If the addresses do not match, the
-- intrusion is logged in the Security Violations Log Table and
-- appropriate action is taken. The actual action taken depends upon the
-- intrusion security mode selected. An example of an intrusion violation
-- is depicted in the above figure. Here, Station X transmits a packet to
-- Station C from a repeater port which it is not authorized to use.
--
-- Eavesdrop prevention prevents a station authorized to use a given
-- repeater port from receiving data packets addressed to any station
-- other than itself. To enforce eavesdrop prevention, the repeater
-- compares the unicast destination address of a packet being transmitted
-- out a given repeater port with the address(es) in that port's
-- authorized address list. If the addresses do not match, a garbled
-- version of the packet is transmitted. Otherwise, the packet is
-- transmitted unaltered. Packets with multicast or broadcast destination
-- addresses are never subject to eavesdrop prevention. An example of
-- eavesdrop prevention is depicted in the above figure. Here, Station A
-- transmits a packet addressed to Station B. Station B receives the
-- packet correctly but Station C and Station X receive a garbled version
-- of the original packet.
--
-- If eavesdrop prevention is enabled on a given port but that port's
-- authorized address list is empty, the repeater may optionally enforce
-- eavesdrop prevention based the last source address seen on that port
-- (as indicated by rptrAddrTrackLastSourceAddr or
-- rptrAddrTrackNewLastSrcAddress).
--
-- -
|
| 1149.4 | | STRWRS::KOCH_P | It never hurts to ask... | Fri Jul 28 1995 09:46 | 8 |
|
Can we get an update on repeater security which was enabled in the last
upgrade of the firmware.
Did the two types of intrusion detection get enabled? That is the
method where it learns 1 address (DECnet/Ethernet) and then maintains
that address until cleared and then the other one which is tied to only
delivering clear packets to the station currently plugged into a port?
|
| 1149.5 | | NETCAD::HERTZBERG | History: Love it or Leave it! | Fri Aug 04 1995 13:40 | 21 |
| >> Did the two types of intrusion detection get enabled? That is the
>> method where it learns 1 address (DECnet/Ethernet) and then maintains
>> that address until cleared ...
The auto-learning of security addresses requires cooperation between
Hubwatch and the repeater firmware. The 900TP and 900CP support this
now with the just-released version of Hubwatch. Support for this
feature in the other security-capable repeaters (900TM, 900GM, 900FP,
90TS, 90FS) will be incorporated in the soon-to-be-released code
updates for these products (you'll still need the latest version of
Hubwatch).
>> ...and then the other one which is tied to only delivering clear
>> packets to the station currently plugged into a port?
Not sure what this part of the question means. Eavesdropping
protection works by jamming the data portion of any unicast packet
whose source address is not an authorized address. This feature has
been shipping for some time now. The only new part is the
auto-learning of authorized addresses, discussed above.
|