Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05

From: Jouni Korhonen <[email-masked]>
Date: Fri, 8 Mar 2013 13:26:48 +0200

Folks,

It seems the document as such still needs more work to be
acceptable as a WG item. We will have time for a discussion
around the fragmentation in Orlando meeting agenda and see
then where to head to.

Related to this, we will also have a presentation of the
other alternative proposals seen on the list.

- Jouni & Mauricio

On Feb 22, 2013, at 1:46 PM, Alejandro Perez Mendez <[email-masked]> wrote:

> 
>> I support adopting the previous version of this draft
>> (draft-perez-radext-radius-fragmentation-04) and would support adopting
>> the current version (draft-perez-radext-radius-fragmentation-05) if a
>> mechanism was added for fragmented information in access-request prior
>> to authentication.  That is, I disagree with one of the changes the
>> authors made between 04 and 05.
> 
> Hi Sam,
> 
> we have been discussing this aspect internally, and we have concluded that the support of fragmentation prior to authentication will be re-incorporated into the next version of the document, though it will be noted that it may have the potential to allow DoS attacks.
> 
> Best regards,
> Alejandro
> 
> 
>> 
>> --Sam
>> _______________________________________________
>> radext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/radext
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Mar 2013 07:40:44 -0500

Jouni> Folks,

    Jouni> It seems the document as such still needs more work to be
    Jouni> acceptable as a WG item. We will have time for a discussion
    Jouni> around the fragmentation in Orlando meeting agenda and see
    Jouni> then where to head to.

    Jouni> Related to this, we will also have a presentation of the
    Jouni> other alternative proposals seen on the list.

    Jouni> - Jouni & Mauricio

do you have someone to speak to the alternative of just use TCP when
possible?

I actually don't consider it a strict alternative, but I do think it
should be discussed and would be happy to help present if you don't have
anything lined up.

My personal preference is that we use TCP when possible and this draft
when not.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Fri, 08 Mar 2013 09:54:57 -0500

> around the fragmentation in Orlando meeting agenda and see

  After much discussion in the past week, the fragmentation draft
authors have decided to change the draft, and re-issue it under a new
name.  The name change reflects a change in focus which we hope makes
fragmentation easier to understand.

  The net result is the same, but the underlying theory is different.
I'll give a short explanation here.

  The first goal is to work with existing RADIUS proxies.  This goal is
satisfied by using Access-Request / Access-Accept.  A User-Name is
included in the Access-Request, so that existing proxies can forward the
packets.

  The second goal is to do this *only* for authorization.  There is no
need to support "large data" for CoA, Accounting, etc.  This goal is
satisfied by using Access-Request / Access-Accept.

  The third goal is to not change existing authentication methods or
packet flows.  This goal is new, and results in the name change.  We are
no longer fragmenting "access requests", we are exchanging large amounts
of authorization data.

  The third goal is satisfied by exchanging *references* to the
authorization data in the Access-Request and Access-Accept.  These
references satisfy the requirements of RFC 6158, as pointed out by Bernard.

  The problem we're solving then becomes "how to dynamically provision
authorization data".  When defined that way, the discussion becomes
simpler.  The exchange of this data no longer affects existing
authentication methods.

  The exchange of large data happens pretty much as discussed in the
current draft.  There are technical details, of course.  These details
again become simpler when they don't affect existing methods.

  The resulting exchange is then done in three steps.

1. send pre-authentication authorization data NAS to Server.

2. authentication (as is done now)

3. send post-authentication authorization data Server to NAS.

  Step (1) finishes with a token which is used in the Access-Request for
step (2).  Step (2) finishes with a token in the Access-Accept, which
refers to step (3).

  Either or both of steps (1) and (2) can be omitted.  If the
authorization data is small enough, it can just be put into packets for
step (2).

  I hope that this explanation is clear, and satisfies the concerns
raised here.  We hope to have an updated draft ready by next week.

  Alan DeKok.