[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD review of draft-ietf-radext-tcp-transport-05
Hi Alan,
Thank you for the answers. The proposed changes answer my concerns and I
suggest that you go ahead with issuing a revised I-D.
The only terms I am still a little bit uncertain about are 'common
Internet MTU' and 'common Ethernet MTU' but I understand what you mean
and I cannot find a better term. Let us use them, and maybe other will
find something better as a term in future reviews.
Regards,
Dan
> -----Original Message-----
> From: Alan DeKok [mailto:aland@deployingradius.com]
> Sent: Monday, April 26, 2010 7:56 PM
> To: Romascanu, Dan (Dan)
> Cc: radiusext@ops.ietf.org
> Subject: Re: AD review of draft-ietf-radext-tcp-transport-05
>
> 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/>