Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure
draft-jones-opsec-06

[Ballot discuss]
1.During the Seoul meeting an issue was reaised which has
  not been addressed yet, and my reviewer Dan Romascanu
  considers this a key issue:
    Part of the content of this document is appropriate for
    large IP SPs networks, but not for enterprise networks
    deploying IP technology. Without specifying clearly this
    in the scope section (1.3), the document risks to be
    mis-leading. I actually have already encountered cases
    where people were taking the recommendations in this
    document ad-literam for enterprise IP routing and
    other IP-related equipment. In the absence of such a
    correction I oppose publishing this version as an
    Informational RFC.
    Actually in Seoul I pleaded for issuing a similar
    document for enterprise networks. I think that this
    is important work.
 
  This can be fixed with:
  - Change the current title:
      Operational Security Requirements for IP Network Infrastructure
    into something aka:
      Operational Security Requirements for ISP IP Network Infrastructure

  - In sect 1.3: Change "IP networks" into "ISP networks"
    or "ISP IP networks"

2.I still see SNMP being referenced with RFC1157. That RFC
  is SNMPv1 which we have obsoleted. I'd prefer a refence
  to RFC3410 and RFC3411. And I also think it is mandatory
  to put some text in this document that states that SNMPv1
  does NOT provide proper security and that deployment of
  SNMPv3 instead is STRONGLY RECOMMENDED.

[Ballot comment]
------- 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
good.

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
locked?

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

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.

2.2.4

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
separation?

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
ok?

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

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.

[Ballot discuss]
1.During the Seoul meeting an issue was reaised which has
  not been addressed yet, and my reviewer Dan Romascanu
  considers this a key issue:
    Part of the content of this document is appropriate for
    large IP SPs networks, but not for enterprise networks
    deploying IP technology. Without specifying clearly this
    in the scope section (1.3), the document risks to be
    mis-leading. I actually have already encountered cases
    where people were taking the recommendations in this
    document ad-literam for enterprise IP routing and
    other IP-related equipment. In the absence of such a
    correction I oppose publishing this version as an
    Informational RFC.
    Actually in Seoul I pleaded for issuing a similar
    document for enterprise networks. I think that this
    is important work.

2.I still see SNMP being referenced with RFC1157. That RFC
  is SNMPv1 which we have obsoleted. I'd prefer a refence
  to RFC3410 and RFC3411. And I also think it is mandatory
  to put some text in this document that states that SNMPv1
  does NOT provide proper security and that deployment of
  SNMPv3 instead is STRONGLY RECOMMENDED.

[Ballot comment]
------- 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
good.

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
locked?

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

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.

2.2.4

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
separation?

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
ok?

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

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

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.

[Ballot discuss]
1.During the Seoul meeting an issue was reaised which has
  not been addressed yet, and my reviewer Dan Romascanu
  considers this a key issue:
    Part of the content of this document is appropriate for
    large IP SPs networks, but not for enterprise networks
    deploying IP technology. Without specifying clearly this
    in the scope section (1.3), the document risks to be
    mis-leading. I actually have already encountered cases
    where people were taking the recommendations in this
    document ad-literam for enterprise IP routing and
    other IP-related equipment. In the absence of such a
    correction I oppose publishing this version as an
    Informational RFC.
    Actually in Seoul I pleaded for issuing a similar
    document for enterprise networks. I think that this
    is important work.

2.I still see SNMP being referenced with RFC1157. That RFC
  is SNMPv1 which we have obsoleted. I'd prefer a refence
  to RFC3410 and RFC3411. And I also think it is mandatory
  to put some text in this document that states that SNMPv1
  does NOT provide proper security and that deployment of
  SNMPv3 instead is STRONGLY RECOMMENDED.

3.Comments from Juergen Schoenwaelder:
  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).)

[Ballot comment]
------- 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
good.

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
locked?

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

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.

2.2.4

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
separation?

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
ok?

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

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

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

