Subject: Re: [radext] #15: DTLS Comments

From: "radext issue tracker" <[email-masked]>
Date: Wed, 07 Nov 2012 19:30:06 -0000

#15: DTLS Comments

Changes (by aland@…):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  RDTLS => dtls

Comment:

 This issue has 3 items in it.  In order:

 1) I wonder if a more general warning about the possibility of down-
 negotiation would be a better fit.

 Sure.  Suggest text.  Don't just say "do more".

 2) Why is this still done when DTLS is used for a transport?

 Very simple. If you're not going to send RADIUS packets, then the RADIUS
 server shouldn't be talking to you.  The issue of "unrelated exchanges" is
 a red herring.

 3) Encouraging (change SHOULD NOT to MAY) can only shine light on the
 issue and force implementors to address appropriately.

 No.  This is a security issue.  NASes which implement DTLS should use it.
 Otherwise, the protocol would be subject to a downgrade attack.

-- 
-----------------------------------+-------------------------
 Reporter:  peterd@…               |       Owner:  aland@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:  milestone1
Component:  dtls                   |     Version:  1.0
 Severity:  Candidate WG Document  |  Resolution:  wontfix
 Keywords:                         |
-----------------------------------+-------------------------

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

---

From: "radext issue tracker" <[email-masked]>
Date: Wed, 07 Nov 2012 21:47:00 -0000

#15: DTLS Comments

Comment (by peterd@…):

 WRT 2) what is the reason or benefit for silent discard as opposed to
 maintaining parity with RADIUS/UDP behavior where the underlying transport
 currently need not be blessed or re-established?

 My concern with unnecessarily terminating DTLS sessions you increase the
 possibility of existing in the region where packet loss cannot be
 disambiguated from a closed session from perspective of the sender.  This
 requires a longer delay than necessary before the client attempts a new
 DTLS session.

 If one is to require behavior with the strongest MUST language then an
 affirmative technical justification should be available as to why the
 behavior is NECESSARY.

 Separately this response further assumes silent discard means the request
 is somehow invalid.  This is incorrect.

 Accounting request may be silently discarded if the RADIUS server is
 unable to take responsibility for logging or forwarding a particular
 accounting message to persistent storage.

 RADIUS messages may be silently discarded if they contain an unrecognized
 command code.

 With regards to "red herring" I believe my point is valid - any pending
 responses will in fact be discarded by UNECESSARY closure of DTLS session.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Wed, 07 Nov 2012 22:42:40 -0000

#15: DTLS Comments

 possibility of existing in the region where packet loss cannot be
 disambiguated from a closed session from perspective of the sender.

 My response is the same as before.  If the sender doesn't implement
 RADIUS, he has NO BUSINESS talking to the RADIUS server.

 Please describe in detail why it's a good idea to maintain DTLS
 connections to a client which is sending you crap packets.  It makes
 absolutely no sense.

 > Separately this response further assumes silent discard means the
 request is somehow invalid. This is incorrect.

 I disagree.  The RFCs are clear on this topic.  Only invalid packets are
 silently discarded.  There is no text anywhere saying valid packets may be
 "silently discarded"

 Absolute nonsense.  See RFC 2866.  The accounting packets are "silently
 discarded" when they are malformed.

 The accounting server may choose to NOT RESPOND.  However, it does not
 "silently discard" the request, as per the definition in Section 1.1. of
 RFC 2866.

 > RADIUS messages may be silently discarded if they contain an
 unrecognized command code.

 Yes.  The RFCs make it clear which command codes are allowed to be sent to
 which ports.  If the client violates that,

 This is a security issue for me, which trumps being polite.  A client
 which sends "good" RADIUS packets followed by garbage to the RADIUS server
 is misbehaving.  It is not implementing the RADIUS protocol.  It is
 potentially compromised, and is attacking the RADIUS server.

 The only sane thing to do when a client sends garbage is to stop talking
 to it.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Wed, 07 Nov 2012 23:28:06 -0000

#15: DTLS Comments

Comment (by peterd@…):

 Sec 1.1 of RFC 2866
 "This means the implementation discards the packet without further
 processing.  The implementation SHOULD provide the capability of logging
 the error, including the contents of the silently discarded packet, and
 SHOULD record the event in a statistics counter."

 Sec 1.1 of draft-ietf-radext-dtls-02
 "This means that the implementation discards the packet without
      further processing.  See Section X.Y for additional requirements on
      packets being silently discarded."

 How does "ignoring" an accounting packet because you know you can't do
 anything with it differ from the definition of silent discard based on
 definitions referenced?  How is the reader to understand difference
 between ignore and silent discard?

 Sec 4.1 draft-ietf-radext-dtls-02:

 "Last Packet
      A variable containing a timestamp which indicates when the last
      valid packet was received for this connection.  Packets which are
      "silently discarded" MUST NOT update this variable."

 With regards to security client has already authenticated itself to
 server.  To assume a security benefit one must assume ALL of the systems
 security has already failed in which case the well of value has already
 dried up.

 I think there is additional benefit in maintaining parity with RADIUS.
 RADIUS/UDP servers are not required to distrust any further communication
 if they receive a packet they don't like.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Thu, 08 Nov 2012 00:25:19 -0000

