Subject: [radext] #141: Comments on Section 4.2

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

#141: Comments on Section 4.2

 Section 4.2

 The discussion of connected sockets is implementation specific.

 Should the client always initiate DTLS if it supports it?  What will a
 legacy RADIUS server do if it receives a type code of 22? Will the client
 switch over after a timeout?

 THere also is a DTLS heartbeat that can be used, which could be an
 alternative.  The DTLS heartbeat can go in the reverse direction as well.

 It might be useful for servers to support RFC 5077 stateless session
 resumption.

-- 
-------------------------+-------------------------------------------------
 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/141>
radext <http://tools.ietf.org/radext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Tue, 27 Nov 2012 13:00:21 -0000

Comment (by [email-masked]):

 - socket text has been moved to the Implementation Guidelines section.

 - clients also need a "DTLS Required" flag.  This will be added to the
 document, along with discussions of timeouts

 - legacy RADIUS servers discard non-RADIUS packets.  The first byte is
 thus irrelevant.

 - the client will not switch protocols automatically.  If it is configured
 to do DTLS, it will do DTLS.

 - references to RFC 6520 (heartbeat) and 5077 will be added.

 Severity:  In WG Last   |  Resolution:
 Keywords:               |

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