[Ballot discuss]
1.During the Seoul meeting an issue was reaised which has
  not been addressed yet, and my reviewer Dan Romascanu
  considers this a key issue:
    Part of the content of this document is appropriate for
    large IP SPs networks, but not for enterprise networks
    deploying IP technology. Without specifying clearly this
    in the scope section (1.3), the document risks to be
    mis-leading. I actually have already encountered cases
    where people were taking the recommendations in this
    document ad-literam for enterprise IP routing and
    other IP-related equipment. In the absence of such a
    correction I oppose publishing this version as an
    Informational RFC.
    Actually in Seoul I pleaded for issuing a similar
    document for enterprise networks. I think that this
    is important work.

2.I still see SNMP being referenced with RFC1157. That RFC
  is SNMPv1 which we have obsoleted. I'd prefer a refence
  to RFC3410 and RFC3411. And I also think it is mandatory
  to put some text in this document that states that SNMPv1
  does NOT provide proper security and that deployment of
  SNMPv3 instead is STRONGLY RECOMMENDED.

3.Comments from Juergen Schoenwaelder:
  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).)

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

[Ballot comment]
------- 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
good.

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
locked?

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

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.

2.2.4

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
separation?

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
ok?

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

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?

[Ballot discuss]
1.During the Seoul meeting an issue was reaised which has
  not been addressed yet, and my reviewer Dan Romascanu
  considers this a key issue:
    Part of the content of this document is appropriate for
    large IP SPs networks, but not for enterprise networks
    deploying IP technology. Without specifying clearly this
    in the scope section (1.3), the document risks to be
    mis-leading. I actually have already encountered cases
    where people were taking the recommendations in this
    document ad-literam for enterprise IP routing and
    other IP-related equipment. In the absence of such a
    correction I oppose publishing this version as an
    Informational RFC.
    Actually in Seoul I pleaded for issuing a similar
    document for enterprise networks. I think that this
    is important work.

2.I still see SNMP being referenced with RFC1157. That RFC
  is SNMPv1 which we have obsoleted. I'd prefer a refence
  to RFC3410 and RFC3411. And I also think it is mandatory
  to put some text in this document that states that SNMPv1
  does NOT provide proper security and that deployment of
  SNMPv3 instead is STRONGLY RECOMMENDED.



----------------
Comments from Juergen Schoenwaelder:

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

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

[Ballot comment]
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.

[Ballot discuss]
I'm joining the club - this document can't possibly have had enough review.
This paragraph is just plain wrong:

  Spoofed Packet.

      A "spoofed packet" is defined as a "packet having a source address
      that, by application of the current forwarding tables, would not
      have its return traffic routed back through the interface on which
      it was received."

Multihoming and asymmetric routing is now outlawed in the Internet? No way!

Received the following long list of comments from
Pekka on ops directorate (previous list was truncated):

substantial
-----------

2.1.1 Support Secure Channels For Management

  Requirement. The device MUST provide mechanisms to ensure end-to-end
      integrity and confidentially for all network traffic and protocols
      used to support management functions.  This MUST include at least
      protocols used for configuration, monitoring, configuration
      backup, logging, time synchronization, authentication, and
      routing. This requirement MAY be satisfied using either In-Band or
      Out-of-Band mechanisms as defined in Section 2.2 and Section 2.3.
[...]
      Protocols that use encryption: SSH, SFTP, SNMPv3, BGP, NTP,
        Kerberos.


==> This needs some additional warnings, as the MUST requirements cannot
be fulfilled at present without resorting to IPsec.  How do you perform
Secure Logging for example otherwise?

==> s/use/are able to use/  --- let's not give a false sense of security
that they would automatically yield security.  Also,
NTP or BGP do not provide encryption, but rather authentication
and integrity.

2.2 In-Band Management Requirements

  This section lists security requirements for devices that are managed
  In-band.

==> "are managed", "will be managed" or "can be managed"?  Can the user
know before purchasing a box how it's going to be managed if not
the last one?

  o  saturation of customer lines or interfaces can make the device
      unmanageable

