[radext] #7: IESG DISCUSS comments
"radext issue tracker" <trac@tools.ietf.org> Thu, 13 May 2010 22:26 UTC
Return-Path: <owner-radiusext@ops.ietf.org>
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656783A6876 for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Thu, 13 May 2010 15:26:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.395
X-Spam-Level:
X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZycnTbKBdPnL for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Thu, 13 May 2010 15:26:14 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BCCF43A67FA for <radext-archive-IeZ9sae2@lists.ietf.org>; Thu, 13 May 2010 15:26:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1OCgm1-0008l4-RQ for radiusext-data0@psg.com; Thu, 13 May 2010 22:20:57 +0000
Received: from [2001:1890:1112:1::2a] (helo=zinfandel.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <trac@tools.ietf.org>) id 1OCglw-0008kY-Ty for radiusext@ops.ietf.org; Thu, 13 May 2010 22:20:53 +0000
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1OCglv-0000Gb-04; Thu, 13 May 2010 15:20:51 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: radext issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.6
Cc: radiusext@ops.ietf.org
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: aland@deployingradius.com, iesg@ietf.org
X-Trac-Project: radext
Date: Thu, 13 May 2010 22:20:50 -0000
Reply-To: radiusext@ops.ietf.org
X-URL: http://tools.ietf.org/radext/
Subject: [radext] #7: IESG DISCUSS comments
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/7
Message-ID: <054.d27c5aec83dba9effc0acd5c01a691fb@tools.ietf.org>
X-Trac-Ticket-ID: 7
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: aland@deployingradius.com, iesg@ietf.org, radiusext@ops.ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>
#7: IESG DISCUSS comments -----------------------------------+---------------------------------------- Reporter: iesg@… | Owner: aland@… Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: status-server | Version: 1.0 Severity: Submitted WG Document | Keywords: -----------------------------------+---------------------------------------- Date first submitted: April 21, 2010 Reference: http://datatracker.ietf.org/doc/draft-ietf-radext-status- server/ Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSSes are resolved. Russ Housley Comment (2010-04-21) Please consider the comments from the Gen-ART Review by Francis Dupont: - Abstract page 2: there is an explicit reference to a RFC, this is in general forbidden but IMHO we are here in the allowed exception case. - 2.1.1 page 8: a servers policy -> a server policy - 3 page 10 (twice): etc. -> etc., ??? - 4.2 page 13: adminstrators -> administrators - 4.2 page 15 (twice): e.g. -> e.g., - 4.3 page 16: modelled -> modeled - 4.3 page 16: usually the hysteresis against flapping tries to keep the connection (i.e., failover after 3 missed responses), here it is the opposite. IMHO it is very aggressive but it is how RFC 3539 works so I have no concern about it. - 4.5 page 16: Proxyhas -> Proxy has - 4.5 page 17: cannot, -> cannot - 4.5 page 18: i.e. -> i.e., - 5 page 19: EAP-MEssage -> EAP-Message - 8 page 23: synthesise -> synthesize - 8 page 23: in "the suggestion of [RFC5080] Section 2.2.2, which suggests" suggests -> proposes - 8 page 23: configurably is not in my dict? - 9.2 page 23: IMHO the RFC2119 reference should be moved to normative references section (perhaps others too?) - Authors' Addresses -> Author's Address Jari Arkko Comment (2010-04-22) The document says: The "hop by hop" functionality of Status-Server packets is useful to RADIUS clients attempting to determine the status of elements on the path between the client and a server. This should read: ... determine the status of the first element on the path between ... (because you are not forwarding from the proxy and there are no security associations from a client to proxies beyond the first one, there is no way to test proxies 2 and onwards) The document notes on the discussion of codes and port numbers: However, as the category of [RFC2866] is Informational, this conflict is acceptable. This is merely a statement about the status of various RFCs. Personally, the substantive change is that this new RFC would allow a new code to be used on port 1813. I think it should do an "Updates: RFC 2866" and get it over with. Lars Eggert Discuss (2010-04-19) Section 4.1., paragraph 2: > The client SHOULD also have a configurable global timer (Tw) that is > used when sending periodic Status-Server queries during server fail- > over. The default value SHOULD be 30 seconds, and the value MUST NOT > be permitted to be set below 6 seconds. If a response has not been > received within the timeout period, the Status-Server packet is > deemed to have received no corresponding Response packet, and MUST be > discarded. DISCUSS: I would like to discuss two issues with this design. First, since it is only RECOMMENDED to implement Tw and not REQUIRED, clients need not do so. How do clients without Tw decide that a server has not responded? Second, there is no discussion on what rate clients should be using when *issuing* Status-Server queries. The current text allows a client to send Status-Server queries to the server at high rates, and does not require the client to reduce its sending rate when it receives no responses. In other words, there currently isn't any sort of congestion control. Has this been discussed by the working group? It seems like all the pieces are already there to implement a simple congestion control scheme: have clients issue at most one request per Tw (already implied by Section 4.3 text but not clearly stated anywhere), double Tw up to some conservative maximum when the server does not respond, restore the initial Tw when it does (Section 4.3 again has some text that goes into that direction). Comment (2010-04-19) Section 1812., paragraph 4: > The server MAY prioritize the handling of Status-Server packets over > the handling of other requests, subject to the rate limiting > described above. Without congestion control, implementing this MAY guarantees that the minimum amount of useful (= non-Status-Server) work will be done. Section 4.3., paragraph 3: > If no response is received to Status-Server packets, the RADIUS > client can initiate failover to another proxy. By continuing to send > Status-Server packets to the original proxy at an interval of Tw, the > RADIUS client can determine when the original proxy becomes > responsive again. This uses Status-Server messages as an overload detection mechanism. They need to be sent in a way that will back off the rate under overload, because otherwise the scheme can turn into an overload *generation* mechanism. Section 4.5., paragraph 17: > It is RECOMMENDED, therefore, that implementations desiring the most > benefit from Status-Server also implement server failover. The > combination of these two practices will maximize network reliability > and stability. If Status-Server messages are being sent in a way that is congestion controlled (i.e., the rate is reduced under overload). Tim Polk Comment (2010-04-22) I support Lars' and Peter's discuss positions. Robert SparksComment (2010-04-22) Support Lars' discuss re: limiting message rates If there is a reason to perform a major edit on this document, please consider splitting the "documenting what was deployed" and "recommending fixes" into clearly separate sections (if not documents). Peter Saint-Andre Discuss (2010-04-20) Is the use of MD5 in generating the Response Authenticator subject to collision attacks? If not, it would be helpful to describe why not, and provide a reference to RFC 4270. If so, then the security considerations need to be updated. Comment (2010-04-20) Given that the Request Authenticator should be unpredictable and unique, a reference to RFC 4086 would be appropriate. Please add a reference to RFC 1321 for the definition of MD5. Sean Turner Comment (2010-04-21) I support Peter's discuss. Additionally, I noted the same thing Peter did wrt to random numbers. Section 3: In the Request Authenticator description the two paragraphs repeat that Request Authentication SHOULD be unpredictable and then says why. Maybe the second paragraph should be tweaked: The Request Authenticator value in a Status-Server packet SHOULD also be unpredictable **because** an attacker **could** trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Status-Server request from a client. -- Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/7> radext <http://tools.ietf.org/radext/> -- 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/>
- [radext] #7: IESG DISCUSS comments radext issue tracker
- Re: [radext] #7: IESG DISCUSS comments radext issue tracker
- Re: [radext] #7: IESG DISCUSS comments radext issue tracker