_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

=
RADEXT WG IETF 89 Agenda  

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

Jabber room: radext at jabber.ietf.org (Please join)
TUESDAY, March 4, 2014
1420-1550  Afternoon Session II (90 mins)
Richmond/Chelsea/Tower

14:20 - 14:30, Preliminaries (5 minutes)
------------------------------------------
Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda bash
Document Status

Note Well
-------------------------------------------

Any submission to the IETF intended by the Contributor for publication as a=
ll
or part of an IETF Internet-Draft or RFC and any statement made within the
context of an IETF activity is considered an "IETF Contribution". Such
statements include oral statements in IETF sessions, as well as written and=

electronic communications made at any time or place, which are addressed to=
:

 o The IETF plenary session
 o The IESG, or any member thereof on behalf of the IESG
 o Any IETF mailing list, including the IETF list itself, any working group=

   or design team list, or any other list functioning under IETF auspices
 o Any IETF working group or portion thereof
 o Any Birds of a Feather (BOF) session
 o The IAB or any member thereof on behalf of the IAB
 o The RFC Editor or the Internet-Drafts function

All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979
(updated by RFC 4879).

Statements made outside of an IETF session, mailing list or other function,=

that are clearly not intended to be input to an IETF activity, group or
function, are not IETF Contributions in the context of this notice.  Please=

consult RFC 5378 and RFC 3979 for details.

A participant in any IETF activity is deemed to accept all IETF rules of
process, as documented in Best Current Practices RFCs and IESG Statements.

A participant in any IETF activity acknowledges that written, audio and
video records of meetings may be made and may be available to the public.=0B

Document Status
-------------------------------------------
 * All RADEXT I-Ds are either past WGLC or in publication process.

 o draft-ietf-radext-ieee802ext -> IESG
 o draft-ietf-radext-dtls       -> pending ACK -> proto write-up
 o draft-ietf-radext-nai        -> proto write-up
 o draft-ietf-radext-dynamic-discovery -> pending ACK -> proto write-=
up
 o draft-ietf-radext-radius-fragmentation -> short WGLC -> proto writ=
e-up

Working group draft discussion (20 minutes)
-------------------------------------------

14:25 - 14:35 RADIUS dynamic discovery, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

14:35 - 14:45 Support of fragmentation of RADIUS packets, Diego Lopez (10 m=
inutes)
http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation

Chartered individual draft discussion (15 minutes)
--------------------------------------------------

14:45 - 15:00 Larger Packets for Remote RADIUS over TCP, Sam  Hartman (15 m=
inutes)
http://tools.ietf.org/html/draft-hartman-radext-bigger-packets

Individual draft discussion (40 minutes)
----------------------------------------

15:00 - 15:15 RADIUS Extensions for Port Set Configuration and Reporting, J=
aqueline (15 minutes)
http://datatracker.ietf.org/doc/draft-cheng-behave-cgn-cfg-radius-ext/

15:15 - 15:25 CoA Proxying, Alan (10 minutes)
Presentation

15:25 - 15:40 RADIUS Extensions for Key Management in WLAN network, Li (15 =
minutes)
https://datatracker.ietf.org/doc/draft-xue-radext-key-management/

Wrap-up (10 minutes)
--------------------
15:40 - 15:50 Next Steps: WG Chairs & ADs (10 minutes) 
WG Goals/Milestones status, next steps 
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 intere=
sted.  
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 a=
go)
- 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 violati=
ng
- 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 Negotia=
tion 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 sug=
gest end-to-end failure).
- Alan: is okay for me.
- Mauricio: would be good moment to add to charter; many things from charte=
r 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 an=
d and back.
- Benoit: is this on the charter already, or should it be added? Looks to b=
e on charter already.
- Show of hands: unanimous that this is good work, so adopt as WG item. Cha=
irs 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? Aga=
in 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 betwee=
n
- 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 p=
ulls 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 fix=
ed 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 nat=
ural 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 - no=
ne 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.
The
   authors acknowledge this is formally violating [RFC2865], but there
   are no known operational issues with it.  Once this document goes
   beyond being considered as experimental, it will state it updates
   [RFC2865].