==> this is not balanced, reword e.g. to:

  o  saturation of customer lines or interfaces can make the device
      unmanageable, unless an out-of-band management has been reserved
      specifically to avoid this problem.

(or in some other way take better into an account that no same ISP will
*ever* just choose _only_ in-band management.)

  o  in-band management traffic on public interfaces may be intercepted

==> also:

  o  in-band management traffic on public interfaces may be intercepted,
      but typically that would require a significant compromise in the
      routing system.
..

  o  Since the same networking code and interfaces are shared for
      management and customer data, it is not possible to isolate
      management functions from failures in other areas. (For example, a
      "magic packet" or buffer overrun that causes the data forwarding
      portions of a router to crash will also likely make it impossible
      to manage.  This would not necessarily be the case if the
      management and data forwarding elements were completely separated)



==> this seems so misguided that I would remove it completely or reword
it a LOT.  If you crash a forwarding element with a magic packet, it
will be unmanageable using out-of-band mechanisms as well.

2.2.1 Use Encryption Algorithms Subject To Open Review

==> the author has probably mixed the terms "Encryption" and
"Cryptography", as continuously he keeps referring to mechanisms which
use e.g. signatures but provide no encryption.  A lot of sections need
to be re-reviewed.

  Requirement. If encryption is used to provide secure management
      channels, then it MUST support encryption algorithms that are
      subject to "open review" as defined in Section 1.8.

==> This is ambiguous.  It could be read to say, "all encryption
algorithms subject to open review MUST be supported" while it probably
tries to say something slightly different.  And if not all, what's
the "mandatory to implement" set of mechanisms so that interoperability
will be ensured?

[[ I have skipped the review of the rest of the 2.2.X sections as
they seem to be highly problematic, and should probably be fixed
with the help of the security area guys ]]

2.3.1 Support a 'Console' interface

  Requirement. The device MUST support complete configuration and
      management via a 'console' interface that functions independently
      from the forwarding and control planes.

==> "independently from control planes".  You must probably clarify to
make it clearer what you mean by "control plane".  I guess "IP control
plane" or whatever?  I mean, if the CPU of the system is hosed or at
100%, or all the memory has been exhausted due to a memory leak,
even console interface doesn't help.


2.3.2 'Console' Has A Simple Default Communication Profile

  Requirement. The device MUST support a simple default profile of
      communications parameters on the 'console'.
[...]
  Examples.

        The following is a profile widely used for RS232 console
        connections:

==> At front you say "MUST ... default profile".  What do you mean?
That the consoles of the same type must have the same parameters
(physical or otherwise)?  I don't think the language about RS232 in
the examples is strict enough to create good interoperability/standard.

FWIW, we have 3 kinds of 9 pin (not to mention 25 or RJ11 or RJ45..)
console cables in our machine room, so choosing one is pretty
important.  Not sure, however, whether coming to a consensus might
be more difficult.

  Requirement. If it is possible to change the default console
      communication profile, then there MUST be a method defined and
      published for returning to the default configuration.
==> this seems like too obvious to be true.  If you can change the
profile, you obviously can change it back :-).  I assume you mean
something like, "must be able to reset the console configuration
without console access" or something -- if so, say it!

  Examples.

      A physical toggle switch on the device might provide a way of
      resetting the default parameters.  Another method might be to send
      a break or a predefined character sequence on a serial line.

==> unless this mechanism is standardized (different key sequences for
10 different vendors) I don't think this really helps that much :-).

2.3.5 'Console' Supports Fall-back Authentication

  Requirement. The 'console' SHOULD support an authentication mechanism
      which does not require functional IP or depend on external
      services.  This authentication mechanism MAY be disabled until a
      failure of other preferred mechanisms is detected.  In the event
      of fall-back AUTHENTICATION, the interface SHOULD either im      a locally defined AUTHORIZATION profile or consider all commands
      to be AUTHORIZED. This mechanism SHOULD be implemented as a
      fall-back if the preferred authentication method is not "LOCAL".

