Subject: [Pana] FW: draft-ietf-pana-snmp-01.txt

From: Alper Yegin <[email-masked]>
Date: Fri, 23 Jul 2004 14:14:27 -0700

David Harrington's review feedback on the pana-snmp I-D...

Thank you David.

Alper

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Thursday, July 22, 2004 7:46 PM
To: [email-masked]; [email-masked]
Cc: 'Wijnen, Bert (Bert)'
Subject: draft-ietf-pana-snmp-01.txt

Hi,

I have some comments on draft-ietf-pana-snmp-01.txt. Can you forward
to the pana mailing list?

I have not done a through review, but as SNMPv3 co-chair, I like to
check documents produced by WGs to see if they are planning to use
SNMPv3 as it was designed to be used. I have not looked closely at
whether the modules being reused are being used appropriately, whether
the design of mib tables and indices is appropriate, whether it meets
the mib review guidelines, and so on. 

It would be smart to ask Bert if he can get a MIB Doctor to act as
Technical Advisor for the WG, if the WG is going to use SNMPv3 for
secure configuration.

1) section 4.2.1, "SNMP enables the re-use of existing mibs, this is
detailed in Section 4." Since this statement is made in section 4, it
seems wrong.

"mibs" s/b "mib modules"

It is incorrect to say that SNMP enables the re-use of existing mibs. 

First, SNMP is a protocol used to transport mib module information;
the mib module is actually independent of the protocol, since the mib
can be used with any protocol that knows how to address and carry its
data. So it isn't SNMP that makes mib module re-use possible.

Second, while an existing mib module might be appropriately used to
manage a new technology, the management approach must fit the mib
module's design; It would be inappropriate to re-use an existing mib
module in a manner for which it was not designed. 

So, a better way to say this would be "PANA management can be modeled
in a way that is consistent with existing standard mib modules."

2) "With the use of SNMPv3 as the PAA-EP protocol, the polling and
notification models are supported by SNMP get and trap operations,
respectively." - "traps" should be "notifications".

3) "In general, the polling model is less scalable than the
notification model as the number of PaCs and/or EPs increases." 

I think this is debatable, depending to a degree on how you define
scalability. A product I worked on worked very well with large
networks using a polling model; when a telecomm customer tried to use
the product as an event-driven solution, sending all the information
from devices to the application using notifications, it hosed the
application; the application couldn't process all the data fast enough
because it was constantly being interrupted with new event reports,
and it never caught up. The event-driven approach wasn't scalable
because an SNMP receiver has no ability to control the flow, and the
agent has no way to know that the receiver can't process the events
fast enough; with the polling method, the application could control
the flow, and can see whether the agent has handled requests on a
timely basis. 

To help minimize the need to constantly poll devices looking to see if
anything has changed, the SNMP designers recommend using a
notification-directed polling approach. If an important change has
occurred, the device can notify the application that the change has
occurred, and the application can then poll the appropriate mib module
for the updated information. 

The notifications should be designed as part of a mib module to
identify which changes are important, and the mib module should also
have a "knob" to allow an operator to decide whether to enable the
notification, and whether to rate-limit it.

So I think it is inappropriate to say the polling model is less
scalable. That's merely an opinion and should not be part of a
standards specification.

4) The whole discussion of traps and unreliability is inappropriate
for an SNMPv3-based design. This is a problem from SNMPv1. SNMPv3
supports an Inform notification, for which there is a response
message.

5) "Thus, the notification model should be used for supporting this
type of authorization." Is this really required in the RFC2119
"SHOULD" sense? I don't think so, personally. It seems more like the
author's opinion of how to implement, not a standards requirement.

6) "This type of authorization" - should this be a new paragraph? It
seems to be a different topic than trap unreliability.

7) section 4.2.2 discusses various models of one-to-many relations. Is
section 4 supposed to be about the requirements for PANA, or a
discussion of how SNMP meets the requirement? If the requirement is
simply that the protocol used must support one-to-many relationships,
the whole first paragraph isn't needed here. SNMP supports
one-to-many, many-to-one, and many-to-many relationships.

If the requirements have not yet been identified in other PANA
documents, then it would be better to list the requirements in one
section, and then use a different section to show how SNMP meets the
requirement, referencing where the requirement is identified. If the
requirements are identified elsewhere, why not just reference the
requirement in the other document?

8) section 4.2.3 - would it be more succinct to say "SNMPv3 includes
the User-based Security Model (USM, [RFC3414]), which provides
authentication,
   confidentiality, and integrity."? I found the existing text
confusing since I couldn't tell what three standardized mechanisms
were being referenced.

"See Section 9" points to a section that should be listing sensitive
objects. It would probably be better to point the reader to RFC3410 or
the USM RFC if they want further details on the threats addressed.

9) 4.2.6 "shorter enough" s/b "short enough"

10) 5.3 - I'm concerned that this notification could be used to
overwhelm an SNMP application, thus creating a DoS attack on the
management of the network. A attacker could detect that such
traps/notifications are sent by multiple devices, and the attacker
could deliberately send lots of traffic through the devices.

