[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[radext] #7: IESG DISCUSS comments
#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/>