Re: Review of draft-ietf-radext-tcp-transport (Part II)

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> [BA] How about this?

  OK.

>    The changes to RADIUS implementations required to implement this
>    specification are largely limited to the portions that send and
>    receive packets on the network.
>  
> 
> [BA] Is this sentence necessary?  What portions of a RADIUS
> implementation **donât** relate
> To sending and receiving packets?   Iâd recommend that it be deleted.

  Implementations have re-tranmission timers for UDP sockets.  These
timers need to be disabled for TCP sockets.

  The timers are usually "internal" to an implementation, and don't
directly involve recv() or send() calls.

> [BA] You might say âSince these ports are unused by existing RADIUS
> implementations, 
> the assigned values SHOULD be used as the default ports for RADIUS over
> TCP.â

  OK.

> I would merge section 2.4 into this section so that one section can
> cover ports 
> for both RADIUS over TCP and RADIUS over TLS.

  OK.

> You might revise this section to make it clear that the advice for use
> of MIBs 
> with RADIUS over TCP also applies to RADIUS over TLS.

  I thought I'd leave that to the RTLS document.

> [BA] Suggest this section be renamed âLiveness Detectionâ.

  How about "detecting live servers" ?

>    Implementations of this specification SHOULD treat the "silently 
>    discard" texts referenced above as "silently discard and close the
>    connection." 
> 
> [BA] What is the alternative to this behavior?  Could this be a MUST?

  There are some cases where "silently discard" is OK for TCP.  I don't
recall right now, but I do remember auditing the previous documents.

  The text following that sentence outlines the situations where closing
the connection is a MUST.

>    TCP connections MAY be closed if any of the circumstances outlined 
>    below are seen.  Alternatively, the TCP connection MAY remain open if
>    any of the following circumstances are seen, but the invalid packet
>    MUST BE silently discarded.
>
> [BA] Not sure how you can do this in practice.  Are you assuming that the 
> Length field remains valid?

  Yes.  The previous MUST requirement are applied first.

  How about the clarifications to the text:

 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.

> Section 2.6.6
>
> Given the discussion in Section 1.1, Iâm wondering if this section (or
> some other section) 
> shouldnât make a recommendation on the maximum RADIUS message size
> applicable to use with
> RADIUS/EAP.  It seems to me that using a larger RADIUS message size
> would make a lot of sense. 

  Only when the transport protocol to the supplicant allows large EAP
packets.

  If the NAS sends a Framed-MTU, most RADIUS servers will honor it.
This works today when large packets are allowed.

  Alan DeKok.

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