Subject: Re: [radext] Kathleen Moriarty's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS and COMMENT)

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 9 Feb 2015 18:26:28 -0500

Alan,

Thanks for adding int he proposed text into the latest version.  Clearing
now.

Kathleen

On Wed, Jan 21, 2015 at 2:31 PM, Kathleen Moriarty <
[email-masked]> wrote:

> Alan,
>
> On Wed, Jan 21, 2015 at 2:18 PM, Alan DeKok <[email-masked]>
> wrote:
> > On Jan 21, 2015, at 1:21 PM, Kathleen Moriarty <
> [email-masked]> wrote:
> >> In the security considerations section, I didn't see a discussion on
> >> packet re-assembly and associated security issues such as overlapping
> >> fragments.
> >
> >   There are no overlapping fragments.  The fragmentation method was
> designed to avoid that.
> >
> >   Unlike IP, there is no “fragment offset” field.  There is simply a
> “fragment length” field.  The fragments are requested and received in
> lock-step order.  The data in each fragment is appended to the previous
> data.
> >
> >>  If there is a reference that already covers that in the
> >> draft, I missed it and would appreciate you pointing me to it.
> >
> >   Section 12.4 says:
> >
> >    This proposal does not modify the way RADIUS interacts with the
> >    underlying transport (UDP).  That is, RADIUS keeps following a lock-
> >    step behaviour, that requires receiving an explicit acknowledge for
> >    each chunk sent.
> >
> >  The overview in Section 4 describes the process.  But it doesn’t
> explicitly say that the fragments are simply appended.  It just says:
> >
> >    … When all the chunks have
> >    been received, the original list of attributes is reconstructed and
> >    processed as if it had been received in one packet.
> >
> >  which leaves the “reconstruction” process open to interpretation.
> >
> > We could add a short paragraph after the preaching text:
> >
> > The reconstruction process is performed by simply appending all of the
> chunks together.  Unlike IPv4 fragmentation, there is no “fragment offset”
> field.  The chunks in this specification are explicitly ordered, as RADIUS
> is a lock-step protocol, as noted in Section 12.4.  That is, chunk N+1
> cannot be sent until all of the chunks up to and including N have been
> received and acknowledged.
> >
> >   We could also add text to the end of Section 12.4:
> >
> > Another benefit of the lock-step nature of RADIUS, is that there are no
> security issues with overlapping fragments.  Each chunk simply has a
> length, with no “fragment offset” field as with IPv4.  The order of the
> fragments is determined by the order in which they are received.  There is
> no ambiguity about the size or placement of each chunk, and therefore no
> security issues associated with overlapping chunks.
>
> Thank you for the quick response and proposed text, this looks very
> good and I think is helpful.  I'll switch to a yes when this text is
> added.
>
> --
>
> Best regards,
> Kathleen
>

-- 

Best regards,
Kathleen