[radext] #182 (radius-fragmentation): transport review questions

["radext issue tracker" <[e-mail]>]

#182: transport review questions

 - the document should more clearly distinguish between the limiting sizes
 of messages at different layers in the stack

     Although RADIUS uses the term "packet" even for RADIUS-level
     data (RFC 2965), I'll use the following terms:
         message    - a RADIUS unit of data
         packet - a UDP unit
         datagram - an IP unit

     i.e., a single RADIUS message (up to 4096 bytes) is always
     sent in a single UDP packet, which may be sent over one or more
     IP datagrams. Thus RADIUS already relies (heavily, IMO) on
     IP-level fragmentation and reassembly.

     E.g., RADIUS specifies a max length of 4096 octets;
     the field supports the same length as a max IP
     datagram (65535). The largest IPv4 datagram that is guaranteed
     to be reassembled is 576 bytes. So RADIUS is already
     potentially sending UDP packets that can't be reassembled
     by IPv4. There's nothing I see in RADIUS that reacts to
     path MTU or even interface MTU.

 - the need to send "large amounts" of data should be better discussed

     Even the 100K data limit can generate an excessive
     burst if the network is congested. See RFC 5405.

     However, given the stop-and-go (windowsize =1) protocol
     of exchanging fragments one at a time, this probably isn't
     an issue - but it should be explained as such.

 - PMTUD is a red-herring unless RADIUS sets the DF bit

     That would be a bad idea, IMO, because RADIUS already
     allows message sizes in excess of the largest safely
     assumed MTU. There's no good reason to set DF=1
     for RADIUS packets - they're not sent at a high enough
     data rate to have problems with IPv4 ID uniqueness
     (see RFC 6864).

     However, RADIUS doesn't appear to set the DF bit,
     nor is that discussed in this doc, so this is a
     red herring.

 - nothing in RADIUS appears to avoid IP fragmentation per se

     So I don't see why that's being added here.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-radext-
  [e-mail]           |  [e-mail]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  radius-fragmentation     |    Version:
 Severity:  Waiting for Shepherd     |   Keywords:
  Writeup                            |
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/radext/trac/ticket/182>
radext <http://tools.ietf.org/radext/>