Subject: Question on reliable transports

From: Alan DeKok <[email-masked]>
Date: Sun, 05 Oct 2008 16:34:16 +0200

I've been working on the TCP && DTLS drafts, and have a few questions
for a wider audience, especially those with experience deploying RadSec.

  First, there appears to be a fair bit of overlap between the
discussion of TCP as a reliable transport, and the reliable transport
offered by DTLS.  Many of the issues surrounding lack of retransmission,
transport-layer "connections", etc. are the same.

  My thought was to slightly re-target the TCP draft to be a "RADIUS
over reliable transport" draft.  The result would be a draft that
applies to both TCP and DTLS, and possibly to future reliable transports
for RADIUS.  Any TLS issues would be left to the DTLS draft, which could
then concentrate on security, rather than on reliable transport.

  Does this approach seem reasonable to the list?  The drafts are still
individual submissions, but the may be WG drafts at some point in the
future, so obtaining consensus now would be a positive step.

  The second issue is what to do about accounting over reliable
transport.  Accounting-Request packets that do not get "accepted"
silently fail with the server failing to respond to the client.  i.e.
there is no Accounting-NAK packet in RADIUS.

  The issue here is that this behavior severely limits the utility of
reliable transport.  If the accounting server does not ACK a series of
Accounting-Request packets, then the client must wait for timeouts
before re-using the request ID's.  When coupled with the limit of 256
packets being sent over one connection, these limits may result in an
upper bound of only a few packets/s.

  How do these issues affect real-world deployments of RadSec?  Is it a
problem?  If so, is a solution required?

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 5 Oct 2008 09:19:10 -0700

The suggested approach seems reasonable to me.   This is more or less the same reasoning
that led to having RFC 3539 cover SCTP as well as TCP. 

> Date: Sun, 5 Oct 2008 16:34:16 +0200
> From: [email-masked]
> To: [email-masked]
> Subject: Question on reliable transports
>

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 6 Oct 2008 12:52:28 +0700

Bernard Aboba  <mailto:[mailto://[email-masked]%5d>
[mailto://[email-masked]] writes:

.

> offered by DTLS. 

I'm just trying to figure out what the "reliable transport offered by DTLS"
might be.  AFAICT, RFC 4347 defines a kind of pseudo-reliability (including
retransmission timers, buffering of out-of-order messages, etc.) for the
DTLS handshake but not for records (which is presumably where the actual
RADIUS messages would reside).

.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 06 Oct 2008 11:05:28 +0200

Glen Zorn wrote:
> I'm just trying to figure out what the "reliable transport offered by
> DTLS" might be.  AFAICT, RFC 4347 defines a kind of pseudo-reliability
> (including retransmission timers, buffering of out-of-order messages,
> etc.) for the DTLS handshake but not for records (which is presumably
> where the actual RADIUS messages would reside).

  Hmm... going back and reading it again, it's pretty obvious.  No
reliable transport.  It even says that.

  OK.  Looking at RFC 4279 (TLS PSK), the RC4 methods are forbidden by
RFC 4347.  The other methods CBC, which means that they can't be
randomly accessed.  So the PSK methods appear to be unsuitable for DTLS.
 RFC 4785 defines PSK with NULL encryption methods, which isn't good for
our purposes.  The following draft proposes a Galois Counter Mode for
PSK: draft-ietf-tls-psk-new-mac-aes-gcm-03.txt

  The description of the GCM method says that the results can be
calculated in parallel, which would seem to mean it's suitable for
random access.  But I'm not a crypto expert, and I don't know for sure.

  The DTLS-SRTP draft (draft-ietf-avt-dtls-srtp-05.txt) defines it's own
encryption methods.

  Maybe Hannes has some comments here?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 08 Oct 2008 08:44:20 +0200

Glen Zorn wrote:
> I don't understand.  Why would random access(whatever that means in this
> context) matter?

  Many common TLS cipher suites depend on cipher block chaining, or CBC.
 This means that receiving out of order packets is impossible, because
you need packets 0..N in order to decrypt packet N+1.

  A stream cipher with random access means that if you miss out on
packet N, you can "seek" to a position that lets you decode packet N+1.
 Other encryption methods allow similar behavior without using stream
ciphers.

  I've taken a look at other DTLS drafts, and none mention required
cipher suites.  I've looked at DTLS packet traces, but Wireshark doesn't
decode DTLS packets (yet).

  Looking at the OpenSSL source code, the only cipher suite it forbids
for DTLS is RC4.  Which makes me wonder if CBC mode maybe does work...

  Alan DeKok.