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

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 21 Jan 2015 10:21:46 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-radext-radius-fragmentation-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In the security considerations section, I didn't see a discussion on
packet re-assembly and associated security issues such as overlapping
fragments.  If there is a reference that already covers that in the
draft, I missed it and would appreciate you pointing me to it.

In a quick search, I found a couple of references that may be useful for
some text/reference on details of this attack type,  but are at the IP
layer.  The draft already prevents other attack types that involve
ordering and size of fragments with lengths included, so this is just
meant to ask about overlapping fragments.

Section 4 of: https://tools.ietf.org/html/rfc1858
https://tools.ietf.org/html/draft-ietf-6man-overlap-fragment-03

Examples might overlap to change any part of the AAA data once
reassembled.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work on this draft, I also agree that it is well written
and placed well as experimental.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 21 Jan 2015 14:31:31 -0500

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 21 Jan 2015 14:18:54 -0500

Section 12.4 says: