Re: AD review of draft-ietf-radext-tcp-transport-05

[Alan DeKok <aland@deployingradius.com>]

Romascanu, Dan (Dan) wrote:
> The issues are divided into Technical (T) and Editorial (E). 
> 
> T1. The document is marked as EXPERIMENTAL. It would be useful if it
> mentions in one of the introductory sections what are the goals and
> limitations (if any) of the experimental deployment and what would be
> the success criteria of the experiment that would allow for taking the
> document to the standards track later. 

  Suggested text for Section 1 (Introduction).  Move the last paragraph
from Section 1.2 to higher up in the document, and add some text:

...
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.

"Bare" TCP transport MAY, however, be used when another method such as
IPSec [RFC4301] is used to provide additional confidentiality and
security.  Should experience show that such deployments are useful,
this specification could be moved to standards track.
...

> T2. Section 2.2: 
> 
>>  Since these ports are unused by existing RADIUS implementations, the
>    assigned values SHOULD be used as the default ports for RADIUS over
>    TCP.
> 
> Why is this a SHOULD and not a MUST? 

  No reason...  I'll change it.

> T3. Section 2.3 needs a complete re-writing: 
...
> The correct solution is for the MIB documents to be updated in the
> future with new MIB objects of appropriate syntax. For the time being
> the only thing that this section should say is that the MIB modules do
> not support RADIUS over TCP and that they will need to be updated in the
> future. 

  Suggest replacing the text in 2.3 with:

The MIB Module definitions in [RFC4668], [RFC4669], [RFC4670],
[RFC4671], [RFC4672], and [RFC4673] are intended to be used for RADIUS
over UDP.  As such, they do not support RADIUS over TCP, and will need
to be updated in the future.  Implementations of RADIUS over TCP
SHOULD NOT re-use these MIB Modules to perform statistics counting for
RADIUS over TCP connections.

> T4. The following section in 2.6.1 is confusing: 
> 
>>  Much of the discussion in this section can be summarized by the
>    following requirement.  RADIUS requests MAY be re-transmitted
>    verbatim only if the following 5-tuple (Client IP address, Client
>    port, Transport Protocol, Server IP address, Server port) remains the
>    same. 

  I think it's best to simply delete that paragraph.

> T5. The last paragraph in 2.6.1: 
> 
>>   The above requirement is necessary, but not sufficient in all cases.
>    Other specifications give additional situations where the packet is
>    to be considered as a new request.  Those recommendations MUST also
>    be followed.
> 
> Having a MUST requirement over undefined 'other specification' is not
> implementable. I would suggest to either clarify what are these 'other
> specifications' or take this out. 

  OK.  I'll delete it.

> E1. Please expand TLS at first occurrence. 

  Done.

> E2. The Introduction section speaks about 'the default Internet MTU
> (576). Strictly speaking this value is not standardized in any place,

  That should be the "common Internet MTU".  The text could say:

These packets are larger than the common
Internet MTU (576), resulting in fragmentation of the packets at the
IP layer when they are proxied over the Internet.

> and later in section 1.1 reference is made to RADIUS packets being
> restricted to 1500 octets in size. Looks like an unnecessary
> inconsistency. 

  That is for a different use-case.  I can update that text to say:

For example, where EAP-TLS authentication [RFC5216] is
attempted and both the EAP peer and server utilize certificate chains
of 8KB, as many as 15 round-trips can be required if RADIUS packets
are restricted to the common Ethernet MTU (1500 octets) for EAP over
LAN (EAPoL) use-cases.

> E3. Section 1.2 - the syntax in the RADIUS server definition is
> inconsistent with the syntax of the rest of the definitions

  OK.  That could say:

A device that provides one or more of authentication, authorization,
and/or accounting (AAA) services to a NAS.


> E4. Section 2.6.7: 
> 
>>  We RECOMMEND that implementors of this specification
>    familiarize themselves with TCP application programming concepts.  We
>    RECOMMEND also that existing TCP applications be examined with an eye
>    to robustness, performance, scalability, etc.
> 
> The use of capitalized (a la 2119) keywords in a personalized phrase
> does not make much sense. RECOMMEND is not a keyword actually. I suggest
> rephrasing. 

  Changed to: "It is RECOMMENDED that..."

  If this looks OK, I'll issue an updated draft tomorrow.

--
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/>