Subject: [Isms] Transport protocol discussion

From: "David B Harrington" <[email-masked]>
Date: Mon, 1 Aug 2005 10:11:59 -0400

Hi,

I have some concerns about trying to select "the" ISMS transport
protocol; why are we trying to choose "the" transport rather than
trying to choose a security application (e.g. TLS, SASL, SSH) that
might incidentally be able to run over different transport protocols?
Or is that what is meant by "selecting a transport protocol"?

If we talk about selecting one transport protocol (i.e. UDP vs TCP),
do we have new research with independently-verifiable statistics about
the reliability and performance of these protocols as a transport for
SNMP? If we don't have new info, I would consider discussing this for
the umpteenth time to be a waste of face-to-face meeting time.

David Harrington
[email-masked]

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 01 Aug 2005 09:12:58 -0700

> the umpteenth time to be a waste of face-to-face meeting time.

My $.02:

The important transport question is whether support for datagram
mode is a requirement. If it is, that substantially constrains
the solution set--and potentially requires some more design work :)

-Ekr

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 2 Aug 2005 09:05:02 +0200

<inline>
Tom Petch
----- Original Message -----
From: "Eric Rescorla" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 01, 2005 6:12 PM
Subject: Re: [Isms] Transport protocol discussion

> the solution set--and potentially requires some more design work :)

You've lost me here and I would like to understand.

I see SNMP applications as datagram, message out message(s) back, not stream,
not full duplex.  If we have a full duplex stream transport, then a SNMP-like
message exchange can be imposed on it, as the SNMP over TCP RFC demonstrates;
needs work, but can be done.

Tom PEtch

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 02 Aug 2005 01:36:49 -0700

> needs work, but can be done.

Well, that's not datagram, that's record-oriented stream transport.
The key difference being reliability and in-sequence delivery.

One scenario where this is important is in real-time multimedia
applications. If a packet gets lost, having it get retransmitted
500ms or 1s later doesn't do much good. What you *do* want is
the next packet. But in reliable stream transport like TCP,
packet n+1 can't be read until packet n is received.

I'm not enough of an SNMP expert to say whether this is important
in SNMP....

-Ekr

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 02 Aug 2005 02:34:25 -0700

>>>>> On Mon, 01 Aug 2005 09:12:58 -0700, Eric Rescorla <[email-masked]> said:

Eric> My $.02:

Eric> The important transport question is whether support for datagram
Eric> mode is a requirement. If it is, that substantially constrains
Eric> the solution set--and potentially requires some more design work
Eric> :)

[I'm not going to make the meeting later today due to a conflict,
though I hope to listen from a different room...  the end result is
that I'll ramble on now instead ;-]

I think it would be best, personally, to have a result with a choice.
Unfortunately, that is looking less and less likely.  The thing that
concerns me the most is that we're trying to make a decision about the
need for a datagram mode without any hard data (because none is
available).  We don't have any hard data papers anymore telling us how
well modern TCP algorithms and network architectures have improved
things.

A lot of people like to state that the need for UDP is beyond us and
that SNMP shouldn't need it anymore because TCP works just fine these
days.  But in actuality, I think the human-half of us is what is
measuring that metric.  I do have problems with TCP sessions all the
time in broken networks (frequently wireless).  But they're fixable by
restarting the TCP session.  The concrete example is that I've
probably restarted ssh connections multiple times in this week alone
because the TCP session properties had made my shell worthless from a
responsiveness point of you.  But it's easy to fix: I typed "exit" and
relogged on.  The delay was not huge for a human (5 seconds maybe), my
shell history was restored through the use of a decent shell, and it
happened at the right time (I noticed when things weren't responsive
and made the decision myself).  When using HTTP, I hit the stop button
and then hit reload.  Who, seriously, hasn't done that on a
semi-regular basis because you the human know something is wrong and
that will often fix the problem?

My worry is that coding that human decision process about when to
restart a broken TCP session because recovery will be faster by
restarting than waiting for the TCP stack to fix the session will be
impossible.  I'm not at all convinced that TCP sessions are stable,
based on my experience over the last few years.  I do think they've
gotten better, but I'm not willing to bet the management of my network
on it.

I'm not at all saying that UDP should be the only solution.  I'm
saying I don't know what the best choice is, but I'm fairly convinced
that no one actually knows.  I haven't seen any recent studies on the
subject and I don't think we'd be doing the future service by forcing
the selection of one or the other.  I'd even be tempted to make 2 MUST
transports, one UDP and one TCP because of this.  But I can't believe
I just said that, because now I'm about to get flamed.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Aug 2005 12:48:23 +0200

On Tue, Aug 02, 2005 at 02:34:25AM -0700, Wes Hardaker wrote:

[...]

> gotten better, but I'm not willing to bet the management of my network

SNMP stacks usually come with a default retry/timeout strategy and
they report some 'noResponse' error once you have had your retries.
What happens next is either left to a human or some magic - I am not
sure there is at the end that much difference in the magic here.

[Yes, there are several technical differences I am ignoring here,
 but the point is that even with SNMPv1 you have to have some logic
 do deal with situations where your network is in trouble.]

We simply have to give up the idea of a "one size fits all" security
model. There are several trade offs to be made and operational
requirements differ between environments.

Personally, I see practical value in SNMP/SSH because it would enable
me to transition to a secure version of SNMP with close to zero
deployment costs. Eric Fleischman lives in a different environment and
he surely likes to have SNMP/Kerberos because it allows him to
transition to a secure version of SNMP with close to zero deployment
costs.

The question for me is whether we want to enable people to make such
"close to zero deployment costs" transitions to secure SNMP or whether
we continue to work on the "one size fits all" security approach,
something we have been doing not too successful for more than a dozent
years now.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany