Subject: Re: [Isms] Rough Consensus Declaration: ISMS Architecture is EK

From: Keith McCloghrie <[email-masked]>
Date: Fri, 6 May 2005 17:56:32 -0700 (PDT)

Apparently, the people who voted for (including the maybe's and the
not-against's) EK, believe that they voted not only for encapsulating
the keying but also for encapsulating SNMP messages.  Assuming this is
true, then it seems to me that if one is forced to pay the price of TLS
in order to have secure SNMP, then I no longer see any benefit in
running SNMP over UDP.  There are both advantages and disadvantages of
running SNMP over TCP; the advantages include larger messages and flow
control.  For the disadvantages, all but one of them are inherent in
encapsulating SNMP messages in TLS; the remaining one is the minor issue
that both SNMP and TCP have reliability mechanisms, i.e., SNMP engines
should avoid having SNMP's retransmission timers fire before TCP's
retransmission timers (see page 2 of RFC 3430).  That one remaining
disadvantage is negligible compared to larger messages and flow-control.
Therefore, to define SNMP-over-DTLS-over-UDP is silly; the only
sensible way of using TLS is to define SNMP-over-TLS-over-TCP.

So, I believe the WG's choice of EK discards the perceived wisdom 
of the last 15+ years that UDP was the preferred transport mapping.
Nevertheless, given that the WG has decided to do this, I think it
should be made explicit by:

  - putting RFC 3430 on the standards track,
  - starting an update to remove the word "preferred" from RFC 3417,
  - not wasting any time on defining a SNMP-over-DTLS-over-UDP,

Keith.

PS. As a further observation, I will note that this has occurred in a
Security Area Working Group.  How sad this all is.

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

---

From: "David B Harrington" <[email-masked]>
Date: Sat, 7 May 2005 00:27:55 -0400

Hi Keith,

I am well aware of the  UDP vs TCP debate, and understand your
concerns.

Personally, I think a UDP transport is, and has always been, important
for troubleshooting broken networks. However, network robustness has
changed dramatically since the late 80s.

SNMP has also changed in terms of its use cases. MIB modules
originally provided limited amounts of information. But now tables
have grown in size, and MIB modules provide more information than
earlier MIB modules. Much more management/monitoring is done for
well-functioning networks. I think the advantages of larger messages
and flow control are warranted for this type of management.

I still believe a UDP transport will be important for troubleshooting.
This could be provided by also having USM (with maybe a single root
user), but supporting a DTLS transport to supplement a TLS transport
would seem to make more sense, if TLS and DTLS can share a security
infrastructure.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Keith McCloghrie
> Sent: Friday, May 06, 2005 8:57 PM
> To: [email-masked]
> Subject: Re: [Isms] Rough Consensus Declaration: ISMS 
> Architecture is EK
>

---

From: "David B Harrington" <[email-masked]>
Date: Sat, 7 May 2005 00:38:55 -0400

Hi,

If DTLS has significant session setup requirements, then the USM/UDP
might still be a better choice for troubleshooting. We should consider
the applicability of various solutions for troubleshooting a broken
network, and for managing a non-broken network.

 David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of David B Harrington
> Sent: Saturday, May 07, 2005 12:28 AM
> To: 'Keith McCloghrie'; [email-masked]
> Subject: RE: [Isms] Rough Consensus Declaration: ISMS 
> Architecture is EK
> 
> Hi Keith,
> 
> > the keying but also for encapsulating SNMP messages.  Assuming
this
> is
> > running SNMP over UDP.  There are both advantages and
disadvantages
> of
> > PS. As a further observation, I will note that this has occurred
in
> a

---

From: Sam Hartman <[email-masked]>
Date: Sat, 07 May 2005 16:07:51 -0400

>>>>> "David" == David B Harrington <[email-masked]> writes:

    David> Hi, If DTLS has significant session setup requirements,
    David> then the USM/UDP might still be a better choice for
    David> troubleshooting. We should consider the applicability of
    David> various solutions for troubleshooting a broken network, and
    David> for managing a non-broken network.

I'd really like it if someone would work on some requirements for SNMP
security when the network is down/broken.  What do you want to be able
to do?  Is being able to push out updates for a few users while the
network is functioning enough?  Is keeping long-lived sessions alive
enough?

I honestly have no idea, but I'm quite sure I cannot provide useful
suggestions for security protocols until you decide what the
requirements are.  I think guessing at the requirements for working
networks will probably yield acceptable results but I think the
security community needs significant help from the management
community on requirements for broken networks.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 7 May 2005 22:40:56 +0200

On Sat, May 07, 2005 at 04:07:51PM -0400, Sam Hartman wrote:

> I think guessing at the requirements for working

The management community may have different opinions on this and thus
the question is rather difficult to answer. Almost all bigger networks
I am familiar with run management traffic on a logically separate 
network, sometimes even physically separate. The degree of separation
of the management network from the production network has impact on 
how concerned you are about running SNMP over a broken network...

A related question is to what extend SNMP tools are used in situations 
where the network is broken to debug and repair things. I know many 
networks where SNMP is used to collect statistics and to some extend 
to spot problems but once there is real trouble, people either resort 
to the CLI to repair things (which requires TCP of course) or they pick 
up the phone to instruct some human being to do what needs to be done. 

/js

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

---

From: "David B Harrington" <[email-masked]>
Date: Sun, 8 May 2005 00:29:47 -0400

Hi Sam,

I think the strength of security for SNMP in a broken network needs to
be fairly equivalent to the strength of security provided in a
non-broken network.

There are a few assumptions about working in a broken network, if SNMP
is in-band (run over the broken network) rather than out of band:
1) security should not be dependent on a third party who may not be
reachable via the broken network,
2) it is desirable to receive some packets from the managed system, so
at least partial status can be deterined, even if all packets cannot
be delivered, and packets may not be delivered in order, and
3) it is acceptable to have only a limited numbers of users able to be
authenticated, e.g. root, instead of a large number of users, when the
network is broken. 

David Harrington
[email-masked]

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Saturday, May 07, 2005 4:08 PM
> To: [email-masked]
> Cc: 'Keith McCloghrie'; [email-masked]
> Subject: Wehn the network doesn't.
>

---

From: "Tom Petch" <[email-masked]>
Date: Sun, 8 May 2005 11:37:55 +0200

I see people resorting to Telnet in a broken network only because SNMP set
operations do not have the necessary security; secure SNMP and the Telnet will
diminish.

But the session setup, including any security exhanges, needs to be simple
enough to work in a less than reliable network ie an 8-way handshake (eg) is
likely to fail.

I think the weakness of TCP is that it does things we do not need (sequencing,
flow control), does not do what we need (security) and taken together we may
need an excessive number of messages before anything useful can happen.

We need sessions - that has been axiomatic for months - but that does not mean
TCP; as has been pointed out before, our session needs could be achieved by
suitable data in the PDU header, suitable secured.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 May 2005 11:22:30 -0700

>>>>> On Sat, 07 May 2005 16:07:51 -0400, Sam Hartman <[email-masked]> said:

Sam> I'd really like it if someone would work on some requirements for
Sam> SNMP security when the network is down/broken.  What do you want
Sam> to be able to do?  Is being able to push out updates for a few
Sam> users while the network is functioning enough?  Is keeping
Sam> long-lived sessions alive enough?

When good networks go bad...  The endless discussion.

The problem with this discussion is that there is very little data to
back it up.  However, I suspect that everyone will at least agree that
the following breakage-line is likely to be true.  It's just that the
points along the line aren't accurately placed because of the lack of
data:

Good network <-> Slow Network TCP Works <-> Slower network UDP works <-> Dead

The problem is that determining at which point TCP and UDP each stop
working is subject to a large debate that I don't think it would be
productive to have.  However, I don't know if we can fully avoid it
since we're trying to decide if we need a secure UDP solution.

The problems:

1) Originally everyone believed that TCP would quickly die.
   Fortunately it turned out that it survived better than people
   believed and more recent improvements in TCP have improved the
   situation greatly as well.  Thus TCP now functions in networks
   where it didn't use to.  But, it's still not the 

2) Everyone believes that UDP functions better in broken networks, but
   realistically it's still not great either.  It still suffers from
   problems and some people believe that it functions fantastically.
   It doesn't.  It just barely works.  But it does work better than
   TCP, though probably not by huge amounts.  It is here that very
   little recent data exists, at least that I've seen, about how UDP
   and TCP compare and how close on the above line those two nodes
   would appear.  I suspect some people would even argue that they are
   in the same place, though I'd personally disagree (especially
   without data).  Does anyone know of a recent study comparing the
   two?  There's got to be one, but I don't have a reference to one.

   I will say that anyone who has tried to use ssh/telnet in a really
   poorly behaving network is probably using it while it's still
   almost functioning.  I know one of the most common things to do
   when your TCP connection is going bad is you quit it and restart.
   As much of a pain as that is, because it requires a brand new
   connection potentially with a new cryptographic exchange, it often
   fixes a connection faster than it would have been fixed on its own.
   Fortunately, I think that more advancements in TCP will happen in
   the next decade that may fix these problems.  But that's still a
   guess and it is actually unknown if improvements in highly lossy
   networks will happen.  I certainly hope so.

3) "Networks never go bad anymore".  Although this was probably the
   case in the late 90s and early 00s where outages were less and less
   likely, I'd argue we're just reaching the point where it's going to
   get worse again.  There certainly was a period where less and less
   people worried about management in troubled networks because it was
   increasingly rare.  However, as we head more and more into wireless
   network infrastructures I think we're only going to be back into an
   era where we will have to try and fix networks that have died.
   Anyone who has been to frequent IETF conferences knows that
   wireless networks aren't perfect much of the time.  Fortunately in
   those cases, there are backplanes which are wired.  However, I
   suspect in the future more and more networks will be deployed where
   you may not be able to physically back-path a device because the
   only connections to it will be wireless.  Certainly if MANET and
   similar environments live up to their potential this will be the
   case.  And it's for this reason that I think we still need to be
   able to do management over protocols that can handle heavily-lossy
   networks.  Whether this is a new super-TCP mode or falling onto UDP
   when things go bad, I don't know.  I'd rather not bet on a new
   super-TCP mode until it exists and thus I think it's worth our
   trouble to define a SNMP-over-secure-UDP solution as a potential.
   Of course, if operators then deploy huge infrastructures and modes
   that require 12 round trips and connections to a centralized keying
   system at all times then that's their own fault.  But we should
   offer the potential for something better in those bad times.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 May 2005 14:53:34 -0400

>>>>> "Wes" == Wes Hardaker <[email-masked]> writes:

    Wes> The problem is that determining at which point TCP and UDP
    Wes> each stop working is subject to a large debate that I don't
    Wes> think it would be productive to have.  However, I don't know
    Wes> if we can fully avoid it since we're trying to decide if we
    Wes> need a secure UDP solution.

So, I think determining this in terms of TCP vs UDP is kind of going
about it the wrong way.

I'd recommend looking at what sort of local security you may need and
how you want to get it and whether that has any implications for ISMS.

Most of the security solutions we're talking about have significant
infrastructure requirements.  Let's assume we secure UDP with DTLS.
Let's look at all the possible external dependencies we could still
have.  I'm introducing a few dependencies that are a bit unrealistic,
but only a bit.

I assume your DTLS uses certificates in one direction and some sort of
password fed into an AAA infrastructure in the other direction.  That
seems plausible at least.  I'm also assuming your infrastructure
actually does certificate validation; that's unrealistic but the
security community would like to at least pretend you do that.

Here are some of the external dependencies you have:

* Certificate validation depends on an OCSP server. 

* To get to the OCSP server we need DNS and TCP to some external
  entity.  

* If we are lucky, it has the data cached.  If we are very unlucky, it
  starts chasing down certificates in an LDAP directory.  IT may
  follow an arbitrary chain of referrals and how to authenticate to an
  arbitrary number of LDAP servers.

* Your AAA infrastructure is backended by Kerberos.  That's actually
  not completely unheard of.  So, your RADIUS server needs to have DNS
  working and needs to talk to a KDC.

So, to send a command to your SNMP engine, you might well need DNS,
OCSP, LDAP, RADIUS and Kerberos all to be working.  UDP vs TCP just
isn't the right level to be looking at this.

When running a security infrastructure in practice, you tend to want
to have some very simple security infrastructure to fall back on when
fixing problems you use with your production infrastructure.  For
example you may well install ssh keys for the security managers onto
enough of the infrastructure that you can get security working again
when things break.

I  think  you need  to  look at  under  what  circumstances your  SNMP
security   solution  needs   to  be   independent  of   your  security
infrastructure.  Here  are the possible  answers I can see;  there are
probably potential solutions I'm missing:

* USM provides enough of a solution for the case where the network is
  not working well enough for the security infrastructure.  

* Go use something else other than SNMP to fix your network; we all
  hope the netconf folks solved this problem for us.  If not, we're
  actually not that unhappy with our CLIs when we get right down to
  it.  [Yes, this is phrased to spark discussion.]
 
* Everything will be OK; we just use ISMS.

* If you have long-lived sessions you'll probably be OK and have
  enough sessions open to fix things when they break.  If not, we can
  fall back to CLI/USM/whatever else.

* We need to consider how to bootstrap local security using the
  security infrastructure.

I think only in the last case--where you look at bootstrapping
security infrastructure--does the TCP vs UDP debate become a real
issue.  

--Sam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 May 2005 22:13:19 +0200

> since we're trying to decide if we need a secure UDP solution.

There is a secure UDP solution which is called SNMPv3/USM. People who
rely on using SNMP to fix a truly broken network can use it to get
full control over the on the wire retransmission behaviour. 

Perhaps this is the sort of disclaimer to put into secure transport 
documents which require TCP as a transport. Let the operators then
decide.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 May 2005 13:52:35 -0700

>>>>> On Mon, 9 May 2005 22:13:19 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> There is a secure UDP solution which is called SNMPv3/USM. People who
Juergen> rely on using SNMP to fix a truly broken network can use it to get
Juergen> full control over the on the wire retransmission behaviour. 

Or, keep active sessions open in the new mode.  Leave that the choice
to the operator please.  Either solution is certainly usable depending
on preference.  TCP sessions that need to be restarted don't allow for
this.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 May 2005 23:22:08 +0200

> on preference.  TCP sessions that need to be restarted don't allow for

What does "keep active sessions open in the new mode" mean? I have 
trouble to grasp the meaning of your comment.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 May 2005 14:36:54 -0700

>>>>> On Mon, 9 May 2005 23:22:08 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> What does "keep active sessions open in the new mode" mean? I have 
Juergen> trouble to grasp the meaning of your comment.

Sorry, how about: keep active ISMS sessions open

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 12 May 2005 08:04:17 +0200

<snip>
> isn't the right level to be looking at this.

No problem:-)  The command generator/SNMP manager/SNMP client runs on a server
platform that has everything a server would be expected to have and more, or can
readily acquire it.

The issue, perhaps unique to SNMP, is that the SNMP server/agent/command
responder is the one with limited facilities, perhaps Telnet/TFTP/TCP/UDP and
nothing else, where anything that SNMP needs must be added, assuming that the
platform is up to it.  And that is the system likely to have poor communications
when the network is not working too well.

So taking your statement literally, and I expect you did not quite have this in
mind, the generation/sending of the command is no problem.  It is the
authentication of it at the server (which only has Telnet etc) that may be the
challenge.

Reading security RFC and I-D I find it hard to tease out this issue; they are
couched in terms of client and server but seem to assume that the server is the
server for all protocols, client ditto.

Tom Petch

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 May 2005 10:46:07 -0400

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> <snip>
    >>  So, to send a command to your SNMP engine, you might well need
    >> DNS, OCSP, LDAP, RADIUS and Kerberos all to be working.  UDP vs
    >> TCP just isn't the right level to be looking at this.
    >> 

    Tom> No problem:-) The command generator/SNMP manager/SNMP client
    Tom> runs on a server platform that has everything a server would
    Tom> be expected to have and more, or can readily acquire it.

    Tom> The issue, perhaps unique to SNMP, is that the SNMP
    Tom> server/agent/command responder is the one with limited
    Tom> facilities, perhaps Telnet/TFTP/TCP/UDP and nothing else,
    Tom> where anything that SNMP needs must be added, assuming that
    Tom> the platform is up to it.  And that is the system likely to
    Tom> have poor communications when the network is not working too
    Tom> well.

1) If the network is not working well, central services like DNS may
   not be available to any party.

2) I constructed the example so that it was the command responder who
   needed to contact both the AAA server and the OCSP server.  So it
   is the command responder that needs all those facilities.