[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
03bis draft review
Hi.. it's me again..
When I flew to Seoul, I made a few additional remarks to the 03bis
document. I've checked these against the -04 candidate. The
following ones are still around: (nothing very major, I think.)
substantial
-----------
The following are some ALGORITHMS that satisfy the requirement at
the time of writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998]
for applications requiring symmetric encryption; RSA [RFC3447] and
Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring
key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications
requiring message verification.
==> maybe it would be useful to state that MD5 (as it's commonly used
-- e.g., the BGP MD5 checksums would not fulfill the requirements if
so) is (not) sufficient (and maybe why). Or is this taking it too
far?
2.2.3 Use Cryptography in Protocols Subject To Open Review
==> I don't quite understand the title, so maybe a rewording might not hurt,
e.g. "Cryptographic Protocols Subject to Open Review"
2.4.7 Support Remote Configuration Restore
Requirement.
The device MUST provide a means to restore a configuration that
was saved as described in Section 2.4.6. The system MUST be
restored to its operational state at the time the configuration
was saved.
==> how does this relate to 2.4.6 where passwords in the configs MAY
be excluded from the saved config? I.e., how would such excluded
config be restored in particular wrt. passwords and other info (e.g.,
BGP MD5 secrets which are typically excluded but critical to restore
the box)? Maybe need a bit rewording, or at least a note in
"Warnings" section if nothing else...
2.5.1 Ability to Identify All Listening Services
Requirement.
The vendor MUST:
* Display the interfaces on which each service is listening.
==> services aren't bound to interfaces, but IP addresses (which may in turn
be bound to interfaces, but their access might not be limited to such).. so
this is a bit non-sensical requirement. Maybe must display which IP
addresses the service is bound to? (Note that that is not commonly
supported either, I think -- but at least one vendor does.)
==> this may also require small finetuning of text in section 2.5.3,
"Ability to Control Service Bindings for Listening Services".
* which network element received the packet (interface, MAC
address or other layer 2 information that identifies the
previous hop source of the packet)
==> related to the previous point, this is good in principle, but might not
give sufficient advice (or sufficiently tight leash to the operators :), as
interface is not sufficient in e.g. Ethernet media. Maybe some notion of
PtP vs non-PtP interface requirements needs to go in here somewhere..
Examples.
This requirement implies that it is possible to filter based on
TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits,
and ICMP type and code fields. One common example is to reject
"inbound" TCP connection attempts (TCP, SYN bit set).
==> This "established/initial" -check is not actually as simple as that, and there
is variance about this with the vendors, so this text may need rewording (or
picking a different example).
That is, some check, "SYN & !ACK" for initial, and
"ACK | RST" for established. Others check for "SYN & !(ACK|FIN|RST)" for
initial. (The difference is practically that one approach allows SYN+RST
christmas packets in through the established rule, and the other does not.) I had a long
rant amount that with a few vendors a year or two ago but I don't remember
the exact details.
2.12.3 Support Simultaneous Connections
Requirement.
The device SHOULD support multiple simultaneous connections by
distinct users, possibly at different authorization levels.
==> should the SHOULD be a MUST? I think this is pretty important, at
least, and AFAIK, pretty widely implemented as well..
3.2 Document Service Defaults
Requirement.
The vendor MUST provide a list of the default state of all
services.
==> has this been done in practice? I sure would love to get this info, but
haven't seen it myself at least...
editorial
---------
o Physical security,
==> remote "," (last bullet item)
The following are some ALGORITHMS that satisfy the requirement at
==> any reason why you're writing ALGORITHMS in a few places in all-caps?
If cryptography is used to meet the secure management channels
requirements, then the key lengths and algorithms SHOULD be
==> s/channels/channel/ ?
Protocols that have not been subjected to widespread, extended
public/peer review are more likely to have undiscovered weaknesses
or flaws than open standards and publicly reviewed protocols
==> add dot at the end.
As of this writing, RS-232 is still strongly recommended as it
provides the following benfits:
==> s/benfits/benefits/
2.3.3 'Console' requires minimal functionality of attached devices.
==> uppercase first chars in words
2.5.7 Support Counters For Packets Dropped
==> s/Packets Dropped/Dropped Packets/
Examples.
Examples of this might include filters that permit only SNMP and
SSH traffic from an authorized management segment directed to the
device itself, while dropping all other traffic addressed to the
device.
==> (this may be semi-editorial) -- maybe s/other/other such/ -- you make a
leap of faith that SNMP/SSH is the only thing the device needs (which might
be OK for an ethernet switch, maybe, but certainly not routers I think :-).
The definition of "significant" is subjective. At one end of the
spectrum it might mean "the application of filters may cause the
box to crash". At the other and would be a throughput loss of
==> s/and/end/ (last one)
and TCP. It SHOULD support filtering of of all other protocols
==> kill extra "of".
The device MUST provide a logging facility that is based on
protocols subject to open review Section 1.8. Custom or
==> s/review/review, see/
2.12.12 Ability to Assign Privilege Levels to Users
Requirement.
The device MUST be able to assign a defined set of authorized
functions, or "privilege level," to each user once they have
authenticated themselves the device. Privilege level determines
which functions a user is allowed to execute. Also see See
Section 2.12.11.
==> s/the device/to the device/
==> s/See//
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings