Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure
RFC 3871

Note: This ballot was opened for revision 06 and is now closed.

(Steven Bellovin) Yes

(Bill Fenner) (was Abstain) Yes

(Ted Hardie) (was Discuss) Yes

(Harald Alvestrand) (was Discuss) No Objection

Comment (2004-04-14)
No email
send info
Reviewed by Brian Carpenter, Gen-ART

NOTE (from Harald): I find it strange that the first "this is the author's opinion, not the IETF" paragraph - CAVEAT LECTOR - is in the definition of terms in section 1.8. I'd be happier if that was copied to the abstract.

(Margaret Cullen) No Objection

Comment (2004-01-21 for -)
No email
send info
I have entered a no-obj position, because I have no technical issues with this
document.  However, given the feedback we received about the process in this
case, are we considering a longer review period and/or more discussion before
passing this document?

(Ned Freed) No Objection

Comment (2004-02-05 for -)
No email
send info
I see no point in belaboring the points others have already made.

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2004-01-22)
No email
send info
  Delete last sentence in Abstract.

  Replace 'insure' with 'ensure' throughtout the document.

  The document uses [PKCS.3.1993] as a reference for Diffie-Hellman.  It
  should also reference RFC 2631.

  Use of '*must*' ought to be replaced with either 'must' or 'MUST'.

  Delete the last paragraph of Appendix B.  It begins: 'Version: $Id:'

(David Kessens) (was Discuss, No Objection) No Objection

Comment (2004-04-14)
No email
send info
We got two positive comments from the ops directorate.

(Allison Mankin) (was Discuss) No Objection

Comment (2004-01-22)
No email
send info
These aren't blocking comments, but a few bits.  The TCP term should
be fixed with an RFC Editor Note.

- SOHO is unexpanded (in "SOHO devices").

"traffic goes where its supposed to go (availability, confidentiality)"  - why is this about
  confidentiality?  Also a nit - "its" should be "it's"

"TCP state bits" - this term is wrong - change to "TCP control flag bits"

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) (was Discuss) No Objection

Comment (2004-04-15)
No email
send info
------- Earlier concerns that have been cleared ----

From OPS Directorate

Overall: This document is not publishable in its current form.
While the goal of the document (getting vendors to
provide better security facilities in switches and routers) seems
laudable, the guidance provided is just not specific enough in many
places. There are too many choices allowed, so that vendors could claim
compliance but not actually interoperate, or even be secure.  As a
result, publishing the document at this point could do more harm than

Here are some specific comments:

Section 1.4:

This section is entitlted "definition of a secure network" yet many of the
requirements have little to do with security, such as availability.

"The following assumptions are made:

   o  Devices are physically secure.
   o  The management infrastructure (AAA/DNS/log server, SNMP management
      stations, etc.) is secure."

More specific guidance is needed. Are we saying that we are
assuming that an attacker can't access the console port?  If not, is
this because of a recommended practice (e.g. use of token card security),
or just because we are assuming that the door to the closet is always kept

Rather than assume that management infrastructure is secure, it would be
more helpful to provide some guidelines as to how to ensure they are in
fact secured.  For example, one might recommend ensuring that AAA clients
have decent random number generators or implement IPsec or at least use
different shared secrets.  One might use SNMPv3, etc.  The draft never
gets specific enough on this, in my opinion.

Section 2.1.1

I was expecting some specific guidance here.  For example, support
for SNMPv3, SSH, etc. Instead, this section just talks about some ways
that things *might* be secured.  Based on this section, I guess one could
use SNMPv2 over TLS over TCP *or* SNMPv3 *or* SNMPv2 over IPsec to secure
management traffic and be compliant. If the goal is to use a management
station to securely manage devices, that level of guidance is not helpful.

Per-packet integrity protection doesn't guarantee that the log files won't
get modified.

"Protocols that use encryption"

Is it being suggested that traffic should or must be encrypted?  That
these protocols should or must be implemented? I'm not sure.

Is it being suggested that transmission layer encryption (not even
integrity protection) would address BGP-related security threats?
Reference to some of the BGP security documents might be helpful.

"Protocols that do not use encryption:"  Is this an attempt to recommend
that secure equivalents be used instead of insecure alternatives?  If so,
then the text should say this and supply specific recommendations.

"   Warnings. The use of encryption does not guarantee that the protocol
      is secure."

OK.  So what is the recommendation?

2.2 In-band management

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

2.2.1 Encryption algorithms

Hilarie's draft (included in the bibliography) should be cited in this

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

2.2.2 Strong encryption

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

2.2.3  Encryption protocols

I think there is a bit of confusion here between transforms supporting
confidentiality + auth + integrity & replay protection and security
protocols.  It's nice to say that IETF standards should be used, but we
have so many of them that can be used in so many different ways that this
advice is not specific enough.


It would be helpful to cite specific parameters (e.g. IPsec policies, IKE
negotiation parameters) that may need to be customized.  The problem is
that there are lots of other knobs that are just not worth adjusting --
they will cause interoperability problems for not much security benefit.
The recommendation seems to imply that if you don't allow a customer to
tweak every conceivable IKE setting you're non-compliant.

2.3.5  Fallback authentication

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

2.3.8  Separate resources for the management plane

Is it really necessary to require a different CPU and memory for the
management interface?  Why can't a memory manager enforce the required

2.4.1 CLI

Why must the CLI provide access to "all management functions"?  Does this
mean that the CLI has to support all the capabilities of all the SNMP MIBs
on the box to be compliant?