A new version of I-D, draft-ietf-radext-radius-fragmentation-05.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Name:		draft-ietf-radext-radius-fragmentation
Revision:	05
Title:		Support of fragmentation of RADIUS packets
Document date:	2014-03-07
Group:		radext
Pages:		28
URL:            http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-fragmentation-05.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/
Htmlized:       http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-05

Abstract:
   The Remote Authentication Dial-In User Service (RADIUS) protocol is
   limited to a total packet size of 4096 octets.  Provisions exist for
   fragmenting large amounts of authentication data across multiple
   packets, via Access-Challenge.  No similar provisions exist for
   fragmenting large amounts of authorization data.  This document
   specifies how existing RADIUS mechanisms can be leveraged to provide
   that functionality.  These mechanisms are largely compatible with
   existing implementations, and are designed to be invisible to
   proxies, and "fail-safe" to legacy clients and servers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

The
   authors acknowledge this is formally violating [RFC2865], but there
   are no known operational issues with it.  
Once this document goes
   beyond being considered as experimental, it will state it updates
   [RFC2865].
A new version of I-D, draft-ietf-radext-radius-fragmentation-05.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Name:		draft-ietf-radext-radius-fragmentation
Revision:	05
Title:		Support of fragmentation of RADIUS packets
Document date:	2014-03-07
Group:		radext
Pages:		28
URL:            http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-fragmentation-05.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/
Htmlized:       http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-05

Abstract:
   The Remote Authentication Dial-In User Service (RADIUS) protocol is
   limited to a total packet size of 4096 octets.  Provisions exist for
   fragmenting large amounts of authentication data across multiple
   packets, via Access-Challenge.  No similar provisions exist for
   fragmenting large amounts of authorization data.  This document
   specifies how existing RADIUS mechanisms can be leveraged to provide
   that functionality.  These mechanisms are largely compatible with
   existing implementations, and are designed to be invisible to
   proxies, and "fail-safe" to legacy clients and servers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

The
   authors acknowledge this is formally violating [RFC2865], but there
   are no known operational issues with it.  
The
   authors acknowledge this is formally violating [RFC2865], but no
   operational issues are expected as no known implementation 
   perform that verification when proxying Access-Requests, since doing so would
   preclude them to support future extensions. 

Once this document goes
   beyond being considered as experimental, it will state it updates
   [RFC2865].
A new version of I-D, draft-ietf-radext-radius-fragmentation-05.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Name:		draft-ietf-radext-radius-fragmentation
Revision:	05
Title:		Support of fragmentation of RADIUS packets
Document date:	2014-03-07
Group:		radext
Pages:		28
URL:            http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-fragmentation-05.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/
Htmlized:       http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-05

Abstract:
   The Remote Authentication Dial-In User Service (RADIUS) protocol is
   limited to a total packet size of 4096 octets.  Provisions exist for
   fragmenting large amounts of authentication data across multiple
   packets, via Access-Challenge.  No similar provisions exist for
   fragmenting large amounts of authorization data.  This document
   specifies how existing RADIUS mechanisms can be leveraged to provide
   that functionality.  These mechanisms are largely compatible with
   existing implementations, and are designed to be invisible to
   proxies, and "fail-safe" to legacy clients and servers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

Hello,

with my shiny new chair hat on:

While it is true that an implementer of 6929 does not need to see this
document, it is also true that this document is effectively allocating a
bit from a structure that is in that document.  If this document does
not update 6929, then it is possible that the next document to update
that structure will fail to notice this and allocate the same bit for a
different purpose.

  I hope we're all smart enough to remember that the bit is allocated.
If we're not... the WG should be shut down.

I believe it's a bad idea to rely on collective memory or a mailing list
archive.

So, regardless of what the consensus will be: try an "Updates" or not;
create an IANA registry or not - the fact that a loosely-knit
relationship to RFC6929 exists, and where the pitfalls are, should be
reflected inside the draft itself.

As for where - I think it helps to keep in mind that that there will be
numerous rounds of reviewing going on after the document has cleared WGLC.

In particular, the Operations Area will conduct an ops-dir review as
part of the IETF LC. There are very specific questions in the ops-dir
review template, one of which is:

"Are there any coexistence issues?"

