From owner-ipsec-policy@mail.vpnc.org Mon Jan 3 00:42:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08504 for ; Mon, 3 Jan 2005 00:42:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035ASgZ028224; Sun, 2 Jan 2005 21:10:28 -0800 (PST) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j035ASqc028221; Sun, 2 Jan 2005 21:10:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j035A59D027715; Sun, 2 Jan 2005 21:10:07 -0800 (PST) (envelope-from kseo@bbn.com) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0359wjf003765; Mon, 3 Jan 2005 00:09:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 3 Jan 2005 00:13:09 -0500 To: ietf-enroll@mit.edu, inch@nic.surfnet.nl, ipsec@ietf.org, ipseckey@ietf.org, ipsec-policy@vpnc.org, isms@ietf.org, kitten@ietf.org, ietf-kink@vpnc.org, ietf-krb-wg@anl.gov, ietf-ltans@imc.org, mobike@machshav.com, msec@securemulticast.org, ietf-openpgp@imc.org, pki4ipsec@icsalabs.com, ietf-pkix@imc.org, ietf-sacred@imc.org, ietf-sasl@imc.org, ietf-ssh@netbsd.org, ietf-smime@imc.org, authtime@nist.gov, syslog-sec@employees.org, ietf-tls@lists.certicom.com From: Karen Seo Subject: 2005 Network and Distributed System Security Symposium (NDSS '05) Cc: kseo@bbn.com Content-Type: multipart/alternative; boundary="============_-1107393303==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-1107393303==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" ** My apologies if you receive multiple copies of this message. ** ANNOUNCING THE INTERNET SOCIETY'S 2005 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'05) February 2, 2005 - Pre Conference Workshop February 3-4, 2005 - Symposium Catamaran Resort Hotel, San Diego, California General Chair: Eric Harder, National Security Agency Program co-Chairs: Dan Simon, Microsoft Research Dan Boneh, Stanford University ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/ The 12th annual NDSS Symposium brings together innovative and forward thinking members of the Internet community including leading edge security researchers and implementers, globally recognized security technology experts, and users from both the private and public sectors who design, develop, exploit, and deploy the technologies that define network and distributed system security. NDSS'05 provides a balanced mix of technical papers (with a strong emphasis on implementation) that cover new and practical approaches to security problems that are endemic to network and distributed systems. THIS YEAR'S TOPICS INCLUDE: * Cryptography in Network Security * Denial of Service Attacks, * Peer to Peer Approaches * Internet Defense * Intrusion Detection * Platform Security. FEATURED GUEST SPEAKER: * Amit Yoran, who was responsible for coordinating cyber-security activities for Homeland Security, will speak on "Security Challenges and Opportunities of the Future Enterprise" PRE CONFERENCE WORKSHOP TOPICS INCLUDE: * Security in handling mobility on the internet * Security in wireless LANs * Security for telephony or voice over IP * Trust relations in ad hoc networks * Key management strategies to support mobility * Security in RFID. More information is available at: http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml Parties interested in submitting papers should see the above web page for directions REGISTER EARLY FOR BEST PRICING Registration for NDSS'05 is now open. Student rates are available for both the workshop and symposium. See the web site for more information -- http://www.isoc.org/ndss05/ Registration fees: * November 31, 2004-January 10, 2005 $625. * After January 10, 2005 $695. SPONSORSHIP OPPORTUNITIES AVAILABLE! If your organization would like to help support NDSS and gain visibility through sponsoring, please contact: sponsor-ndss@isoc.org. Information is also available at http://www.isoc.org/ndss05/ Karen Seo NDSS'05 Publicity Chair --============_-1107393303==_ma============ Content-Type: text/html; charset="us-ascii" 2005 Network and Distributed System Security Symposium (ND
  ** My apologies if you receive multiple copies of this message. **

               ANNOUNCING THE INTERNET SOCIETY'S
2005 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'05)

February 2, 2005 - Pre Conference Workshop
February 3-4, 2005 - Symposium
Catamaran Resort Hotel, San Diego, California
General Chair:  Eric Harder, National Security Agency
Program co-Chairs: Dan Simon, Microsoft Research
                   Dan Boneh, Stanford University

ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/

    The 12th annual NDSS Symposium brings together innovative and
    forward thinking members of the Internet community including
    leading edge security researchers and implementers, globally
    recognized security technology experts, and users from both
    the private and public sectors who design, develop, exploit,
    and deploy the technologies that define network and distributed
    system security.

    NDSS'05 provides a balanced mix of technical papers (with a
    strong emphasis on implementation) that cover new and practical
    approaches to security problems that are endemic to network and
    distributed systems. 

THIS YEAR'S TOPICS INCLUDE:
     * Cryptography in Network Security
      * Denial of Service Attacks,
    * Peer to Peer Approaches
       * Internet Defense
      * Intrusion Detection
   * Platform Security.
FEATURED GUEST SPEAKER:
        * Amit Yoran, who was responsible for coordinating cyber-security
          activities for Homeland Security, will speak on "Security
          Challenges and Opportunities of the Future Enterprise"

PRE CONFERENCE WORKSHOP TOPICS INCLUDE:
* Security in handling mobility on the internet
        * Security in wireless LANs
     * Security for telephony or voice over IP
       * Trust relations in ad hoc networks
    * Key management strategies to support mobility
        * Security in RFID.
     More information is available at:
        http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml
     Parties interested in submitting papers should see the above
        web page for directions

REGISTER EARLY FOR BEST PRICING
     Registration for NDSS'05 is now open. Student rates are available
     for both the workshop and symposium. See the web site for more
     information -- http://www.isoc.org/ndss05/  Registration fees:
        *  November 31, 2004-January 10, 2005   $625.
        *  After January 10, 2005               $695.

SPONSORSHIP OPPORTUNITIES AVAILABLE!
     If your organization would like to help support NDSS and gain
     visibility through sponsoring, please contact:
     sponsor-ndss@isoc.org.  Information is also available at   
     http://www.isoc.org/ndss05/


