RADEXT IETF 89 London, UK Tuesday, March 4, 2014 Meeting started 2:23PM and adjourned 3:52PM Chairs: Jouni Korhonen Mauricio Sanchez AD: Benoit Claise 1.Preliminaries a. Note Takers: Stefan Winter b. Agenda bash: no changes c. Call for new WG co-chair: Mauricio stepping down. Email Benoit if interested. d. Document Status: as per slide deck, no comments ********************************************************************************* 1. RADIUS dynamic discovery, Stefan Winter http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery - presented per slide deck; no comments - Chairs state the next step is for short WGLC of draft -11 ********************************************************************************* 2. Support of fragmentation of RADIUS packets, Diego Lopez http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation - presented as per uploaded slide deck - main issue is the lack of State/*-Password/EAP-Message in the first chunk of a fragmented packet. - Is this really a significant issue? Sam, Stefan: not worth any changes. - Lionel: just need to document that it somehow violates RFC2865. - Alan: update RFC2865, removing the MUST for fragments? - Alternatively: an EAP-Message with nonsense would also do. - Klaas: proxies - do any proxies have problems with this? - Diego: none (Alan: one historic implementation has been seen, long time ago) - unrelated issue by Sam: document review by ADs: no alarm signs. - How to go on? - many say: dont care, -04 is good enough - Benoit: would be better to document this somewhere - Alan: or add phony EAP-Message? Group: no. - Conclusion: add a sentence or two admitting that this is formally violating - RFC2865, but no known operational issues with it, so should be okay - Lionel: about the T and M bit; is there an IANA registry for those bits? - Who knows which bits exist, if later specs add more bits? - Mauricio: take it to the list (over time already) ********************************************************************************* 3. Larger Packets for Remote RADIUS over TCP, Sam Hartman http://tools.ietf.org/html/draft-hartman-radext-bigger-packets - Presented per slide deck - Sam: if you can modify your infrastructure, use TCP, can send 64K packets this is then better than fragmentation. Do we need capability discovery for this to work over proxies? Current draft uses Status-Server for Negotiation piggybacking. Could work, not very clean. - Need to work on IANA consideration to add new RADIUS code (Error). - This is considered better than Access-Reject (which would incorrectly suggest end-to-end failure). - Alan: is okay for me. - Mauricio: would be good moment to add to charter; many things from charter are now almost finished. Wait for those other drafts to be final, then well possible to add it. - Sam: would want a cross-reference from fragmentation to bigger-packets and and back. - Benoit: is this on the charter already, or should it be added? Looks to be on charter already. - Show of hands: unanimous that this is good work, so adopt as WG item. Chairs will confirm on ML. ********************************************************************************* 4. RADIUS Extensions for Port Set Configuration and Reporting, Jaqueline http://datatracker.ietf.org/doc/draft-cheng-behave-cgn-cfg-radius-ext/ - Presented per slide deck - Alan: why extended space? Chairs: no more space left in standard space. - Alan: then give datatypes draft priority. - Alan: is this about the number of TCP ports allowed to use? Yes; but that is not easily visible in the draft. - Alan: don't make complex datatypes. - Chairs: read draft? Pleasant surprise: many. Interested in this work? Again pleasant surprise; draft has momentum. - Will confirm on mailing list; open up charter discussion to get this on. - Lionel: Do we have a clear requirement definition for conversation between - AAA server and NAS? Does this all have to be in a AAA conversation? - Could be by-reference (like with Filter-Id). Jouni: broadband typically pulls all config via AAA conversation; this is standard practice. - Jouni: should ask authors for more details. - Arran: slightly odd way of operation; more natural would be "allocate fixed range" or "allocate on demand"; but this draft doesn't allow for that. ********************************************************************************* 5. CoA Proxying, Alan DeKok - Presented per slide deck - Stefan: Operator-Name is also what dynamic discovery uses; looks like natural continuation and useful work - Chairs: could become chartered if current work items are finished. ********************************************************************************* 6. RADIUS Extensions for Key Management in WLAN network, Li https://datatracker.ietf.org/doc/draft-xue-radext-key-management/ - Stefan and others: why does this have to RADIUS? Could be any protocol as it distributes keys (not related to AAA interaction) - Lionel: other issues - layer 2 link, security, IP address assignment - none of this is RADIUS. This does not fit into RADIUS framework. - Chairs: suggest to take work to the mailing list. Maybe there is a better protocol than RADIUS - people on the list will undoubtedly comment on a possible better place.