2.4.2 Scripting

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

2.4.3 Slow links

How do we know if a given CLI works over slow links?  Does XML based
configuration not qualify?  I guess NetConf is a waste of time then, eh?

2.7 Filtering

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

2.7.4 Performance

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

Please be more specific.

2.12.5 AAA

RADIUS is [RFC2865].  Do RADIUS implementations need to satisfy the security
recommendations in [RFC3579]?  Are any of the recommended protocols
(Kerberos, RADIUS, Diameter, TACACS+) ok? [RFC3539] doesn't discuss AAA
security, so I'm not sure why it's referenced here. [RFC3588] is about
Diameter, so it doesn't discuss RADIUS security.

2.12.6 Accounting

Are there any reliability requirements (see RFC 2975)?  Or is any protocol

AAA protocols typically don't send accounting records for things like
status and configuration changes.  Does this mean those protocols are

2.14 Security features must not cause operational problems

I think more specific guidance is needed here.  For example, one could
say that the device should have a NIST-certified crypto module.

2.15  Security features should have minimal performance impact

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

--- more earlier comments that have been cleared or are non-blocking anyway

These were from Juergen Schoenwaeler and were for an earlier revision

  With my SNMP background, I was of course puzzled about the
  requirement to be able to reset counters. I would personally
  like to have one or two sentences added that such a reset
  means the display of counters in e.g. a CLI interface but
  not necessarily the reset of the real physical counters.
  (In other words, I expect that the CLI takes a snapshot
  of a counter C at time t and then later displays C(now)-C(t) 
  on the CLI or whatever interface (this is basically what
  a management application running on top of SNMP would do).)

Below are the other comments I wrote down last night - most of them
(except the one referring to page 38) are purely editorial and may 
have already been observed by others.

Page 15: RS2323 -> RS232

Page 16: I am not really sure that RS 232 interfaces do not need additional
         software. In fact, without a modem/terminal program, using RS 232
	 interfaces is kind of hard (of course depends on your OS).

Page 26: The following sentence does not read well: "This requirement makes 
         it possible restrict access to management services using routing."

Page 29: "support to to rate-limit" -> "support to rate-limit"

Page 36: Reset of counter requirement should probably explain how this
         relates to SNMP. I hope the idea is that the displayed counter
         is reset, not the real counter underneath it.

Page 38: The warning concerning syslog are interesting and the current
         best solution concerns me (since it just says that there is no
	 deployable secure syslog solution at the moment, more than two
         years after publication of RFC 3195). This should probably make
	 the IESG think about the question whether RFC 3195 is going to
	 be the right solution...

Page 41: "... the address a reliable for ..." -> 
         "... the address reliable for ..."

Page 51: "... will may leave the operator ..." ->
	 "... may leave the operator ..."

------- more earlier comments (when doc was still targeted as BCP)

comments from Dan Romascanu

Here are some of my reservations:

1. Section 1.7

   Basis For Testing and Certification. As a  basis for testing and
      certification of security features of networked products.

I would be reluctant to include this use. As a BCP and non-normative document, I fail to see how this can be a basis for certification. Some of our customers are taking very seriously certification of security, and if IETF is to issue a normative reference for such an activity, we need a more serious (and normative) document.

2. Use of term 'password'

This document takes a very odd approach for the use of term password, especially for a security document. It starts by claiming in Section 1.8 that 'password' will be used in a very broad way, kind of an alias for 'security token'. However, this is not consistently followed and almost all other instances of 'password' in the document refer to the old good interpretation that we all knew. On the other hand, other types of 'passwords' like SNMP community strings get special treatment in some sections.

3. Requirement 2.5.3 - If this requirement is to be followed for SNMP, any remote discovery or remote operation for an SNMP managed device would be impossible without the presence of a on-site operator to configure locally SNMP through some local craft interface. I do not think that this is BCP - at least not for some classes of networks and devices.

4. Same about requirement 2.12.9

5. It is odd that while talking about SNMP in the context of secure management, the document does not mention the need to activate the auth and priv modes, and the need to use access control with different rights for different sections of the MIB. Maybe if the authors were aware about how these can be used, their concerns reflected in requirements 2.5.3 and 2.12.9 would have been alleviated.

6. The way the first paragraph in Section 2.2 is written it makes a strong case against using in-band management. I would observe that this is far from being a BCP. I suggest that this paragraph be re-formulated. While showing up the increased risks and mentioning the attacks related to usage of in-band management, in should emphasize that there are means to defend, hence the requirements in the following sections.

7. The 'Warning' section in 2.3.1 is a strong argument in favor of RS-232, but has little to do with Security.

8. Sections 2.4.1 to 2.4.4 would belong to a 'CLI Requirements' document, but why should they be part of a 'Operational Requirements for Security' BCP? I would also observe that there is no 'standard CLI' - not in IETF at least - at this point in time.

9. However, if we are dealing with proprietary interfaces, why are requirements for 'Web interfaces' - quite widely used in device and server management almost totally absent?

Please do not interpret this as a fully negative view of the document. Quite the opposite, I find it very valuable, and there are many useful and accurate items. Most of my reservations are related to the management aspects, and to the fact that it provides requirements which are not aligned with a BCP. Maybe dropping 'BCP' from the title, and making the document just an Informational at this point in time would be better.

I also apologize for not having caught these during the IETF Last Call period.

(Alex Zinin) (was Discuss) No Objection