Subject: [OPSAWG] Comments on draft-ietf-opsawg-operations-and-management-03

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Mar 2008 13:29:37 +0200 (EET)

Hi,

[Resend: David's Huawei address bounced and I mistyped the mailing 
list address.]

(Not subscribed to the list, so I'm cc:ing the chairs so they can pass this to 
the list if necessary and if the mailing list moderation doesn't work.)

Just a couple of relatively small detail comments on 
draft-ietf-opsawg-operations-and-management-03:

  - Section 4.4 has:

    A number of efforts have existed in the IETF to develop policy-based
    management.  RFC3198 [RFC3198] was written to standardize the
    terminology for policy-based management across these efforts.

    It is highly desirable that text processing tools such as diff, and
    version management tools such as RCS or CVS or SVN, can be used to
    process configurations.  This approach simplifies comparing the
    current operational state to the initial configuration.

I believe that for all intents and purposes, from IETF perspective, 
policy-based management is dead.  This should be reflected in the text as now 
and then, new protocols come up envisioning leveraging COPS-PR or whatever and 
showing them the error of their ways is easier if we have a clear guidance on 
this in a BCP document.

Wrt the second paragraph, I'd generalize "initial configuration".  It is 
commonplace to compare configuration changes to e.g., last day, last week, last 
month, etc. -- having configuration in a text, and human-understandable format 
is very valuable for various reasons such as change control (or verification), 
configuration consistency checks, etc.

- in section 4.7 you ask:

    Standard SNMP notifications or SYSLOG messages
    [I-D.ietf-syslog-protocol] might already exist, or can be defined, to
    alert operators to the conditions identified in the security
    considerations for the new protocol.  [DISCUSS: can somebody provide
    an example of an existing notifications or syslog messages related to
    security, other than SNMPv3-specific notifications?]

I'm not sure what exactly you're looking for, but from ops point of view, 
syslog is probably the most important security tool.  For example, you can log 
all the commands entered by the operator using syslog (giving you some degree 
of audit trail), or you can see who has logged on/off using SSH from where, 
failed SSH logins can be logged using syslog, etc.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "David Harrington" <[email-masked]>
Date: Tue, 25 Mar 2008 09:30:16 -0400

Hi,
Comments inline. 

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Tuesday, March 25, 2008 7:30 AM
> To: David Harrington
> Cc: [email-masked]; [email-masked]
> Subject: Comments on draft-ietf-opsawg-operations-and-management-03
> 
> Hi,
> 
> 

I don't believe we should cut a wide swath and say "don't even try to
do policy-based management in the IETF".

There is a companion OPSAWG document under development that discusses
existing IETF protocols and data models. The content was embedded in
earlier revisions of the guidelines document but has been moved from
the guidelines to keep the guidelines smaller. In the "survey"
document, we state that COPS-PR is not recommended, and the reasons
why:

   COPS-PR has not had wide deployment, and operators have stated that
   its use of binary encoding (BER) for management data makes it
   difficult to develop automated scripts for simple configuration
   management tasks in most text-based scripting languages.  In an IAB
   Workshop on Network Management [RFC3535], the consensus of
operators
   and protocol developers indicated a lack of interest in PIB modules
   for use with COPS-PR.

   As a result, the IESG has not approved any policy models (PIB
   modules) as an IETF standard, and the use of COPS-PR is not
   recommended.

> configuration consistency checks, etc.

will do.

> failed SSH logins can be logged using syslog, etc.

I can use this to a degree.

What I was looking for is a direct correlation between a documented
security event and some corresponding SNMP notification or syslog
messages. This is made more difficult by a lack of standardized syslog
message content and by some IETF security protocols not addressing
manageability. 

For example, there is no MIB module for managing SSH (thus no
traps/informs), and no recommendation in the SSH documents to log
security events. Ditto for TLS. 

EAP has no MIB, but does make the suggestion to log, For example,
   A peer MUST NOT send a Nak (legacy or expanded) in reply to a
Request
   after an initial non-Nak Response has been sent.  Since spoofed EAP
   Request packets may be sent by an attacker, an authenticator
   receiving an unexpected Nak SHOULD discard it and log the event.

IPsec SPD configuration MIB has knobs to control the logging of
events, and defines notifications for some security events.

David Harrington
[email-masked]
[email-masked]
[email-masked]