Re: Reply to comments on opsec draft from Bert Wijnen/OPS directorate.

[George Jones <gmj@pobox.com>]

...continued

bw>
bw> 2.2 In-band management
bw>
bw> I was expecting a recommendation here.  Is this section just here to
bw> provide a threat analysis of in-band management?

Note the heirarchy:

   2.      Functional Requirements
   2.1     Device Management Requirements
   2.1.1   Support Secure Channels For Management
   2.2     In-Band Management Requirements
   2.2.1   Use Encryption Algorithms Subject To Open Review

Actual requiremnts are @ the 3ed level (for the most part). Higher
level items are used to group similar reqs...in the case of these
two, larger groups have shurnk to a single requirement.

The text here was intended to introduce the inband/out-of-band reqs to
make the tradeoffs apparent.  Do you think it detracts by being here ?
In other places there was criticism that there was not enough threat
analysis.

bw> 2.2.1 [use] Encryption algorithms [subject to open review]
bw>
bw> Hilarie's draft (included in the bibliography) should be cited in this
bw> section.

This req. is about openness of protocols.   The draft is about
strength.

bw>
bw> It also would be helpful to cite the NIST mode documents.

Which ones in particular ?

bw> 2.2.2 Strong encryption
bw>
bw> This section seems somewhat redundant with the previous one.  Using
bw> open algorithms that aren't strong isn't very helpful, so its seems to
bw> me that the two sections should be combined.

You can't please everyone.   A major criticism from one of the
pre-last-call reviewers said that compound requrirements should
be seprated.

I agree that it's not very helpful to use weak, open algoritims or
(presumably) strong, closed ones, but they are distinct reqs.


bw>
bw> 2.2.3  Encryption protocols
bw>
bw> I think there is a bit of confusion here between transforms supporting
bw> confidentiality + auth + integrity & replay protection and security
bw> protocols.

What am I missing (if I'm confused here, I'm still not seeing it).
Can you provide more clear wording ?

bw>  It's nice to say that IETF standards should be used, but
bw> we have so many of them that can be used in so many different ways
bw> that this advice is not specific enough.

I thought I sort of said that.

03>   Warnings.
03>
03>      Note that open review is necessary but may not be sufficient.
03>      It is perfectly possible for an openly reviewed protocol to
03>      misuse (or not use) encryption.

Use of encryption in openly reviewed protocols is
necessicary but not sufficient.   This req is aimed at ensureing the
necessary.

bw> 2.2.4
bw>
bw> It would be helpful to cite specific parameters (e.g. IPsec policies,
bw> IKE negotiation parameters) that may need to be customized.

This was suggested earlier, but it would seem more appropriate
for the ipsec WG (which is winding down ?)

bw>  The
bw> problem is that there are lots of other knobs that are just not worth
bw> adjusting -- they will cause interoperability problems for not much
bw> security benefit.  The recommendation seems to imply that if you don't
bw> allow a customer to tweak every conceivable IKE setting you're
bw> non-compliant.

First, not that this is a SHOULD.  Second, it dosn't explicitly
mention IKE.  Third the intent is to point out that NO configuration
options is bad (e.g. hard-wired 56-bit DES with no user configurable
options).   Please tell me if there is a better way to say that.

bw> 2.3.5  Fallback authentication
bw>
bw> I was expecting some specific security recommendations here such as
bw> support for token card authentication, or even a prohibition against
bw> use of cleartext passwords.

This is here to deal with the case where IP is down.  You can't
get to your Auth serververs for token cards (unless you have
one directly attached to each device).   Transmission of cleartext
passwords is prohibited elsewhere in the doc.

The example section does mention "local accounts" (e.g. unix style
username/password combos stored on the device were in mind).

bw>
bw> 2.3.8  Separate resources for the management plane
bw>
bw> Is it really necessary to require a different CPU and memory for the
bw> management interface?

Note again this is a SHOULD.

bw> Why can't a memory manager enforce the required
bw> separation?

Full seperation is cleaner...no issues of contention, possible leaks, etc.

bw>
bw> 2.4.1 CLI
bw>
bw> Why must the CLI provide access to "all management functions"?

I've updated the justification:

04> The CLI (or equivalent) is needed to provide the ability to do
04> reliable, fast, direct, local management and monitoring of a device.
04> It is particularly useful in situations where it is not possible to
04> manage and monitor the device via "normal" means (e.g. SNMP) that
04> depend on functional networking.  Such situations often occur during
04> security incidents such as bandwidth-based denial of service attacks.

bw> this mean that the CLI has to support all the capabilities of all the
bw> SNMP MIBs on the box to be compliant?

I had not considered that, but it does seem to be implied.

To the extent that functionality is available only to remote SNMP
management stations or (worse) closed, proprietary mananagemnt
solutions, to that extent it may not be possible to collect data and
respond to incidents.

bw>
bw> 2.4.2 Scripting
bw>
bw> How can a CLI only support a single scripting language?  How are we to
bw> make a judgement about which languages a given CLI "supports?"