The probability that an ops-dir reviewer will pick up the T-Bit
allocation coexistence issue during his reading are very high
(especially if the proto write-up mentions this as one of the
contentious points :-) ); so if that issue is not explicitly documented,
it will probably surface at that point, and we'll need to deal with it.

We can of course wait for that to happen, but I'd rather preempt such a
useless extra round and fix the issue in the draft right now.

Another question in the ops-dir review is

"Is an operational considerations and/or manageability section part of
the document?"

I believe the best way forward is to add such a section to the draft (it
could be a sub-section of Introduction, or be a section of its own). The
section would document what was argued on the mailing list, where the
pitfalls are, and that an "Updates" would be a reasonable possiblity to
avoid them if allowed by process.

With that text in the document, the WG can then try to use Updates or
not - and the reason for doing so can then be found in the document
itself. If the actual Updates relationship later doesn't fly, the text
highlighting the issue will at least still be in there - and not in
someone's brain or deep down in the ML archives. I realise that the text
then wouldn't necessarily be found by someone implementing a follow-up
spec to RFC6929 due to lack of an Updated-By, but chances are at least
way better.

(And as an individual: if we have an Operations/Manageability section
anyway at that point - wouldn't it be a good idea to move the "formal
violation of RFC2865" into that section as well? )

Greetings,

Stefan Winter

I believe that this update relationship needs to be retained.

  It may be useful, but IETF process may forbid it.

  Alan DeKok.

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

Asunto:	New Version Notification for draft-ietf-radext-radius-fragmentation-05.txt
Fecha:	Thu, 06 Mar 2014 23:51:26 -0800
De:	internet-drafts@ietf.org
Para:	Alejandro Perez-Mendez <alex@um.es>, "Alejandro Perez-Mendez" <alex@um.es>, Diego R. Lopez <diego@tid.es>, "Alan DeKok" <aland@networkradius.com>, Alan DeKok <aland@networkradius.com>, "Rafael Lopez" <rafa@um.es>, "Gabriel Lopez-Millan" <gabilm@um.es>, Gabriel Lopez-Millan <gabilm@um.es>, Fernando Pereniguez-Garcia <pereniguez@um.es>, Rafa Marin-Lopez <rafa@um.es>, "Diego R. Lopez" <diego@tid.es>, "Fernando Pereniguez-Garcia" <pereniguez@um.es>

Asunto:	New Version Notification for draft-ietf-radext-radius-fragmentation-05.txt
Fecha:	Thu, 06 Mar 2014 23:51:26 -0800
De:	internet-drafts@ietf.org
Para:	Alejandro Perez-Mendez <alex@um.es>, "Alejandro Perez-Mendez" <alex@um.es>, Diego R. Lopez <diego@tid.es>, "Alan DeKok" <aland@networkradius.com>, Alan DeKok <aland@networkradius.com>, "Rafael Lopez" <rafa@um.es>, "Gabriel Lopez-Millan" <gabilm@um.es>, Gabriel Lopez-Millan <gabilm@um.es>, Fernando Pereniguez-Garcia <pereniguez@um.es>, Rafa Marin-Lopez <rafa@um.es>, "Diego R. Lopez" <diego@tid.es>, "Fernando Pereniguez-Garcia" <pereniguez@um.es>

Asunto:	New Version Notification for draft-ietf-radext-radius-fragmentation-05.txt
Fecha:	Thu, 06 Mar 2014 23:51:26 -0800
De:	internet-drafts@ietf.org
Para:	Alejandro Perez-Mendez <alex@um.es>, "Alejandro Perez-Mendez" <alex@um.es>, Diego R. Lopez <diego@tid.es>, "Alan DeKok" <aland@networkradius.com>, Alan DeKok <aland@networkradius.com>, "Rafael Lopez" <rafa@um.es>, "Gabriel Lopez-Millan" <gabilm@um.es>, Gabriel Lopez-Millan <gabilm@um.es>, Fernando Pereniguez-Garcia <pereniguez@um.es>, Rafa Marin-Lopez <rafa@um.es>, "Diego R. Lopez" <diego@tid.es>, "Fernando Pereniguez-Garcia" <pereniguez@um.es>