IETF69 - Chicago, DIME Meeting Minutes ====================================== Agenda/Milestones (Hannes) ========================== * Plan is to get some of the WG documents to last call * The following two documents are planned to be ready for WGLC in 2 months: 1. diameter mip6-split 2. diameter mip6-integrated * Send app-design-guide document to other SDOs for review. * MBONED WG asked for review of "AAA Framework for Multicasting". Tina Tsou and Jouni Korhonen will review it. * Discussion about RADEXT FilterRules (draft-ietf-radext-filter-rules-03.txt) * Issues: Considering performance, size, extensibility, what should we decide for encoding? Dave : RADEXT in general seems to prefer Grouped AVP. If it is a string, who is going to use it? It really depends on who is the actual consumer. There seem to be more people in favor of new encoding. It is mentioned that grouped AVP could be better in terms of performance, considering that it will be consumed by a machine rather than a human. The issue will be taken to the list. Hannes : Looking for opinion on what people prefer. Binary encoding or BSD stlye text encoding. Try to get a feel on who understands the issue in the WG. * Few people raised their hands. RFC3588bis (Victor) =================== * RFC3588bis work update. Victor Fajardo presented. 3 new revisions since last meeting. IPSec is removed, SLPv2 is removed for peer discovery, routing precedence rules added for redirect mechanism Dave/Jabber : Why SLPv2, IPSec and references to end-to-end security are removed. Victor : For SLPv2, nobody seems to be interested, neither in WG nor in Interope, hence removed. IPSec, isn't tightly coupled with Diameter unlike TLS, a lower layer issue, that is the reason why it is removed. Hannes : For end-to-end security there is no defined mechanism yet. Diameter CMS was to address that but nobody seemed to ask for it. Glen : Diameter CMS was suppose to fill in the end-to-end security needs but no one seems to be interested. * Command code allocation process relaxed from IETF Consensus to Expert Review. (Issue #55) Glenn : Why are Vendor-Specific command not supported? The main reason was interoperability concerns, especially for intermediaries. There are concerns rose about other SDOs defining their own codes and claim is not Diameter. Review by IETF mentioned as still useful, but other SDO could be reluctant to come for a review. Hannes : Our hope would be that the app design guideline could help when used in conjunction with the "expert review" process. It would allow them the opportunity to ge the techincal stuff right. Glenn : I don't think its going to help. Its questionable why there are vendor specific Application-Ids and AVPs but no command codes. Idea about allowing vendor specific command codes but only for vendor specific applications. Tina : Agrees with Glenn. It seems like there was some level of consensus about this. David : TS.XXX already has some vendor specific command code * TLS post-connection checks Tolga : Question about what we are going to do about TLS post-connection checks. Could be addressed in 3588bis or as a separate draft, depends on the size of the solution. Sip-domain-certificates draft can provide some guidelines. Victor : Prefer separate draft that may generic and can cover all other common cases. Application Design Guidelines (Victor) ====================================== * The document is updated based on reviews, mainly for readability, core guidelines are the same. Text has been added to specify that applications can define their own state machines rather than trying to fit in what is defined in 3588. * More reviewers are needed. After initial review is done, will be sent to other SDOs Hannes : Take a look at the current document. We can pass it on to the other SDOs. Quality of Service Parameters for Usage with the AAA Framework (Jouni) ====================================================================== * Defines QoS parameters that can be used for carrying QoS info. Is now a WG item. Some review has been done. seems close to WGLC. David : Question about whether extended RADIUS parameter format will be used. It shouldn't matter, because they are single BLOBs. ??? : Coordination about using nsis namespace could be necessary, we have other documents that doing similar things. Hannes : What is the status of these documents? We may want to reference them. Dan : WGLC should be distributed to RADEXT and NSIS as well. Hannes : We had the an options for the Qos filter to Use a grouped AVP to attach the action of previous AVP. It does'nt make it easy to reuse RADIUS. Need some guidance on how that should be done. David : The document depends on traffic rules in RADIUS. Hannes : There would be a normative dependency on the RADIUS document. Depends also on the decided encoding. Diameter QoS ============ * Presentation of the Qos models - description of push and pull models. Tolga : Providing end-to-end Qos would probably be very hard. Sun : Understand the concern but QoS usually enforced at network edge. End-to-end will probably be enforced between organizational boundaries. Huawei : Question about the architecture (???). What are the specific scenario (???) In the industry there are many solution about the end-to-end solution. Will this be used by the industry. Architecture is too abstract. ??? : Agree. There maybe some intermediaries in between end-points that do not participate in the Qos transaction. But it is important to support applications in different domains. ??? : Question about whether brokers are necessary? They seem useful especially if AF and PDF are belonging to different organizations. Tolga : Current operators do not employ per stream reservation. They deploy more comprehensive strategy. Hannes : We have the obligation to provide a complete story. An applicability statement about push model could be useful rather than excluding the push model. We need to explain the issues associated with it. Sun : Question about who discovers the PDF on the path for end-to-end. An approach where the first PDF discovers the rest of the PDFs could be used. Tina : Adding more information/detail about push mode. Push mode state machine needs to be defined. More discussion on end-to-end Qos and how to support it. Hannes : This document is not close to WGLC yet but a midpoint review will be done. Need some suggestion on how we can accelerate the work. Push model is still high level on this document. Sun : Push model needs more detailed description/usage. Peter : The model should support a scenario where there maybe no AS. Tina : Sent text to the list regarding the push model. Diameter MIP6 Split Scenario (Jouni) ==================================== * Document needs more review from interested people. * Minor Mobile IPv6 bootstrapping additions. Hannes : New requirements from the MIPv6 working group to support MIP6 auth had some changes. Many different things dumped into the same document. Still has a couple of issues. Diameter MIP6 Integrated Scenario (Jouni) ========================================= * Two revisions since last IETF. Revisions are major based on MIPv6 requirements. No longer bootstrapping certain prefix information. * Also support some requirements made by 3GPP/3GPP2. * Implicit capability advertisement replaced with explicit capability advertisement. Ahmad : Question about why MIP6-Home-Address MIP6-Home-Link-Prefix removed. Jouni : Because bootstrapping with MIP6 uses split scenario mechanisms, this is based on MIP6 requirements document. It is mentioned that it still could make sense to put these parameters, if they want Home Agent to do it, they can ignore them. Maybe this should be brought to MIP6 list? Ahmad : After we bootstrap the HA info we also establish IPSec ? Hannes : Thats what at least the MIPv6 WG came up with. Tina : Does this cover pre-authentication Madjid : Preauthentication, is not there for MIP6 Jouni : Document progress: if they make progress, they will inform. Hannes : The MIP6-Home-Link-Prefix issue should be brought to the list. Crosscheck with MIP6 RADIUS draft is necessary. Document seems to be ready for WGLS after last reviews. David : Do we have two different docs for the same goal, one for RADIUS one for Diameter? They address different interfaces. RADIUS Home Agent-AAA, Diaemter NAS-AAA. Hannes : Good point. Some differences exists in scope and detail. David : Suboptimal trying to keep same capability separate. Have chat to have some integrating solutions to same problem. Madjid : Debating RFC4285 support is now informational. Big chunk of the document is referencing 4285. What can be done about this? Hannes : Downgrade the reference? Will doublecheck the procedure and will post to the list. Diameter Proxy Mobile IPv6 (Jouni) ================================== * Background, NETLMM proposed protocol for Proxy MIPv6 * Now considering transition issues for PMIP include NAS-AAA, accounting. Current document is at 00 state. Issues present in previous presentation also relates to this work. ??? : Are address attributes here really necessary? Something to be discussed on the list. Frank : Many common point with MIPv6 integrated scenario. Differences should be highligthed in this document. It is possible that the LMA has no idea of the MN IP address. Jouni : There is some text describing the SA between LMA and AAA. Hannes : We can move the discussion to the list. Ahmad : There is already a draft doing similar things in RADIUS, it makes sense to synchronize. Frank : Additional comments, procedures need to be added explaining how to use it. Madjid : Questions about whether this belong to Dime or MIP6. Hannes : We need to make assessment individually. Diameter related questions are in DIME. Diameter MIP4 Performance (Ahmad) ================================= * Performance of MIPv4 authentication on RADIUS and Diameter MIPv4 * No hard data to support analysis ??? : Question about why RRQ is lost. It is not lost, just RTT takes more than 1 sec. ??? : Question about where this belongs, MIPv4 or Dime. ??? : Question whether data/measurements are available for the problem addressed. Routing-Extensions Draft (Tolga) ================================ * Separate routing and re-direct functionality * Use a B2BUA scheme to do on-path routing * Use existing 3588 mechanism * Security procedures on application level are employed No comments Congestion Draft (Tolga) ======================== * Prevent overloading of congested nodes * Loadbalancing * Another parameter in routing decision Glen : What is the goal here, to address network congestion or node congestion? Tolga : The goal is Diameter node overload control. Glen : Isn't TCP guarding against network congestion? Tolga : rwnd is a parameter of how fast the other end is consuming messages, it is different than cwnd. Glen : Why existing mechanisms are not enough, particularly why TOO_BUSY_HERE is not enough. Tolga : It does not inform about abatement, does not have levels. No consensus, discussions need to continue about whether this is a problem which needs to be solved. State Recovery Work (Ulf) ========================= * Ulf is planning to submit a solution document as personal draft. * Develop a possible solution for auditing for diameter. Base Protocol MIB/Credit Control MIB (Glen) =========================================== * Glenn is waiting for comments for both documents.