Re: [P2PSIP] An SNMP Usage for RELOAD
peng.yonglin@zte.com.cn Tue, 25 October 2011 02:24 UTC
Return-Path: <peng.yonglin@zte.com.cn>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCA911E80B8; Mon, 24 Oct 2011 19:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.176
X-Spam-Level:
X-Spam-Status: No, score=-95.176 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLSaYyKgN4dL; Mon, 24 Oct 2011 19:24:02 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 549C01F0C52; Mon, 24 Oct 2011 19:23:56 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466213465113155; Tue, 25 Oct 2011 10:15:48 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 96241.4995755854; Tue, 25 Oct 2011 10:23:42 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9P2NhB2076847; Tue, 25 Oct 2011 10:23:43 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn)
To: p2psip@ietf.org, opsawg@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF6B726AFE.B03E2E5F-ON48257934.000821E3-48257934.000D1EC1@zte.com.cn>
From: peng.yonglin@zte.com.cn
Date: Tue, 25 Oct 2011 10:23:31 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-25 10:23:44, Serialize complete at 2011-10-25 10:23:44
Content-Type: multipart/alternative; boundary="=_alternative 000D1EBE48257934_="
X-MAIL: mse02.zte.com.cn p9P2NhB2076847
Cc: David Harrington <ietfdbh@comcast.net>, meng.yu@zte.com.cn, hao.zhenwu@zte.com.cn
Subject: Re: [P2PSIP] An SNMP Usage for RELOAD
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 02:24:04 -0000
Hi, We have done more research on security and other issues based on David's comments, and updated our draft. This is the new version of draft: http://www.ietf.org/id/draft-peng-p2psip-snmp-03.txt We welcome any comments! Thanks! Our analysis of David's comments as follows(blue text): 1) Use SNMPv3 terminology Apparently, you come from the RELOAD side of things, not the SNMP side. Your text doesn't use the common SNMP terminology for various SNMP-related things. You will have a better chance of success if you describe SNMP-related things using the normal SNMPv3 terminology. This isn't critical; your ideas seem reasonable, but since you don't use the standard terminology, you might mean slightly different things than what it would mean if you used the standard terminology. (I don't have a RELOAD background, so some of my comments might seem wrong because I don't know the RELOAD concepts and terminology. Now you'll understand my point ;-) PYL: We have updated the draft using SNMP terminology. As we are not SNMP experts, some terminology may not be accurate. We will try to improve this over time. 2) Use SNMPv3 It is important to make sure you are talking about SNMPv3. SNMPv1 and SNMPv2 have been declared Historic, and no new work should be done using those protocols. However, any MIB module should be able to be used with any version of SNMP. My concern is that SNMPv3 has assumptions about security associations, and you need to make sure those are considered. PYL: We detailed the security and NAT traversal and other content considerations of the document based on the architecture and description mode of SNMPv3. 3) Use MIB modules You are talking about the manager getting information from a managed node. The right way to approach "information from a node" is to define a MIB module that contains the information for the managed node. SNMP (typically) only carries information from MIB modules. So when you talk about the information about a node, you probably should talk about a MIB module at the managed node. If the functionality is different at the O-node and R-node, you might need different MIB modules, or have one MIB module that supports both roles. PYL: No MIB concerning implementation mechanism need be defined, and we may define the MIB about the managed objects of RELOAD Node in the future. 4) Use SNMP EngineID You talk about a Node ID in the RELOAD network. There is also an identifier in the SNMP network, called the SnmpEngineID. It might be possible to use the SnmpEngineID as a RELOAD Node ID, but SnmpEngineID is not user-friendly. SnmpEngineID is needed for two SNMP endpoints to talk to each other. So you might want to have the SnmpEngineID included in the Registration information. Typically, two SNMP nodes need to be pre-configured to talk because SNMP has access control for the MIB database, and the user needs to be configured to have access to the database. So a discovery mechanism to determine where to find a manager might be superfluous, since a security association between the manager and managed node might need to be pre-established anyway. I am not trying to convince you not to do this discovery work, but to be aware it might not make sense. OTOH, a mechanism that would allow an agent to find its manager, especially in a NAT environment, could be very useful for SNMP. See also RFC5343. PYL: RELOAD NodeID isn't user-friendly too, we propose to derive the SnmpEngineID based on RELOAD NodeID. Therefore, each RELOAD Node is associated with an SNMP Engine. We haven't defined the detailed ways to construct the SnmpEngineID in the draft. We may construct the SnmpEngineID by RELOAD NodeID and private enterprise number, also may use RELOAD NodeID as SnmpEngineID. Pre-configuration is appropriate for the manager deployed staticly, and discovery is appropriate for the manager deployed dynamically. We intend to deploy dynamically manager in RELOAD network. 5) Consider using PROXY-MIB SNMPv3 uses hop-to-hop security, but the management is end-to-end. SnmpEngeinID is used both during authentication/authorization at a hop-by-hop level, and is contained in the SNMP message to identify the source node for the information. (so, for example, a trap message to manager A from node C is identified as being from node C, even if the SNMP message gets relayed via node B, and SNMP message security is done C-to-B, and then B-to-A. The contents of the varbinds are still identified as being from node C. There is a PROXY-MIB in RFC3413(?) to specify how to relay SNMP messages. This allows node A to have a security association with B, and B to have a security association with C, without requiring A to have a security association directly with C. I do not believe this is in wide-spread use, but it was designed into SNMP explicitly to help get through intermediaries, such as firewalls. (NATs and ICE were not widely deployed at that time, but it can also be applied to getting around NATs.) 6) Consider using MIDCOM-MIB This was written after SNMPv3 completed, and before ICE. It was designed to deal with NATs and firewalls, and other middle boxes. I believe it is not widely deployed. I think the IETF community prefers ICE for getting around NATs, but for doing SNMP management through a RELOAD-managed middlebox, it might be helpful. maybe not. PYL: As our solution sets up a direction connection between SNMP agents, PROXY-MIB or MIDCOM-MIB may not be used in our draft. 7) Use existing SNMPv3-supported security protocols USM is the mandatory-to-implement security for SNMPv3, because SNMPv3 needs to work when a network is not working well, and USM is self-contained in SNMPv3. However, for normal management tasks, and much easier key distribution, operators greatly prefer using therir already-widely-deployed security solutions, such as SSH, TLS, and DTLS. Operators particulary disliked having to maintain a whole different security infrastructure just for carrying SNMP. RFC5590, 5591, 5592, and 5953 add support for using existing security infrastructure for SNMPv3+ messages. This might be a better approach than designing a RELOAD-specific solution for carrying SNMP securely. PYL: We think the TLS security model is a good fit for RELOAD. RELOAD also uses TLS for connecting nodes and provides certifications that can be reused by SNMP TLS. 8) Be aware of address translation issues for SNMP It is important for the information conveyed using SNMP to be accurate. and that means if the managed node puts its IP address into a MIB, and that MIB is translated into SNMP varbinds, and those varbinds go through a NAT (or here a RELOAD proxy), that the IP address inside the varbind is not modified. RFC 2962 discusses ALG considerations for SNMP. I think your proposal is, to a degree, an ALG for SNMP (but your proposal lacks enough detail for me to be sure). Please be sure to read RFC2962. This even has an IESG Note attached: This document describes an SNMP application layer gateway (ALG), which may be useful in certain environments. The document does also list the issues and problems that can arise when used as a generic SNMP ALG. Specifically, when using SNMPv3's authentication and privacy mechanisms this approach may be very problematic and jeopardize the SNMP security. The reader is urged to carefully consider these issues before deciding to deploy this type of SNMP ALG. PYL: We use the RELOAD mechanisms to traverse NAT. As we use TLS for security, the SNMP ALG problem may not arise in our solution. 9) Using SNMP to do configuration can be problematic Because SNMPv1 was not secure, and CLI can be used to do configuration, many SNMP agents do not really support SETs. if they do support SETs, those SETs often never get saved to NVRAM. So recommending SNMP to configure nodes could be a problem in many implementations. I'm not telling you not to do this, but be aware of the problems (maybe write this into an "Operations and Management Considerations" section). PYL: RELOAD has provided some mechanisms for basic configuration. We will try to figure out which way is better for setting the RELOAD nodes. ************************************************* 邮 件:peng.yonglin@zte.com.cn 内 线:81543 外 线:025-52871543 手 机:13776637274 传 真:025-52872187 ************************************************* -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
- [P2PSIP] 答复: An SNMP Usage for RELOAD wang.wei108
- [P2PSIP] An SNMP Usage for RELOAD David Harrington
- Re: [P2PSIP] An SNMP Usage for RELOAD peng.yonglin
- Re: [P2PSIP] [OPSAWG] An SNMP Usage for RELOAD t.petch
- [P2PSIP] 答复: Re: [OPSAWG] An SNMP Usage for RELOAD peng.yonglin
- Re: [P2PSIP] [OPSAWG] An SNMP Usage for RELOAD t.petch
- Re: [P2PSIP] [OPSAWG] An SNMP Usage for RELOAD Romascanu, Dan (Dan)
- [P2PSIP] 答复: Re: Re: [OPSAWG] An SNMP Usage for R… peng.yonglin
- [P2PSIP] 答复: Re: [OPSAWG] An SNMP Usage for RELOAD peng.yonglin
- Re: [P2PSIP] [OPSAWG] An SNMP Usage for RELOAD Juergen Schoenwaelder