Subject: RE: [Isms] TLS / SSH scalability concerns

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 13 May 2005 09:44:45 -0700

Hi,

With regard to SIP using DTLS, folks may want to read
<draft-jennings-sip-dtls-00.txt> (February 2005).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Eliot Lear
> Sent: Friday, May 13, 2005 12:39 PM
> To: Blumenthal, Uri
> Cc: [email-masked]
> Subject: Re: [Isms] TLS / SSH scalability concerns
> 
> 
> I think there might be some truth on both sides of this issue.  For 
> instance, maintaining established sessions goes to Juergen's 
> point that 
> you need to keep getting the biggest baddest largest server to manage 
> "All of This".  On the other hand, if you're not taking 
> authentication 
> steps on each packet there's something to be gained, I'm sure.
> 
> I think it's safe to say that people know how to deal with 
> both.  And I 
> actually think a whole lot of people know a whole lot more about TLS. 
> That has certain benefits.  I would imagine the same thing 
> will be able 
> to be said about DTLS, assuming a major app picks it up.  SIP? 
> Something else?
> 
> Eliot
> 
> Blumenthal, Uri wrote:
> >>FYI (in case you not already know):
> >>
> >>http://www.umiacs.umd.edu/docs/Du.ppt
> >>
> >>They concluded that SNMP/TLS was more efficient than USM. 
> > 
> > 
> > And I have a very nice bridge for sale in the vicinity of NYC. :-)
> > 
> > 
> >>Anyway, these results need to be taken w/ a grain of salt as
> >>there are many factors (e.g. # msgs per session) that may
> >>affect the results.
> > 
> > 
> > The facts are:
> >   - SNMP spends extra cycles on ASN.1 security wrapping/unwrapping;
> >   - TLS spends extra cycles on TCP overhead;
> >   - TLS has large session establishment overhead;
> >   - DES/AES and MD5/SHA1 is done by both, and the cost is similar.
> > 
> > Therefore, the more messages are sent within one long session - the
> > greater the chance of amortizing the session establishment 
> cost and come
> > out even (seems rather obvious). As for TLS solution 
> turning out *more*
> > efficient - forgive me for not entirely trusting those 
> results (assuming
> > apples-to-apples comparison, i.e. using SNMPv3 in both cases).
> > 
> > _______________________________________________
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> > 
> > 
> 
> _______________________________________________
> 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: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Fri, 13 May 2005 11:26:01 -0700

Is it possible that the way USM uses DES causes inefficiency?
DES is a stream cipher, but USM uses it to encrypt short messages.
DES IV needs to be re-initialized repeatedly for each USM message,
and the IV salt needs to be appended to each message.  That seems 
to be more overhead compared to TLS (init DES only once per session)

I don't know much about DTLS, but it may face a similar issue 
(i.e. using stream ciphers to encrypt short, unreliable datagrams)  
Does anyone know how DTLS solves this issue?  Does it need to
re-init DES per datagram?

Khanh 

> From: Blumenthal, Uri [mailto:[email-masked]] 
> 
> The facts are:
> Therefore, the more messages are sent within one long session 
> - the greater the chance of amortizing the session 
> establishment cost and come out even (seems rather obvious). 
> As for TLS solution turning out *more* efficient - forgive me 
> for not entirely trusting those results (assuming

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 13 May 2005 14:38:24 -0400

> Is it possible that the way USM uses DES causes inefficiency?

Hmm, maybe... But to a noticeable extent...?

> DES [you mean CFB mode] is a stream cipher, but USM uses it to encrypt
> short messages. DES IV needs to be re-initialized repeatedly for each
> USM message, and the IV salt needs to be appended to each message. 
> That seems to be more overhead compared to TLS (init DES only once
> per session)

True... Good observation!

> re-init DES per datagram?

On the other hand, not reinitializing the IV can lead to attacks...

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Fri, 13 May 2005 12:17:16 -0700

>> I don't know much about DTLS, but it may face a similar issue (i.e. 
>> using stream ciphers to encrypt short, unreliable datagrams) Does 
>> anyone know how DTLS solves this issue? Does it need to re-init DES 
>> per datagram?
> 

That's right.  That's why I don't think DTLS (or any datagram transport)
can do any better than USM regarding this issue.
 
Khanh

---

From: "McDonald, Ira" <[email-masked]>
Date: Sat, 14 May 2005 15:46:10 -0700

Hi,

DTLS is explained (in current <draft-rescorla-dtls-04.txt>)
in terms of differences from TLS/1.1 (work-in-progress from
IETF TLS WG).  In particular, note the following excerpts:

3.1. Loss-insensitive messaging

   In TLS's traffic encryption layer (called the TLS Record
   Layer), records are not independent. There are two kinds of
   inter-record dependency:

      1. Cryptographic context (CBC state, stream cipher key
      stream) is chained between records.

      2. Anti-replay and message reordering protection are
      provided by a MAC which includes a sequence number, but the
      sequence numbers are implicit in the records.

   The fix for both of these problems is straightforward and
   well-known from IPsec ESP [ESP]: add explicit state to the
   records. TLS 1.1 [TLS11] is already adding explicit CBC state
   to TLS records. DTLS borrows that mechanism and adds explicit
   sequence numbers.

<...>

