RADEXT IETF 84 Vancouver, Canada Friday, Aug 3, 2012 Meeting started 11:22AM and adjourned 1:20PM Chairs: Jouni Korhonen Mauricio Sanchez AD: Benoit Claise 1. Preliminaries -Chairs asked for jabber scribes (Alan DeKok) and note takers (Nancy Cam-Winget). -Chair reviews the agenda. Agenda order is modified to allow Diego L. to go first. -WG Goals/Milestones status -Some slightly delayed drafts; one majorly delayed (UDP/DTLS) -Dynamic discovery gets TTL considerations added (missing in Diameter RFC) -Mention of accomplishments: 2 RFC's (TCP/TLD 6613, 6614 in May), IPv6 write up almost done too once that's done, it'll go to WGLC. The radius extensions will be discussed today and couple other ones Radius/DTLS and IEEE attributes. -Different efforts outside charter are good to address so need to recharter. *************************************************************** 2. Recharter discussion -Recharter status: approved by Dan R. (previous AD prior to IETF 83), proposed charter went out May 9 with rough consensus (e.g. no explicit disagreements). Review with Benoit: updates to milestones and loosening diameter requirements (e.g.mandate to include diameter considerations). -Benoit Claise: exchanged email to do a further but not sure it made it to the new text. -Alan DeKok: comments that the change may include protocol change in RADIUS if we're just changing RADIUS attributes, should not affect diameter. -Mauricio: the latest version sent last night should have text to reflect this. Have just sent the new text to the group. -Lionel: believes having specific section for diameter compatibility may only be needed if interoperability with diameter is needed. For instance drafts for securing radius may not really apply with diameter. -Mauricio clarifies that there are instances where diameter is not impacted, so perhaps we just state that explicitly to acknowledge the fact that there's no impact to diameter. Lionel agrees. -Mauricio: have just sent to the reflector the updated text per the latest exchanges with Benoit to address the diameter considerations. -Alan: since we're updating charter, are we interested in increasing packet size? Given that packet ID is a bit, are we interested in enlarging that space as there¹s at least 1 vendor that has extensions to do this believes RADIATOR has a VSA to detect that it's RADIATOR uses a 32bit ID to key off the VSA to allow for 65K packets outstanding. Do we want to standardize on this and expand the charter now? Believes once we start fragmentation discussions, then we might address this as well and address it now. -Mauricio: comments concerns on biting off too much. Alan: believes that fragmentation may already be supported in industry we just need to formalize how we do it and need to address the nastiness of the packet size. -Benoit: what's the next step for charter? Do we do it to both diameter and radius so that both groups respond in parallel vs. serially. -Mauricio tends to agree and presumes that both groups would be amenable. To Alan's comment: it's a valid discussion to have on the mail list, but perhaps we go through another recharter exercise in a year given that we've had no discussion on packet size of late, so we need to have the discussion before we determine how to recharter to address this. -Any other comments? ­as none is given- Mauricio will post and give time to proceed on the rechartering. *************************************************************** 3.Support of fragmentation of RADIUS packets, Diego Lopez -http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation -Version -02 improved: to indicate fragmentation is most likely to occur due to authorization exchange happening after authentication has completed. -Improved discussions on how to better optimize and determine chunk sizes as they can not be exactly 4Kb payloads -Better organization of the document (subsections) -Added a new section to deal with state attributes -Added discussion of proxies in new section as this is key use case -More updates will be needed: to address the addition of user-name to any access request message and to include considerations for fragmentation in the access request and access-challenge messages (shows proposed text and will send it to the mail list too for working group adoption) -Mauricio asks who've read the spec: only a couple. -Mauricio: we need more participation so will go to the mail list to solicit more review and feedback. -Benoit: comments that as part of the rechartering there has to be enough interest to ensure we get good reviews. If we can not get reviewers during the wglc, what to do? -Mauricio: agrees that's not a situation we want to get into. -Alan: as a larger issue, the list has been relatively quiet. Speaking to the extensions, it'll be soon there'll be no opportunity to do further extensions. So it's a wider issue than just for this document. -Mauricio: agrees that it is a broad issue, so need to solicit getting at least 2 to 3 solid reviews for each draft. -Mauricio: comments that a new draft should be coming out soon for this draft. -Diego: mentions its possible that some others may want to participate but as there's overlap with abfab they just can not show up. *************************************************************** 4. RADIUS Protocol Extensions, Alan DeKok -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions -not a lot of change. There's been some reviews in the last few months, so terminology has been updated; miscellaneous word smithing and inclusion of text vectors. Some sample implementations have been done (by Alan) to get traction. -Mauricio: asks, has there been interoperability testing? Alan: yes. There are some implementation issues as they treat attributes as integer, that is no longer possible with this so there are discussions going with the implementers; the freeRADIUS will support this where in some places it may not be possible in some branches given the limitations in code/api. -Mauricio: asks who's read the draft. Next steps is to take this draft to review and wglc -Benoit: there's a big difference here: given that there are 3 implementations then there has been some review; so if we get their OK then we should be OK. -Alan: there was a previous document (3yrs old), Stefan, Avi and Alan got together to clean up the old document and simplify so all the comments drawn from old proposal died, but not sure if its lack of review or approval so happy with the review and OK signaling from the implementers of latest draft. -Jouni: increasing amount of radius implementations with the funny encodings, so they'll need to pick up this new version to move forward. Alan mentions IANA still has 40 attributes outstanding, so this draft needs to be published asap to push back on the use of old format and use the new format to avoid attribute exhaustion. -Jim Schaadt: are you going to want to address the abfab document that's in wglc already? -Alan: discussion on mail list already, will not say anything to IANA so abfab will get the allocations based on old space until there's no more. -Would prefer that we stop new work now and get them to adopt new format to avoid them doing their own format extensions. -Mauricio: if we can go to wglc and get it done in a week, should help accelerate things/process. *************************************************************** 5. CoA proxying, Alan DeKok -No associated drafts with this topic -Came from discussions in doing CoA in large deployments especially in roaming environment.When doing CoA (RFC 5176) saying to do proxy CoA but doesn't specify how. -'User-Name' doesn't work, it really needs to be the 'originating realm'. So this needs documentation that it works, there's an implementation in freeRADIUS. -Problem statement: need to get packet to the NAS but NAS-IP-addr doesn't work; an operator-NAS-identifier needs to be used (it's an opaque token meaningful only to the operator). It's a fairly simple construct to adopt, it seems to work (in freeRADIUS). -Mauricio: asks is this a new draft? -Alan: yes as need -Jouni: we don't really want to touch RFC 5176 -Alan: everyone he's polled seems to think it's a good idea; there doesn't seem to be great demand so not sure it needs to be a working group item but given abfab and other work, this will become important. -Jouni: there are a bunch of specs that assume that proxy CoA work, we don't have an idea if there are deployments using it or if its broken? -Jim Shchaadt: how is this different from machine-name and other used for channel-binding used in abfab? -Alan: don't know. Operator-Name is already defined by the realm, if there's something that matches with an opaque identifier for the NAS, then we could use that. But independent, there needs to be documentation to show how to do this; so can look at abfab. -Jim: OK, just want to make sure there are not 2 attributes to solve the same thing. -Mauricio: is next step to start discussion in the mail list? -Alan: will write a draft and start discussion that way. -Lionel: when using the operator-name, does that mean the ends need to be stateful? -Alan: home server tracks user session, in addition to home server tracking, it adds the operator name and identifier so CoA, the intermediate servers can have that mapping. For CoA it ignores the user-name but matches by the operator name and realm. -Mauricio: will track in mail list but not included in the rechartering *************************************************************** 6. DTLS updates (Alan) -http://tools.ietf.org/id/draft-ietf-radext-dtls -Got some feedback from Nancy -Need to fix some typing, so there¹s been very little feedback on the list. Do we dig a little deeper? -There are 2 implementation: radsecproxy, jradius and freeRadius soon (2012/2013) -Mauricio: are the other implementors participating in the list? Alan: not really, previous author is no longer in the space. -Mauricio: who's read the draft? Only 1. -Given that there are implementations, its important that we move forward and get more reviews and get it to wglc. -Alan: can get another draft ready soon, add cross references and fix some references. It's basically a patch to RFC 6614; the only addition needed may be mandatory to implement. -Nancy: I¹ll post comments to the list. -Alan: given the document doesn't change a whole lot not sure there¹s not much else to do. -Mauricio: await Nancy's comments and then more forward from there. *************************************************************** 7. RADIUS traffic accounting work, Stefan Winter -http://tools.ietf.org/id/draft-winter-radext-fancyaccounting -http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics -Status: 2 drafts to speak of the same thing: to extend existing accounting drafts. -Draft-winter-radext-fancyaccounting uses classes by string label which should be a URN pointing to the exact definition of what is being accounted for. -Draft-yeh-radext-ext-statistics only addresses IPv6 vs. IPv4; DSCP was added does the accounting by enumerated integer labels. -What to do with 2 drafts? WG needs to discuss if the accounting should be extensible or focus on (hardcoding) IPv6 vs. IPv4? -Overall comments was more focused on the 'winter' draft and seemed positive though questions was on string labels vs sending the exact traffic definition in IPFilterRule syntax. Less discussion on 'yeh' draft. -Mauricio: I'd like to understand who has read the draft? A few people have read one draft (winter). - - -Alan: believes they are both very similar, the winter draft is simpler and more clear; has comments on how to clean up with filter rules. If there are complicated rules, then you may not want to send these in the packet; so using the old style filter rule may not be good to use; identifiers are better. But don't have strong intelligent suggestion to address URN. -Benoit: as a newbie, but when seeing accounting stuff then thinks of ipfix which is an evolution of netflow information. So, while there's no straight proposal, it feels that they are very similar. -Mauricio: agrees that there may be some replication, but there is benefit to address accounting within the radius application. -Benoit: this should be investigated further; there was a meeting that discussed the different protocols/transports and the conclusion was 'ok' but make sure that they are all using the same information model. -Mauricio: accounting for radius does support information and agree that there are too many different data models and it would be good in practice to converge. -Benoit: information model convergence should be doable, data model understand -Stefan: has reservations on model convergence. While ipfix could be used to report the NAS the information it needs to account for, not sure though. Discussion on the list steered to generating a different draft to define the different types of traffic flows that could be reported the NAS. -Alan: clarifies that there's 2 things needed: to define the traffic class (getting sent to the NAS as it may not be in RADIUS) and then providing the traffic class information itself. -Matt B: draft-yeh seems to be fairly straight forward as it only focuses on the IPv6 traffic as it doesn't bring other stuff to the table. As a quick browse on the winter draft, while it¹s a nice architecture it may be bringing a bigger picture to solve a little problem (e.g. IPv6) -Alan: Avi has done a lot of 3GPP and other similar work to what's been proposed in the winter draft; e.g. bringing flexibility and classifiers to accounting. -Jouni: mentions yes some work has been done in the diameter space. -Mauricio: we could take a narrower scope in the yeh draft, but Stefan raises good point that if new work comes then they'd have to define a new classifier so would be good to discuss that too. So may need a combination of both drafts and encourages them to converge to a new draft. But question is whether we take a tactical approach vs. flexible approach. Given the timing of the discussion, it may be too early for full consensus yet. Will poll nonetheless. -Show of hands for tactical (e.g. yeh) approach: 1 -Show of hands to expand/flexibility for traffic classes (e.g. winter): 4 -Mauricio: at least in the room consensus is for flexibility. But will take poll to the mail reflector. -Benoit: would be good to mention in recharter the path to be taken. -Mauricio: text in charter is loose to allow for either approach. *************************************************************** 8. RADIUS dynamic discovery, Stefan Winter http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery -rev 04 published June 2012. -Major changes:clarifying text (for diameter equivalence) for S-NAPTR lables -included dynamic authorization packets -updates based on eduroam experience: -user inputs with trailing dots had problems -TTL of discovered targets addressed -Text added to warn of excessive delays from name resolution systems -Mauricio: is draft implemented in eduroam to address their environment? -Stefan: radsecproxy and radiator have this, don¹t know how widely its deployed (~100 realms) but it seems to be working. -Mauricio: who¹s read the draft? ~2 -considering where the work is, it looks solid so may be good for a wglc. *************************************************************** 9. RADIUS Attributes for IEEE 802 Networks, Bernard Aboba -http://tools.ietf.org/id/draft-aboba-radext-wlan -WGLC completed, one open issues #109 reason codes -Discussion of email exchange: use of WLAN-Reason-Code and section 2.14 adds values to Act-Terminate-Cause -Bernard discusses Joe's email of Acct-Terminate-Cause is allowed in Access-Reject -Alan: unless the Acc-Terminate-Cause is being used for something then lets just disconnect them. -Bernard: I think there was also a reason to allow for this. -Nancy: goes through the proposal came from 11u. So, could be in Access Reject or CoA. -Bernard: goes through each of the disassociate discussion to get clarity on the ones placed on the proposal. Concern is are these the only ones needed? Nancy: not sure as these are 11u specific. -Bernard: asks whether we ask IANA to assign a field that¹s controlled by IEEE or have IANA own the value assignments. Also where do these apply? Is it valid to have them in Access Accept, Access Reject and CoA or some combination? -Nancy: will have to check with our implementations. -Bernard: this would only be valid for 802.11. Nancy agrees. -Bernard: for the accounting case, should these WLAN codes also be carried to accounting terminate cause. -Alan: there are number of telcos who have the accounting separated, so this may be useful for them too. -Nancy agrees as the rationale why this was instigated. -Bernard: group describes number of operator descriptions and the only thing to raise is that an earlier document on location that has similar attributes. If the goal is to just shove the .11 in here then may be OK, but is seems like there's some weirdness to have both the location draft and this have similar attributes. Will raise this on the list. -Lionel: don't know. But for 3GPP to retrieve this information, they can rely on the geopriv information, but for interworking with hotspot since it was introduced in .11 then this would override the geopriv with wi-fi infro. -Jouni: never a great success to use the location stuff. So we can forget that stuff. *************************************************************** 10. Wrap-up -Mauricio: Already discussed (re)charter at beginning of meeting, so now need to take action per what we discussed. -Mauricio: Read the drafts! Specially those going to WGLC. Need more reviewers. -Lionel: 3GPP waiting for IEEE as they have an internetworking dependency. -Mauricio: We will look at taking IEEE to WGLC as quickly as possible.