Subject: [radext] #7: IESG DISCUSS comments

From: "radext issue tracker" <[email-masked]>
Date: Thu, 13 May 2010 22:20:50 -0000

#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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Fri, 14 May 2010 06:35:38 -0000

#7: IESG DISCUSS comments
-----------------------------------+----------------------------------------
 Reporter:  iesg@…                 |        Owner:  aland@…                  
     Type:  defect                 |       Status:  closed                   
 Priority:  blocker                |    Milestone:  milestone1               
Component:  status-server          |      Version:  1.0                      
 Severity:  Submitted WG Document  |   Resolution:  fixed                    
 Keywords:                         |  
-----------------------------------+----------------------------------------
Changes (by aland@…):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 addressed in -08

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

---

From: "radext issue tracker" <[email-masked]>
Date: Fri, 14 May 2010 06:35:11 -0000

Type:  defect                 |      Status:  assigned                 

  * status:  new => assigned

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