[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-dekok-radext-dtls-02 comments
On Mon, 22 Mar 2010, Alan DeKok wrote:
Also, an *explicit* note that secrets should not be re-used is
required, in my opinion. This forbids one "obvious" class of
implementations, where there's only one secret for RADIUS && RDTLS.
Sec 4.1.1 -
"Where the RADIUS specifications require that a
RADIUS packet received via the DTLS session is to be "silently
discarded", the entry in the tracking table corresponding to that
DTLS session MUST also be deleted, the DTLS session MUST be closed,
and any TLS session resumption parameters for that session MUST be
discarded."
Why is this still done when DTLS is used for a transport? IIRC in the
TCP mapped drafts this was done to mitigate possibility of loss of
protocol synchronization - not possible WRT DTLS.
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? When this occurs is
the client trusted to reestablish a DTLS session? If so why? Where is
this trust defined? Administratively?
There is an additional concern in that DTLS closure messages have no
retransmission timers and are not guaranteed to be delivered. When this
occurs future messages will be discarded by the peers DTLS stack until
the clients "lifetime" timer expires and the DTLS session is reestablished.
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?
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?
regards,
Peter
--
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/>