Comments on: draft-ietf-opsec-current-practices-03.txt

[Warren Kumari <warren@kumari.net>]

Hi,

I have some feedback on the draft. It is looking really good, most of  
the comments are for really minor items....

Warren.


-------------------------------------------------------------------
Notes on: draft-ietf-opsec-current-practices-03.txt

Section 1.2:
"Man-In-The-Middle: An attack where a malicious user impersonates
either the sender or recipient of a communication stream." -- To my  
mind a MIM attack is more of an active attack where the malicious  
user impersonates party A to B (and possibly B to A) while inserting,  
modifying or dropping certain traffic. The original definition also  
covers things like phishing, session hijacks, etc (unless this class  
of attacks is excluded by the use of the phrase "communication  
stream"?).

Section 2.1:
"Message Insertion: This can be a valid message (which could be a
reply attack,, which is a scenario where a message is captured and
resent at later time)." -- double commas.

Section 2.1:
"A denial of service is a consequence of an attack and
can be the result of too much traffic (i.e. flooding), or exploting
protocol expoitation or inserting/ deleting/ diverting/ midifying
messages." -- spelling: exploiting, exploitation, modifying.

Section 2.1.4.  Additional Considerations
"The physical and logical authentication and logging systems should be
run independently of each other and reside in different physical
locations." -- possibly you could mention that these systems also  
need to be secured. I have seen cases where the proximity card admin  
system is unsecured (it was in an unlocked closet off the lobby!)

Section 2.2.1.5.  Man-In-The-Middle
Yay! That description explains MIM better than the definition in 1.2 :-)

Section 2.2.2.
"If SNMP is used for in-band management, it is for read queries only
and restricted to specific hosts." -- if possible the view is also  
restricted to only what the management station needs (some devices  
will expose their config file with the read-only SNMP community --  
views can limit what they will send).

Section 2.2.3:
"Using SSH for device access ensures that noone can spoof the traffic  
during the SSH session." -- spelling: no one (or no-one)


Section 2.2.3:
Perhaps you could mention something about securing access to the AAA  
server. I have seen 2 cases where this bit someone:
1: The AAA server was compromised and a slew of things happened --  
dictionary attacks were carried out against the password file, an  
existing username was changed and the a new user was added.

2: An individual was let go and his TACACS account was yanked, but  
the TACACS shared secret was not changed. He was able to get access  
to a workstation on the network, spin up a TACACS server (with  
himself as the only account and using the unchanged shared secret) on  
that workstation. He then announced a /32 (using zebra) for the  
primary TACACS server into network and was able to access devices.


Section 2.5.8:
"Data Origin Authentication - By using MD5 authentication and/or
the TTL-hack a routing peer can be reasonably certain that traffic
originated from a valid peer."  -- cite the TTL Security hack.

Section 2.5.9:
"Although MD-5 routing protocol
extensions have been implemented which can provide both services,
they are not consistently deployed amongst ISPs." -- Spelling: MD5


Thats all I have for now (AKA: My boring meeting has just ended --  
let me know if you want any more feedback.)

Warren.