4.1.2.2. Null or standard stream cipher

   The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL
   cipher.

   The only stream cipher described in TLS 1.1 is RC4, which
   cannot be randomly accessed. RC4 MUST NOT be used with DTLS.

4.1.2.3. Block Cipher

   DTLS block cipher encryption and decryption are performed
   exactly as with TLS 1.1.

4.1.2.4. New Cipher Suites

   Upon registration, new TLS cipher suites MUST indicate whether
   they are suitable for DTLS usage and what, if any, adaptations
   must be made.

Cheers,
- Ira

> Behalf Of Khanh Nguyen (khanhvn)
> Sent: Friday, May 13, 2005 2:26 PM
> To: Blumenthal, Uri
> Cc: [email-masked]
> Subject: RE: [Isms] TLS / SSH scalability concerns
> 
>

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 16 May 2005 09:28:26 -0700

Khanh,

I've seen those figures as well as another study stating that SNMP
performed better over TCP than over UDP. However, our own experience is
that local environmental issues dramatically effect performance. For
example, performance characteristics over wired LANs and wired WANs can
differ, depending on local factors. The performance deltas within
wireless environments can be quite significant, depending on whether one
is using WLANs, Mobile IP, NEMO, or MANET. TCP performance over
satellites is becoming well known and significantly impacts the
application being conveyed. My point being that the reason I have been
emphasizing the need for flexibility is because there are so many
different possible environments, and large enterprises need to be able
to tweak configurations appropriately.

--Eric

-----Original Message-----
From: Khanh Nguyen (khanhvn) [mailto:[email-masked]] 
Sent: Thursday, May 12, 2005 2:49 PM
To: [email-masked]; [email-masked]
Subject: RE: [Isms] TLS / SSH scalability concerns

They concluded that SNMP/TLS was more efficient than USM.  Anyway, these
results need to be taken w/ a grain of salt as there are many factors
(e.g. # msgs per session) that may affect the results.

Khanh

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Mon, 16 May 2005 12:30:20 -0700

> From: Fleischman, Eric [mailto:[email-masked]] 
> 
> Khanh,
> 
> I've seen those figures as well as another study stating that 
> SNMP performed better over TCP than over UDP. However, our 
> own experience is that local environmental issues 
> dramatically effect performance. For example, performance 
> characteristics over wired LANs and wired WANs can differ, 
> depending on local factors. The performance deltas within 
> wireless environments can be quite significant, depending on 
> whether one is using WLANs, Mobile IP, NEMO, or MANET. TCP 
> performance over satellites is becoming well known and 
> significantly impacts the application being conveyed. My 
> point being that the reason I have been emphasizing the need 
> for flexibility is because there are so many different 
> possible environments, and large enterprises need to be able 

Eric,

I am with you about this.  I just have some concerns about 
the efficency of using UDP for secure transport.  UDP in 
general has less overhead than TCP, but the situation may 
be reversed when security is added (e.g. DTLS has more 
overhead than TLS).  Anyway, efficiency is just one of
many factors to be considered, and I agree with you that 
SNMP should have the transport flexibility, and let the 
operators decide what's best for their environments.

Khanh

> Anyway, these

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Mon, 16 May 2005 16:31:08 -0700

> From: David T. Perkins [mailto:[email-masked]] 
> 
> Have you compared DTLS using SHA and AES vs USM using SHA and AES?

No, and I am not aware of any performance analysis/test that 
compares DTLS-AES vs USM-AES.  AES CBC modes is similar to 
DES, so I guess DTLS-AES will have similar overhead as DTLS-DES.   
 
BTW, this brough up a related issue:  I am wondering if 
DES/AES OFM (Output Feedback Mode) is more suitable than CBC 
mode (which DTLS uses) to encrypt unreliable UDP datagrams.
OFM was designed for noisy/lossy channel (e.g. satelite 
communication).  Unlike CBC, OFM blocks can be decrypted 
individually, and transmission errors do not propagate to 
the next blocks, so OFM may be a good fit for unreliable 
UDP transport & troubleshooting mal-function networks.  
Another alternative is the new CRT (Counter) mode that NIST
recently adopted for AES.  Like OFM, CRT blocks can be 
decrypted individually.  

> Using a new security model will allow the definition of 
> syntax of the msgSecurityParameters field, since it probably 
> no longer needs many of the values needed to support USM 
> (since they are part of either session establishment or done by DTLS).

That's true.

Khanh

> Regards,
> /david t. perkins

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Mon, 16 May 2005 16:45:30 -0700

> From: Wes Hardaker [mailto:[email-masked]] 
> 
> Khanh> FYI (in case you not already know):
> Khanh> http://www.umiacs.umd.edu/docs/Du.ppt
> 
> Wes> After that presentation was given, I actually stood up to the 
> Wes> microphone and explained a number of the biases in it that made
it 
> Wes> an unfair comparison.
> 
> I should follow that up with it's not that I don't believe 
> that the results are true.  They may be.  I just don't trust 
> that particular data set at all to draw that conclusion from.

Sure.  Their test cases seem to be very limited.  We don't 
have other empirical data to either confirm of counter their 
conclusions, but I think in the end, things may go both ways
depend on the environments.

Khanh

> --
> Wes Hardaker
> Sparta, Inc.