==> there seem to be multiple requirements here?  Does it make sense
to include these in one requirement?  Or you should make it clearer
what are the different options for console authentication, e.g.:
1) remote authentication, with possible fallbacks
2) local auth for everything
3) read-only access without local authentication ("login + ena")
4) fully privileged without auth

FWIW, our consoles do mostly 2) and some 3).  I wouldn't want to do 1),
because more often than not, I guess when you have an emergency the
fallback mechanism could be screwed up.  But I guess this depends a lot
on how often (and how) you use the console, how many admins you have,
etc.

2.3.8 Provide Separate Resources For The Management Plane

  Requirement. If the device implements separate network interface(s)

      for the management plane per Section 2.3.6 then the device SHOULD
      provide separate resources and use separate software for different
      classes of interface.

==> I don't think anybody implements something like this and this should be
removed.  I can't say this is B_C_P.

2.4.8 Support Text Configuration Files

  Requirement. The device MUST provide a means to remotely save a copy
      of the system configuration file(s) in a textual format.  It MUST
      NOT be necessary to use a proprietary program to view the
      configuration. The configuration MUST also be viewable as text on
      the device itself. Sensitive information such as passwords that
      could be used to compromise the security of the device MAY be
      excluded from the saved configuration.

==> is text compression using e.g. gzip or bzip2 allowed, though?

2.5.4 Ability to Control Service Bindings for Listening Services

  Requirement. The device MUST provide a means for the user to specify
      the bindings used for all listening services.  It MUST support
      binding to a list of addresses and netblocks.  It MUST also
      support configuration of binding services to any interface local
      to the device, physical or non-physical (e.g. "loopbacks").

==> it should be clearer what's in scope for this.  Is e.g. the Cisco
'ip receive acl' or Juniper firewall filter on loopback interface
sufficient?  I guess this requirement and subsequent discussion should
take other approaches than just controlling the binding into
consideration.

...

Looking back at this after reading 2.7.2 makes seem like that such
features would not fulfull these criteria.  I don't know of major
implementations which support this, so I suggest dropping this
section completely.  It's not even necessary with 2.7.2..

2.5.6 Support Automatic Anti-spoofing for Single-Homed Networks

  Requirement.

      The device MUST provide a means to designate particular interfaces
      as servicing "single-homed networks" (see Section 1.8) and MUST
      provide an option to automatically drop "spoofed packets" (Section
      1.8) received on such interfaces.  . This option MUST work in the
      presence of dynamic routing and dynamically assigned addresses.

  Justification. See [RFC2867] Network Ingress Filtering.

==> note that the examples you note do not actually satisfy the first
MUST, i.e., be able to designate some interfaces as being single-homed.
I don't believe this is supported and should be removed or changed to
a MAY.

==> wrong RFC, it's 2827 :-)
==> s/ . //

==> I'd consider generating a SHOULD support option for Multi-Homed
networks as well. FWIW, draft-savola-bcp38-multihoming-update-03.txt
which has been approved may be of interest.  Unfortunately, there are

no clear mechanisms which help for multi-homed/asymm. case -- only
a couple of fixes to the problem with a specific assumptions.  But in any
case, this should mentioned briefly in this section, or a new section
of its own.

2.6.1 Support Rate Limiting

  Requirement. The device MUST provide the capability to limit the rate
      at which it will pass traffic based on protocol, source and
      destination IP address or CIDR block, source and destination port,
      and interface.  Protocols MUST include at least least IP, ICMP,
      UDP, and TCP and SHOULD include any protocol.

==> You take no stance whether such rate-limiting, filtering etc.
mechanisms must be implemented with certain performance -- e.g.
line-rate.  Some implementations are useless even though rate-limiting
is possible in theory.

2.7.4 Ability to Filter Without Performance Degradation

  Requirement. The device MUST provide a means to filter packets

      without performance degradation. The device MUST be able to filter
      on ALL interfaces (up to the maximum number possible)
      simultaneously and with multiple filters per interface (e.g.,
      inbound and outbound).
[...]