Karen Seo
NDSS'05 Publicity Chair
--============_-1107393303==_ma============-- From owner-ipsec-policy@mail.vpnc.org Tue Jan 11 17:50:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12223 for ; Tue, 11 Jan 2005 17:50:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0BMAo58068229; Tue, 11 Jan 2005 14:10:50 -0800 (PST) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0BMAoas068228; Tue, 11 Jan 2005 14:10:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from localhost.localdomain (adsl-63-195-146-66.dsl.scrm01.pacbell.net [63.195.146.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0BMAZ3g068184 for ; Tue, 11 Jan 2005 14:10:39 -0800 (PST) (envelope-from baerm@mikesoffice.com) Received: from localhost.localdomain (unknown [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id DCC12D015; Tue, 11 Jan 2005 14:10:14 -0800 (PST) Received: (from baerm@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j0BMA03j005297; Tue, 11 Jan 2005 14:10:00 -0800 X-Authentication-Warning: localhost.localdomain: baerm set sender to baerm@mikesoffice.com using -f To: Harrie Hazewinkel Cc: ipsec-policy@vpnc.org, Bert Wijnen Subject: Re: mib-doctor review of draft-ietf-ipsp-spd-mib From: Michael Baer X-Face: "*g#dUT3;8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: (Harrie Hazewinkel's message of "Tue, 30 Nov 2004 10:13:22 +0100") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) XEmacs/21.4 (Rational FORTRAN, powerpc-unknown-linux) References: <15889186-42B0-11D9-A818-0003934A5A7E@lisanza.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Harrie, Responses are in-line below, >>>>> "HH" == Harrie Hazewinkel writes: HH> Hi all, HH> On Berts request I have done a review of the HH> draft-ietf-ipsp-spd-mib-01.txt. Hereby my comments. (I am HH> subscribe to this list so I do not need an explicit CC). HH> - General, it may be subjective, but I do not like the use HH> of 'we' and 'us' in an RFC. Therefore, I suggest, for HH> example change "we should do" into "one should do". Changed, I rephrased sentences to not use 'we' except for the text in the example which I left. HH> - There are also parts of this MIB which use similar ideas HH> as the HH> packet filtering in the DIFF-SERV MIB. Maybe it is good to HH> make a check wheter that can be used. I believe that at HH> least some terms can be used from that MIB. For instance, HH> incoming -> ingress. Actually, also the draft itself speaks HH> sometimes of inbound and sometimes of incoming (in HH> particular the FORMAL MIB part). incoming|inbound|outgoing|outbound replaced by ingress and egress respectively in the text. HH> - Beyond that I believe it would be a good thing first to HH> clean up the HH> usage of the language. Sometimes, many object descriptions HH> can be made way more precise. HH> - Some comments on the objects, need to be repeated for HH> other HH> simila objects also. These are not explicitly added. HH> - What is the rational of defining a filter and a subfilter? HH> Is the subfilter not just another filter. Yes it is basically just another filter. The sub filter table is used by the compound filter table to create a set of filters which can be used as a single filter. The tables that use filters such as the ruleDefinitionTable can in this way point to a single filter or to a set of filters via the compound filter table. HH> - I beleive it may help a reader/implementor a lot if the HH> logical structure is explained at front of the MIB module. HH> This descrription is currently brief by the size/complexity/ HH> relations of the tables in the MIB module. HH> (more detailed comments below) HH> regards, Harrie >> Abstract >> >> >> This document defines a SMIv2 Management Information Base >> (MIB) module for configuring the security policy database of >> a device implementing the IPSec protocol. The policy-based >> packet filtering and the corresponding execution of actions >> is of a more general nature than for IPsec configuration >> only, such as for configuration of a firewall. This MIB >> module is designed with future extensibility in mind. It is >> thus possible to externally add other packet filters and >> actions to the policy-based packet filtering system defined >> in this document. HH> I am not sure of the usefulnes of 'future extensibility' HH> here. I would also indicate that it is therefore possible to HH> extends with enterprises specific managed objects. I rephrased the sentence and dropped 'future'. Enterprise filters and actions additions are explicitly mentioned. New ending: This MIB module is designed to be extensible. It is thus possible to externally add other enterprise or standards based packet filters and actions to the policy-based packet filtering system defined in this document. >> 1. Introduction [snip] It is possible to add other packet >> transforming actions to this MIB module if those actions >> needed to be performed conditionally on filtered traffic. HH> The last part of the sentence sounds odd. Rephrased and also changed 'filtered' to 'network'. New Text: It is possible to extend this MIB module and add other packet transforming actions that are performed conditionally on network traffic. >> Companion documents [RFCXXXX], [RFCYYYY] document actions >> which are specific to IPsec and IKE. No IPsec or IKE >> specific actions are defined within this document. HH> Add note that RFCXXXX and RFCYYYY must be replaced by the HH> RFC-editor. Note added. >> 3. Relationship to the DMTF Policy Model >> >> >> The Distributed Management Task Force (DMTF) has created an >> object oriented model of IPsec policy information known as >> the IPsec Policy Model White Paper [IPPMWP]. The contents of >> this document are also reflected in the "IPsec Configuration >> Policy Model" (IPCP) [RFC3585]. HH> Is it not opposite? The "IPsec Configuration Policy Model" HH> is also reflected in this document. >> This MIB module is a task specific derivation of the IPCP for >> use with SNMPv3. HH> But how does the MIB relate to the previous documents? Ah, It's suppose to mean that the IPCP reflects the DMTF's Model (i.e. the original design is the DMTF's model) and that the SPD-MIB is an instantiation of the IPCP for use with SNMPv3. I rephrased this paragraph to make it clearer (hopefully). New text: The Distributed Management Task Force (DMTF) has created an object oriented model of IPsec policy information known as the IPsec Policy Model White Paper [IPPMWP]. The "IPsec Configuration Policy Model" (IPCP) [RFC3585] is based in large part on the DMTF's IPsec policy model. The IPCP document describes a model for configuring IPsec. This MIB module is a task specific derivation (i.e. an SMIv2 instantiation) of the IPCP's IPsec configuration model for use with SNMPv3. >> o Policies, Groups, Conditions, and some levels of Action are >> generically named. That is we dropped prefixes like "SA", or HH> 'we dropped' -> 'this document drops' What is 'SA'? Rephrased with first person plural dropped. SA is an IPsec acronym for Security Association. I added the acronym's expansion to the text. changed to, '...IPsec specific prefixes like "SA" (Security Association)...' >> "ipsec". This is because we feel that packet classification >> and matching of conditions to actions is more general than >> IPsec and could possibly be reused by other packet >> transforming actions which need to conditionally act on >> packets matching filters. HH> If this are general packet filters, why not using diff-serv HH> packet filters. It can be used somewhat generally, but it is specific to the IPSP WG's IPsec Policy Model (and the DMTF's model that is based on). >> o Filters are implemented in a more generic and scalable >> manner, >> rather than enforcing the condition/filtering pairing and >> their restrictions upon the user. The MIB module offers a >> compound filter object to provide for greater flexibility >> when creating complex filters. HH> Implementations hints are fine, but is it really that this HH> document implement things in a 'more generic and scalable HH> manner'. I guess not, since the RFC does not specify HH> implementation specific things and there contradicts. The introductory text for this item was "The high-level areas where this MIB module diverges from the IPCP model are:". That is, we are saying this MIB model is more generic and scalable than the IPCP model. rewritten to be more explicit: Filters are implemented in a more generic and scalable manner, rather than enforcing the condition/filtering pairing of the IPCP and its restrictions upon the user. This MIB module offers a compound filter object to provide for greater flexibility than the IPCP when creating complex filters. >> 4. MIB Module Overview >> >> >> The MIB module is modularized into several different parts: >> rules, filters, and actions. HH> Start new paragraph as you do for the other 'parts'. done >> The rules section connects endpoints and groups of rules >> together. HH> The rules section does not do anything. Maybe the objects HH> defined in the section. It is not really clear what a 'rule' HH> is. HH> The rules section provides endpoint relationships and HH> grouping of the 'rules'. rephrased to: The rules section provides the data structure needed to represent the relationship between endpoints and groupings of rules. >> This is partially made up of the ipspEndpointToGroupTable, >> ipspGroupContentsTable, and the ipspRuleDefinitionTable. HH> Why partially? In that case this MIB is incomplete. It is a partial list because the writer (in this case, me) was trying to describe the general idea of how the MIB has been designed and not an exact listing of all the tables within the rules section. Also, if I remember correctly, when this was written there was still some flux in the MIB. In any case, I changed it to a complete list for this paragraph and the next. I also fixed the table prefixes (ipsp -> spd) which had changed in the MIB and were incorrect here. >> Each row of the ipspRuleDefinitionTable connects a filter(s) >> with an action(s). It is structured to allow for reuse >> through the future creation of extension tables that provide >> additional filters and/or actions. In fact, the companion >> documents to this one do just that to define IPsec and IKE >> specific actions to be used within this SPD configuration >> MIB. >> >> >> The filter section of the MIB module is composed of all the >> different HH> 'of all the' -> ' of the' done. >> types of filters in the Policy Model. It is partially made >> up of the HH> Again 'partially'... changed. >> trueFilter, ipspCompoundFilterTable, ipspIpHeaderFilterTable, >> ipspIpOffsetFilterTable, ipspTimeFilterTable, and the >> ipspIpsoHeaderFilterTable. >> >> >> The action section of the MIB module contains different >> action types HH> 'contains different' -> 'contains the different' hmm, no that isn't the intention of the text. Obviously, the original text is not clear. I rewrote it to: The action section of this MIB module contains only the simple static actions required for the firewall processing that an IPsec SPD implementation requires (e.g. accept, drop, log, ...). The companion documents to this document define the complex actions necessary for IPsec and IKE negotiations. >> from the Policy Model. This document contains only the basic >> actions needed for firewall processing (accept, drop, log, >> ...) that an SPD implementation will need. The companion >> documents define the IPsec and IKE specific actions. >> >> >> 4.1 Usage Tutorial >> >> >> In order to make use of the tables contained in this >> document, a general understanding of firewall processing must >> be first understood. The processing of the security policy >> database involves applying a set of firewall rules to an >> interface on a device. The given set of rules to apply to >> any given interface is defined within the >> ipspEndpointToGroupTable table. This table maps a given >> interface to a group of rules. The interface itself with in >> this table is specified using its assigned address. There is >> also one group of rules per direction (inbound and outbound). HH> This sounds more like introduction. >> >> >> 4.1.1 Notational conventions >> >> >> Notes about the following example operations: >> >> 1. All of the example operations in the following section >> make use >> of default values for all columns not listed. The operations >> and close are the minimal SNMP Varbinds that must be sent. HH> 'operations and close' do sound odd here. Maybe it is they HH> are eplained later, but a read (me) is confused. typo, changed to 'operations and column' >> 2. The example operations are formatted such that a row >> (i.e. the >> table's Entry object) is operated on by using the indexes to >> that row and the column values for the that row. It is left >> as an exercise for the reader to turn these into real SNMP >> operations using real OIDs and real varbinds in a SET PDU. >> Example: >> >> >> >> rowEntry(index1 = value1, index2 = value2) = (column1 = >> column_value1, column2 = column_value2) HH> I am not getting this example. Maybe it is better if you HH> once explain how the excercise for the reader must be done. added a more specific example of the usage notation as follows, 2. The example operations are formatted such that a row (i.e. the table's Entry object) is operated on by using the indexes to that row and the column values for the that row. 3. The following is a generic example of the notation used in the following section's examples of this MIB's usage: rowEntry(index1 = value1, index2 = value2) = (column1 = column_value1, column2 = column_value2) 4. The following is a specific example of the notation used in the following section's examples of this MIB's usage. In order to set the address status column to deprecated for a row in the IP-MIB::ipAddressTable with the index values of ipAddressAddrType = ipv4 and ipAddressAddr = = 10.0.0.1. The example notation would look like the following: ipAddressEntry(ipAddressAddrType = 1, -- ipv4 ipAddressAddr = 0x0a000001 ) -- 10.0.0.1 = (ipAddressStatus = 2) -- deprecated >> IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, >> Integer32, mib-2 FROM SNMPv2-SMI HH> Add rfc as comment. (also other imports) done >> spdMIB MODULE-IDENTITY >> DESCRIPTION "This MIB module defines configuration objects >> for managing IPsec Security Policy. HH> Policy -> Policies done >> Copyright (C) The Internet Society (2003). This version of HH> We are in the year 2004. changed to 2005 :) >> this MIB module is part of RFC XXXX, see the RFC itself for >> full legal notices." >> >> >> -- Revision History >> >> >> REVISION "200401070000Z" -- 7 January 2004 DESCRIPTION >> "Initial version, published as RFC xxxx." >> -- RFC-editor assigns xxxx HH> Hmm, you use here also RFC XXXX. That was also a reference. HH> Change one of them. generic temporary references changed to specific temporary references >> >> spdConfigObjects OBJECT IDENTIFIER ::= { spdMIB 1 } >> spdNotificationObjects OBJECT IDENTIFIER ::= { spdMIB 2 } >> spdConformanceObjects OBJECT IDENTIFIER ::= { spdMIB 3 } >> spdActions OBJECT IDENTIFIER ::= { spdMIB 4 } HH> In your introduction text I saw there are three parts. For HH> instance, rules and actions, I see actions here, but no HH> rules. The introduction is an abstracted way of looking at the structure for processing packets that is modeled from the IPsec Configuration Policy Information Model. The borders of the model are not the MIBs themselves. In the model, there are rules, filters, and actions. The IPSEC-SPD-MIB includes rules, filters and some actions (i.e. simple static actions) from that conceptual view. The more specific configuration objects for the IPSEC and IKE negotiation Actions are then defined within the IPSEC-IPSECACTION-MIB and IPSEC-IKEACTION-MIB respectively. >> -- Note: the following subassignments have been used in other >> MIBs: >> -- IPSEC-IPSECACTION-MIB: >> -- ipsaMIB MODULE-IDENTITY ::= { spdActions 1 } >> -- IPSEC-IKEACTION-MIB: >> -- ipiaMIB MODULE-IDENTITY ::= { spdActions 2 } HH> Why do you not import them? The values are not used within the IPSEC-SPD-MIB. The comment is just here for a reader's informational purposes >> SpdBooleanOperator ::= TEXTUAL-CONVENTION STATUS current >> DESCRIPTION "The SpdBooleanOperator operator is used to >> specify whether sub-components in a decision making process >> are ANDed or ORed together to decide if the resulting >> expression is true or false." SYNTAX INTEGER { or(1), and(2) >> } HH> How about XOR and NOT/negate? Or not possible to use? This type is directly created from the IPsec Policy Model as defined. That is, the IPCP model just has the AND and OR values. With negation, however, there is also the ability to create NAND and NOR logic as well as the ability use the same filter set for both AND and NAND in different rules. >> SpdIPPacketLogging ::= TEXTUAL-CONVENTION STATUS current >> DESCRIPTION "SpdIPPacketLogging specifies whether or not an >> audit message should be logged when a packet is passed >> through an SA. HH> It does not really indicate whether logging i must be done, HH> but more precise how many bytes of the message must be HH> logged. I guess, it would be better to express that. It does indicate whether logging should be done (e.g., a value of -1 indicates no logging, a value >= 0 indicates logging), but I changed the initial DESCRIPTION sentence to make it more explicit, SpdIPPacketLogging specifies whether or not an audit message should be logged when a packet is passed through a Security Association (SA) and if some of that packet should be included in the log event. HH> Beyond that what is an SA?? An SA is a Security Association, a commonly used acronyms in the IPsec doc's. I expanded it (de-acronymed it?) in the DESCRIPTION above. >> A value of '-1' indicates no logging. A value of '0' or >> greater indicates that logging should be done and how many >> bytes of the beginning of the packet to place in the >> log. Values greater than the size of the packet being >> processed indicate that the entire packet should be sent. >> >> >> Examples: '-1' no logging '0' log but do not include any of >> the packet in the log '20' log and include the first 20 bytes >> of the packet in the log." HH> The examples roughly duplicate the text before and do not HH> added much. >> spdIncomingPolicyGroupName OBJECT-TYPE SYNTAX SnmpAdminString >> (SIZE(0..32)) MAX-ACCESS read-write STATUS current >> DESCRIPTION "This object indicates the policy group >> containing the global system policy that is to be applied on >> incoming packets (I.E., arriving at a interface) when a given >> endpoint does not contain a policy definition in the >> spdEndpointToGroupTable. Its value can be used as an index >> into the spdGroupContentsTable to retrieve a list of >> policies. A zero length string indicates no system wide >> policy exits and the default policy of 'accept' should be >> executed for incoming packets until one is imposed by either >> this object or by the endpoint processing a given packet." >> ::= { spdLocalConfigObjects 1 } >> >> spdOutgoingPolicyGroupName OBJECT-TYPE SYNTAX SnmpAdminString >> (SIZE(0..32)) MAX-ACCESS read-write STATUS current >> DESCRIPTION "This object indicates the policy group >> containing the global system policy that is to be applied on >> outgoing packets (I.E., leaving an interface) when a given >> endpoint does not contain a policy definition in the >> spdEndpointToGroupTable. Its value can be used as an index >> into the spdGroupContentsTable to retrieve a list of >> policies. A zero length string indicates no system wide >> policy exits and the default policy of 'accept' should be HH> I beleive that the description is close to the InComing, but HH> for outgoing packets, I do not believe you could use HH> 'accept'. Agreed, I changed this to 'drop' for both outgoing and incoming policyGroupNames (which better matches the IPsec documents as well). >> executed for outgoing packets until one is imposed by either >> this object or by the endpoint processing a given packet." >> ::= { spdLocalConfigObjects 2 } >> >> >> >> >> spdEndpointToGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF >> SpdEndpointToGroupEntry MAX-ACCESS not-accessible STATUS >> current DESCRIPTION "This table is used to map policy >> (groupings) onto an endpoint where traffic is to pass by. >> Any policy group assigned to an endpoint is then used to >> control access to the traffic passing by it. >> >> >> If an endpoint has been configured with a policy group and no >> contained rule matches the incoming packet, the default >> action in this case shall be to drop the packet. >> >> >> If no policy group has been assigned to an endpoint, then the >> policy group specified by spdSystemPolicyGroupName should be >> used for the endpoint." ::= { spdConfigObjects 2 } >> >> >> spdEndpointToGroupEntry OBJECT-TYPE SYNTAX >> SpdEndpointToGroupEntry MAX-ACCESS not-accessible STATUS >> current DESCRIPTION "A mapping assigning a policy group to an >> endpoint." INDEX { spdEndGroupIdentType, spdEndGroupAddress >> } HH> Why is the spdEndGroupDirection not part of the index? It HH> looks to me you make a distinction and thus need to be HH> reflected in making configurations also. Yep, it should be part of the index, fixed. >> ::= { spdEndpointToGroupTable 1 } >> >> spdEndGroupDirection OBJECT-TYPE SYNTAX INTEGER { >> incoming(1), outgoing(2) } MAX-ACCESS not-accessible STATUS >> current DESCRIPTION "The direction of the packet crossing the >> interface. As packets arrive or leave an interface, the >> appropriate policy is applied according to the direction it >> is traveling: into or out of the device." HH> The text does like to me partial repeating itself. changed to: This object indicates which direction of packets crossing the interface should be associated with which spdEndGroupName object. Ingress packets, or packets into the device match when this value is inbound(1). Egress packets or packets out of the device match when this value is outbound(2). >> ::= { spdEndpointToGroupEntry 1 } >> >> >> spdEndGroupIdentType OBJECT-TYPE SYNTAX InetAddressType >> MAX-ACCESS not-accessible STATUS current DESCRIPTION "The >> Internet Protocol version of the address associated with a >> given endpoint. All addresses are represented as an array of >> octets in network byte order. When combined with the >> spdEndGroupAddress these objects can be used to uniquely >> identify an endpoint that a set of policy groups should be >> applied to. Devices supporting IPv4 MUST support the ipv4 >> value, and devices supporting IPv6 MUST support the ipv6 >> value. >> >> >> Values of unknown, ipv4z, ipv6z and dns are not legal values >> for this object." ::= { spdEndpointToGroupEntry 2 } >> >> >> spdEndGroupAddress OBJECT-TYPE SYNTAX InetAddress (SIZE >> (4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION >> "The address of a given endpoint, the format of which is >> specified by the spdEndGroupIdentType object." ::= { >> spdEndpointToGroupEntry 3 } >> >> >> >> spdEndGroupName OBJECT-TYPE SYNTAX SnmpAdminString >> (SIZE(1..32)) MAX-ACCESS read-create STATUS current >> DESCRIPTION "The policy group name to apply to this endpoint. >> The value of the spdEndGroupName object should then be used >> as an index into the spdGroupContentsTable to come up with a >> list of rules that MUST be applied to this endpoint." HH> This text looks to me a duplicating. If the object has a HH> value I would indeed think it must be used. But how can you HH> make sure that these are used in the spdGroupContentsTable. Well it is how this object is supposed to be used according to the MIB design. But, if the referenced row does not exist, the default action when the endpoint has been configured and nothing matches a packet is to drop the packet (this is in the DESCRIPTION of the psdEndpointToGroupTable). In other words, for completely un-configured machines the default is spdIncomoing/OutgoingPolicyGroupName (which, from above, use to be 'accept' but is now 'drop'). For machines (mis)configured to have a spdEndpointToGroupTable entry for an endpoint but no matching spdGroupContentsTable entry exists, the default is to drop the packet. HH> While thinkin of it, why not using the index of this table HH> in the spdGroupTable? Looks easier to me. The advantages to the current set up are mostly flexibility and scalability. A group can be made up of multiple subgroups with the current method. Also, any of these groups can be applied to different endpoints. For example, for a rule of 'only accepting html traffic' that is then applied to three different endpoints, only one group would have to be created in the spdGroupContentsTable and then all the endpoints could point to it from the spdEndpointToGroupTable. A complex set of rules forming a group or subgroup could also be created and applied to multiple endpoints this way without duplicating the rows making up the group. >> ::= { spdEndpointToGroupEntry 4 } >> This object may not be set to active until one or more active >> rows exist within the spdGroupContentsTable for the group >> referenced by the spdEndGroupName object." ::= { >> spdEndpointToGroupEntry 7 } HH> What happens when you do set it active and those rows do not HH> exist. It should respond with an inconsistentValue error. But I made this more explicit: This object is considered 'notReady' and may not be set to active until one or more active rows exist within the spdGroupContentsTable for the group referenced by the spdEndGroupName object." >> spdGroupContentsTable OBJECT-TYPE SYNTAX SEQUENCE OF >> SpdGroupContentsEntry MAX-ACCESS not-accessible STATUS >> current DESCRIPTION "This table contains a list of rules >> and/or subgroups contained within a given policy group. HH> Is this table used for two purposes? Yes and no, this table is recursive and the spdGroupContComponentName can refer to a rule or to another entry in this table. That is, groups can be made up of rules and subgroups (a subgroup is otherwise identical to a group). So the table is used for the purpose of creating groups, but a group can be made up of rules and/or other groups. >> The entries are sorted by the spdGroupContPriority object and >> MUST be executed in order according to this value, starting >> with the lowest value. Once a group item has been processed, >> the processor MUST stop processing this packet if an action >> was executed as a result of the processing of a given group. >> Iterating into the next policy group item by finding the next >> largest spdGroupContPriority object shall only be done if no >> actions were run when processing the last item for a given >> packet." ::= { spdConfigObjects 3 } >> >> >> spdGroupContentsEntry OBJECT-TYPE SYNTAX >> SpdGroupContentsEntry MAX-ACCESS not-accessible STATUS >> current DESCRIPTION "Defines a given sub-component within a >> policy group." HH> The table does contain a list of rules and/or subgroups, but HH> the entries do consist of sub-components. On top of that a HH> sub-component is not defined either. a sub-component is either a rule or a another group as referenced by spdGroupContComponentName depending on the value of sdpgroupContComponentType. I changed the above DESCRIPTION to: "Defines a given sub-component within a policy group. A sub-component is either a rule or another group as indicated by spdGroupContCompontentType and referenced by spdGroupContCompontentName." >> INDEX { spdGroupContName, spdGroupContPriority } ::= { >> spdGroupContentsTable 1 } >> spdGroupContPriority OBJECT-TYPE SYNTAX Integer32 (0..65535) >> MAX-ACCESS not-accessible STATUS current DESCRIPTION "The >> priority (sequence number) of the sub-component in this >> group." ::= { spdGroupContentsEntry 2 } >> >> >> spdGroupContFilter OBJECT-TYPE SYNTAX VariablePointer HH> Since below the pointer refers to entries in tables. Is a HH> RowPointer not prefered then? It can also point to an object, for example the object spdTrueFilterInstance is a valid value. >> MAX-ACCESS read-create STATUS current DESCRIPTION >> "spdGroupContFilter points to a filter which is evaluated to >> determine whether the sub-component within this group should >> be exercised. HH> What is considered a sub-component? see above for sub-component definition. I change this to be more explicit: "spdGroupContFilter points to a filter which is evaluated to determine whether the spdGroupContComponentName within this row should be exercised. >> >> If this column is set to a VariablePointer value which >> references a non-existent row in an otherwise supported >> table, the inconsistentName exception should be returned. If >> the table or scalar pointed to by the VariablePointer is not >> supported at all, then an inconsistentValue exception should >> be returned." HH> What should the value be if the variable pointed to is HH> destroyed? That shouldn't be allowed. The following additions have been made, to DESCRIPTION clause of spdIpHeadFiltRowStatus, spdIpOffFiltRowStatus, spdTimeFiltRowStatus, spdIpsoHeadFiltRowStatus, If active, this object must remain active if it is referenced by an active row in another table. An attempt to set it to anything other than active while it is referenced by an active row in another table will result in an inconsistentValue error. to spdSubFiltRowStatus's DESCRIPTION If active, this object must remain active unless one of the following two conditions are met. An attempt to set it to anything other than active while the following conditions are not met will result in an inconsistentValue error. The two conditions are: I. No active row in the SpdCompoundFilterTable exists which has a matching spdCompFiltName. II. Or at least one other active row in this table has a matching spdCompFiltName." to spdSubActRowStatus's DESCRIPTION This object can only be set to notInService or destroy if one of following two conditions are met. If a set of 'destroy' is attempted and neither condition is met an inconsistentValue error is returned. The two conditions are: I. No active row in the spdCompoundActionTable exists which has a matching spdCompActName. II. Or at least one other active row in this table has a matching spdCompActName." to the DESCRIPTION clause of ipsaSaPerActRowStatus, ipiaIkeActRowStatus, ipiaIpsecActRowStatus, An attempt to set it to anything other than active while it is referenced by an active row in another table will result in an inconsistentValue error. >> DEFVAL { spdTrueFilterInstance } HH> Why do you not use a zeroDotZero? I'm not sure what's meant here. But we wanted this value to default to true because we believe this will be used more often than any single other filter at this location. >> ::= { spdGroupContentsEntry 3 } >> >> >> spdGroupContComponentType OBJECT-TYPE SYNTAX INTEGER { >> reserved(0), group(1), rule(2) } MAX-ACCESS read-create >> STATUS current DESCRIPTION "Indicates whether the >> spdGroupContComponentName object is the name of another group >> defined within the spdGroupContentsTable or is the name of a >> rule defined within the spdRuleDefinitionTable." HH> What do the values mean here? I believe group and rule are HH> ok, but reserved? Hmm, we were thinking it was standard way of protecting from misuse of 0 as value in SMIv2. But I could only find one other MIB that did this so the reserver(0) values have been removed. >> DEFVAL { rule } ::= { spdGroupContentsEntry 4 } >> >> >> spdGroupContComponentName OBJECT-TYPE SYNTAX SnmpAdminString >> (SIZE(1..32)) HH> I notice a lot of times that this indicates a group or rule HH> name. Why not making a single TC providing the semantics HH> for such a name. Mainly because the TC SnmpAdminString already exists, is commonly used, and provided what we wanted. >> MAX-ACCESS read-create STATUS current DESCRIPTION "The name >> of the policy rule or subgroup contained within this group, >> as indicated by the spdGroupContComponentType object." ::= { >> spdGroupContentsEntry 5 } >> spdRuleDefDescription OBJECT-TYPE SYNTAX SnmpAdminString >> MAX-ACCESS read-create STATUS current DESCRIPTION "A user >> definable string. HH> 'definable' -> 'defined' changed (as mentioned above, I also deleted unnecessary pronoun 'your' from following sentence). >> spdRuleDefFilter OBJECT-TYPE HH> DEF-VAL?? It looks to me a similar object as before. It is similar, but the previous filter pointer was for the special case of filtering before processing a group whereas this is the filter associated to an action via this rule. That case had a default value that will often be used. In this case, there was no default value that made sense. >> ::= { spdRuleDefinitionEntry 3 } >> >> >> spdRuleDefFilterNegated OBJECT-TYPE SYNTAX TruthValue >> MAX-ACCESS read-create STATUS current DESCRIPTION >> "spdRuleDefFilterNegated specifies whether the filter >> referenced by the spdRuleDefFilter object should be negated >> or not." DEFVAL { false } HH> What is the rational for the negation, is not better to HH> added the negated rule instead of this mechanism? This mechanism allows for a negated rule. A row in this table is a 'rule'. There is also negation at the compound filter level. Both of these locations derive from the IPCP model. >> ::= { spdRuleDefinitionEntry 4 } >> >> >> spdRuleDefAction OBJECT-TYPE HH> DEFVAL? No default value makes sense in this case. >> spdCompFiltDescription OBJECT-TYPE SYNTAX SnmpAdminString >> MAX-ACCESS read-create STATUS current DESCRIPTION "A user >> definable string. You may use this field for your >> administrative tracking purposes." DEFVAL { ''H } HH> Before this was defined as "". changed to "". >> >> spdTrueFilter OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS >> read-only STATUS current DESCRIPTION "This scalar indicates a >> (automatic) true result for a filter. I.e. this is a filter >> that is always true, useful for adding as a default filter >> for a default action or a set of actions." ::= { >> spdStaticFilters 1 } HH> What does this add in the boolean logic? It allows a user to have an action automatically run. >> >> >> spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 >> } >> >> >> -- >> -- Policy IPHeader filter definition table >> -- >> >> >> spdIpHeaderFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF >> SpdIpHeaderFilterEntry MAX-ACCESS not-accessible STATUS >> current DESCRIPTION "This table contains a list of filter >> definitions to be used within the spdRuleDefinitionTable or >> the spdSubfilterTable table." ::= { spdConfigObjects 8 } HH> I believe this is similar as defined in the DIFF-SERV-MIB. HH> Would it not be better to use those filters. For instance, HH> also the IPCDN WG could use the same filters for traffic HH> filtering. They are very similar. The main difference is that spdIpHeaderFilterTable fits into the SPD design of referencing the filters by a name (octet string) as opposed to the diffServMultiFieldClfrTable's integer index. That said, if the community prefers the usage of the diffServMultiFieldClfrTable and the loss of the text references, we could switch to using the DIFF-SERV-MIB's table. >> spdTimeFiltTimeOfDayMaskStart OBJECT-TYPE SYNTAX DateAndTime >> MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates >> the starting time of day for which this filter evaluates to >> true. The date portions of the DateAndTime TC are ignored >> for purposes of evaluating this mask and only the time >> specific portions are used." DEFVAL { >> '00000000000000002b0000'H } ::= { spdTimeFilterEntry 7 } HH> I beleive it would be better to make a new Time TC. You add HH> more semantics to a value that you want. DateAndTime is a commonly used TC. We could make a specific TC, but it would be an entire TC that was specific to only these two (i.e. mask start and stop) inter-related values in one table in one MIB. >> spdTimeFiltTimeOfDayMaskEnd OBJECT-TYPE SYNTAX DateAndTime >> MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates >> the ending time of day for which this filter evaluates to >> true. The date portions of the DateAndTime TC are ignored >> for purposes of evaluating this mask and only the time >> specific portions are used. If this starting and ending time >> values indicated by the spdTimeFiltTimeOfDayMaskStart and >> spdTimeFiltTimeOfDayMaskEnd objects are equal, the filter is >> expected to be evaluated over the entire 24 hour period." >> DEFVAL { '00000000000000002b0000'H } ::= { spdTimeFilterEntry >> 8 } HH> I would earlier follow a schema as in RFC 2445 is used. HH> Mostly a full day starts at, 00:00:00 and ends at 23:59:00 One of the main uses for the filter is to be able to create a way to filter out parts of a day. These are not defining a 'day' but are only supposed to be a way to filter a range of hours. For Example, only allow html traffic Monday through Friday from 9 am to 5 pm. The start would be value would be set to 9 am the end value to 5 pm (and the day of week BITS value would have the first 5 bits set). I changed the spdTimeFiltTimeOfDayMaskEnd to spdTimeFiltStopTimeOfDayMask and the spdTimeFiltTimeOfDayMaskStart to spdTimeFiltStartTimeOfDayMask to make it clearer. >> spdIPInterfaceType OBJECT-TYPE SYNTAX InetAddressType >> MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION >> "Contains the interface type for the interface that the HH> The value should represent an interface type, but you use an HH> InetAddressType as syntax. Is this really correct. It is correct, but the name is misleading. They are the (non-accessible) index values from the spdEndpointToGroupTable. I renamed it to spdIPEndpointAddType (and also spdIPInterfaceAddress to spdIPEndpointAddress) here and in the notifications that use it. >> packet which triggered the notification in question is >> passing through." ::= { spdNotificationVariables 2 } >> >> >> spdIPInterfaceAddress OBJECT-TYPE SYNTAX InetAddress >> MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION >> "Contains the interface address for the interface that the >> packet which triggered the notification in question is >> passing through." HH> As with the previous object. Does this have any relationship HH> to the interface MIB. They are related to the spdEndpointToGroupTable's index values for the endpoint's address. Since they are index values and are not accessible in that table, we created notifications objects to include them in a notification. >> ::= { spdNotificationVariables 3 } >> >> >> spdIPSourceType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS >> accessible-for-notify STATUS current DESCRIPTION "Contains >> the source address type of the packet which triggered the >> notification in question." HH> 'in question' what does it add. hmm, not much. Removed it here and in other notifications. >> ::= { spdNotificationVariables 4 } >> >> >> spdPacketDirection OBJECT-TYPE SYNTAX INTEGER { inbound(1), >> outbound(2) } MAX-ACCESS accessible-for-notify STATUS current >> DESCRIPTION "Indicates if the packet whic triggered the >> action in questions was inbound our outbound." ::= { >> spdNotificationVariables 8 } HH> From the previous source/destinations i get the feeling the HH> direction HH> is already fixed. Why this object? If everything is configured correctly, the direction should be derivable from the source/destinations. If there is a misconfiguration and the incorrect action is being triggered, this may not be the case (i.e. the difference between what should trigger the action and what did trigger the action.). >> >> >> spdPacketPart OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS >> accessible-for-notify STATUS current DESCRIPTION "Is the >> front part of the packet that triggered this notification. >> The size is determined by the value of 'SpdIPPacketLogging' >> or the size of the packet, whichever is smaller." ::= { >> spdNotificationVariables 9 } HH> The value SpdIPPacketLogging is first of all an HH> TEXTUAL-CONVENTION, secondly the SYNTAX is "Integer32 HH> (-1..65535)" and thus may become 65535 and does not fit in HH> the SNMP packet. How will that be handled? changed to: Is the front part of the packet that triggered this notification. The initial size limit is determined by the smaller of the size indicated by 'SpdIPPacketLogging' and the size of the triggering packet. The final limit is determined by the SNMP packet size when sending the notification. The maximum size that can be included will be the smaller of the initial size given above and the length that will fit in a single SNMP notification packet after the rest of the notification's objects and any other necessary packet data (headers, encoding, etc...) has been included in the packet. >> -- spdRuleFilterCompliance MODULE-COMPLIANCE STATUS current >> DESCRIPTION "The compliance statement for SNMP entities that >> include an IPsec MIB implementation with Endpoint, Rules, and >> filters support." HH> Maybe it is a good idea to provide also a ReadOnly HH> Compliance statement. I can immagine setups/implementations HH> that do not allow configuration via SNMP. (See for HH> intstance, the DIFF-SERV-MIB. We never saw any interest by anyone to support this MIB ReadOnly so we didn't think the work to support it was justifiable. >> MODULE -- This Module MANDATORY-GROUPS { spdEndpointGroup, >> spdGroupContentsGroup, spdRuleDefinitionGroup, >> spdIPHeaderFilterGroup, spdStaticFilterGroup, >> spdStaticActionGroup } >> >> >> GROUP spdIpsecSystemPolicyNameGroup DESCRIPTION "This group >> is mandatory for IPsec Policy implementations which support a >> system policy group name." HH> If mandatory, why not in the MANDATORY-GROUPS? (also others) It is only mandatory for 'implementations which support a system policy group name.' In this way a system could be in compliance with limits. A system may not support system policy groups, but if it does, it's mandatory to support spdIpsecSystemPolicyNameGroup >> OBJECT spdEndGroupRowStatus SYNTAX RowStatus { active(1), >> createAndGo(4), destroy(6) >> } >> DESCRIPTION >> "Support of the values notInService(2), notReady(3), >> and createAndWait(5) is not required." >> >> >> OBJECT spdEndGroupLastChanged MIN-ACCESS not-accessible >> DESCRIPTION "This object not required for compliance." HH> This may be not required for compliance, but it is defined HH> in a MANDATORY-GROUP. I guess you want to change the HH> grouping then. The grouping is logical, but we didn't want to force compliance for lastChanged objects. Our belief was that it would be more confusing to split table object's into multiple groups and instead put them into one group with mentioned exceptions. In looking at this though, the similarly used RowStatus values are redundant. The RowStatus TC already allows this behavior so these have been excised from the MIB. >> >> spdEndpointGroup OBJECT-GROUP OBJECTS { spdEndGroupName, >> spdEndGroupLastChanged, spdEndGroupStorageType, >> spdEndGroupRowStatus >> } >> STATUS current >> DESCRIPTION >> "The IPsec Policy Endpoint Table Group." >> ::= { spdGroups 1 } HH> This counts also for the other descriptions, but it does not HH> add any value. I would suggest a more description text of HH> for instance why/what this group of objects are for. change to (and others similarly): "This group is made up of the objects from the IPsec Policy Endpoint Table." >> >> >> spdActionNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { >> spdActionNotification, spdPacketNotification >> } >> STATUS current >> DESCRIPTION >> "Notifications." HH> This description adds nothing. It is equal as not having it. HH> WHat kind fo notifications are these? changed to: "This group is made up of all the Notifications for this MIB." >> ::= { spdGroups 14 } >> >> >> >> END >> >> >> >> 6. Security Considerations >> >> >> 6.1 Introduction >> >> >> This document defines a MIB module used to configure IPsec >> policy services. Since IPsec provides security services it >> is important that the IPsec configuration data be at least as >> protected as the IPsec provided security service. There are >> two main threats you need to thwart when configuring IPsec >> devices. >> >> >> 1. Malicious Configuration: only the official administrators >> should >> be allowed to configure a device. In other words, >> administrators' identities should be authenticated and their >> access rights checked before they are allowed to do device >> configuration. The support for SET operations to the IPSP >> MIB in a non-secure environment, without proper protection, >> can have a negative effect on the security of the network >> traffic affected by the IPSP MIB. >> >> >> 2. Disclosure of Configuration: Malicious parties should not >> be >> able to read configuration data while the data is in network >> transit. Any knowledge about a device's IPsec policy >> configuration could help an unfriendly party compromise that >> device and/or the network(s) it protects. It is thus >> important to control even GET access to these objects and >> possibly to even encrypt the values of these objects when >> sending them over the network via SNMP. >> >> >> SNMP versions prior to SNMPv3 did not include adequate >> security. Even if the network itself is secure (for example >> by using IPsec), even then, there is no control as to who on >> the secure network is allowed to access and GET/SET >> (read/change/create/delete) the objects in this MIB module. >> >> >> It is RECOMMENDED that implementers consider the security >> features as provided by the SNMPv3 framework (see [RFC3410], >> section 8), including full support for the SNMPv3 >> cryptographic mechanisms (for authentication and privacy). >> >> >> Further, deployment of SNMP versions prior to SNMPv3 is NOT >> RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and >> to enable cryptographic security. It is then a >> customer/operator responsibility to ensure that the SNMP >> entity giving access to an instance of this MIB module, is >> properly configured to give access to the objects only to >> those principals (users) that have legitimate rights to >> indeed GET or SET (change/create/delete) them. >> >> >> Therefore, when configuring data in the IPSEC-SPD-MIB, you >> SHOULD use SNMP version 3. The rest of this discussion >> assumes the use of SNMPv3. This is a real strength, because >> it allows administrators the ability to load new IPsec >> configuration on a device and keep the conversation private >> and authenticated under the protection of SNMPv3 before any >> IPsec protections are available. Once initial establishment >> of IPsec configuration on a device has been achieved, it >> would be possible to set up IPsec SAs to then also provide >> security and integrity services to the configuration >> conversation. This may seem redundant at first, but will be >> shown to have a use for added privacy protection below. >> >> >> 6.2 Protecting against in-authentic access >> >> >> The current SNMPv3 User Security Model provides for key based >> user authentication. Typically, keys are derived from >> passwords (but are not required to be), and the keys are then >> used in HMAC algorithms (currently MD5 and SHA-1 HMACs are >> defined) to authenticate all SNMP data. Each SNMP device >> keeps a (configured) list of users and keys. Under SNMPv3 >> user keys may be updated as often as an administrator cares >> to have users enter new passwords. But Perfect Forward >> Secrecy for user keys is not yet provided by standards track >> documents, although RFC2786 defines an experimental method of >> doing so. >> >> >> 6.3 Protecting against involuntary disclosure >> >> >> While sending IPsec configuration data to a PEP, there are a >> few critical parameters which MUST NOT be observed by third >> parties. HH> It would be wise to spell those objects out. added: Specifically, except for public keys, keying information MUST NOT be allowed to be observed by third parties. >> These include IKE Pre-Shared Keys and possibly the private >> key of a public/private key pair for use in a PKI. Were >> either of those parameters to be known to a third party, they >> could then impersonate your device to other IKE peers. Aside >> from those critical parameters, policy administrators have an >> interest in not divulging any of their policy configuration. >> Any knowledge about a device's configuration could help an >> unfriendly party compromise that device. SNMPv3 offers >> privacy security services, but at the time this document was >> written, the only standardized encryption algorithm supported >> by SNMPv3 is the DES encryption algorithm. Support for other >> (stronger) cryptographic algorithms is in the works and may >> be done as you read this. Policy administrators SHOULD use a >> privacy security service to configure their IPsec policy >> which is at least as strong as the desired IPsec policy. >> E.G., it is unwise to configure IPsec parameters implementing >> 3DES algorithms while only protecting that conversation with >> single DES. >> >> >> 6.4 Bootstrapping your configuration >> >> Hopefully vendors will not ship new products with a default >> SNMPv3 user/password pair, but it is possible. Most SNMPv3 >> distributions should hopefully require an out-of-band >> initialization over a trusted medium, such as a local console >> connection. HH> I understand the point, but what should a vendor do? added: If a product does install with default user/password information, these values should be changed before connecting to a network. >> 8.1 Normative References >> HH> The normative refences for SNMP based RFC' can be cleaned up HH> I believe in accordance with the new boiler plate. be aware HH> that the MIB modules that are imported still must be HH> references as RFC. >> >> [RFC3585] Jason, J., Rafalow, L. and E. Vyncke, "IPsec >> Configuration Policy Information Model", RFC 3585, August >> 2003. >> >> >> 8.2 Informative References >> >> >> [RFCXXXX] Baer, M., Charlet, R., Hardaker, W., Story, R. and >> C. Wang, "IPsec Security Policy IPsec Action MIB", December >> 2002. >> >> >> [RFCYYYY] Baer, M., Charlet, R., Hardaker, W., Story, R. and >> C. Wang, "IPsec Security Policy IKE Action MIB", December >> 2002. HH> Add note for RFC editor to replace RFCXXX/YYY. Also you use HH> RFC XXXX for the dradft itself. done. (it's in the xml doc) >> >> [IPPMWP] Lortz, V. and L. Rafalow, "IPsec Policy Model White >> Paper", November 2000. >> >> >> >> Authors' Addresses HH> I would put the addresses more compact. No need for filling HH> pages. The spacing is an artifact of the xml2rfc application. -- Michael Baer baerm@mikesoffice.com From owner-ipsec-policy@mail.vpnc.org Thu Jan 13 14:34:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06725 for ; Thu, 13 Jan 2005 14:34:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DJ10bu089721; Thu, 13 Jan 2005 11:01:00 -0800 (PST) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0DJ10iG089720; Thu, 13 Jan 2005 11:01:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from hoemail1.lucent.com ([192.11.226.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0DJ0nCC089681 for ; Thu, 13 Jan 2005 11:00:49 -0800 (PST) (envelope-from bwijnen@lucent.com) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0DJ0kSG000416 for ; Thu, 13 Jan 2005 13:00:47 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 13 Jan 2005 20:00:45 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155062BE8C7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Michael Baer , Harrie Hazewinkel Cc: ipsec-policy@vpnc.org Subject: RE: mib-doctor review of draft-ietf-ipsp-spd-mib Date: Thu, 13 Jan 2005 20:00:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One thing that immediately caught my eye when quickly browsing this response was: > 4. The following is a specific example of the notation used in the > following section's examples of this MIB's usage. In order to > set the address status column to deprecated for a row in the > IP-MIB::ipAddressTable with the index values of ipAddressAddrType > = ipv4 and ipAddressAddr = = 10.0.0.1. The example notation > would look like the following: > > ipAddressEntry(ipAddressAddrType = 1, -- ipv4 > ipAddressAddr = 0x0a000001 ) -- 10.0.0.1 > = (ipAddressStatus = 2) -- deprecated > Pls, when you want to use example IPv4 addresses, stick to and use the ones assigned/reserved for that purpuse as per RFC3330: 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. Addresses within this block should not appear on the public Internet. And if you are going to do a revision (which is what it looks like), then the following may be considered too: IDNITs (as available at: http://ietf.levkowetz.com/tools/idnits/) results looks reasonably OK: -------- $ idnits draft-ietf-ipsp-spd-mib-01.txt idnits 1.58 draft-ietf-ipsp-spd-mib-01.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html : * The document seems to lack an IANA Considerations section. Checking conformance with RFC 3667/3668 boilerplate... the boilerplate looks good. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt : - The page length should not exceed 58 lines per page, but there was 65 longer pages, the longest (page 63) being 70 lines - It seems as if not all pages are separated by form feeds - found 0 form feeds but 65 pages Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. ---- reference checking: --------- !! Missing citation for Normative reference: P062 L040: [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An !! Missing citation for Normative reference: P062 L046: [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, !! Missing citation for Normative reference: P062 L052: [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network !! Missing citation for Normative reference: P062 L057: [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model !! Missing citation for Normative reference: P062 L062: [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based ------------ Bert From owner-ipsec-policy@mail.vpnc.org Wed Jan 19 06:33:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02684 for ; Wed, 19 Jan 2005 06:33:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0JAxjdq004442; Wed, 19 Jan 2005 02:59:45 -0800 (PST) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0JAxj4G004441; Wed, 19 Jan 2005 02:59:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0JAxRVm004304 for ; Wed, 19 Jan 2005 02:59:31 -0800 (PST) (envelope-from bwijnen@lucent.com) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0JAxM08021944 for ; Wed, 19 Jan 2005 04:59:22 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Jan 2005 11:59:21 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550639C2D2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Michael Baer Cc: Harrie Hazewinkel , ipsec-policy@vpnc.org Subject: RE: mib-doctor review of draft-ietf-ipsp-spd-mib Date: Wed, 19 Jan 2005 11:59:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just another nit: REVISION "200401070000Z" -- 7 January 2004 DESCRIPTION "Initial version, published as RFC ZZZZ." -- RFC-editor assigns ZZZZ -- ZZZZ: To be assigned by IANA ::= { mib-2 xxx } ZZZZ (the RFC-number) gets assigned and filled in by RFC-Editor. The xxx (branch under mib-2) gets assigned by IANA. Further, I get from SMICng: W: f(spd.mi2), (71,21) The first revision should match the last update for MODULE-IDENTITY spdMIB W: f(spd.mi2), (197,4) Row "spdEndpointToGroupEntry" has indexing that may create variables with more than 128 sub-ids The DESCIPRION clause of the tableEntry should have a warning for implementations to watch out for more than 128 subids. See the draft-ietf-ops-mib-review-guidelines-03.txt For example: Implementors need to be aware that if the size of spdEndGroupAddress exceeds xxx octets then OIDs of column instances in this table will have more than 128 sub- identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. You need to check how much xxx is, smilint is your friend E: f(spd.mi2), (915,4) Item "spdTrueFilter" must not have items registered below it caused by: spdTrueFilter OBJECT-TYPE SYNTAX Integer32 ... snip .. spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 } Not sure what you are trying to do here W: f(spd.mi2), (2174,20) Item "spdPacketPart" should have SIZE specified W: f(spd.mi2), (112,4) Textual convention "SpdIPPacketLogging" defined but not used *** 1 error and 4 warnings in parsing Bert > -----Original Message----- > From: Michael Baer [mailto:baerm@mikesoffice.com] > Sent: Friday, January 14, 2005 09:43 > To: Wijnen, Bert (Bert) > Cc: Harrie Hazewinkel; ipsec-policy@vpnc.org > Subject: Re: mib-doctor review of draft-ietf-ipsp-spd-mib > > > >>>>> "Bert" == Bert Wijnen writes: > > Bert> One thing that immediately caught my eye when quickly > Bert> browsing this response was: > > The current draft is attached. The comments below should be fixed > in it, but I haven't gone through all of Harries previous comments. > > From owner-ipsec-policy@mail.vpnc.org Fri Jan 21 21:36:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16106 for ; Fri, 21 Jan 2005 21:36:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0M20rqX044025; Fri, 21 Jan 2005 18:00:53 -0800 (PST) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j0M20rMk044024; Fri, 21 Jan 2005 18:00:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from localhost.localdomain (adsl-63-195-146-66.dsl.scrm01.pacbell.net [63.195.146.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0M20gTv044013 for ; Fri, 21 Jan 2005 18:00:46 -0800 (PST) (envelope-from baerm@mikesoffice.com) Received: from localhost.localdomain (unknown [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 11183D016; Fri, 21 Jan 2005 18:00:32 -0800 (PST) Received: (from baerm@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j0M20FDU007885; Fri, 21 Jan 2005 18:00:15 -0800 X-Authentication-Warning: localhost.localdomain: baerm set sender to baerm@mikesoffice.com using -f To: "Wijnen, Bert (Bert)" Cc: Harrie Hazewinkel , ipsec-policy@vpnc.org Subject: Re: mib-doctor review of draft-ietf-ipsp-spd-mib From: Michael Baer References: <7D5D48D2CAA3D84C813F5B154F43B1550639C2D2@nl0006exch001u.nl.lucent.com> X-Face: "*g#dUT3;8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: ("Wijnen, Bert's message of "Wed, 19 Jan 2005 11:59:19 +0100") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) XEmacs/21.4 (Rational FORTRAN, powerpc-unknown-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Bert" == Bert Wijnen writes: Bert> Just another nit: Bert> REVISION "200401070000Z" -- 7 January 2004 Bert> DESCRIPTION "Initial version, published as RFC ZZZZ." Bert> -- RFC-editor assigns ZZZZ Bert> -- ZZZZ: To be assigned by IANA Bert> ::= { mib-2 xxx } Bert> ZZZZ (the RFC-number) gets assigned and filled in by RFC-Editor. Bert> The xxx (branch under mib-2) gets assigned by IANA. oops, search/replace error, I changed the comment back to xxx Bert> Further, I get from SMICng: Bert> W: f(spd.mi2), (71,21) The first revision should match the last Bert> update for MODULE-IDENTITY spdMIB Bert> W: f(spd.mi2), (197,4) Row "spdEndpointToGroupEntry" has indexing Bert> that may create variables with more than 128 sub-ids Bert> The DESCIPRION clause of the tableEntry should have a warning for Bert> implementations to watch out for more than 128 subids. Bert> See the draft-ietf-ops-mib-review-guidelines-03.txt Bert> For example: Bert> Implementors need to be aware that if the size of Bert> spdEndGroupAddress exceeds xxx octets then OIDs of column Bert> instances in this table will have more than 128 sub- Bert> identifiers and cannot be accessed using SNMPv1, SNMPv2c, or Bert> SNMPv3. Bert> You need to check how much xxx is, smilint is your friend Smilint is my friend :). There would be a lot more errors without it. At one point, though, the smilint checks got deleted from our Makefile and there were a large number of missed errors because of it. I was ignoring the warnings in this case, though, as the spdEndGroupAddress is limited to being of type ipv4 or ipv6 (by spdEndGroupAddrType I think), so it should only be 4 or 16 octets and the OID limit isn't hit. But I just added text to the DESCRIPTION clause indicating both the practical lengths currently possible (i.e. 4 and 16 octets) as well as the actual OID sub identifier limits for this variable (115). Bert> E: f(spd.mi2), (915,4) Item "spdTrueFilter" must not have Bert> items registered below it Bert> caused by: Bert> spdTrueFilter OBJECT-TYPE Bert> SYNTAX Integer32 Bert> ... snip .. Bert> spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 } I don't think this is illegal (although I can see why SMICng didn't like it). It as actually copied from the DISMAN-EVEN-MIB: sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 }. The main reason this object was created is that it is used as a defval for a variablePointer typed object. The variablePointer needs to point to an actual instance of an object and not just the definition. Bert> Not sure what you are trying to do here Bert> W: f(spd.mi2), (2174,20) Item "spdPacketPart" should have Bert> SIZE specified How the size limit is reached is discussed in the DESCRIPTION clause (this is only true in the last version I sent out as this description was updated from Harrie's initial comments). Bert> W: f(spd.mi2), (112,4) Textual convention "SpdIPPacketLogging" Bert> defined but not used SpdIPPacketLogging is meant to be used directly by any action MIB's that are used in conjunction with the SPD-MIB. It's also used less directly (i.e. in a non-SMI syntactical fashion) by the spdPacketPart notification object and the spdPacketNotfication notification. A value of this type is actually the initial value used in deciding the SIZE of spdPacketPart object above. Bert> *** 1 error and 4 warnings in parsing Bert> Bert >> -----Original Message----- >> From: Michael Baer [mailto:baerm@mikesoffice.com] >> Sent: Friday, January 14, 2005 09:43 >> To: Wijnen, Bert (Bert) >> Cc: Harrie Hazewinkel; ipsec-policy@vpnc.org >> Subject: Re: mib-doctor review of draft-ietf-ipsp-spd-mib >> >> >> >>>>> "Bert" == Bert Wijnen writes: >> Bert> One thing that immediately caught my eye when quickly Bert> browsing this response was: >> >> The current draft is attached. The comments below should be fixed >> in it, but I haven't gone through all of Harries previous comments. >> >> -- Michael Baer baerm@mikesoffice.com From anglewell@126.com Mon Jan 24 16:06:29 2005 Received: from 126.com ([222.248.82.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25932 for ; Mon, 24 Jan 2005 16:05:43 -0500 (EST) Message-Id: <200501242105.QAA25932@ietf.org> From: =?GB2312?B?s8K3xg==?= Subject: =?GB2312?B?xNqyv9fKwc8tvq3A7dTE?= To: ipsp-archive@ietf.org Content-Type: text/html;charset="GB2312" Reply-To: cathy1980112@126.com Date: Wed, 26 Jan 2005 05:05:40 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 
八百份机密资料分享，仅供会员内部参考

如果不舍得把目光从眼前移开，你就永远发现不了新大陆；

新春新规划，搭建职业晋身阶梯，新年送给朋友和自己最好的礼物；

别人跑得比我快，不是我能力差，是因为别人骑着马，现在我也找到一匹快马了；

 

八百份报告，两千五百个电子文件，可以先从目录中任选三份免费分享；

联系电邮： anglewell@126.com  sammy0327@163.com

联系电话：13001227005、13798310001

（如果这封信打搅了您，请随手删除，烦请告知您的邮箱，以后我们将不再打搅您） 
资料明细：




001 MKS—组织咨询培训手册 




002 MKS—咨询顾问培训手册（四合一） 




003 MKS—中信实业银行私人银行经理工作手册 




004 MKS—中信实业银行贷记卡中心组织架构建设方案 




005 MKS—中粮集团战略咨询报告 




006 MKS－中国企业如何改善绩效管理 




007 MKS—中国联：开拓业务增长的战略 




008 MKS—企业业绩管理基本框架   




009 MKS—中国电信大客户培训战略报告 




010 MKS—中国电信：电信产品与服务市场细分研究报告 




011 MKS—中国JY集团战略咨询项目建议书（03年7月） 




012 MKS—制定制胜的市场营销策略 




013 MKS—政府教育咨询报告 




014 MKS—招商集团发展战略咨询报告 




015 MKS—战略咨询培训手册 




016 MKS—云南电信KPI方案 




017 MKS—赢得人才七法则 




018 MKS—伊拉克战后重建机会研究报告 




019 MKS—一汽大众：通过业务流程再造建立独特的竞争优势 




020 MKS—迅速改善中信银行零售业绩方案 




021 MKS—协助员工拥抱变革 




022 MKS-西南证券人力资源战略咨询报告 




023 MKS—TSH集团战略设计与IPO咨询报告(03年7月) 




024 MKS—天津LG发展战略咨询报告 




025 MKS—思考问题之道 




026 MKS—市场研究方法 




027 MKS—实达项目报告（全套） 




028 MKS—实达建立高绩效的市场营销及销售管理体系咨询报告 




029 MKS—实达公司项目启动报告 




030 MKS—上海国际汽车城发展咨询报告 




031 MKS—上柴制定制胜的公司战略.ppt 




032 MKS—商业银行如何快速改善零售业绩研究报告 




033 MKS—三星电子（中国）竞争对手研究报告（NOKIA） 




034 MKS—软件业如何走出困境 




035 MKS---如何善用组织共用的价值理念 




036 MKS—人力资源最佳典范 




037 MKS—汽车产品开发流程 




038 MKS—企业战略规划模板 




039 MKS-企业并购中的人力资源问题 




040 MKS—平安员工发展咨询报告 




041 MKS—平安人力资源方案集成 




042 MKS—美国国防部作的咨询报告 




043 MKS—科建润滑油业务发展战略咨询报告 




044 MKS—精细运营系统解决方法 




045 MKS－黑龙江庆新油田业绩管理报告 




046 MKS—广电股份全套咨询方案(14个文件) 




047 MKS—改善百威啤酒经营业绩.品牌定位及新产品开发咨询报告 




048 MKS—放松流程管理：流程网络如何发挥专业分工的力量 




049 MKS—第一年咨询顾问培训教材（全套） 




050 MKS—大唐电信战略的制定方法咨询报告 




051 MKS报告—中国进入信用卡时代 




052 MKS—宝钢股份精益生产诊断结果汇报报告 




053 MKS—把握中国资本市场的机遇 




054 MKS—SZ数码业绩管理咨询报告 




055 MKS—SZ数码建立一流的经营业绩管理体系 




056 MKS—SZ数码公司发展战略咨询报告 




057 MKS—PA保险招聘手册 




058 MKS—PA保险员工培训咨询报告 




059 MKS—PA保险信息系统规划咨询报告 




060 MKS—PA保险薪酬改革咨询报告 




061 MKS—PA保险人员配置咨询报告 




062 MKS—PA保险保险未来组织模式报告 




063 MKS—PA保险2002工作计划报告 




064 MKS—NOKIA制胜美国市场报告 




065 MKS—LX事业部战略规划报告 




066 MKS—LX科技业务流程改造报告 




067 MKS—LX集团战略咨询项目建议书 




068 MKS—LX集团三年规划战略 




069 MKS—LX集团2002年服务器网络事业部规划 




070 MKS—LX集团：建立成功的财务管理体系 




071 MKS—KJ集团业务计划与资金预算手册 




072 MKS－KJ集团业绩评估操作手册 




073 MKS—KJ集团信息管理流程咨询报告 




074 MKS－KJ集团新产品开发实施手册 




075 MKS—GS银行深圳分行业绩改善与客户管理咨询报告 




076 MKS—7S模型 




077 远卓咨询—人力资源战略提升管理能力(158P) 




078 远卓—中远公司法人治理结构咨询建议报告 




079 远卓—惠州德赛：各自主产业业务发展的理解 




080 远卓管理顾问—东方通信项目建议书 




081 远卓顾问—珠海九丰集团主要职位说明书 




082 远卓顾问—浙江金融租赁股份有限公司项目建议书 




083 远卓顾问—联合证券总体战略咨询研讨会报告 




084 远卓顾问—湖南亚华乳品集团战略及营销体系构建建议 




085 XHX—中国阳光投资集团组织结构及关键流程报告 




086 XHX—中国房地产行业研究报告 




087 XHX—战略咨询工具模型 




088 XHX—战略咨询方法及实例 




089 XHX—新飞冰箱组织架构咨询方案 




090 XHX—新飞冰箱营销渠道建设咨询报告 




091 XHX-三木集团--绩效考核实务培训 




092 XHX—三木集团：总部所有岗位说明书 




093 XHX—三木集团：岗位评价方法培训 




094 XHX—摩托罗拉市场分销战略基准咨询最终报告 




095 XHX—美的集团竞争对手的集团战略基准比较和竞争咨询项目建议书 




096 XHX—泸州老窖中长期发展战略 




097 XHX—李宁管理咨询项目五个阶段工作汇报报告 




098 XHX—李宁管理咨询项目第一阶段汇报 




099 XHX—嘉陵集团管理与竞争力提升中期报告 




100 XHX—复星集团某子集团战略咨询建议书 




101 XHX—东滩公司组织管理体系设计方案咨询报告 




102 XHX—东滩公司商业房地产发展战略研究报告 




103 XHX—东滩公司发展战略定位综合报告 




104 XHX－电广传媒组织结构设计 




105 XHX—大庆石油发展集团石化贸易业务战略研究报告 




106 XHX—北京李宁KPI指标体系 




107 XHX—北京贝尔绩效考核管理项目建议书 




108 XHX—奥瑞金战略性人力资源管理 




109 XHX—motorola团体直销模式设计项目建议书 




110 XHX—HE成功经验咨询报告（为三星中国总部） 




111 普华咨询—鲁能帆茂物流规划报告 




112 普华永道—+C143中石油财务信息系统设计报告 




113 普华永道—中国建设银行风险管理组织结构及实施方案 




114 普华永道战略管理框架 




115 普华永道—新世界发展上海投资公司操作全案 




116 普华永道—天歌科技集团人力资源咨询报告 




117 普华永道—天歌集团成本管理流程咨询报告 




118 普华永道—四川天歌科技集团业务战略和管理咨询报告（研讨会） 




119 普华永道—四川天歌科技集团成本管理流程咨询报告 




120 普华永道—美的物流规划报告 




121 普华永道—华凌电器企业管理诊断与转形计划 




122 普华永道—裁员管理 




123 普华永道—6SIGMA实施项目建议书 




124 普华永道—京东方组织提升与流程再造 




125 罗兰贝格—咨询工具箱 




126 罗兰贝格—中小型企业战略和管理问题研究报告 




127 罗兰贝格—中土畜总公司战略规划与组织模式咨询报告 




128 罗兰贝格—中国五矿集团发展战略规划 




129 罗兰贝格—中国土蓄总公司战略规划及组织管理咨询报告 




130 罗兰贝格—中国通用技术集团贸易业务发展战略报告 




131 罗兰贝格-中国摩托车行业及摩托车企业发展研究报告 




132 罗兰贝格—中国航空业重组之路 




133 罗兰贝格—整合营销内部培训(下) 




134 罗兰贝格—整合营销内部培训(上) 




135 罗兰贝格—战略分析内容和工具 




136 罗兰贝格—如何在日本市场获得成功？ 




137 罗兰贝格—协信集团定岗定编、核心业务流程和激励体系咨询报告 




138 罗兰贝格—协信集团KPI考核体系 




139 罗兰贝格—为重庆某摩托车科技集团做的战略咨询报告（立一流摩托产业集团） 




140 罗兰贝格—图解消费者 




141 罗兰贝格—通用技术集团战略咨询研讨会报告 




142 罗兰贝格—+C763陕西西北高科技实业公司战略实施报告（1-3） 




143 罗兰贝格—山东移动客户关系管理建议书 




144 罗兰贝格－人力资源管理总框架 




145 罗兰贝格—缺货管理 




146 罗兰贝格---轻纺供应链设计方案 




147 罗兰贝格—汽车行业研究报告（1-2） 




148 罗兰贝格－南航股份中期战略规划报告 




149 罗兰贝格—某公司供应链优化咨询报告 




150 罗兰贝格—某大型企业集团财务解决方案 




151 罗兰贝格—客户忠诚度研究报告 




152 罗兰贝格—客户管理管理咨询方法 




153 罗兰贝格—科龙电器品牌战略和营销组织架构（完整） 




154 罗兰贝格—华润万佳超市咨询方案（1~3） 




155 罗兰贝格—供应链重组培训材料 




156 罗兰贝格—东莞房地产战略审计报告 




157 罗兰贝格—标准项目建议书模板 




158 罗兰贝格—宝钢国际咨询报告（完整版） 




159 罗兰贝格—CH营销咨询报告 




160 罗兰贝格—CH营销系统业绩评估系统 




161 罗兰贝格—CH业务计划与控制体系最终报告 




162 罗兰贝格—CH事业部制建议书 




163 罗兰贝格—CH电池营销组织及管理平台设计方案 




164 科尔尼—中远集团：物流行业及发展趋势研究报告 




165 科尔尼研究成果—行业整合周期曲线 




166 科尔尼研究成果—人才招聘战略 




167 科尔尼研究成果—企业增长组合战略理论框架 




168 科尔尼研究成果—并购的终极状态 




169 科尔尼—屯河水泥采购物流咨询报告 




170 科尔尼—华侨城集团发展战略报告 




171 科尔尼—东风汽车战略规划 




172 科尔尼—德隆天山水泥发展战略建议书 




173 科尔尼—德隆国际控股战略采购方法与流程报告 




174 HJCY—中青旅战略困境研究报告 




175 HJCY—中青旅集团旅游主业战略研究报告 




176 HJCY—中国电信企业文化诊断报告终稿 




177 HJCY-新奥集团组织机构调整方案 




178 HJCY—新奥集团员工诊断报告 




179 HJCY—维维豆奶营销战略报告 




180 HJCY—企业培训系统解决方案 




181 HJCY—奇正制药战略绩效管理报告 




182 HJCY—奇正制药业绩考核咨询报告 




183 HJCY—奇正制药薪酬管理咨询报告 




184 HJCY—奇正藏药咨询方案（全套完整） 




185 HJCY—公司治理结构与集团化管理 




186 HJCY—KPI设计思路与实施实践教材 




187 HJCY_福田资本运营与金融产业发展研究报告 




188 汉普咨询—长沙卷烟BPR&ERP项目—供应链汇报 




189 汉普知识管理文摘集——战略管理 




190 汉普—物流管理培训资料 




191 汉普—唐人神集团IT规划培训式咨询项目建议书 




192 汉普—北汽福田车辆股份有限公司信息化规划建议 




193 汉普—白沙集团管理模式与供应链设计方案 




194 德勤—中国石化财务控制咨询方案 




195 德勤—日本沃尔玛 




196 德勤—证券公司流程再造研究报告 




197 德勤—湘火炬内控制度（1-3） 




198 德勤—石药集团：建议中国一流的以市场为导向的药业营销公司 




199 德勤—企业组织结构和部门职能 




200 德勤—企业评估指标 




201 德勤—平衡积分卡在中国企业的实践应用 




202 德勤—金融服务公司的战略伸缩性（英文） 




203 德勤—激励机制咨询方法 




204 波士顿咨询—某大型集团组织结构于与关键绩效考核指标问题及设计报告 




205 波士顿—品牌培训 




206 波士顿—BCG矩阵 




207 毕马威—正泰集团数字化诊断报告 




208 毕马威研究报告—企业移动商务发展趋势 




209 毕马威—财务分析培训资料 




210 毕马威—北方光电Oracle实施采购业务方案 




211 毕博咨询—上海国际物流中心咨询报告（6.27稿） 




212 毕博咨询—如何给予顾客最佳购物体验 




213 毕博咨询—广东移动未来流程咨询报告 




214 BDZH—中国住宅总公司咨询报告（全套） 




215 BDZH—榆树林油田公司战略发展咨询报告 




216 BDZH—新太科技战略咨询组织结构设计 




217 BDZH—新产品开发管理设计咨询报告 




218 BDZH—为宁波华能作咨询全部12份报告 




219 BDZH—汕头超声电子母子公司管理诊断报告 




220 BDZH—秦皇岛港战略规划-PPT-138页 




221 BDZH—宁波华能成套业务管理设计报告 




222 BDZH—鲁艺房地产开发有限责任公司咨询项目建议书 




223 BDZH——江钻股份人力资源评估及诊断报告 




224 BDZH－江苏牧羊集团战略和组织结构报告 




225 BDZH—湖南统一人力资源体系建设方案 




226 安盛咨询—雅戈尔营销网络咨询建议书 




227 安盛咨询—新天国际集团咨询项目建议书 




228 安利公司—電子商務潮流中多層次傳銷產業之變革 




229 安利的獎金制度 




230 安达信—转变促成的基本方法 




231 安达信—中石化组织结构咨询报告 




232 安达信—战略培训教材 




233 安达信—小天鹅咨询报告（1~4） 




234 安达信—深圳顺电实业内部营运审计项目管理咨询方案 




235 安达信—深圳科技工业园总公司战略实施方案 




236 安达信—企业变革框架(中国重点国企领导人培训教材159P) 




237 安达信—某软件公司的咨询方案 




238 安达信—丽珠集团咨询方案1 




239 安达信—和光物流咨询报告（完全版）PPT,3.16MB  




240 安达信—国泰君安BPR项目文档——全面预算体系介绍 




241 安达信—贵州轮胎股份企业资源计划系统流程分析总结报告 




242 安达信—东方通信项目战略规划（1234） 




243 安达信—北方工业公司企业管理控制系统咨询报告 




244 艾森哲—中国铝业薪酬设计咨询方案 




245 艾福斯给红塔仁恒纸业做的erp整体解决方案 




246 埃森哲—组织设计的指导思想 




247 埃森哲—深圳航空物流区项目建议书 




248 埃森哲—建立世界级的财务和业绩管理能力 




249 埃森哲—家电物流业研讨会报告 




250 埃森哲—工业蓝图 




251 埃森哲—处于变革边缘的中国供应链管理 




252 中远集团（COSCO）综合管理手册 




253 中医药行业市场分析报告（2003） 




254 中小乳品企业致胜策略研究 




255 中外广告妙语全句10000条 




256 中金—最新家电研究报告(20040514)




257 中金报告—金地集团投资升值潜力0




258 中核集团企业财务预算（细化）表格 




259 中海阳光棕榈园广告推广与营销 




260 中海名都第二期项目推广方案(上下) 




261 中国中药行业研究报告 




262 中国制药企业的营销渠道模式与评价 




263 中国远洋运输集团财产清查培训资料(利安达信隆） 




264 中国邮政： 目标市场物流解决方案 




265 中国移动通信公司与中国联合通信公司营销比较分析报告 




266 中国移动内地运营子公司年度绩效考核管理办法 




267 中国医药保健品行业研究报告 




268 中国物流业的发展现状、机遇及政策取向报告 




269 中国网络游戏产业研究报告 




270 中国外贸企业基于供应链的业务再造研究报告 




271 中国乳品行业市场分析报告（2004年2月） 




272 中国汽车用钢市场研究报告2003-05 




273 中国企业赢利之十五种黄金模式 




274 中国葡萄酒行业市场分析报告 




275 中国女性内衣销售渠道研究报告(200304) 




276 中国奶业发展战略研究报告 




277 中国联通品牌战略规划—广东省广告公司 




278 中国空调企业营销渠道模式研究报告 




279 中国家族企业可持续发展与制度变革专题研究报告 




280 中国家具行业报告1 




281 中国化妆品行业研究报告 




282 中国国际工程咨询—中国空空导弹研究院战略转型项目报告 




283 中国电信设备市场研究报告 




284 中国电信“家庭信息终端”市场推广策划全案 




285 中国第一汽车集团四川专用汽车厂发展战略研讨 




286 中国第一份塑料产业发展研究报告2003-10 




287 中国保险产业分析报告 




288 中国安防市场调查报告 




289 中关村文化广场策划报告 




290 中高档酒上海市场运作成功经验研究报告 




291 中电通信手机营销企划全案 




292 中昌集团组织设计方案咨询报告 




293 沃尔玛物流配送体系 




294 沃尔玛全球国际营销中国区域市场推广营销方案书 




295 沃尔玛课程—高绩效谈判与议价 




296 沃尔玛经营管理理念全集 




297 企业综合体质自我分析表 




298 企业资金预算制度 




299 企业资金管理办法 




300 企业治理研究—让公司的战略发挥实效 




301 企业应收帐款管理与催帐实战技巧教材 




302 企业如何才能招聘到优秀人才 




303 企业人事制度汇编 




304 企业集团内部会计控制 




305 企业规章制度大全 




306 企业管理表格大权大全 




307 企业岗位分析与设计 




308 企业福利制度汇编 




309 企业财务内控制度全案 




310 企业财务管理制度全集 




311 企业不同发展阶段及绩效指标设计 




312 某著名咨询机构—某知名企业业务流程优化报告 




313 某著名医药公司培训教材（九个PPT） 




314 某著名家电集团三年发展规划 




315 某著名公司的授权体系 




316 某著名策划机构—上海广电市场推广策略  




317 某知名咨询公司—企业发展战略规划方案 




318 某知名企业时间管理培训材料 




319 某知名企业股票期权激励方案 




320 某知名企业部门职责、岗位设计和人力资源考核办法 




321 某医院人力资源诊断报告 




322 某实业有限公司绩效管理培训教程(老员工培训教程) 




323 某科技有限公司培训制度 




324 某集团公司责权利匹配调查报告




325 某集团公司绩效考核制度 




326 某集团财务预算管理制度2 




327 某钢铁公司销售信息华管理项目建议书 




328 某钢铁公司企业改制建议书 




329 某服装企业业务运作流程图及说明书 




330 某大型企业集团营销诊断报告 




331 某大型集团公司50个岗位岗位说明书 




332 某大型集团KPI手册 




333 某超大型集团整体财务管理制度 




334 摩托罗拉公司—全面生产维护管理体系 




335 麦当劳员工手册 




336 麦当劳训练发展系统 




337 麦当劳管理大全（38个文件） 




338 麦当劳订货物流管理 




339 麦当劳的业务领导 




340 麦当劳的人力资源管理 




341 可口可乐销售技巧培训资料 




342 可口可乐公司员工培训资料 




343 可口可乐EXCEL表格资料大全(财务,物料,采购,销售等) 




344 科龙职位评估系统 




345 科龙营销系统管理手册（15万字） 




346 科龙项目业务流程说明书(总部） 




347 科龙项目业务流程说明书(分公司） 




348 科龙集团大型促销活动策划方案 




349 科龙电器电子商务策划方案 




350 康师傅－职位说明书培训 




351 康师傅新人入职培训教材 




352 康师傅的渠道变革研究报告 




353 康弘集团中成药的销售模式诊断与设计报告 




354 华为营销人员完全培训教材 




355 华为销售人员培训资料(上下） 




356 华为素质模型 




357 华为—千兆企业网解决方案 




358 华为科技园二期总结报告 




359 华为技术有限公司编成开发规范与案例 




360 华为技术—计划体系与工具 




361 华为调研报告 




362 华为SAP解决方案 




363 华润集团投资管理内部文件 




364 华润集团的资本运作及架构重组研究报告 




365 华润超市—目标与绩效管理 




366 北京紫金润广告—三里屯商品市场推广方案 




367 北京紫金润广告—2003年远大空调北京地区品牌传播提案 




368 北京讯达广告—奔驰Axor展示会策划方案 




369 北京现代伊兰特新品上市暨品牌传播策划案 




370 北京万通发展战略项目内部评估报告 




371 北京万通东方策略—双花园项目营销策划报告（送出版） 




372 北京双鹤药业市场营销文件 




373 北京某著名房地产公司制度汇编 




374 北京麦当劳连锁公司员工手册 




375 北京宏业信通公司战略企划方案 




376 北京东润枫景提案 




377 北京北辰集团发展战略报告 




378 北京NOKIA薪资方案 




379 北电技术服务手册 




380 北大江明华博士—营销渠道管理 




381 北辰绿色家园提案 




382 宝铁储运公司战略规划报告(WORD,完整) 




383 宝洁营销体系全套管理文件 




384 宝洁品牌销售团队管理方案  




385 宝洁核心竞争力——供应链管理 




386 宝洁店内形象手册 




387 TCL质量环境职业安全三合一手册 




388 TCL销售公司业务流程和经营管理重点手册 




389 TCL网络营销传播手册（完全版） 




390 TCL内训教材-客户关系管理与客情维护 




391 TCL内部培训教材 




392 TCL集团市场调研报告 




393 TCL电脑店铺管理手册 




394 TCL大区经理管理手册 




395 TCL大区经理管理手册 




396 SZ数码—职位管理与绩效管理体系 




397 SZ数码—杜邦分析法 




398 SZ数码KPI 




399 LX投资－企业发展与人力资源战略 




400 LX手机销售手册 




401 LX企业管理体系 




402 LX客户关系管理解决方案 




403 LX集团员工行为规范 




404 LX集团品牌宣传方略 




405 LX集团会议组织和管理制度 




406 LX集团核心价值观培训ppt 




407 LX集团各类文件模板及表格 




408 LX关于实施ERP的沉痛教训与成功经验报告 




409 LX服务机构奖励办法 




410 LX财务基础知识培训教程 




411 用友—银河证券财务信息系统方案书 




412 用友—伊利集团分销系统项目建议书 




413 用友软件—美的空调信息系统建设方案书 




414 用友软件—NC全面预算与资金管理解决方案 




415 用友集团内部培训资料—谋划变革0 




416 总裁的智慧：中国顶尖企业家演讲录 




417 主基二元考核法——真正的绩效考核 




418 珠江啤酒集团企业形象CF创意表现方案（唐都广告） 




419 重庆伴山名都提案 




420 职业经理人全面素质提升训练系统（MBA经理人教程） 




421 浙南制药股份有限公司发展战略 




422 浙江嘉信医药股份有限公司员工持股可行性研究报告 




423 浙大方圆科技公司职位说明调研报告（69P） 




424 招商银行广州三新活动全套方案策划书 




425 张裕葡萄酿酒股份有限公司营销系统培训计划 




426 曾仕强—中国式管理与人性管理实践 




427 远成集团华东公司战略规划 




428 预算管理培训教材 




429 与家乐福打交道细节如金 




430 赢创置业—丽水湾2003年营销推广整合方案 




431 营销执行标准（153P） 




432 营多干脆面营销企划案 




433 印象干红广告策划及方案 




434 颐和山庄D区高层传播策略 




435 伊利集团岗前培训手册 




436 药品零售市场行业分析 




437 养生堂——阳光计划 




438 眼科用药市场调查报告 




439 兖矿集团—关于建设国际化现代化可持续发展的跨国集团的思考 




440 烟草业市场营销整体解决方案 




441 烟草行业IT培训资料 




442 亚洲开发银行—中国国别战略与规划 




443 亚马逊电子商务模式分析 




444 信产部研究院—中国电信产业的国际化发展战略 




445 新惠普企业价值与战略目标 




446 新产品的上市与推广运作策略解决方案 




447 肖勇政-投资计划书内容及编制方法 




448 小天鹅波尔卡空调营销策划总方案 




449 项目管理专家完全手册 




450 湘火炬一季度 经营分析报告 




451 香雪抗病毒口服液营销报告 




452 香港某著名物业公司甲级写字楼物管全套文件(几十个doc)! 




453 香港隆基（涂料）集团发展战略中期咨询报告 




454 香港4A公司运作流程的運行 




455 现场管理实务 




456 厦门市商业网点布局规划 




457 喜之郎经销商通路精耕细则 




458 锡恩顾问—持续增长模式操作方案 




459 西南证券2004年投资策略报告 




460 西门子公司核心能力字典 




461 西门子的员工手册 




462 西点军校行为准则 




463 物流中心作业系统 




464 武汉万科物业管理方案 




465 武汉金佰利华中地区多点配送方案 




466 未来乘用车消费群体发展预测报告 




467 伟世人力资源—国际职位评估系统 




468 伟世_大庆石油薪酬结构设计方案 




469 微軟—平衡計分卡 




470 微软中国公司成本控制指南 




471 万兆家园-叠彩人家营销策划案例 




472 万科职员手册2004版 




473 万科员工手册 




474 万科四季花城五期策略 




475 团体合作游戏 




476 统一企业内部分析研究评估报告 




477 统一企业的标准化运作 




478 同路传播—万科?17英里提案 




479 通用电气公司的薪金和奖励制度 




480 通用电气的企业文化和管理 




481 通用电气：在集权与分权间谋求均衡结构 




482 天健咨询—中国移动预算管理咨询报告 




483 腾讯QQ香港上市文件全套文件 




484 唐都—EMC品牌传播策略执行方案 




485 太太药业现有业务流程调研报告 




486 太太药业生产流程文档 




487 太极集团销售管理系统建设规划 




488 台湾著名咨询公司研究报告—掌握中國未來十年的大機會 




489 台湾旺旺集团（总部）工作分析培训讲义 




490 台湾“斑尼顿”山东市场企划案 




491 宋新宇_企业经营成功的八大战略 




492 世联地产——XX项目咨询方案完整版 




493 世界银行—中国铁路重组报告 




494 世纪阳光顾问—销售关系技巧讲义 




495 世纪经典大厦营销策划书 




496 胜利油田中胜实业集团企业改制重组咨询报告 




497 神龙标致AQMPP培训资料 




498 深圳家居装饰市场调查分析报告 




499 深圳傲天软件17个经典职位说明书 




500 申银万国—MBO操作方案 




501 上市公司资金结算中心设计方案 




502 上市公司股权转让协议（27页） 




503 上海锦绣江南（一期）策划推广报告 




504 上海国际金融大厦投资规划 




505 商业集团公司全面预算管理方法 




506 商务礼仪大全 




507 陕西经委战略—打造西部制造业基地（终稿） 




508 山东某某医疗科技股份有限公司宣传与推广公共媒体年度计划书 




509 沙宣深层洁净洗发露上市策划方案 




510 三星秘笈2003.08.19 




511 三星电子（中国）员工素质全面提升培训教材 




512 三九集团内部控制制度全集(438P) 




513 软件销售十大策略 




514 软件销售的商业实施 




515 日产汽车现场管理(绝密) 




516 人力资源管理手册 




517 人大张瑞君—全面预算管理解决方案 




518 全球五大著名企业的绩效管理实操 




519 全面预算管理的系统化实施探索——华润集团6S管理体系 




520 全国物流公司名单（共24800家） 




521 全国机械行业最新研究报告(200308) 




522 全国大中型塑料企业详细资料 




523 全国611家乳品企业详细资料 




524 清华同方员工股票期权计划 




525 清华大学博弈论讲义 




526 清产核资基础报表格式(xls 63) 




527 青岛市城市规划文本 




528 强势品牌在中国的精耕之道 




529 平衡计分卡相关经典图例 




530 平安讲师训练课程 




531 南方集团绩效考核培训版 




532 男用化装品市场调查报告 




533 米其林的中国发展战略 




534 蒙牛集团终端管理手册 




535 蒙牛集团《企业文化手册》PPT 86页 




536 美星顺峰机械集团发展战略报告 




537 美世—万通地产薪酬咨询报告 




538 美世—领导力素质开发模型 




539 美世管理咨询—盈利的艺术 




540 美国汽车零部件电子商务应用分析报告 




541 美国公司CEO的激励体系 




542 美孚如何成为一个聚焦战略的公司1 




543 美的集团销售系统财务管理 




544 美的集团人力资源制度（全套） 




545 漫画现场管理 




546 麦肯光明—美的品牌策略 




547 鲁能品牌战略与规划 




548 龙媒传播—科龙传播策略 




549 联通2004平面广告方案（姚明版） 




550 联合利华--销售运作手册 




551 联合利华公司的食品安全管理体系 




552 连锁超市防损工作手册 




553 乐百氏集团事业部改造方案 




554 浪潮通软技术白皮书 




555 蓝色创意—星河湾2003年推广方案 




556 蓝豹摩托上市策划案 




557 兰德决策思维研究报告 




558 跨国饮料公司销售计划 




559 跨国公司人力资源管理资料精选 




560 可控降解塑料产品营销策划方案 




561 壳牌石油IT架构规划与实施经验介绍 




562 凯捷安永报告－建立适应性供应链，获取竞争优势 




563 开思ERP技术白皮书 




564 开发中国农村市场—县(市)电媒介方案 




565 九天企划—宗庆品牌规划案A 




566 精英集团质量管理系统（IT） 




567 经理人如何快速学会看财务报表 




568 经典营销创意案例100个 




569 经典商务礼仪 




570 经典房地产广告语全集 




571 金太阳建材城的咨询诊断提案——访谈分析部分 




572 金牌客户服务管理_美的公司内训教材 




573 金科集团主要业务流程手册 




574 金光集团(亚洲浆纸)薪资福利完全手册 




575 金蝶ERP作业流程——仓库作业流程 




576 金杯通用的供应链规划 




577 接待礼仪(淡如微风) 




578 江苏隆力奇零售终端管理 




579 健力宝营销体系中央计划系统流程 




580 健力宝集团—2003年全新的系统建设规划 




581 价值战略：以客户为中心的战略设计 




582 家乐福金融报告 




583 佳美广告—美林海岸花园2002年品牌策略 




584 加盟连锁店规章制度 




585 技法篇--入职培训资料（LX科技） 




586 激活人力资源的薪酬体系设计 




587 激发员工工作热情的二十种非经济手段 




588 绩效考核—非量化总表 




589 慧聪—万科星园传播策略 




590 慧聪公司内部培训资料—业务、法务、商务礼仪等 




591 惠悦国际—中国移动（香港）公司人力资源管理咨询报告 




592 惠普咨询—广州医药物流改造项目书 




593 惠普战略规划与评审 




594 惠普—康柏企业文化整合方案 




595 惠普管理培训完全手册 




596 惠普公司政府关系成功经验报告 




597 华源集团的资产重组案例 




598 华源“佛龙宝”保健品市场推广方案 




599 华信惠悦—民生银行人力资源规划 




600 华普—HEAvaya项目物流解决方案书 




601 华联综超管理手册（全） 




602 虎门荔林华庭体验式精品小区策划方案 




603 湖南电信人力资源管理咨询方案 




604 泓泰集团供应链管理（SCM）系统可行性报告 




605 宏智科技员工绩效管理制度 




606 宏碁電腦股份有限公司股東會議事規則 




607 红桃K成都市场方案 




608 红牛电子商务发展战略实施步骤大纲 




609 合生创展集团电子商务策划方案 




610 合富辉煌—柳州大型项目市场建议书 




611 汉口西北盛世名门项目市场定位报告 




612 韩国某著名公司员工评价制度 




613 海信新形象发布计划（梅高广告） 




614 海润国际—天瑞特推广策略案 




615 海螺型材路演材料 




616 国外体育休闲用品公司物流现状调 




617 国外大型企业运用风险投资机制发展新业务和资本运作的经验介绍 




618 国泰君安—中国民营企业香港上市操作方案 




619 国泰广告—“丹芭碧”上市活动计划0




620 国企变革过程中裁员策略的比较研究 




621 国美公司战略与业务管理项目建议书  




622 国家经贸委报告—产业集群、工业园区发展与新型工业化 




623 国际健康养生园策划方案 




624 国际风情街项目调研规划书 




625 广州旭日—紫薇田园都市传播策略 




626 广州星汇园市场营销策划方案 




627 广州市房地产 市场细分及定位 




628 广州地铁IT战略规划咨询报告 




629 广州地板市场调研报告 




630 广州「星河湾」零干扰服务理念管理方案 




631 广西花红药业市场战略 




632 广东省广告—飞鹿空调旺季媒体策划方案 




633 广东联通2002年整合营销建议方案 




634 广东金业集团运营管理信息化总体方案 




635 光大花园营销推广企划全案(201P) 




636 管理提升训练课程—管理与人际关系 




637 管理变革101招 




638 股票期权操作方案集成（26项） 




639 公司成本控制要点指南 




640 高盛—资本市场策略 




641 高科技公司规章制度大全 




642 岗位分析与岗位说明 




643 感冒药（AA）的市场定位与广告策划书 




644 盖天力CF策略及表现提案 




645 富恒咨询—内衣销售渠道研究报告 




646 复星实业四个事业部2002-2006年规划 




647 福州某地块的行销建议书 




648 福特汽車-產品策略及品牌管理 




649 服装行业营销策划方案 




650 服装企业的BPR项目报告 




651 丰田中国市场营销战略研究报告 




652 丰田现场管理 




653 丰田汽车生产管理系统 




654 非财务人员财务管理培训 




655 方正电脑品牌传播沟通建议方案 




656 方太—移动PC项目可行性分析报告 




657 方太集团冰箱生产线可行性报告 




658 番禺奥林匹克花园策划案 




659 鄂州龙人新药上市推广营销策划案 




660 杜邦战略实施系统 




661 杜邦公司面对面销售技巧 




662 杜邦公司的中国战略研究报告 




663 东软集团内部管理文档 




664 东方谊福科技发展有限公司-绩效管理模型 




665 东方钢铁知识管理系统 




666 顶新食品成品仓库管理手册ISO 




667 电子书籍—城市经营决策 




668 电扬广告—喜之郎 




669 电通广告-雪花啤酒传播策略广东省广告—飞鹿空调旺季媒体策划方案 




670 电通广告培训资料 




671 电通广告—丰田汽车广告定位 




672 电通广告—HE集团年度市场战略企划方案 




673 第一太平洋戴维斯物业管理质量手册（人事行政部分） 




674 德隆重型车战略 




675 德隆战略投资模式 




676 德隆国际战略投资有限公司战略规划管理 




677 德国大众汽车中国业务成本分析及利润预测报告 




678 戴尔电脑重要客户运作系统 




679 戴尔电脑的供应链管理研究报告 




680 戴德梁行给上海某顶级写字楼的整体营销策略 




681 大中型企业集团八大总监职务描述 




682 大型MALL营运管理模式—九隆街 




683 大型IT企业组织管理制度 




684 大屯能源—矿井水净化设备项目可行性研究报告 




685 大唐电信财务管理解决方案(75P) 




686 大鹏证券—楼兰酒业创业板上市建议报告 




687 大连外国语学院发展战略规划（2020） 




688 达能食品的策略销售管理和有效推销技巧 




689 达彼思—通用别克汽车提案 




690 川池集团股份有限公司CIS导入方案 




691 处事三十六计 




692 成都市房地产市场分析及趋势预测  




693 超越安利-陈如兴 




694 厂区网络建设方案书 




695 长隆香江野生动物园2003年国庆促销活动策划方案




696 太太药业机密资料 




697 长城润滑油战略规划及发展咨询报告（235P） 




698 长城润滑油公司实体绩效管理制度细则 




699 长城宽带运营成本统计体系 




700 长安园?产业别墅营销策划全案 




701 长安福特全国市场整合传播方案 




702 财务有关的28个岗位说明书 




703 波多李奇绩效管理标准 




704 标准合同大全 




705 碧桂园凤凰城（地产）策划书 




706 奔驰公司的管理制度 




707 宝钢股份公司竞争力研究报告 




708 百事轻怡可乐促销方案 




709 白云威尼斯蓝湾上市推广策略书 




710 白沙集团品牌塑造与企业文化成功经验全套资料 




711 奥美—新浪网市场推广建议 




712 奥美－荣事达冰箱上市-传播执行计划 




713 奥美—建立伊利品牌方案 




714 奥美—广东电信广告沟通策略提案 




715 奥美—枫丹白露酒店推广策略 




716 奥美—PASSAT广告提案 




717 奥美—HE波轮洗衣机品牌行销规划建议 




718 奥美—360度品牌管理整体解决方案 




719 安永—中国银行不良贷款的年度报告 




720 安永—管理财务风险 




721 安永—关于CRM的咨询报告 




722 爱立信薪酬体系 




723 XXX农药股份有限公司战略营销框架思路 




724 TOSHIBA2001品牌运作策略方案 




725 THMOAS集团企业内部顾问培训(英文) 




726 SYSCO—企业信息化培训教材 




727 SONY绿色伙伴计划文件 




728 SH目标管理技术 




729 PEOPLESOFT—人力资本最优化 




730 PA保险指导人制度 




731 PA保险新人培训手册 




732 PA保险公司礼仪手册 




733 ORACLE—香港电信项目实施文件 




734 ORACLE—万向钱潮ERP项目实施可行性分析报告 




735 Oracle顾问咨询实施方法介绍 




736 MOTOROLA内部控制标准内控标准 




737 MOTOROLA财务管理 




738 LH股份有限公司经营状况诊断报告 




739 KJ集团培训管理办法 




740 KFC岗位操作指南 




741 KFC店长工作手册 




742 ISO9000完全培训资料 




743 ISO14000完全培训资料 




744 ISO14000美国船级社培训教材 




745 IBM公司的企业管理 




746 HONDA战略全解密 




747 HE中国造—HE成功经验完全报告 




748 HE整体物流方案 




749 HE以市场链为纽带的业务流程再造模式 




750 HE企业文化手册 




751 HE集团管理调研报告 




752 haier培训管理手册 




753 GE在日本市场的拓展计划 




754 EMC华冠电脑品牌规划 




755 BEA系统—银行省级大集中中间件解决方案 




756 BCG_2004年3月最新出炉的中国寿险业分析报告 




757 AMT—星牌建材项目建议书 




758 AMI—SHELL调研报告 




759 ADERSON绩效管理体系 




760 AC尼尔森为康师傅做的饼干零售市场研究报告 




761 AC尼尔森—南孚电池市场调查报告 




762 AC安盛咨询— 雅戈尔营销网络建设咨询报告 




763 6sigma在GE的运用 




764 毕博咨询－能力素质模型 




765 毕博咨询—清华紫光人力资源培训资料 




766 5S推行实务专业版（1） 




767 5S推行实务专业版（2） 




768 5S内部培訓资料（国内著名制造业企业） 




769 300个企业家和培训师必读的哲理故事 




770 21世纪中国饲料业发展战略研究报告 




771 2003云南红酒湖南市场推广及促销计划书 




772 2003亚洲音乐节商业赞助企划方案 




773 2003年中国白酒行业研究报告(193P) 




774 2003年食品行业研究报告 




775 2003年食品行业市场研究分析报告 




776 2003年全国民营企业500强详细资料 




777 2003年度广东房地产市场分析报告 




778 2003摩托车行业分析报告 




779 2003电工仪表行业市场分析报告 




780 2003财年LX商用渠道信誉评价体系 




781 ××食品有限公司业务操作规范 




782 《中华多宝珍珠口服液全国招商书》 




783 《销售人员专业技能训练整体解决方案》(下) 




784 《销售人员专业技能训练整体解决方案》(上) 




785 《丽臣营销企划案》 




786 《经典 4A 全攻略教程》 




787 《HW供应商指南》 




788 《IBM的营销策略纲要》 




789 《HE模式》精要—最好的管理层培训教材之一 




790 “中录时空数字文化家园” 青岛 市招商指导手册 




791 “香雪”抗病毒口服液（华东地区）市场拓展战略分析报告 




792 “奥普浴霸”的市场营销策略研究报告 




793  KFC肯德基企业内部管理




794  2003电工仪表行业市场分析报告




795  汉普—三九集团连锁经营项目竟标书PPT




796  普华永道—项目管理（多个pdf）




797  MKS—联想三年规划




798  罗兰贝格—工作方法体系介绍

799  埃森哲—咨询顾问生涯



800  安达信—绩效考评体系