[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More Comments/suggestions on draft
George and everybody,
Here are some more comments on the current
draft.
George - for comments on the logging section, 2.11,
should I just make the changes and check them in to
CVS?
In general, I think the document is coming along
nicely. We ought to be able to have good
substantiative discussions about it next month
at the IETF meeting.
Also in general, I'm a little worried about the
statements of several performance requirements
in the current draft. They are not quantified
at all. I'm not sure this is a big deal, but
I would like to understand other peoples' positions
on this issue.
[In response to the on-going discussions about
the scope of this document, I have a slightly
different way of looking at it than George.
Basically, this document describes security features
that network infrastructure devices should provide
in order to protect themselves and the networks they
support. I don't think it matters whether the
device is a Cisco 7200 running IOS or a PC running
Linux, if it is being employed in an infrastructure
role then it should meet these requirements.
By defining the scope in terms of role, we can
avoid getting vendor-specific and also avoid
getting readers confused about whether this stuff
applies to their desktop workstation.]
Anyway, specific comments below. Please excuse
my wordiness.
...nz
---------------------------------------------------
Section Comment
-------- ----------------------------------------
2.1.4 Shouldn't this restriction be bi-directional?
If the device has a separate control plane,
forwarding control->data and data->control
should both be prohibited by the separation.
The "Justification" section only mentions
one direction.
2.1.5 This requirement could be split; I think the
requirement for the data plane should be a
little different than for the mgmt plane.
(in particular, if the data plane is totally
flooded, remote management over the mgmt
plane should still work. If the mgmt ports
are totally flooded, I think it is quite
unrealistic to expect remote management to
still work, but local management should)
2.1.6 This requirement should be split into two:
one for backup, and a separate one for
restore/recovery.
2.3.4 Do these requirements need to be limited by
2.3.5 layer? For instance, should I be able to
turn off ARP? How about IKE? Or PNNI?
2.3.13 These requirements, and some others about docs
2.3.14 and vulnerabilities, should probably be in their
own section. Maybe a "disclosure" section?
Anyway, I don't think they belong in 2.3 with
layer 3 and 4 functional requirements.
2.6.1 I think these requirement needs to be more
explicit. Does this mean IP protocol number, or
any kind of protocol? I think it might be
better to split this requirement into two:
one about filtering on the protocol (IP, ATM,
ARP, Ethernet, etc.) and one specifically about
IP.
2.6.4 There are really four different places at which
2.7.1 filtering is being required by these rules: (1)
2.7.2 into an interface, (2) out from an interface,
(3) forwarding, and (4) to the device itself.
First, I think that inbound and outbound
interface filtering should be two separate rules.
Second, 2.7.1 seems to be undecided about whether
the device needs true transit filtering or whether
in-bound filtering at the interface is sufficient.
Third, I think that 2.6.4 should be moved over to
section 2.7.
2.7.3 This rule definitely needs to be split. Filtering
traffic to SNMP or HTTP is quite different from
filtering routing updates based on their content.
One rule should be mandate per-service filtering
on those services that interact with the control
plane or device configuration; the second rule
should mandate route filtering for routing protocols
in particular.
2.8.1 In the warning section, yes, this capability
violates RFC 1812, section 4.3.3.1. Tough noogies!
2.9.1 Maybe need to use a more explicit term than "hits"?
2.9.6 There are situations where a packet may be rejected
by more than one filter rule (e.g. the src address and
TCP port number match separate 'deny' rules). Does
this requirement need to explicitly state that the
packet need be counted against only one of the rules'
counters?
2.10.3 I believe that these two requirements need to be
2.10.4 refactored into three requirements:
1. application of filtering does not degrade
data plane throughput or managability
2. application of logging in filters does not
degrade throughput or managability
3. application of filter rule counters does
not degrade throughput or managability
2.10.4 Change "discard" to "forego".
2.11.3 This is one of those disclosure/documentation kind
of requirements that should be in a separate section.
2.11.1 There are a couple of things I'd like to add here,
particularly related to stuff in 2.12.9 and 2.1.6.
2.11.6 I'm a little worried about the exact statement of
this requirements. For example, it might be
difficult, with RFC3195 BEEP over SSL, to separate
integrity and replay protection. I think the
independence of the protection mechanisms can be
downgraded from MUST to SHOULD.
2.11.9 Is the notion of a "security-related" message
explicit enough? Should this refer back to
section 2.11.1?
2.11.10 This requirement needs to be split.
2.11.12 Untranslated addresses are important, but not all
filters will capture IP addresses (c.f. 2.6.5).
Also, I think this section could use some examples?
[I think this is very tricky -- if my firewall or
router is performing NAT, and I filter on outbound
traffic at an interface, will the router be able
to know the pre-NAT address in order to log it?]
2.11.13 The justification for this requirement reads very
oddly to me. (Since DNS names change over time, I
think this is a motivation to include DNS names in
logs by default, because then you'd be able to see
what 68.59.123.244 mapped to while it was attacking
you last week, not what it maps to today.) To me,
the main reason for logging to forego DNS lookups
by default is that they give any old attacker the
ability to force your device to perform an arbitrary
DNS reverse lookup! I don't want to give attackers
that ability! Let them do their own lookups :-)
2.12.4 Change "well know" to "well-known".
2.12.9 I think the Justification section needs re-wording.
2.12.11 Change "are authenticated the device" to
"have authenticated themselves to the device".
2.13.1 This requirement should probably be split. I think
the device should be able to filter on the MPLS
information (analogous to layer 2 filtering) and on
the encapsulate layer 3+4 information.
Still, this might be challenging. Can current devices
do this? (I don't have any MPLS set up here at the
moment so I cannot easily check.)
3.1.1 The current wording seems to imply at the same secure
channel must be usable for all management protocols.
Is that the message we want to convey?
3.1.5 This requirement should have its own subsection, it
does not belong with the rest of 3.1.
4.1.1 Should the ability to ignore ARP and other layer 2
protocols also be listed here?
Apdx A I was a little surprised to see the 2.12.9 does not
appear in any profile. Perhaps it should be in A.2 ?