11) pana802FilterVlanId - be aware that there are textual conventions
for vlanID and vlanindex that might be appropriate here. In addition,
the TCs may support cases that your syntax may not be able to support.
Bert Wijnen can advise you where to find the current TC.

12) I recommend using bullets to list the possible enumerations. As
written, it's a little bit harder to find the values one is looking
for, and then to parse the sentence it is contained in. This is obvous
not a big problem, but it does seem to improve ease-of-use.

13) did you consider using the SNMPConf work to provide policy based
mgmt? If not, why not?

14) pana802FiltRowStatus depends on the description in
pana802FilterType; wouldn't it be better to put the requirements in
one place? Would it be better to describe what process an application
should use to change the entry so applications know how to do it, and
agent implementers know how to implement support for the process
consistently? Failure to clearly specify this might result in
differnet vendors handling this in different ways, and applications
having to know how to do it multiple ways depending on which vendors'
equipment it is doing it to.

15) Once you've begun to identify the sensitive objects, it might be a
good idea to provide appropriate VACM view families for controlling
access. This will ensure that it will be possible to reasonably apply
access controls to the tables you design.

Hope this helps,

David Harrington
[email-masked]
co-chair SNMPv3 WG, concluded

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: [email-masked]
Date: Mon, 26 Jul 2004 11:05:06 +0200

thank you david for your review. indeed it does help. I think we agree 
on most of your comments.

* from a general point of view, a fair amount of your comments deal with 
text inherited from earlier discussion and docs we had on PANA framework 
issues (traps, pana reqs, etc.). thank you for pointing this out and I 
agree we need to clean this up in order to provide a coherent standards 
specification.

* a MIB doctor for PANA: good idea IMO. nethertheless, we should wait 
the MIB objects are in a more advanced stage to ask for this review. 
PANA decisions must be taken first (especially L2 support, see the open 
issues).

* concerning the non-choice of SNMPconf, I see 2 reasons for this (FYI):
- a "strategical" one: in order to promote its framework. PANA WG wants 
to stay as neutral as possible on this interface. smthg widely spread 
and readily re-usable is needed here. SNMPv3 is ok then.
- a technical one: PANA WG does not need a full policy suite, since 
PAA-EP cares about access control only.

* finally, for the remainning points, I think we agree on and I will 
personaly take care to integrate your proposals in the next iteration of 
the document and of course I'll keep you and the PANA WG informed.

thanks again,
yacine

Alper Yegin wrote:

> -----Original Message----- From: David B Harrington 
> [mailto:[email-masked]] Sent: Thursday, July 22, 2004 7:46 
> PM To: [email-masked]; [email-masked] Cc: 
> 'Wijnen, Bert (Bert)' Subject: draft-ietf-pana-snmp-01.txt
> 
> 
> Hi,
> 
> whether the modules being reused are being used appropriately, 
> whether the design of mib tables and indices is appropriate, whether 
> it meets the mib review guidelines, and so on.
> 
>  detailed in Section 4." Since this statement is made in section 4,
> it seems wrong.
> 
> "mibs" s/b "mib modules"
> 
>  can be used with any protocol that knows how to address and carry 
> its data. So it isn't SNMP that makes mib module re-use possible.
> 
> application; the application couldn't process all the data fast 
> enough because it was constantly being interrupted with new event 
> reports, and it never caught up. The event-driven approach wasn't 
> scalable because an SNMP receiver has no ability to control the flow,
>  and the agent has no way to know that the receiver can't process the
>  events fast enough; with the polling method, the application could 
> control the flow, and can see whether the agent has handled requests 
> on a timely basis.
> 
> To help minimize the need to constantly poll devices looking to see 
> if anything has changed, the SNMP designers recommend using a 
> occurred, and the application can then poll the appropriate mib 
> module for the updated information.
> 
> 7) section 4.2.2 discusses various models of one-to-many relations. 
> Is section 4 supposed to be about the requirements for PANA, or a 
> authentication, confidentiality, and integrity."? I found the 
> existing text confusing since I couldn't tell what three standardized
>  mechanisms were being referenced.
> 
>  objects. It would probably be better to point the reader to RFC3410 
> or the USM RFC if they want further details on the threats addressed.
> 
> 
> 
>  for vlanID and vlanindex that might be appropriate here. In 
> addition, the TCs may support cases that your syntax may not be able 
> to support. Bert Wijnen can advise you where to find the current TC.
> 
> for, and then to parse the sentence it is contained in. This is 
> obvous not a big problem, but it does seem to improve ease-of-use.
> 
>  should use to change the entry so applications know how to do it, 
> and agent implementers know how to implement support for the process
> 15) Once you've begun to identify the sensitive objects, it might be 
> a good idea to provide appropriate VACM view families for controlling
>  access. This will ensure that it will be possible to reasonably 
> apply access controls to the tables you design.
> 
> Hope this helps,
> 
> David Harrington [email-masked] co-chair SNMPv3 WG, 
> concluded
> 
> 
> 
> _______________________________________________ Pana mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/pana
>