#15: DTLS Comments

 definitions referenced?

 Because "silently discard" has a well-defined meaning, as stated in
 Section 1.1, and used throughout the document.  The discussion of not
 responding says this:

    If the RADIUS accounting server is unable to successfully record the
    accounting packet it MUST NOT send an Accounting-Response
    acknowledgment to the client.

 Note it doesn't say "silently discard" the request.  It says it doesn't
 send a reply.

 > How is the reader to understand difference between ignore and silent
 discard?

 I can't really answer that.  If the difference isn't obvious, I suggest
 asking the WG to re-write RFC 2866.

 > RADIUS/UDP servers are not required to distrust any further
 communication if they receive a packet they don't like.

 Sure.  But there's no connection in UDP.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Thu, 08 Nov 2012 02:37:31 -0000

#15: DTLS Comments

Comment (by peterd@…):

 Having quoted 1.1 in its entirety I observed no text dedicated to
 constraining underlying reason during definition of "silent discard".

 What seems to be implied since silent discard happens to be used to
 describe failures such as malformed requests or bad authenticators an
 implicit constraint is created against the meaning of the term.

 I disagree.  I believe definitions exist on their own outside of their
 use.

 Regardless there still should be a valid technical justification to
 support a MUST requirement.  The only technical justification provided was
 security which does not seem credible given TLS layer is completely
 responsible for security of the system.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Thu, 08 Nov 2012 03:10:56 -0000

#15: DTLS Comments

 It would help to read the rest of RFC 2865.  Section 1.1 defines what is
 meant by "silently discard".  The rest of the document describes the
 situations (and reasons) why you "silently discard" a packet.

 I fail to see why there is ANY controversy here.  RFC 2865 has been out
 for over a decade.  It's predecessors are nearly 20 years old.  This is
 the first indication that anyone has any issue with that text.

 Inventing a straw man doesn't make your position stronger.

 use.

 Straw man.

 > Regardless there still should be a valid technical justification to
 support a MUST requirement.

  Straw man.

 I've been explaining the technical justification.  Have you been reading
 my messages?

  >The only technical justification provided was security which does not
 seem credible given TLS layer is completely responsible for security of
 the system.

 Nonsense.  By that "logic", there's no need to verify the format of a
 RADIUS packet received via DTLS.  After all, the TLS layer is completely
 responsible for security, so anything it sends you MUST be well formed,
 right?  So there's no need to verify the packet format, the attribute size
 / content, etc.  You can just rely on TLS security.  By that "logic", we
 shouldn't worry about viruses spreading over HTTPS.  After all, the
 connection is "secured" by TLS.

 One last time:

 When a RADIUS server has a DTLS connection to a client, the client is
 expected to send RADIUS packets inside of that DTLS connection.  If,
 instead, the client sends non-RADIUS packets, then the connection is non-
 RADIUS.  There is no reason for a RADIUS server to talk to a client that
 isn't doing RADIUS.  Having a DTLS transport for non-RADIUS doesn't
 matter.  The RADIUS server only talks RADIUS.

 And yes, I understand your position.  There is little to no application
 cost to throw away a malformed RADIUS packet received inside of a DTLS
 datagram.  The issue is I don't *care* about the application cost.  I care
 about network security.

  I will not reply to any further comments on this topic.  I have explained
 my position, and had it countered via straw-man arguments.  I've asked for
 explanations of your position, and gotten little more than "just 'cause".

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

---

From: "radext issue tracker" <[email-masked]>
Date: Thu, 08 Nov 2012 04:27:40 -0000

#15: DTLS Comments

Comment (by peterd@…):

 I have no problem with RFC 2865 definition of silently discard.  I have a
 problem with a characterization of silently discard not supported by
 existing text.

 Unfortunately after going back and checking I see no technical
 justification for a MUST requirement other than the security reference.

 Obviously trust established using DTLS between client and server does not
 preclude server from acting in any way it deems appropriate to protect
 itself from the client.

 The problem no evidence has been supplied to support why this approach
 would in any way be effective in helping the server protect itself to
 justify a MUST requirement.  While text requires disconnection of the TLS
 session nothing in this document prevents client from simply reconnecting
 and continuing its assault on the server with impunity.

 RADIUS does not specify punitive actions against peers it believes may be
 acting in bad faith other than what is necessary to ensure the integrity
 of the protocol.  The integrity of RADIUS/DTLS is not credibly affected by
 unnecessarily disconnecting DTLS sessions to punish an implementation.

 I think it is important everything possible is done to minimize instances
 of server DTLS session closure to what is absolutely necessary to prevent
 unnecessary service delays.

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