==> with *ZERO* performance degragation?  OK, good luck.  I hope you
don't need Cisco's 10G interfaces for example..  There are a lot of
products which guarantee a certain level of filtering, e.g. up to
100 acl's, but may get degraded performance if you put in 32000
entries where the last one matches.  Your wording would imply that e.g.,
the "32000 rules" -rule would be required.

  Examples. Another way of stating the requirement is that filter
      performance should not be the limiting factor in device
      throughput.  If a device is capable of forwarding 30Mb/sec without
      filtering, then it should be able to forward the same amount with
      filtering in place. This requirement most likely implies a
      hardware-based solution (ASIC).

==> the example is a very classic bad example, because it does not
mention packets per second rate at all.  E.g. you could reword this like:

  Examples. Another way of stating the requirement is that filter
      performance should not be the limiting factor in device
      throughput.  If a device is capable of forwarding 1000Mb/sec of
      packets of any size without filtering, then it should be able
      to forward the same amount with filtering in place.
      This requirement, especially on higher throughput rates, most
      likely implies a hardware-based solution (ASIC).

2.7.5 Support Route Filtering

  Requirement. The device MUST provide a means to filter routing
      updates for all supported dynamic routing protocols.

  Justification. See [RFC3013] and section 3.2 of [RFC2196].

  Examples. Operators may wish to ignore advertisements for routes to
      addresses allocated for private Internets.

==> well, this just isn't done for many vendors and many protocols
at the moment.  For example, inbound OSPF and IS-IS filtering is
often not implemented.  Is this intentional?

2.7.7 Ability to Log Filter Actions

  Requirement.

      It MUST be possible to log all filter actions. The logging
      capability MUST be able to capture at least the following data:
      permit/deny/drop status, source and destination ports, source and
      destination IP address, which network element forwarded the packet
      (interface, MAC address or other layer 2 information that
      identifies the previous hop source of the packet), and time-stamp
      to millisecond accuracy.

      Logging of filter actions is subject to the requirements of
      Section 2.11.

==> I do not agree that all of these are necessary.  For one, ports make
little sense if the protocol is not something like TCP, UDP, or maybe
ICMP.  I'm not 100% sure L2 info i sneeded, and whether millisecond
accuracy is needed either.  These certainly aren't available e.g.
juniper platforms (except maybe if you funnel the logs through syslog
which may be a bad idea).


==> the explicit requirement has shifted down two lines. (editorial)

2.12.8 Ability To Authenticate Without Plaintext Passwords

  Requirement. The device MUST support mechanisms that do not require
      the transmission of plaintext passwords in all cases that require
      the transmission of authentication information across networks.

  Justification. Plain-text passwords can be easily observed using
      packet sniffers on shared networks. See [RFC1704] and
      [I-D.iab-secmech]  for a through discussion.

  Examples. Remote login requires the transmission of authentication
      information across networks. Telnet transmits plaintext passwords.
      SSH does not. Telnet fails this requirement. SSH passes.
==> uhh.. hasn't this already been covered by the requirements for
encryption in the protocols or whatever, inherited from section 2.2?

  [RFC-INDEX]
              IESG and IETF, "The IETF RFC Series", .

==> there are many refs which are not referred to in the text; remove
from the references section, or add in the body.


editorial
---------


  In-Band management.

==> some terms in 1.8 end in a dot and some don't; unify.


      A number of requirements refer to "services". For the purposes of
      this document a "services" is defined as "any process or protocol

==> s/services/service/

      integrity and confidentially of communications.  Examples include

==> s/lly/lity/ (similar elsewhere)

  o  saturation of customer lines or interfaces can make the device
      unmanageable
[...]
      *  CLI-Friendly.  An RS232 interface and a CLI are sufficient in
        most cases to manage a device. No additional software is
        required


==> add dots at the end (same elsewhere)

2.3.4 'Console' requires minimal functionality of attached devices.

==> but remove the dots at the end of section titles..

    times.  Requiring complex or nonstandard behavior on the part of
      attached devices reduces the likelihood that the console will
      without hassles.

