* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Radext Status Pages

RADIUS EXTensions (Active WG)
Ops Area: Robert Wilton, Warren Kumari | 2004-Jul-14 —  
Chairs
 
 


IETF-90 radext minutes

Slides

These are also available from the materials page:
RADIUS fragmentation
RADIUS Extensions for Port based Devices
CoA proxying
RADIUS data types
Populating EAP-Identity
Session 2014-07-23 1520-1650: Salon A - Audio stream - radext chatroom

Minutes

minutes-90-radext minute



          *********************************************************************************
          1. RADIUS Extensions for IP Port Configuration and Reporting, Dean Cheng
          draft-ietf-radext-ip-port-radius-ext-01
          - presented per slide deck
          - First draft presented at IETF89
          - No significant changes to outer TLVs
          - New Sub-TLVs added from discussions on mailing list
          - Clarification of when Sub-TLVs are optional/required depending on
          parent TLV.
          - IANA numbers requested in extended namespace for TLVs
          - Stefan: Protocols such as TCP, UDP, ICMP are enumerated, what about
          SCTP and others, too exotic?
          - Jouni: Can't SCTP run over UDP, could it be represented that way?
          - Arran: Maybe?
          - No consensus on protocol enumeration, further discussion required.
          - Arran: Is there support for reporting on PCP invoked mappings?
          - Dean: No not currently.
          - Discussion to continue on mailing list.
          - Next steps - More comments are reviews from working group.
          
          2. Support of fragmentation of RADIUS packets, Diego Lopez
          draft-ietf-radext-radius-fragmentation-07
          - presented per slide deck
          - Stefan raised 6 issues since 06 but all have been (will be addressed)
          in 07 before TSVDIR
          - Status hopefully moved to "Waiting for TSVDIR review"
          - Alan: Can't do fragmentation across internet with CoA because 5176
          doesn't support proxies.
          - Diego: Will note this in the document.
          - Alan: Known issue being worked on.
          - Section 6 not clear about fragmentation limits in both total size
          limit and packet count.
          - Diego: New section clarifies specification use, does not interact with
          transport layer.
          - Next steps - Minimal issues to resolve (Stefan will hopefully,
          remotely smile)
          
          3. Dynamic Authorization Proxying in Remote Authorization Dial-In User
          Service Protocol (RADIUS), Alan DeKok
          draft-dekok-radext-coa-proxy-00
          - presented per slide deck
          - This has been progressing for the past two years with Jouni as Co-Author
          - Describes how to use CoA proxying in a Roaming environment, RFC 5176
          says you can, but doesn't define how.
          - Solution to add Operator-Name and Operator-NAS-Identifier attribute
          to specify path to home server.
          - Operator-Name now in use by Eduroam
          - Implemented today in FreeRADIUS
          - Sam (via Jim): Include discussion about security considerations,
          traceability, reusing same Operator-NAS-Identifier with multiple sessions.
          - Alan: Given current state of security in RADIUS (mostly cleartext)
          probably not an issue.
          
          4. Data Types in the Remote Authentication Dial-In User Service Protocol
          (RADIUS)
          draft-dekok-radext-datatypes-02
          - presented per slide deck
          - Fix long standing issue in RADIUS - Past ~22 years RADIUS has used
          TLVs from dictionaries, but none define data types.
          - RFC2865 defined some but most others haven't. Has lead to conflicts.
          - What do we do? Add an IANA registry for data types, and an RFC to
          define them.
          - Next steps - Accept as WG document, publish as standards track, start
          using data types in new specifications
          - Benoit: Do we only apply data types from now on, for new
          RFCs/attributes?
          - Alan: Most attributes already defined without conflict (except maybe
          RFC 3162).
          - Alan: Vendors have already created data types for IPv6, this formalises
          that.
          - Alan: Not many uses for brand new data types.
          - Alan: This document defines types for all existing attribues.
          - Dean: Can we reference existing RFCs (2865 et al) for data types?
          - Alan: Sure, but there's no registry. Better just to push this document
          quickly. New documents should reference this draft.
          - Dean: For integer types should a size be specified?
          - Alan: No there are two types 'integer' (32bits) and 'integer64'
          (64bits) no point in defining smaller integers, as gains are minimal.
          
          5. Considerations regarding the correct use of EAP-Response/Identity
          draft-winter-radext-populating-eapidentity-00
          - presented per slide deck
          - Seeks to solve issues with encoding non UTF8 identities, and identity
          selection.
          - Draft still doesn't have a home, hopefully adopted by radext?
          - Alan: invalid radius packet? which technically correct no one actually
          cares about what's in the username?
          - Stefan:
          - Alan: What about 802.11u it advertises available realms?
          - Stefan: 802.11u doesn't solve the problem, too many realms to encode
          in eduroam.
          - Stefan: AP can also just send 'I am member of consortium X' instead,
          which doesn't help here.
          - Other draft RFC 3579 (EAP/RADIUS) uses Calling-Station-ID when no
          User-Name available. Has this been considered?
          - Stefan: Not considered, will read RFC, appreciate comments.
          
          Documents to be adopted by working group
          - Jouni: Three new documents (coa-proxy, datatypes, eapidentity) what's
          the consensus for adoption?
          - Alan: Unsurprisingly supports adoption of his drafts (coa-proxy,
          datatypes).
          - Jim: eapidentity - advisory at best, probably doesn't make sense at
          this moment.
          - Jim: Doesn't care about coa-proxy. But datatypes should have been done
          years ago, Sam/Jim will review.
          - Lionel: Fine with coa-proxy and datatypes.
          - Benoit: Is existing charter sufficient for the the new documents
          (coa-proxy, datatypes)? Or recharter necessary?
          - Jouni: Will try to find justification to move forward under existing
          charter.
          
          Interest in implementing Coa Proxy
          - Alan/Benoit: Anyone else interested in implementing CoA proxy? Would
          be good to have another implementation?
          - Room: Not really...
          - Alan: Operator-Name in widespread use today.
          - Alan: CoA-Proxying is a major issue, so it should still move forward.
          
          Discussion around moving documents to the standards track
          - Jim: Proposes moving TLS (RFC6614) from experimental to the standards
          track.
          - Alan: Agrees. TLS in widespread use. Should republish with no
          changes. DTLS can probably wait for now.
          - Alan: Accounting (RFC 2866) is still informational, should that be
          republished too?
          - Alan: Does experimental/informational status cause any real problems?
          - Jim: Issue with experimental is if it has dependencies (like ABFAB
          has for TLS) it's harder to progress it, informational easier.
          - Benoit: Probably not much point for accounting.
          
          



Generated from PyHt script /wg/radext/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -