Subject: FW: [Isms] Coming to consensus

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 1 Jul 2005 12:17:07 -0700

Eric,

We in the ISMS WG are currently considering mechanisms to secure SNMP
transports. We are considering DTLS, TLS, SSH and BEEP as possible
candidates. I was wondering if you could provide us with insight
concerning DTLS behavior. For example, what performance differences
might Application X experience by being in a protocol stack with DTLS
and UDP when compared to that same application just over UDP? Thanks?

--Eric

-----Original Message-----
From: Kaushik Narayan [mailto:[email-masked]] 
Sent: Friday, July 01, 2005 12:05 PM
To: Fleischman, Eric
Cc: Tom Petch; [email-masked]
Subject: RE: [Isms] Coming to consensus 

Hi Eric,

  Based on this quote it would seem to me that to select SSH would imply
>that SNMP must use TCP transports only. If so, then I personally advise

>against the SSH option because our experience is that SNMP behaves 
>poorly using TCP within bandwidth limited environments. Therefore, I 
>prefer SNMP to be able to use UDP.

I am not sure that SNMPoDTLSoUDP will behave any better that SNMPoTCP
within those limited bandwidth environments.

regards,
   kaushik!

>Therefore, based on this limited
>information, it appears to me that (D)TLS is a preferable alternative 
>when compared to SSH.
>
>--Eric
>
>-----Original Message-----
>From: Tom Petch [mailto:[email-masked]]
>Sent: Friday, July 01, 2005 12:54 AM
>
> >Don't both TLS and SSH require TCP transports while only DTLS can 
> >support UDP?
>
>To quote from "draft-ietf-secsh-architecture-22.txt"
>
>"The transport layer will typically be
>       run over a TCP/IP connection, but might also be used on top of
any
>       other reliable data stream."
>
>so SSH does not need everything TCP has to offer, just reliability.  (I

>seem to recall this coming up in other places, that neither UDP nor TCP

>are right for the upper layers, leading protocol designers to cast 
>around for something that fits better.)
>
>
>
>_______________________________________________
>Isms mailing list
>[email-masked] https://www1.ietf.org/mailman/listinfo/isms

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 01 Jul 2005 18:53:02 -0700

> and UDP when compared to that same application just over UDP? Thanks?

Sure...

There are two kinds of overhead to consider: initial connection
setup and ongoing dataflow.

DTLS's connection setup is similar to that of TLS. The initial
handshake takes 2 or 3 RTTs (depending on if the server uses
the anti-DoS HelloVerifyRequest mechanism). From a computational
perspective, DTLS's overhead is the same as TLS: in the 
standard RSA mode the server has to perform one RSA private 
operation (slowish) and the client has to perform a fast one.
As with TLS there are modes in which both sides have higher
performance costs (e.g., ephemeral keying) and lower (e.g.,
pre-shared keying). Overall, connection setup costs in TLS/DTLS
are pretty similar to those in e.g., SSH.

DTLS's per-packet space overhead is on the order of 30-55 octets
per packet: 

    - 4 octets for header
    - 8 octets for sequence number
    - 8-16 octets for initialization vector (DTLS currently only
                                          supports CBC mode)
    - 10-20 octets for the MAC (10 if you use truncated MACs,
      20 if you use full HMAC-SHA1)
    - 1-16 bytes of padding (depending on message alignment)

The overhead of DTLS is 8 bytes longer than the overhead of TLS 1.1
due to the explicit sequence number required to allow out-of-order
delivery. 

There is of course computational overhead associated with enciphering
the records. However, this overhead is typically small compared to
the speed of modern computers. A fast server should be able to
do gig-speed DTLS/TLS. Obviously, if you have a slow device
you won't be able to go as fast, but it's pretty common to see
TLS in low-powered devices such as Palms and phones so I don't
expect this to be a big problem. In any case, these costs
are inherent in the encrypting and MACing process so as long as
to secure the traffic you need to pay them whatever protocol
you chooce.

best,
-Ekr

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 1 Jul 2005 22:58:22 -0700 (PDT)

HI,

I would say that the question to ask is the
1) CPU
2) space
of SNMPv3/USM vs SNMPv3/new_security_model over DTLS (v3oDTLS)

After the session setup, I would guess that the computation
cost of v3oDTLS vs SNMPv3/USM would be the memcopy of the SNMP
message. The message space difference between v3oDTLS vs
SNMPv3/USM is a little harder, since the IV and HMAC would
be "the same", but the rest of the fields in v3oDTLS would
be compared to the values of msgAuthoritativeEngineID 
(5-20 octets long),  msgAuthoritativeEngineBoots 
INTEGER (0..2147483647), msgAuthoritativeEngineTime
INTEGER (0..2147483647), msgUserName (0-32 octets long).
Thus, using DTLS, the SNMP messages could be bigger,
depending on the size of the engineID and user name!

Note that for each DTLS session, there is space info
that must be saved by each side. It takes some space
too. (But not that much.)

