Subject: [radext] #139: Implementation specifics should be informative

From: "radext issue tracker" <[email-masked]>
Date: Tue, 27 Nov 2012 05:22:53 -0000

#139: Implementation specifics should be informative

 - Section 3 Discussions of connected UDP sockets
 - Section 3 DIscussion of local proxy
 - Section 4.1 Discussion of connected sockets
 - Section 4.1 and 4.1.1 seems a bit implementation specific, I believe it
 should discus DTLS session/state Management instead of Table management.
 an informative description of the table is fine, but most of the text can
 be described without reference to a table.

 Here is some text that I think is more implementation neutral:

 "  DTLS implementations are subject to Denial of Service (DoS) attacks due
   to the ability of an attacker to forge UDP traffic.  RADIUS/DTLS
   servers SHOULD use the stateless cookie tracking technique described
   in [RFC6347] Section 4.2.1.  the server SHOULD NOT allocate state
   until a ClientHello packet has been received with an
   appropriate Cookie value."

 "  DTLS state MUST deleted when a TLS Closure Alert
   ([RFC5246] Section 7.2.1) or a Fatal TLS Error Alert ([RFC5246] Section
   7.2.2) is received."

 The following text tries to clarify some ambiguity around the silent
 discard behavior (I'm not convinced that this is the right behavior, but
 that is a separate issue).

   "Where the RADIUS specifications require that a packet
   received via a DTLS session be "silently discarded", such as a failed
 message authenticator validation, the DTLS session MUST
   be closed, and any TLS session
   resumption parameters for that session MUST be discarded.  The
   implementation MAY provide the capability of logging the error,
   including the contents of the silently discarded packet, and SHOULD
   record the event in a statistics counter."

 " As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
   MUST also maintain a "Last Packet" timestamp per DTLS session.  The
   timestamp SHOULD be updated on reception of a valid DTLS packet.  The
   timestamp MUST NOT be updated in other situations.  When a session
   has not received a packet for a period of time, it is labelled
   "idle".  The server SHOULD delete idle DTLS sessions after an "idle
 timeout".
   The server MAY cache the TLS session
   parameters, in order to provide for fast session resumption."

 " This session "idle timeout" SHOULD be exposed to the administrator as
   a configurable setting.  It SHOULD NOT be set to less than 60
   seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes).
   The minimum value useful value for this timer is determined by the
   application-layer watchdog mechanism defined in the following
   section."

 "RADIUS/DTLS servers SHOULD also keep track of the total number of
   DTLS sessions  They SHOULD stop the creating of new
   sessions when a large number are already being tracked.  This
   "maximum sessions" number SHOULD be exposed to administrators as a
   configurable setting."

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-radext-
  [email-masked]     |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:  milestone1
Component:  dtls         |    Version:  1.0
 Severity:  In WG Last   |   Keywords:
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/139>
radext <http://tools.ietf.org/radext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Tue, 27 Nov 2012 12:49:18 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Suggested new section:

 5.  Implementation Guidelines

    The text above describes the protocol.  In this section, we give
    additional implementation guidelines.  These guidelines are not part
    of the protocol, but may help implementors create simple, secure, and
    inter-operable implementations.

 With sub-sections for server and client.  All implementation-specific
 guidelines have been moved here.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-radext-
  [email-masked]     |  [email-masked]
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:  milestone1
Component:  dtls         |     Version:  1.0
 Severity:  In WG Last   |  Resolution:  fixed
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://tools.ietf.org/wg/radext/trac/ticket/139#comment:1>
radext <http://tools.ietf.org/radext/>