Re: [OPSAWG] An SNMP Usage for RELOAD

[[e-mail]]

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.


*************************************************
邮 件：[e-mail]
内 线：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.