Subject: Re: [P2PSIP] An SNMP Usage for RELOAD

From: [email-masked]
Date: Tue, 25 Oct 2011 10:23:31 +0800

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.

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

---

From: "t.petch" <[email-masked]>
Date: Tue, 25 Oct 2011 16:15:08 +0200

----- Original Message -----
From: <[email-masked]>; <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 25, 2011 4:23 AM

> experts, some terminology may not be accurate. We will try to improve this

You are indeed using SNMP terminology, but I struggle to see how its usage is
the same as in RFC3411.

RELOAD defines a messaging network, on top of which run applications, which
RELOAD calls Usages, so when you define an SNMP Usage, you would appear to be
discarding most of an Architecture for SNMP as defined in RFC3411, perhaps
providing instead a gateway for functionality such as that specified in RFC3414;
or perhaps not, I do not find the I-D clear on this.  Thus you have

                  Application

            +-------+  +-------+  +-------+
            | SIP   |  | XMPP  |  | SNMP  |  ...
            | Usage |  | Usage |  | Usage |
            +-------+  +-------+  +-------+
         ------------------------------------------- Messaging API

                      RELOAD

but elsewhere you say
' SNMP entities talk to each other using SNMP protocol on dedicated connections'
which is rather different.

The I-D reads more like a wish list of requirements, than an overview,
architecture or framework.  Or perhaps it is all beyond me:-(

Tom Petch

<snip>

---

From: [email-masked]
Date: Wed, 26 Oct 2011 11:02:43 +0800

In short, the relation between SNMP Usage and RELOAD as follows:
SNMP Usage get a available IP address, which is used for SNMP 
communication, for snmeEngineID or NodeID or ResourceID or Manager name by 
RELOAD mechanism, such as AppAttach, Store, Fetch.
Then SNMP Usage uses this IP address for SNMP communication between SNMP 
entities by the SNMP mechanism and architecture which defined in RFC3411 
and RFC5953 and other SNMP RFCs (as depicted in the diagram below). And 
now there is little relation between SNMP Usage and RELOAD besides using 
RELOAD certificate. So we say "SNMP entities talk to each other using SNMP 
protocol on dedicated connections"

If you till have questions, please tell us. Thanks!

"t.petch" <[email-masked]> 
2011-10-25 22:15

收件人
<[email-masked]>, <[email-masked]>, <[email-masked]>
抄送
<[email-masked]>
主题
Re: [OPSAWG] An SNMP Usage for RELOAD

----- Original Message -----
From: <[email-masked]>; <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>

> experts, some terminology may not be accurate. We will try to improve 
this

You are indeed using SNMP terminology, but I struggle to see how its usage 
is
the same as in RFC3411.

RELOAD defines a messaging network, on top of which run applications, 
which
RELOAD calls Usages, so when you define an SNMP Usage, you would appear to 
be
discarding most of an Architecture for SNMP as defined in RFC3411, perhaps
providing instead a gateway for functionality such as that specified in 
RFC3414;
or perhaps not, I do not find the I-D clear on this.  Thus you have

                  Application

                      RELOAD

but elsewhere you say
' SNMP entities talk to each other using SNMP protocol on dedicated 
connections'
which is rather different.

Tom Petch

<snip>

---

From: "t.petch" <[email-masked]>
Date: Thu, 27 Oct 2011 12:09:09 +0200

----- Original Message -----
From: <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, October 26, 2011 5:02 AM

> protocol on dedicated connections"

No, it still does not make sense.  You understand that an SNMP engine can do
nothing until it has been customised - snmpEngineID, snmpTargetAddrTable, etc -
and you use RELOAD to obtain that information; I assume you are familiar with
the MIB modules into which that information must then be placed before an engine
can communicate.

Two engines can then communicate but cannot do anything useful without suitable
MIB modules; the I-D says
" SNMP usage for RELOAD SHOULD provide the management functions ...
     ... monitoring the number of the messages
   initiated, forwarded or processed by nodes, reporting program failure
   , message forwarding failure or other error on nodes."

This is a typical usage for SNMP but is quite impossible unless and until a
suitable
MIB module is defined, which is what everyone using SNMP for management
then does.  Your earlier response to David rejected the idea of creating a MIB
module, which leaves me with two SNMP engines able to talk to each other but
having nothing useful to say.

The I-D also says
"As traditional network
   management protocols (e.g., SNMP) cannot be directly applied to
   RELOAD network management, it is necessary to introduce new RELOAD
   usage of SNMP."
which is only true in the sense that SNMP cannot be directly applied to any
network
management, unless and until there is a suitable MIB module.  Once there is,
and you have two communicating engines (which you say you will have), then
of course SNMP can be used to manage anything, including RELOAD.

Tom Petch

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 27 Oct 2011 13:48:43 +0200

Just to make sharper the statements made by Tom. In the SNMP architecture in order for two entities to exchange management information we have a protocol (basic primitives to fetch pieces of information, set values of pieces of information or send notifications related to the pieces of information) and a data model (e.g. MIB model) expressed in a Data Modeling Language (e.g. SMI). The proposed text talks about the protocol (SNMP) but not about the information exchanged (data model). This is of little help. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of t.petch
> Sent: Thursday, October 27, 2011 12:09 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [OPSAWG] An SNMP Usage for RELOAD
> 
> > > 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.
> >
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: [email-masked]
Date: Fri, 28 Oct 2011 11:56:19 +0800

Thanks for Tom's response and Dan's explanation. Please see inline (blue 
text).

2011-10-27 18:09

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
主题
Re: Re: [OPSAWG] An SNMP Usage for RELOAD

----- Original Message -----
From: <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;

> protocol on dedicated connections"

No, it still does not make sense.  You understand that an SNMP engine can 
do
nothing until it has been customised - snmpEngineID, snmpTargetAddrTable, 
etc -
and you use RELOAD to obtain that information; I assume you are familiar 
with
the MIB modules into which that information must then be placed before an 
engine
can communicate.
Yes, these information will be placed into MIB. For example, we say when 
Agent 
get the address of Manager, it will store the address into 
MIB(snmpTargetAddrTable) in the diagram in chapter 9.

Two engines can then communicate but cannot do anything useful without 
suitable

This is a typical usage for SNMP but is quite impossible unless and until 
a
suitable
MIB module is defined, which is what everyone using SNMP for management
then does.  Your earlier response to David rejected the idea of creating a 
MIB
module, which leaves me with two SNMP engines able to talk to each other 
but
having nothing useful to say.
Sorry，our last response maybe confusing. We also think we need MIB module 
which relates to managed objects of RELOAD. 
Only because it doesn't affect the implementation mechanism of management, 
so we plan to study and define it later. 
For now, we try to resolve the discovery and communication problems for 
snmpEngines. 
As our current design does not require a predefined MIB (maybe we miss 
some pats), we leave the MIB definition for future study. 

The I-D also says
"As traditional network
   management protocols (e.g., SNMP) cannot be directly applied to
   RELOAD network management, it is necessary to introduce new RELOAD
   usage of SNMP."
which is only true in the sense that SNMP cannot be directly applied to 
any
network
management, unless and until there is a suitable MIB module.  Once there 
is,
and you have two communicating engines (which you say you will have), then
of course SNMP can be used to manage anything, including RELOAD.

Tom Petch

---

From: [email-masked]
Date: Fri, 28 Oct 2011 13:49:04 +0800

Thanks for your reminder very much.
It isn't needed to add new protocol operations or modify them in our 
draft, and we use only current protocol operations. 
The drat introduces mainly the preparation work before sending protocol 
operations.

***************************************
Email：        [email-masked]
TEL：          025-52871543
Mobile：       13776637274
Fax：          025-52872187
***************************************

Juergen Schoenwaelder <[email-masked]> 
2011-10-27 23:15
请答复 给
Juergen Schoenwaelder <[email-masked]>

收件人
[email-masked]
抄送
[email-masked], [email-masked], [email-masked]
主题
Re: [OPSAWG] An SNMP Usage for RELOAD

On Thu, Oct 27, 2011 at 01:48:43PM +0200, Romascanu, Dan (Dan) wrote:
> Just to make sharper the statements made by Tom. In the SNMP 
architecture in order for two entities to exchange management information 
we have a protocol (basic primitives to fetch pieces of information, set 
values of pieces of information or send notifications related to the 
pieces of information) and a data model (e.g. MIB model) expressed in a 
Data Modeling Language (e.g. SMI). The proposed text talks about the 
protocol (SNMP) but not about the information exchanged (data model). This 
is of little help. 

And it might help to notice that the set of SNMP's protocol operations
has been static for almost 20 years and any attempts to add additional
protocol operations during this period failed to get sufficient support.
So if your idea is to add new operations, you likely will have a hard
time getting this anywhere.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Oct 2011 17:15:31 +0200

/js