==> s/will/will work/

  Requirement. The 'console' SHOULD support an authentication mechanism
      which does not require functional IP or depend on external
      services.  This authentication mechanism MAY be disabled until a
      failure of other preferred mechanisms is detected.  In the event
      of fall-back AUTHENTICATION, the interface SHOULD either implement
      a locally defined AUTHORIZATION profile or consider all commands
      to be AUTHORIZED. This mechanism SHOULD be implemented as a
      fall-back if the preferred authentication method is not "LOCAL".

==> lower capitals will do, no use yelling, mister :-)

  Requirement. The device MUST support a command line interface (CLI)
      or equivalent mechanism that works over low bandwidth connections
[...]

      The device MUST provide accurate, per-interface counts of spoofed
      packets dropped by Section 2.5.6
[...]
  Examples. This requirement MAY be satisfied by implementing a
      centralized authentication system.  See Section 2.12.5. It MAY
      also be satisfied using local authentication. See Section 2.12.6

==> add a dot at the end.


      *  One has to assume that hackers, operators, etc. will erase or
        corrupt all writable media (disks, flash, etc.).  In such
        situations, it is necessary to be able to recover starting with
        only non-writable media (e.g. CD-ROM, a true ROM-based
        monitor).


==> s/will/may/ ??!?

      RS-232 The device could support uploading new code via an RS232
        console port.


==> s/RS-232/RS-232:/ or the like (same with the rest)


  Examples. A 7-bit ASCII configuration file that shows the current
      settings of the various configuration options wold satisfy the

==> s/wold/would/

      what steps should be taken to mitigate risk (e.g., "should I turn
      this service off "?)

==> s/ "?/?"/

  Requirement. The device MUST provide a means to turn off any external
      services listening.

==> s/any external services listening/any listening .../ ?
(please clarify "external" btw.)

    loopback interfaces.  The looopback interfaces may be addressed

==> s/looop/loop/

2.6.3 Support Rate Limiting Based on State

  Requirement. The device MUST be able to rate limit based on on all
      TCP state bits. The device SHOULD support rate limiting of other
      stateful protocols where the normal processing of the protocol
      gives the device access to protocol state.


==> these are control bits, not state per se.

  Examples. This requirement MAY be satisfied by the use of
      RADIUS,TACACS+, or syslog.

==> s/,/, /


  Warnings.

      Note that there may be privacy or legal considerations when
      logging/monitoring user activity.


==> shift the text up two lines. (same elsewhere as well: unify style)

  Justification. This is important because it supports individual
      accountability See section 4.5.4.4 of [RFC2196].


==> s/accountability/accountability./

  [I-D.iab-secmech]
              Bellovin, S., Kaufman, C. and J. Schiller, "Security
              Mechanisms for the Internet", draft-iab-secmech-03 (work
              in progress), July 2003.

  [I-D.orman-public-key-lengths]
              Orman, H. and P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric Keys",
              draft-orman-public-key-lengths-06 (work in progress),
              December 2003.


==> I'd invent shorter "short names" for these references.

Received the following comments from ops directorate:

2.1.1 Support Secure Channels For Management

  Requirement. The device MUST provide mechanisms to ensure end-to-end
      integrity and confidentially for all network traffic and protocols
      used to support management functions.  This MUST include at least
      protocols used for configuration, monitoring, configuration
      backup, logging, time synchronization, authentication, and
      routing. This requirement MAY be satisfied using either In-Band or
      Out-of-Band mechanisms as defined in Section 2.2 and Section 2.3.
[...]
      Protocols that use encryption: SSH, SFTP, SNMPv3, BGP, NTP,
        Kerberos.


==> This needs some additional warnings, as the MUST requirements cannot
be fulfilled at present without resorting to IPsec.  How do you perform
Secure Logging for example otherwise?

==> s/use/are able to use/  --- let's not give a false sense of security
that they would automatically yield security.  Also,
NTP or BGP do not provide encryption, but rather authentication
and integrity.

