Re: draft-dekok-radext-dtls-02 comments

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> On Mon, 22 Mar 2010, Alan DeKok wrote:
>>  In DTLS, the crypto layer ensures that packets have not been modified.
>> Therefore, the only time that packets are malformed is when the sender
>> has sent bad data.  When that happens, they should no longer be trusted
>> to do *anything*.
> 
> I understand DTLS provides encryption and integrity protection.  I don't
> understand why the peer should no longer be trusted?

  If the peer manifestly fails to implement RADIUS, then it can no
longer be trusted to implement RADIUS.

>  When this occurs
> is the client trusted to reestablish a DTLS session?  If so why?  Where
> is this trust defined? Administratively?

  So long as the client implements RADIUS, it can be trusted.  Since
more than one implementation may live at a particular IP address, *new*
connections from that IP cannot be forbidden if one misbehaves.

>>  Yes.  Too bad.  If someone can't be bothered to implement RADIUS
>> properly, their software won't work that well.
> 
> There are valid reasons to ignore a request.  See RFC2138 Sec 3.
> "Unrecognized packet codes are silently discarded"  If a server does not
> recognize a packet code sent by its peer does that mean the DTLS session
> needs to be dropped?

  Why is the client sending non-RADIUS packets to a RADIUS server?

> If so how does one implement new packet codes in the future or co-exist
> with systems that do not support all currently allocated packet codes?

  RADIUS has traditionally had a strong relationship between destination
port and packet codes.  The list of packets allowed to be sent to port
1812 hasn't really changed in 15 years.  When new codes are defined
(e.g. CoA), new ports are defined, too.  RDTLS follows this practice.

  This practice also means that servers *not* implementing a packet code
simply ignore *all* packets sent to a port... including DTLS connection
requests.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>