[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: More Comments/suggestions on draft
@@ will deliminate my comments;-)
-----Original Message-----
From: George Jones
To: Neal Ziring
Cc: opsec@ops.ietf.org
Sent: 6/24/2003 7:25 PM
Subject: Re: More Comments/suggestions on draft
On Fri, 20 Jun 2003, Neal Ziring wrote:
...continued...
> 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?
@@ igmp has been used to scan networks. Turning off arp
implies nothing that doesnt have a hardcoded arp entry will
be able to talk to your stealthed system.
Hmm. Not sure. We require ability to filter on protocols
and at layer 2. These reqs (ability to identify, disable
services) were written with TCP/UDP ports in mind, but
the principal is "if its listening, we want to know about
it and be able to stop it from listening".
Thoughts ?
>
> 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.
Add a "Documentation Requirements" section ? Would these come under
the "Assurance" heading you mentioned earlier ?
[Defering/delegating filtering issues]
> 2.11.3 This is one of those disclosure/documentation kind
> of requirements that should be in a separate section.
OK. See previous question.
>
> 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.
Such as ?
The list of things to log could be, in and of itself, a monster. I
saw a post on the fw-wizards list from Tina Bird noting that this is a
large area that needs work. Hence, the reqirement to log "any event
that affects system integrity" is generic and the list, which is
not intended to be exhaustive, is given in the examples.
>
> 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.
Logging needs work (thanks for volunteering :-)).
We want open standards. We want (at least the option for) reliable,
secure delivery. We also want something that is/can be/will be
implemented. RFC3195 looks good on all but the last count.
Chris (Lonvick) .... if you're lurking out there/cathing up, care
to share your thoughts? Neal, Chris did RFC 3164 and other syslog
related work.
>
> 2.11.9 Is the notion of a "security-related" message
> explicit enough? Should this refer back to
> section 2.11.1?
Again, the question is, do we want to get exhaustive/explicit ?
If so, I think we may be starting up a parallel effort.
>
> 2.11.10 This requirement needs to be split.
Do it.
>
> 2.11.12 Untranslated addresses are important, but not all
> filters will capture IP addresses (c.f. 2.6.5).
OK, so make it generic "Logs MUST Contain Untranslated Addresses"
with examples showing IP addresses, MAC addrsses, etc.
> 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?]
You can only log what you have/know. Do that.
>
> 2.11.13 The justification for this requirement reads very
> oddly to me.
The justification is performance (as I think you're saying below).
Lookups take time, bandwith, processor. If the attacker is flooding
you (maybe with randomized source addresses), he can force you to
spend lots of cycles/time. Lookups by default should be turned off.
There may (should ?) be an option to turn them on.
@@ NSlookups also can give away the fact that your logging.
@@ if the remote scanner/hacker has control of the dns server for the
@@ ip address they are scanning from. So maybe a nslookup from the LOG
server
@@ would be better then an nslookup from the network element?
(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.)
So another thing to consider in this space is that address space
assignments/ownership can also change over time. What to do, what to do
?
> 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".
Done.
>
> 2.12.9 I think the Justification section needs re-wording.
It reads clearly to me...but then I wrote it. Suggestions ?
>
> 2.12.11 Change "are authenticated the device" to
> "have authenticated themselves to the device".
Done.
>
> 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.)
[delegated]
>
> 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?
Changed to:
> The device MUST provide secure end-to-end channels for all network
^
> traffic and protocols used to support management functions.
>
> 3.1.5 This requirement should have its own subsection, it
> does not belong with the rest of 3.1.
It should be split, since it's compound, but it's there for
management purposes, hence it's under management, and its
not commonly/univesally implemented, so its under non-standard (sectio
n 3).
I'll have it split up....it may get it's own seciton just for
size/scope.
>
> 4.1.1 Should the ability to ignore ARP and other layer 2
> protocols also be listed here?
Possibly. The whole stealthing/OoB management thing is being revisited.
>
> 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 ?
The profiles are not up to date with the reqs. That's being addressed.
Thanks,
George M. Jones, | Spam is to email as decay particles are
JAPH | to nuclear waste.
gmj@pobox.com |