OK.  There seems to be enough misunderstanding over that one (the not
being required to use a single language sentance) that I'll take it
out.

bw> 2.4.3 Slow links
bw>
bw> How do we know if a given CLI works over slow links?

When you find yourself using a modem to bring back a router in
a lights-out data center half way round the world that has
had it's configuration wiped out by a hacker and you realize
that it's going to take hours to get the customers back online
because you have to sit waiting for screen repaints, large data
transfers, whatever.

That's reality.   Can you think of a better way to say it ?

bw>  Does XML based
bw> configuration not qualify?  I guess NetConf is a waste of time then,
bw> eh?

I've actualy tried to make it netconf friendly.  See the wiggle room
left in the definition of CLI. It was feedback operators @NANOG and
elsewhere that out-and-out said they would not use the draft unless it
said CLI...and as I was aiming at BCP it was hard to argue against CLI
(as opposed to netconf) being a best *current* practice....same goes
for the venerable RS232 which was out at one point and then back in
after a near revolt.

bw>
bw> 2.7 Filtering
bw>
bw> Lots of the requirements in this section seem redundant.  The
bw> requirements should be consolidated into a few sections.

Sigh.  One reviewer says split them out.   Another says combine them.

I actualy see value in having things as atomic as possible.  It makes
it easier for people with differing needs say "yes, I want the whole
thing except x,y and z".

bw>
bw> 2.7.4 Performance
bw>
bw> Do all conceivable Access-Lists have to operate with no performance
bw> degradation? Nowadays this can include deep packet inspection
bw> (e.g. XML parsing).  If so, then the vast majority of all networking
bw> equipment would not satisfy this requirement.
bw>
bw> Please be more specific.

Will work on it.  Would limiting to layers <= 4 help be better ?

bw>
bw> 2.12.5 AAA
bw>
bw> RADIUS is [RFC2865].

Thanks.  Looks like I copied and forgot to edit the ref.

bw> Do RADIUS implementations need to satisfy the
bw> security recommendations in [RFC3579]?

Not explcitly, but I've added it as a reference.

bw>  Are any of the recommended
bw> protocols (Kerberos, RADIUS, Diameter, TACACS+) ok?

Yes.  This requirement simply says that the device must support
centralized authentiation using standard protocols.   Security
of those protocols comes under 2.*.

bw> [RFC3539] doesn't
bw> discuss AAA security, so I'm not sure why it's referenced
bw> here. [RFC3588] is about Diameter, so it doesn't discuss RADIUS
bw> security.

OK.  Those are gone.  Thanks.

bw>
bw> 2.12.6 Accounting
         16
bw>
bw> Are there any reliability requirements (see RFC 2975)?  Or is any
bw> protocol ok?
bw>
bw> AAA protocols typically don't send accounting records for things like
bw> status and configuration changes.  Does this mean those protocols are
bw> non-compliant?

You raised some good issues.

Franky, this is an area where current practice is weak.
What security info to log and how to log it has been done
pretty hap-hazardly (again, many thanks to Chris Lonvick
et al for their fine work on syslog).  The logging of
security data has not gotten near the attention that,
say, billing records have.

On 17th thought, the following

  2.12.16 Send Accounting Records To Remote Servers
  2.12.17 Accounting Records To Be Sent
  2.12.18 Do Not Log Passwords

belong under logging.  I'll move them there.

I'll aslo add a SHOULD requirement about relibility of
logging, probably citing the reliable syslog draft.
Were implementations more widely available, it would
be a MUST.

There is a lot of security releated data that SHOULD
be logged.  The items I've listed are a pretty low
bar.  I'm going to leave it as it is now, and yes,
if logins/logouts etc. are not logged, then the
device will not be in compliance.

bw> 2.14 Security features must not cause operational problems
bw>
bw> I think more specific guidance is needed here.

All this one is trying to say is if a security feature
is implemented in such a way that it will cause the
box to fall over, stop functioning or do other
nasty things, then even though it technically implemented
a working version of the required feature, it fails
because the feature is not usable.

For example, if it is known that turning on logging
can spike the route processor, the result may be
that operators institute a policy that logging
should not be used.  In this case, the feature,
though technically present, is practically useless.


>  For example, one could
bw> say that the device should have a NIST-certified crypto module.

I think this example was part of a train of thought that goes with
the following comment

bw>
bw> 2.15  Security features should have minimal performance impact
bw>
bw> I think more specific guidance is needed here.  If a device implements
bw> 3DES in software (e.g. not optimized for VPN) it typically won't be
bw> able to provide 100 Mbps performance on decrypt or encrypt. Does this
bw> mean that such a device (e.g. most routers and switches) is
bw> non-compliant?

Yes.

Large carriers/transit networks (the target of this doc) are not doing
software encryption/decryption of customer traffic at the edge.  This
is a problem for customer edge/internal networks.   See the scope.

to be continued again....

Thanks,
----George