RE: More Comments/suggestions on draft

[George Jones <gmj@pobox.com>]

On Thu, 26 Jun 2003, Smith, Donald wrote:

>  @@ 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.

Nothing that is directly connected.  Forwarding would still reach.

But that's specific.  Neal's question still needs a good answer.

Given the general motivation for these requirements (if it's
listening, we want to know, and want to able to turn it off),
the fact that namp supports protocol scanning (see
http://lists.insecure.org/nmap-hackers/2000/Apr-Jun/0119.html
+ nmap docs), and Don's referene, I'm leaning towards including
protocols in the requirement.  Thoughts ?  Yea? Nay ?

> >
> > 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.

Or at least the fact that you're doing a lookup, which may imply
logging....but good point.   Any time an attacker can get you
to send packets, they can learn something.

I'll add a note to the justification.

> @@ if the remote scanner/hacker has control of the dns server for the
> @@ ip address they are scanning from.

Then they could lie in the reply.

> So maybe a nslookup from the LOG
> server
> @@ would be better then an nslookup from the network element?

Choices.  Knobs.  The ability to decide.  That's what we're asking for.

>
>  (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      |
>
>