[radext] IETF 89: Preliminary meeting notes

["Sanchez, Mauricio" <[e-mail]>]

Below are preliminary meeting notes for your review  They are also posted on
IETF website (http://www.ietf.org/proceedings/89/minutes/minutes-89-radext).
Thanks go to Stefan for note taking.

Please post any corrections/feedback to mailing list.

Thanks,
Jouni and Mauricio 

‹‹‹‹‹‹‹‹‹‹‹‹
RADEXT
IETF 89
London, UK

Tuesday, March 4, 2014
Meeting started 2:23PM and adjourned 3:52PM

Chairs:
Jouni Korhonen <jouni.korhonen at broadcom.com>
Mauricio Sanchez <mauricio.sanchez at hp.com>

AD:
Benoit Claise <bclaise at cisco.com>


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
<no draft exists at this time, presentation on what could be interesting
work in radext>
- 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.