Regards,
/david t. perkins

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 01 Jul 2005 23:26:20 -0700

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

In most of these systems the cost of the cryptography dominates
the cost of the memcpy. 

> The message space difference between v3oDTLS vs

So, the rest of the fields are:

Header (5 bytes)
Sequence number (8 bytes)
Block padding (1-16 bytes)

The only one of these that's unique to DTLS is the header.
If you're going to have an anti-replay facility you need a sequence
number--though you could get away with one smaller than 8 bytes. If
you're going to use CBC mode then you need block padding. This is a
function of the crypto, not DTLS. Though 

Note, however, that if the extra overhead from the padding is really
significant, then it would be wise to use Counter mode rather
than CBC, whatever the session encryption protocol you're using.
TLS/DTLS don't define one but it would be easy to do so modelled
on the IPsec Counter mode. I would imagine that it would be similarly
easy to do so if one went the USM route.

> too. (But not that much.)

Well, for DTLS (or TLS or SSH, for that matter) you need
to store the sequence number and cipher and HMAC key
schedules on each side. But this is just the minimum
requirement to have a session-based cryptographic protocol.
There shouldn't be much real difference between any of the
likely candidates here.

Best,
-Ekr

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 2 Jul 2005 08:22:03 +0200

On Fri, Jul 01, 2005 at 11:26:20PM -0700, Eric Rescorla wrote:

> number--though you could get away with one smaller than 8 bytes.

USM does not use sequence numbers. USM uses loosely synchronized clocks
and allows replay within a time window. This has the effect that a lost
SNMP message does not block subsequent messages from getting processed
while the manager times out and retransmits the lost message. Am I
correct that this will be different with DTLS? Does DTLS enforce that
messages are delivered in sequence, much as TCP does?

/js

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 02 Jul 2005 00:09:00 -0700

> messages are delivered in sequence, much as TCP does?

No, it doesn't.

DTLS messages have sequence numbers which allow the recipients to
suppress duplicate records, the same way that IPsec does.  However,
data is delivered to the application in the order received, so there's
no head of line blocking.

-Ekr

---

From: "David T. Perkins" <[email-masked]>
Date: Sat, 2 Jul 2005 11:28:36 -0700 (PDT)

HI,

THis is an interesting question....

When using DTLS, a manager sends a request message, but doesn't
get back a response message. This could be due to
1) the request was not received (dropped by the net)
2) the response was not received (dropped by the net)
3) the agent has gone away (or rebooted)

What does the manager do after the application level time out?
1) resend the original UDP packet
2) resend the original SNMP message as a new DTLS packet
3) bump the v3 sequence number in the message and send a
   new DTLS packet

> messages are delivered in sequence, much as TCP does?
Note - the USM "loosely sync'ed clocks" provides both delay detection
and reply detection. DTLS sequence numbers (I believe) provides
replay detection. Does it provide delay detection, and if not,
is this important?

Regards,
/david t. perkins

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 04 Jul 2005 13:47:02 -0700

> 3) bump the v3 sequence number in the message and send a

My general view--and I think the one that's most consistent with
the way that TLS is used--is for protocols which live above
DTLS to act as much as possible as if DTLS wasn't there. This
implies to me that you shouldn't do (1). Whether you do
(2) or (3) would depend on what you do now if the transport
is UDP.

-Ekr

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 4 Jul 2005 14:35:42 -0700

Hi -

> From: "Eric Rescorla" <[email-masked]>
> To: "David T. Perkins" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, July 04, 2005 1:47 PM
> Subject: Re: FW: [Isms] Coming to consensus
>

By "v3 sequence number" do you mean the request-id (RFC 3416)
or the msgID (RFC 3412)? Assuming it's the latter, RFC 3412 is
clear: "If a request is retransmitted, a new msgID value SHOULD
be used for each retransmission."

Randy

---

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Jul 2005 07:07:19 +0200

Perhaps this is why the authors used a SHOULD?  In this case there are 
good technical reasons NOT to use a new ID.  If the underlying transport 
protocol is TCP then the application is likely not even to know that the 
"request" got retransmitted.  And that is as it should be.

Eliot

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 5 Jul 2005 15:43:17 -0700

Hi -

> From: "Eliot Lear" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, July 04, 2005 10:07 PM

The context for the question was DTLS, not TCP.

In the TCP case, the receiving application will not know that
there has been any transport-layer retransmission, and will see
the message exactly once, unless the connection failed, in which
case it might not see it at all.

In any case,

Since the SNMP engine receiving the message may suppress duplicates,
if the application generating the request is at all interested in the response,
it will need to generate a request with a fresh request-id and msgID.

The one case where one *might* want to re-transmit the SNMP message
without changing the request-id or msgID is when the request is a SetRequest
with side effects such that exactly-once execution is desired, and there are
no other guards in place (e.g. TestAndIncr, though it's not perfect) to allow
the application to determine whether it was the request or the response that
was lost.  Even in this case, there's no guarantee that the receiving engine
would suppress the duplicate.

Randy