Subject: [midcom] Comments on SNMP evaluation in draft-ietf-midcom-protocol-eval-00 .txt

From: "Elwyn Davies" <[email-masked]>
Date: Thu, 30 May 2002 14:48:15 +0100

Hi.

Some thoughts on the SNMP evaluation part:
- There are more areas than just security where only SNMPv3 can meet the
requirements.
- The very simple and unextendable semantics of the SNMP protocol (just
GET/SET/INFORM verbs)
  may be found to be restrictive for the mechanisms needed for Midcom.
- SNMP message transport uses UDP when IP protocols are used (ie essentially
always).  This means that
  message delivery is unreliable which has some knock on effects:
  - The Midcom protocol would have to achieve reliability for itself above
the SNMP layer
  - The Midcom protocol would have to be constructed to be be idempotent
with respect to the MIB
    Module which implements the Midcom communication, because
acknowledgements are just as unreliable
    as original messages.  This means that any of the commands could be
executed more than once as a
    result of retransmissions before an acknowledgement gets through.
  - TRAP messages cannot be realistically used to for the midbox -> agent
direction as they are
    unacknowledged  - Instead need to use acknowledged INFORMs available
only in v3.

Versions 1 and 2 of SNMP have not been used for configuration purposes (only
GET/TRAP verbs used) because of obvious concerns about security:  Network
managers may have qualms about SNMPv3 until it has been extensively tested,
which might slow up the deployment of Midcom if it uses SNMPv3.

Regards,
Elwyn Davies
----------------------------------------------------------------------------
------

Elwyn B Davies

        Routing and Addressing Strategy Prime
        Portfolio Integration			Solutions Ready		

        Nortel Networks plc			Email:
[email-masked]
        Harlow Laboratories     			ESN
6-742-5498
        London Road, Harlow,    		Direct Line
+44-1279-405498
        Essex, CM17 9NA, UK     		Fax
+44-1279-402047
        Registered Office: 			Maidenhead Office Park,
Westacott Way,
        Company No. 3937799			Maidenhead, Berkshire, SSL6
3QH
----------------------------------------------------------------------------
This message may contain information proprietary to Nortel Networks plc so
any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.
----------------------------------------------------------------------------
"The Folly is mostly mine"
and the opinions are mine and not those of my employer.
============================================================================
======

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 30 May 2002 20:44:06 +0200

Hi Elwyn,

Thank you for your comments. Please see my answers below.

--On 30 May 2002 14:48 +0100 Elwyn Davies wrote:

> - There are more areas than just security where only SNMPv3
>   can meet the requirements.

Which areas? Do you mean the two you mention below (INFORMS,
not extensively tested)?

> - The very simple and unextendable semantics of the SNMP
>   protocol (just GET/SET/INFORM verbs) may be found to be
>   restrictive for the mechanisms needed for Midcom.

I don't think so. Can you give an example?

I agree that this restriction might become a bit
inconvenient, but I do not see any requirement that
is not met because of it.

> - SNMP message transport uses UDP when IP protocols are used
>   (ie essentially always).  This means that message delivery
>   is unreliable which has some knock on effects:
>   - The Midcom protocol would have to achieve reliability for
>     itself above the SNMP layer

Typically an SNMP stack includes some reliability mechanisms
"above" SNMP for exactly solving this problem.

Is it intentional, that there is no reliability requirement
for the midcom protocol?

>   - The Midcom protocol would have to be constructed to be
>     be idempotent with respect to the MIB Module which
>     implements the Midcom communication, because
>     acknowledgements are just as unreliable as original
>     messages. This means that any of the commands could be
>     executed more than once as a result of retransmissions
>     before an acknowledgement gets through.

Yes, this is a typical problem with SNMP. However, typically
it is solved case by case. Most cases can be solved by a good
MIB module design that considers this fact. The remaining cases
have to be covered by the SNMP agent implementation at the
midcom server.

>   - TRAP messages cannot be realistically used to for the
>     midbox -> agent direction as they are unacknowledged
>     - Instead need to use acknowledged INFORMs available
>     only in v3.

I disagree. I think that unacknowledged v2 notifications
are sufficient (and meet the requirements). Of course INFORMs
are more desirable.

> Versions 1 and 2 of SNMP have not been used for
> configuration purposes (only GET/TRAP verbs used) because
> of obvious concerns about security:  Network managers may
> have qualms about SNMPv3 until it has been extensively tested,

Just compare deployment and testing of SNMPv3 to the other
protocols that have been suggested. It might turn out to be the
one with the most practical experience.

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

> Regards,
> Elwyn Davies
> ----------------------------------------------------------------------------------
>
> Elwyn B Davies
>
>         Nortel Networks plc                     Email: [email-masked]
>         Harlow Laboratories                             ESN                     6-742-5498
>         London Road, Harlow,                    Direct Line             +44-1279-405498
>         Essex, CM17 9NA, UK                     Fax                     +44-1279-402047
>         Registered Office:                      Maidenhead Office Park, Westacott Way,
>         Company No. 3937799                     Maidenhead, Berkshire, SSL6 3QH
> This message may contain information proprietary to Nortel Networks plc so any
> unauthorised disclosure, copying or distribution of its contents is strictly prohibited.
> ==================================================================================
>
>
>

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

---

From: "Alistair Munro" <[email-masked]>
Date: Fri, 31 May 2002 07:52:51 +0100

Hi All,

I may have missed discussion of the topic, but is TCP-friendliness,
congestion awareness, etc. an issue here?

Regards,

Alistair

--
Dr. Alistair Munro,
Chief Systems Engineer, Degree2 Innovations Ltd.
Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-900-8151
Web: http://www.u4eagroup.com

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Quittek
> Sent: 30 May 2002 19:44
> To: Elwyn Davies; [email-masked]'
> Subject: Re: [midcom] Comments on SNMP evaluation in 
> draft-ietf-midcom-protocol-eval-00 .txt
> 
> 
> Hi Elwyn,
> 
> MIB module design that considers this fact. The remaining 
> cases have to be covered by the SNMP agent implementation at 
> the midcom server.
> 
> have qualms 
> > about SNMPv3 until it has been extensively tested, which 
> might slow up 
> > the deployment of Midcom if it uses SNMPv3.
> 
> protocols that have been suggested. It might turn out to be 
> the one with the most practical experience.
> 
>     Juergen
> --