[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply 3 of 3 to Pekka Savola
...and returning to substantive issues...
ps>
ps> 2.7.7 Ability to Log Filter Actions
ps>
ps> Requirement.
ps>
ps> It MUST be possible to log all filter actions. The logging
ps> capability MUST be able to capture at least the following data:
ps> permit/deny/drop status, source and destination ports, source
ps> and
ps> destination IP address, which network element forwarded the
ps> packet
ps> (interface, MAC address or other layer 2 information that
ps> identifies the previous hop source of the packet), and
ps> time-stamp
ps> to millisecond accuracy.
ps>
ps> Logging of filter actions is subject to the requirements of
ps> Section 2.11.
ps>
ps> ==> I do not agree that all of these are necessary. For one, ports
ps> make
ps> little sense if the protocol is not something like TCP, UDP, or maybe
ps> ICMP.
Already added "(if applicable to the protocol)".
ps> I'm not 100% sure L2 info i sneeded,
Without this, it may be impossible to trace back DoS attacks.
ps> and whether millisecond
ps> accuracy is needed either. These certainly aren't available e.g.
ps> juniper platforms (except maybe if you funnel the logs through syslog
ps> which may be a bad idea).
This is already gone. Subsumed into
04> 2.11.8 Logs Must Be Timestamped
04>
04> Requirement. By default, the device MUST time-stamp all log
04> messages. The time-stamp MUST be accurate to within a second or less.
ps> 2.12.8 Ability To Authenticate Without Plaintext Passwords
ps>
ps> Requirement. The device MUST support mechanisms that do not require
ps> the transmission of plaintext passwords in all cases that
ps> require
ps> the transmission of authentication information across networks.
ps>
ps> Justification. Plain-text passwords can be easily observed using
ps> packet sniffers on shared networks. See [RFC1704] and
ps> [I-D.iab-secmech] for a through discussion.
ps>
ps> Examples. Remote login requires the transmission of authentication
ps> information across networks. Telnet transmits plaintext
ps> passwords.
ps> SSH does not. Telnet fails this requirement. SSH passes.
ps> ==> uhh.. hasn't this already been covered by the requirements for
ps> encryption in the protocols or whatever, inherited from section 2.2?
Yes, implcitly. But I don't think it hurts to make this explciit
here. Also, 2.2 may (yet) undergo some changes.
ps>
ps> [RFC-INDEX]
ps> IESG and IETF, "The IETF RFC Series", <http://
ps> www.ietf.org/iesg/1rfc_index.txt>.
ps>
ps> ==> there are many refs which are not referred to in the text; remove
ps> from the references section, or add in the body.
Gone. Thanks.
ps>
ps>
ps> editorial
ps> ---------
ps>
ps>
ps> In-Band management.
ps>
ps> ==> some terms in 1.8 end in a dot and some don't; unify.
Already done.
ps>
ps>
ps> A number of requirements refer to "services". For the purposes
ps> of
ps> this document a "services" is defined as "any process or
ps> protocol
ps>
ps> ==> s/services/service/
Done.
ps>
ps> integrity and confidentially of communications. Examples
ps> include
ps>
ps> ==> s/lly/lity/ (similar elsewhere)
fixed.
ps>
ps> o saturation of customer lines or interfaces can make the device
ps> unmanageable
ps> [...]
ps> * CLI-Friendly. An RS232 interface and a CLI are sufficient in
ps> most cases to manage a device. No additional software is
ps> required
ps>
ps>
ps> ==> add dots at the end (same elsewhere)
Fixed. Made a pass to find others.
ps>
ps> 2.3.4 'Console' requires minimal functionality of attached devices.
ps>
ps> ==> but remove the dots at the end of section titles..
ps>
ps> times. Requiring complex or nonstandard behavior on the part of
ps> attached devices reduces the likelihood that the console will
ps> without hassles.
ps>
ps> ==> s/will/will work/
fixed.
ps>
ps>
ps> Requirement. The 'console' SHOULD support an authentication
ps> mechanism
ps> which does not require functional IP or depend on external
ps> services. This authentication mechanism MAY be disabled until a
ps> failure of other preferred mechanisms is detected. In the event
ps> of fall-back AUTHENTICATION, the interface SHOULD either
ps> implement
ps> a locally defined AUTHORIZATION profile or consider all commands
ps> to be AUTHORIZED. This mechanism SHOULD be implemented as a
ps> fall-back if the preferred authentication method is not "LOCAL".
ps>
ps> ==> lower capitals will do, no use yelling, mister :-)
Already gone.
ps>
ps> Requirement. The device MUST support a command line interface (CLI)
ps> or equivalent mechanism that works over low bandwidth
ps> connections
ps> [...]
Done.
ps>
ps> The device MUST provide accurate, per-interface counts of
ps> spoofed
ps> packets dropped by Section 2.5.6
ps> [...]
Already fixed.
ps> Examples. This requirement MAY be satisfied by implementing a
ps> centralized authentication system. See Section 2.12.5. It MAY
ps> also be satisfied using local authentication. See Section 2.12.6
ps>
ps> ==> add a dot at the end.
Already fixed.
ps>
ps>
ps> * One has to assume that hackers, operators, etc. will erase or
ps> corrupt all writable media (disks, flash, etc.). In such
ps> situations, it is necessary to be able to recover starting
ps> with
ps> only non-writable media (e.g. CD-ROM, a true ROM-based
ps> monitor).
ps>
ps>
ps> ==> s/will/may/ ??!?
OK.
ps> RS-232 The device could support uploading new code via an RS232
ps> console port.
ps>
ps>
ps> ==> s/RS-232/RS-232:/ or the like (same with the rest)
Done.
ps>
ps>
ps> Examples. A 7-bit ASCII configuration file that shows the current
ps> settings of the various configuration options wold satisfy the
ps>
ps> ==> s/wold/would/
fixed.
ps>
ps> what steps should be taken to mitigate risk (e.g., "should I
ps> turn
ps> this service off "?)
ps>
ps> ==> s/ "?/?"/
Done.
ps>
ps> Requirement. The device MUST provide a means to turn off any
ps> external
ps> services listening.
ps>
ps> ==> s/any external services listening/any listening .../ ?
ps> (please clarify "external" btw.)
04> 2.5.2 Ability to Disable Any and All Services
04>
04> Requirement. The device MUST provide a means to turn off any
04> "services" (see Section 1.8).
...
04> Service.
04>
04> A number of requirements refer to "services". For the purposes
04> of this document a "service" is defined as "any process or
04> protocol running in the control or management planes to which
04> non-transit packets may be delivered". Examples might include
04> an SSH server...
ps>
ps> loopback interfaces. The looopback interfaces may be addressed
ps>
ps> ==> s/looop/loop/
Fixed.
ps>
ps> 2.6.3 Support Rate Limiting Based on State
ps>
ps> Requirement. The device MUST be able to rate limit based on on all
ps> TCP state bits. The device SHOULD support rate limiting of other
ps> stateful protocols where the normal processing of the protocol
ps> gives the device access to protocol state.
ps>
ps>
ps> ==> these are control bits, not state per se.
Already fixed.
ps>
ps> Examples. This requirement MAY be satisfied by the use of
ps> RADIUS,TACACS+, or syslog.
ps>
ps> ==> s/,/, /
already fixed.
ps>
ps>
ps> Warnings.
ps>
ps> Note that there may be privacy or legal considerations when
ps> logging/monitoring user activity.
ps>
ps>
ps> ==> shift the text up two lines.
Fixed.
ps> (same elsewhere as well: unify style)
ps>
ps> Justification. This is important because it supports individual
ps> accountability See section 4.5.4.4 of [RFC2196].
Easier said than done (xml2rfc is a fine tool, but it lacks style
sheets).
At the risk of making things a bit longer, but more readable (I
think), I've redone the formatting for all reques as follows:
04> 2.5.2 Ability to Disable Any and All Services
04>
04> Requirement.
04>
04> The device MUST provide a means to turn off any "services" (see
04> Section 1.8).
04>
04> Justification.
04>
04> The ability to disable services for which there is no operational
04> need will allow administrators to reduce the overall risk posed to
04> the device.
04>
04> Examples.
04>
04> Processes that listen on TCP and UDP ports would be prime examples
04> of services that it must be possible to disable.
04>
04> Warnings.
04>
04> None.
ps>
ps>
ps> ==> s/accountability/accountability./
Done.
ps>
ps> [I-D.iab-secmech]
ps> Bellovin, S., Kaufman, C. and J. Schiller, "Security
ps> Mechanisms for the Internet", draft-iab-secmech-03 (work
ps> in progress), July 2003.
ps>
ps> [I-D.orman-public-key-lengths]
ps> Orman, H. and P. Hoffman, "Determining Strengths For
ps> Public Keys Used For Exchanging Symmetric Keys",
ps> draft-orman-public-key-lengths-06 (work in progress),
ps> December 2003.
ps>
ps>
ps> ==> I'd invent shorter "short names" for these references.
Actually, I didn't invent these. They come from ?Marshall Rose's?
bibxml database fed to xml2rfc. Its convenient and would be work
to change consistently with each update of the db.
You've (finally) been popped. Go ahead and push if you've got more
(you mentiond you wrote up more comments on the plane). You can
see HTMLized diffs betwen (03|03bis) and 4-working @
http://www.port111.com/opsec/draft-jones-opsec-03-to-04-working.html
http://www.port111.com/opsec/draft-jones-opsec-03bis-to-04-working.html
Thanks,
George M. Jones | Sic transit gloria mundi ("So passes away the glory of
| the world")
|
| Kempis (Imitatio Christi Ch3, vi