[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[radext] #24: GEN-ART review of draft-ietf-radext-tcp-transport
#24: GEN-ART review of draft-ietf-radext-tcp-transport
---------------------------------------+------------------------------------
Reporter: aland@â | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: tcp-transport | Version:
Severity: Active WG Document | Keywords: GEN-ART
---------------------------------------+------------------------------------
Subject:
Gen-ART LC review of draft-ietf-radext-tcp-transport-06.txt
From:
Glenn Kowack <glenn@RiverOnce.com>
Date:
Tue, 18 May 2010 01:58:50 -0400
To:
draft-ietf-radext-tcp-transport@tools.ietf.org
CC:
gen-art@ietf.org
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: <draft-ietf-radext-tcp-transport-06.txt>
Reviewer: Glenn Kowack
Review Date: 2010-05-18 (late; my apologies)
IETF LC End Date: 2010-05-11
IESG Telechat date: not known
Summary: This document should be ready for publication as an Experimental
RFC after clarifications (a few are minor; most are nits/editorial). The
ideas appear sound, but the style of the document tends toward
conversational, creating opportunities for ambiguity and confusion. The
text should be more direct and conventional.
Major issues: None.
Minor issues:
Abstract:
âThe Remote Authentication Dial In User Server (RADIUS) Protocol has
traditionally used the User Datagram Protocol (UDP) as its underlying
transport layer.â
Does âtraditionalâ here mean as defined by the specification or is UDP use
optional?
âIt is not intended to define TCP as a transport protocol for RADIUS in
the absence of TLS.â
This might be interpreted by some as disingenuous. Would it be clearer to
say: âThe specification only provides for use of TCP with TLS. Other uses
of TCP are out of scope.â ?
1. Introduction
âSince "bare" TCP does not provide for confidentiality or enable
negotiation of credible ciphersuites, its use is not appropriate for
inter-server communications where strong security is required. As a result
the use of "bare" TCP transport (i.e., without additional confidentiality
and security) is NOT RECOMMENDED, as there has been little or no
operational experience with it.â
This paragraph is confusing. It begins with a clear:
âSince "bare" TCP does not provide for confidentiality or enable
negotiation of credible ciphersuites, its use is not appropriate for
inter-server communications where strong security is required.â
And another clear statement:
âAs a result the use of "bare" TCP transport (i.e., without additional
confidentiality and security) is NOT RECOMMENDED,ââ
But adds: ââ as there has been little or no operational experience with
it.â
That is, the document says there are inherent reasons why TCP is not
appropriate, and then says the reason is lack of experience. This should
be unwound and clarified.
1.1. Applicability of Reliable Transport
âFor a system with a million logins a day running EAP-TLS mutual
authentication with 15 round-trips, and having a packet loss probability
of P=0.01%, we expect that 0.3% of connections will experience at least
one lost packet. That is, 3,000 user sessions each day will experience
authentication failure. This is an unacceptable failure rate for a mass-
market network service.â
Can the document state an acceptable level of failure, and a supporting
citation?
Nits/editorial comments:
1. Introduction
âThe RADIUS Protocol has been defined in [RFC2865] as using the User
Datagram Protocol (UDP) for the underlying transport layer.â
Present tense would be clearer, unless 2865 is no longer applicable.
â2.4, there are also some limitations:
* Unreliable transport. As a result, systems using RADIUS have to
implement application-layer timers and re-transmissions, as described in
[RFC5080] Section 2.2.1.â
Add a blank line between the â2.4â line and the first bullet item, per the
rest of the document.
âAs RADIUS is widely deployed, and has been widely deployed for well over
a decade, these issues have been minor in some use-cases, and problematic
in others.â
The leading âasâ is awkward and not necessary, per this example: âRADIUS
has been widely deployed for well over a decade, and still is. Experience
shows issues that are minor in some use-cases, and problematic in others.â
2.3. Management Information Base (MIB)
âThe MIB Module definitions in [RFC4668], [RFC4669], [RFC4670], [RFC4671],
[RFC4672], and [RFC4673] âââ SHOULD NOT re-use these MIB Modules to
perform statistics for RADIUS over TCP connections.wâ
Typo: trailing âwâ at end of paragraph.
2.4. Detecting Live Servers
âAs RADIUS is a "hop by hop" protocol, a RADIUS proxy effectively shields
the client from any information about downstream servers.â
âeffectivelyâ adds nothing here. However, this change is stylistic and at
the discretion of the author.
âWhen UDP was used as a transport protocolââ
Present tense is more appropriate.
2.6.1. Duplicates and Retransmissions
âIn that situation, RADIUS request MAY be retransmitted to another server
that known to be part of the same pool.â
s/that known/that is known/
[ Running a grammar checker (e.g., in MSWord) should have found this. ]
2.6.4. Malformed Packets and Unknown Clients
âAfter applying the above rules, there are still situations where the
previous specifications allow a packet to be "silently discarded". In
these situations, the TCP connections MAY remain open, or MAY be closed,
as an implementation choice. However, the invalid packet MUST be silently
discarded.
* Packet with an invalid code field
* Response packets that do not match any outstanding request
These requirements minimize the possibility for a misbehaving client or
server to wreak havoc on the network.â
This section would be clearer if the two bullets immediately followed
where they are first mentioned, after ââallow a packet to be âsilently
discarded.â"
Also, does the author mean âminimizeâ or just âreduceâ, above?
2.6.5. Limitations of the ID Field
ââthere would be no free Id to useââ
s/Id/ID/
This reviewer would like to observe that this is one of the most astute
and downright clever Freudian observations about the IETF that he has seen
in many years. He takes his hat off to the author. Sadly, accurately
using upper-case-D âIDâ regrettably MUST win out over literary invention.
âshould reserve ID zero on eachâ
s/ID zero on each/ID zero (0) on each/
âImplementors may be tempted to extend RADIUS to permit more than 256
outstanding packets on one connection. However, doing so will likely
require fundamental changes to the RADIUS protocol, and as such, is
outside of the scope of this specification.â
Two points are confounded here, as illustrated by:
Implementors may be tempted to extend RADIUS to permit more than 256
outstanding packets on one connection. However, doing so is a violation
of a fundamental part of the protocol and SHOULD NOT be done. Making that
extension here is outside of the scope of this specification.
_end review comments
--
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/24>
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/>