2.2 In-Band Management Requirements

  This section lists security requirements for devices that are managed
  In-band.

==> "are managed", "will be managed" or "can be managed"?  Can the user
know before purchasing a box how it's going to be managed if not
the last one?

  o  saturation of customer lines or interfaces can make the device
      unmanageable

[Ballot discuss]
----------------
comments 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
good.

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
locked?

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

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.

2.2.4

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
separation?

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
ok?

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

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?

----------------
Comments from Juergen Schoenwaelder:

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

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

[Ballot discuss]
I got quite some feedback from OPS directorate and MIB Doctors.
I have some myself scribbled on a printed version.
I need to collect/type them and then record them here.
Will do so later today

[Ballot discuss]
I got quite some feedback from OPS directorate and MIB Doctors.
I have some myself scribbled on a printed version.
I need to collect/type them and then record them here.
Will do so later today

[Ballot discuss]
I don't support this going for BCP.  There are a number of cases in the document where
there are value judgements about the trade-offs between user needs and operator
needs, and I feel that the documents justification of them simply does not past muster for
best current practice.  One example:

2.8.3 Ability to Filter on Protocol Header Fields

  Requirement. The filtering mechanism MUST support filtering based on
      the value(s) of any portion of the protocol headers for IP, ICMP,
      UDP and TCP. It SHOULD support filtering of of all other protocols
      supported at layer 3 and 4.  It MAY support support filtering
      based on the headers of higher level protocols.  It SHOULD be
      possible to specify fields by name (e.g. "protocol = ICMP") rather
      than bit-offset/length/numeric value (e.g. 72:8 = 1).

  Justification. Being able to filter on portions of the header is
      necessary to allow implementation of policy, secure operations,
      and support incident response.

  Examples. This requirement implies that it is possible to filter
      based on TCP or UDP port numbers, TCP flags such as SYN, ACK and
      RST bits, and ICMP type and code fields. One common example is to
      reject "inbound" TCP connection attempts (TCP, SYN bit set).
      Another common example is the ability to control what services are
      allowed in/out of a network. It may be desirable to only allow
      inbound connections on port 80 (HTTP) and 443 (HTTPS) to a network
      hosting web servers.

  Warnings. None.

A network could well make a choice that the ability to filter on layer 4 protocol
information (especially headers) opened the network to abuse by operators, local
law enforcement, or black hats; deciding to limit that capability could be a rational
for some networks, just as this decision might be rational for others.  As written,
the trade-offs aren't discussed.

I also find the document's view of "single homed" to be inadequate (since it doesn't
distinguish between the cases where a network may have multiple exits to the same
AS and a single exit, and since it doesn't acknowledge that routing isn't necessarily
symmetric past the first hop in either case).

I'm also disturbed by the "Warnings" style of operational specification.  That may be
too deeply ingrained in the document to change at this point, but it really sounds
much more prescriptive than this document ought to be.  There are balance points
in all of this among competing needs, and this document's flat statements can
really elide how circumstances can cause other choices to be valid.  (The whole console
port discussion being another one where deeply held assumptions about the
size and placement of gear may hide the fact that there are other rational choices
for other types of gear that still fall under the rubric "IP Network Infrastructure")

[Ballot comment]
These aren't blocking comments, but a few bits.  The TCP term should
be fixed with an RFC Editor Note.

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

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

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

[Ballot comment]
These aren't blocking comments, but a few bits.  The TCP term should
be fixed with an RFC Editor Note.

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

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

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

[Ballot discuss]
The introductory  material needs to mention that the BCP requirement on devices
is modified vis-a-vis some devices by Appendix A - edge devices having some of
the Section 2 requirements that other devices do not have. 

I see this being done with an RFC Editor Note.

[Ballot comment]
These aren't blocking comments, but if the document is getting a rev, some fixes:

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

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

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

[Ballot comment]
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:'

[Ballot comment]
- 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"

[Ballot comment]
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?

[Ballot comment]
- 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"