Jouni Korhonen wrote: > 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.
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. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
