Subject: [Isms] Re: TCP, UDP and the rest of the infrastructure

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Jul 2005 14:04:30 -0400

>>>>> "Fleischman," == Fleischman, Eric <[email-masked]> writes:

    Fleischman,> From: Sam Hartman [mailto:[email-masked]]
    Fleischman,> wrote:
    >> Making SNMP work in an unreliable network may not be very
    >> useful if things it depends on for security do not work.

    Fleischman,> I thoroughly agree. However, is there any reason why
    Fleischman,> you (or anyone else) believe that DTLS doesn't
    Fleischman,> provide the necessary capabilities to permit
    Fleischman,> ISMS-secured SNMP over UDP use?

The SNMP part of the connection will be over UDP.  What about CRL
retrieval?  What about OCSP?  What about DNS lookups for all of the
above?

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 06 Jul 2005 11:38:35 -0700

Sam Hartman <[email-masked]> writes:

> retrieval?  What about OCSP?

Of course, in the vast majority of SSL/TLS implementations don't
really do any of this stuff. They just accept certificates if they're
transitively signed by some trust anchor.

That said, how important this consideration is rather depends on
the reasons for using UDP. In most of the environments I'm 
familiar with, UDP is used because it has different performance
properties (for a broad definition of performance), mostly in
terms of timeliness, not because TCP isn't available. In the specific
case of certificate-based handshakes where status checking is being
used, one would presumably use TCP to do the status checking during
the handshake, but this wouldn't be relevant after the session is
completed.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Wed, 06 Jul 2005 21:06:30 +0200

Eric Rescorla wrote:

> In the specific

Right.  Even if one uses DTLS for SNMP, that doesn't mean it's necessary
to use UDP for the other support services (it probably isn't).

Eliot

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 6 Jul 2005 13:28:18 -0700 (PDT)

HI,

Sam - you highlight a huge frustration that I (and probably others)
have with the IETF security community. It appears that the "rules"
are always being changed.

The major goal of the ISMS WG is to use existing security
infrastructures. If a system has a X.509 cert and it is
being used for something else (like a a WEB server), and
now the SNMP agent also wants to use a X.509 cert, it seems
like you are saying with the below, that this cannot be
done, since the "dirty little secret of using X.509 certs
(which is revocation)" has not been solved, and it must be
before SNMP can use certs.

Is this what you are saying? Or I'm I reading too much inbetween
the lines?

> retrieval?  What about OCSP?  What about DNS lookups for all of the

Regards,
/david t. perkins

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 06 Jul 2005 16:38:55 -0400

>before SNMP can use certs.

I don't believe that Sam is saying that.  I think what he's trying to
say is, "Hey, let's consider what the backend authentication protocol
is doing when we ask if we want UDP or TCP".

For example ... some people say that they want UDP because it scales
better, or it performs better on lossy networks.  What I've interpreted
Sam's comments to mean is "Maybe you should ask yourself this question:
if my SNMP protocol can traverse a lossy network fine, but to
authenticate I need to use TCP to talk to some backend server (e.g., to
fetch a CRL, talk to my LDAP server), is that useful?"

--Ken

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 06 Jul 2005 13:58:51 -0700

> fetch a CRL, talk to my LDAP server), is that useful?"

Well, obviously this depends on the reason you want to use UDP.
However, the scaling arguments about UDP vs TCP usually focus
on the need with TCP to keep a whole bunch of TCP connections
open at once. Without making an argument about whether that's
true or not, if you use TCP for OCSP or CRL fetching, these
would be short-lived connections so the same arguments wouldn't
apply.

-Ekr

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Jul 2005 16:48:17 -0400

>>>>> "David" == David T Perkins <[email-masked]> writes:

    David> HI, Sam - you highlight a huge frustration that I (and
    David> probably others) have with the IETF security community. It
    David> appears that the "rules" are always being changed.

Well, security is still evolving so the rules will change.  However
they have not done so in the way you claim--at least I'm not proposing
such a change.  But with every new effort we need to learn from the
mistakes of the past and to do a somewhat better job than we have done
in the past.  If that's what you are frustrated by in terms of rules
changing, I can understand your frustration although I expect to
contribute to it.

That said, it is important not to change the rules too much.  Creating
pressure for evolution is good in my mind.  Creating so much pressure
that we do not accomplish our goals is not.
    David> The major goal of the ISMS WG is to use existing security
    David> infrastructures. If a system has a X.509 cert and it is
    David> being used for something else (like a a WEB server), and
    David> now the SNMP agent also wants to use a X.509 cert, it seems
    David> like you are saying with the below, that this cannot be
    David> done, since the "dirty little secret of using X.509 certs
    David> (which is revocation)" has not been solved, and it must be
    David> before SNMP can use certs.

    David> Is this what you are saying? Or I'm I reading too much
    David> inbetween the lines?

I think you are reading way too much in between the lines;)

All I wanted to say is that you should consider that there may be
other services SNMP depends on from a security standpoint.  The set of
services will grow over time.  This may influence whether UDP is a
requirement.

I did not intend to say that I expect you to require OCSP, CRL
retrieval etc any more than any other use of PKI.  I do expect these
services to be used in the future.