Agenda Bashing ============== A couple of changes to the agenda. Additional item requested. Status report, API (Victor, slides) =================================== Mailing list comments. Dave expects to submit updated draft in a week or two. 3588bis open issues (Victor, slides) ==================================== Open issues. * Inband-Security. Two proposals (1)protect CER/CEA with IPsec (2) open TLS and run Diameter over it. Lots of backward compatibility issues. Third alternative suggested at the mike. Action: write up third proposal in detail, present it on the list for comment. * MAY column for M-bit. Hannes : Favours retaining -- different communities may have different requirements. David : points out that M-bit setting has to be specified on a per-command code, per application basis, not just per AVP. Confusion over MAY is that it implies one can decide at run time. David believes it should be a specification-time decision. Lionel : sees as documentation issue. Bernard : Too many degrees of freedom. ABNF OK by itself. Then the application adds context. The M-bit is more than needed, and there is another degree of freedom beyond that. Hannes : Design team decided that ABNF describes requirements on sender. M-bit describes requirements on receiver. Bernard : Have to get rid of something. Dave : MAY actually means "conditionally mandatory" Conditional mandatory should be spelled out explicitly if that is what is intended. Use of MAY for this purpose is not supported by RFC 2119. Dan declares as AD that consensus be called on removal of MAY column. 10 hands in favour, none opposed. * Cleaning up peer discovery. Proposed to write separate document on dynamic discovery, same as RADEXT. Glen: RADIUS not equal to DIAMETER. * Downgrade "MUST" for SCTP support by servers. Seems to be little interest. * Consistency of default values for Redirect-Host-Usage and Auth-Session-State. Mark : Explained the issue. Pefers ALL-SESSIONS default, but Victor concerned over extra work implied for routing. New twist in E-mail discussion. Victor : Proposes changing Auth-Session-State default to NO-STATE-MAINTAINED. Check with the list. Dan : make this document the highest priority, clean up the issues. Blocking requests from other SDOs. RADEXT: Document coming out that could affect Diameter (Dave Nelson, no slides) ====================================================== * RADIUS - Diameter gateway defined in NASREQ. Issue that some attributes won't translate according to the rules of that gateway. Glen : Extended attributes designed to be compatible with vendor-specific codes. But change to 2-byte code has broken an initial assumption. DIME can fix the problem. Alan : mapping is an issue. Dave : proposed changes to Diameter. DIME must approve. Proposal has been around for about two years. Some question whether Diameter will accommodate all RADIUS AVPs, but DIME needs to get involved or accept the consequences. Dave : VSA is a general purpose extension mechanism. In using it may not be a vendor specific but maybe standards track. Does'nt necessarily mean vendor anymore. Glen : Set the MUST bit on the VSA. Assumption is that radius just go away. Its a big mess to try to get all radius avps to work with radius. Bernard : Radext is going ahead with this and its up to dime to either participate or live with the results MIPv6 Integrated ================ MIPv6 Integrated (Charlie Perkins, slides) ========================================== * Changes from serveral revisions of the document * Changes are minimal - remove all examples - AVNF corections * Chane of mobility capability IANA allocation rules * Review of comments. IESG had hoped to coordinate AVP numbering between RADIUS and Diameter where the content is the same. Glen : maintains these are separate protocols, should be designed separately. Charlie : counter-argument: simplify the life of development teams maintaining both. Hannes : not a real issue -- would simply have different numbers in the respective dictionaries. Dan : Pasi was concerned about allocating multiple values for the same entity in the same space. Not a real issue. Here is first case where Diameter implementation preceded RADIUS. AAA doctors have to rethink their preconceptions. Dave Nelson: exporting attributes from Diameter to RADIUS can't be done in general. ?? : IETF consensus years ago was that Diameter was needed because RADIUS couldn't do the job. The AD opinion suggests undoing that consensus. Fair enough to correct a mistake, but otherwise the IESG does not have the right to force a change. Don't compromise. Consensus to revert and push back on IESG comment. Ahmed : educate the ADs. Need to put together a case to the IESG to complete the Discuss process. Glen to help editorial team. Hannes : explained technical changes to split I-D. Will be submitted to IESG. Hannes : Pasi comments triggered some discussions. AVP allocation ADs wants to make sure we dont Simple AVPs use by both (diameter and radius) Glenn : Radius and Diameter should not be compatible Diameter document should not define radius attributes Hannes : It would not make sense to define a sepate allocations for diameter and radius. 100% alingment on the content of the avps. Glenn : They are separate protocols. Design separate things for separate protocols. Charles : Not a hard problem. its a convinience issue to have the same values. Dan : How about SNMP ? are we going to have the same values ? Pasi thought there is just a managment space waste so that maybe the intent of his comment. We can optimize by doing one. It prove not that simple. I think he already understood the question. Dave : radius attribute space is nearing exhaustion. compatibility is suppose to be upward compatible. downward is filled with difficulty. It has to be changed. Bernard : Major process problems. Justification of diameter is that this could not be done in radius. iesg overturning 10 years of consensus. Perkins : they demand that we push back if there is a strong technical concern. Hannes : Group wants to talk to the ADs and make sure things are separate. Bernard : If we admit to making a mistake then ads can retract Hannes : dont think we made a mistake. Bernard : Invalid discuss - iesg lets you push you around and causes a lot of problems. Hannes : Ask the group ? should we have an iana consideration section and request a couple of diameter apv code without consideration of radius. - 10 folks voted - 0 folks dont want to go back Glenn : Can't compromise with evil. It has a bad idea ... have to Ahmed : Explain to the AD - push back, original ADs where not there Glenn : Some ADs are not techically competent Summary ------- Review of comments. IESG had hoped to coordinate AVP numbering between RADIUS and Diameter where the content is the same. Glen maintains these are separate protocols, should be designed separately. Charlie: counter-argument: simplify the life of development teams maintaining both. Hannes: not a real issue -- would simply have different numbers in the respective dictionaries. Dan: Pasi was concerned about allocating multiple values for the same entity in the same space. Not a real issue. Here is first case where Diameter implementation preceded RADIUS. AAA doctors have to rethink their preconceptions. Dave Nelson: exporting attributes from Diameter to RADIUS can't be done in general. ??: IETF consensus years ago was that Diameter was needed because RADIUS couldn't do the job. The AD opinion suggests undoing that consensus. Fair enough to correct a mistake, but otherwise the IESG does not have the right to force a change. Don't compromise. Consensus to revert and push back on IESG comment. Ahmed: educate the ADs. Need to put together a case to the IESG to complete the Discuss process. Glen to help editorial team. Hannes explained technical changes to split I-D. Will be submitted to IESG. Mipv6 split ----------- * Next step - submit split ID to IESG Diameter QoS parameters (Hannes, no slides) =========================================== Explanation of status. Received IETF LC comments on the parameters document. Need more explanation of the parameters. Questioned need for all parameters that are defined. Coding issue. Glen: this is what Diameter was designed for. What justification to use non-Diameter encoding? 6+2 on Jabber for Diameter encoding, none for others. Hannes explained that current encoding came from NSIS. QoS attributes (Mayutan, slides) ================================ Changes - VLAND-ID-Range - Time-Of-Day-Condition Next rev - Qos-profile-template - excess-treatment - ICMP type Hannes : Dan did an AD review of Qos doc Hannes : Translated mostly on the ip-filter-rule Judy : There's protocol and port information speaker: We may have to just include one or two AVPs for SCTP Hannes : Theres stuff missing but not clear on what it is Hannes : Reuse work nsis did. Side effect, inherited their encoding. Groupd favored custom encoding at that time. After review: - issue of encoding - is this right ? switching to radius encoding or custom - do we need all these qos parameters - many different views Glenn : Fallback to the same old issue. Any set of avps encoding to the classic diameter format. this should be it. Hannes : What type of encoding would you like to be used? - diameter based = 8 people - radius = 0 - custom = 0 Summary: Update -- changes in latest version. A number of further changes planned in next version. Excess-Treatment will move from QoS parameters draft into this one. May need to add SCTP and DCCP in the IPv6 classifier. Routing Design Team (Glen, slides) ================================== Glenn : Most contentous with message routing is strict routing Bernard : One other way is to stick state to the client. In this case, give the state to the client. Glenn : Third way is to do loose routing, fewer problems with load balancing No decision reached yet. Hannes : Real issue is record routing. Why is this really needed ? Bernard : Same reason as decorated NAI is needed. Hannes : Does decorated NAI already solves this ? Bernard : Rare problem. Glenn : How strict is this routing going to be ? Is it domain based ? Hannes : Difference is that the the information is not provided by the end-host Bernard: You should not have both decorated NAI and source routing Alan : Businessses are afraid of decordate NAI as an FYI Sebastian: Does redirect solve this issue ? Glenn : string routing will break redirect Lionel : Its not about having static routes, as soon as you have a dynamic path just make sure all messages goes there Hannes : Not yet clear on any conclusion. Continue the investigation. Glenn : 3GPP should define their solution if this is their own need Lionel : Design team should decide if this is an issue that ietf should handle Summary: First problem: OK Second problem: stateful proxies. Possible solutions: -- all proxies stateful -- loose source routing -- state on clients Alan notes the state on the proxy corrects lack of knowledge at the endpoints. No decision on this one yet. Third problem: Glen doesn't understand the problem. Nor does David. Basically not seen as something to tackle now. Focus on second problem. Discussion on understanding the problem. Reference to RFC 5103. Difference from the first problem is that routing for subsequent messages is defined by nodes in the network rather than the end point. Suggestion that source-based routing and decorated NAI are conflicting and should not be both used. Alan: RADIUS people getting very concerned over decorated NAI. Bernard: no concept of routing metrics in AAA, so something like decorated NAI used. This problem is different, though. Alan suggestion: look at routing research from 25 years ago. The same people are defining the architecture are putting policy in the network. Sebastien: capability already in Diameter. Glen: difference in this case that session is torn down in case of failure, rather than redirect. Hannes wonders why routing would be randomized. Glen: blockages, e.g. due to busy responses. Hannes: will study the problem further, following up on Bernard's suggestions. Glen: issue of whether anyone else but 3GPP needs it. One possible outcome is that we leave it to 3GPP to specify the Diameter extension that they require. Dan: reason we need 3588bis and API documents to set the ground rules. Decorated NAI (Lionel??, slides) ================================ Explanation of changes needed. Disposition: consider for addition to charter. No comments on document. Hannes: turn it into WG doc after rechartering Command codes for 3GPP EPP (Lionel??, slides) ============================================= No specific issue. Question of route for approval of draft. Victor volunteers to review. Dan requests E-mail to ask him to sponsor. Need to fill in PROTO shepherding form. Lionel: No specific issues yet - 3GPP IETF dependencies list Hannes: Need to get bis out of the way RFC 4282 (Alan, slides) ======================= RFC 4282 has broken recommendations regarding NAI. Fortunately implementations don't do bad things. Do need a discussion on internationalizing. Need a document that captures what people do and why it works, or has suggestions. Internationization never tested in Diameter bakeoffs. Lot of overlapping issues between emu, radext, dime. Realm name that goes to AAA will work if treated as an opaque binary token. But need a processed value for DNS lookup. In general, search for the word "ASCII" in our documents (e.g. in 3588bis) and determine whether it is really needed. Alan: try to have all interpretation done by the home domain, so it passes both the opaque token and the DNS lookup value to other domains. - Internationalizing NAI Alan: A lot of test required. Bernard: 3588bis lookup ascii and make sure you really mean it. Dan: Ignoring is not a good option on the other hand the problem is common.