Diameter Maintenance and Extensions (DIME) Agenda for IETF 67 WEDNESDAY, November 8, 2006 0900-1130 Morning Session I Harbor Island I Meeting Minute Taker: Victor Fajardo 1. Agenda Bashing, Document Status and Milestones John Loughney (15 minutes) * API draft - No technical discussion on this topic - What we will do is perform another WG last call and if there is no consensus we can consider pursuing this document as an individual RFC - Pls review and root out technical issues for this document (expert review on this document) - Authors seem to be happy about the API document but htere isn't much feedback from the rest of the WG. May ask AD to submit ask individual RFC. A technical review is still preferred. * URI Scheme - Nobody had submitted URI format to IANA and in the process we found potential bugs but these perceived bugs are not causing any problems - Queried folks and people have implemented this scheme and nobody seems to be bothered by the potential problems. - So, to resolve the problem we make a registry request to IANA and make modifications to the bis to fix the problem * Qos - QoS application is not progressing much. There is interest from WG members and other SDOs. Will ask for expert review. Need to synchup with IP filter rules extensions in RADEXT Comments: John: David, did you make progress on finalizing ip filter spec work ? David Nelson: Yes there are two documents. One that warps the exciting ip filter document into radius and radius uses them and there are other documents such as old nas traffic rules, redirection draft etc. We perform simultaneous review when radext is done John: NSIS is working also working on Qos spec will be a lot more friendly for diameter Qos. If your are interested in seeing diameter make sure that the document works for you. * App Design Guidelines: - There is a comment during the diameter tutorial that reusing a command code and adding a bunch of other avps was not a good strategy. - The basic idea is that when you try to create an application it should be more general and not just for a very specifc purpose. That an application should span several possible deployments, i.e. mobility applications. Comments: Tom: Are you suggesting a superset strategy ? John: Yes, this what we where trying to do with diameter base. What happened in reality is that people are using a subset approach and realizing that it becomes difficuls because when we upgrade a release such as when a new mandatory things that the old release did not have we had problems in doing versioning. (despite being WG it makes sense to do a brain dump to say that this what we think is a good way of designing applications) Tom: Other SDOs have interest on how all these things are going to relate. I worked as editor of the QoS document in the ITU-T. Hannes: We note you name as one of the expert reviewers for the Qos doc David Kessens: Point out that the charter for DIME has not been achieved and should have been achieved some time ago. WG chairs not writing draft documents. Though if this is a general idea then it is welcomed. This charter has a few things that has not been achived. We some issues here in the WG and most have not been delivered for a few months. John: At least on the first two we have some work done and for the rest its well noted that we have to do the work * RFC3588bis - Progress on the base to IESG as a draft standard - This works has suffered in terms of scoping. How big a change do we need. What are reasonable things for diameter base and what are for extensions. We need significant review for the WG to have consensus and move this along as a draft standard. - We need significant working group consensus to move this work forward. - Clarification requested about the reason for the existence of Authorization-App-Id/Authentication-App-Id AVPs. Glen will try to provide some explanation. - Question from Tolga whether we can include AVPs to provide opaque session based data transport and to indicate support for failover. Tolga will provide text. Hannes: Pls concentrate on the basic stuff. We cannot add any new work unless basic stuff is done. Arun: Does this work include changes in current RFC as well ? Is Diamter SIP being pursued ? John: Diameter SIP is now an RFC Glen: Some suggestions - API is essentially usesless until we update 3588. So just rubber stamp and send it to IESG. We can revise it in the future. Aside from Qos and design guidelines, the URI should be done and shipped as well. For Qos, the approach to editing is not clear. Most documents use to a single editor and many contributing authors but Qos has many editors. John: Sit down and talk about it and agree its not a good way to have multiple editors. Hannes: But in the last IETF you are the editor. Glen: I did not know that. Some version control system. John: Lets fix it. Glen: About submitting the base as a draft standard, not sure but need to talk to AD on how we need to proceed. John: We may have to make a decision and say we are actually changing it and proceed as draft but it is best to go to draft if we are actually fixing something. Glen: Under the impression just to fix the erorr but you can't add new features 2. RFC3588bis draft-fajardo-dime-diameter-errata-00.txt Victor Fajardo (30 minutes) - Dump of all the issues into an errata draft - Issue 21 [Diameter URI schemes] John: Just to summarize what I've already mentioned, we already have a solution. We've queried some implementations and nobody really seems to be bothered by it. Document the current status and include that in the bis. We confer with the AD on whether we can just register to IANA without a document or not. Maybe done with just an IANA request. - Issue 21 [Application ID to be used by ASR/ASA, RAR/RAA, STR/STA] Victor: Technically there is not issue or interoperability problems etc. Tolga: For certain deployments, using app id of zero has some problems. In special situations where there are relays in front of load balancers there will be some routing issues with app id of zero. Vishnu: We have deployments which would break if we change app id to zero. Victor: So your applications are not using app id zero for these messages. Glen: That actually was not my original intent. The base doc was a bit messy. There are messages that should be using app id of zero for peer communication and part of the base. The rest are generalized messages that should not really be in the base protocol but they are there to support applications. In that case its completely appropriate to use the app id of the application and in-appropriate to use the app id of zero. John: Does anybody has any issue with Glens solution ? Victor: Some of the documents have app id of zero. John: We can fix those documents. Vishnu: So the conclusion is to use app id of the application ? John: Yes Lionel: What is the implication to use app id of the application for these messages. There was a discussion a while ago on what the meaning of a command code for the base protocol or the application. What would be the implication of this when you add avps to these messages. John: This false into the category on how to use diameter applications. It has been a open issue. Some confusion on what are the implications of the avps such as mandatory avps to the command. Should also be discussed when this issue is discussed. Lionel: Since these are common we should discuss the implication Tom: Example is in Gq where the avps vary depending on particular command. In that case the semantics has changed for the command. Do you use app id of zero. John: It has application specific context then we would need to be using the application id of the application. - Issue 13 [Duplication of App id in the header and App Id avps] Lionel: The basic question is why do we need to have several app ids present in the message. John: Need clarify text on why its there. Glen: Fuzzy recollection on why there are two app ids present. The idea was that diameter applications would have accounting. So one of these ids where either accounting or nothing. John: Need to do some forensic digging. Victor: How will this affect routing Glen: It really would'nt John: Because you would be routing on the header and accouting would be in the body Glen: But nowadays, virtually no applications include accounting so we can remove this feature. John: What we can do is just put an explanation why we have to app ids. And as long as it does'nt do any harm then it should be ok. Tolga: Proposed addition of a session-data avp. Similar to that in credit control app we have failover avp. 3. Diameter Mobility Diameter Mobile IPv6: HA-to-AAAH Interface for MIPv6 Bootstrapping draft-ietf-dime-mip6-split-01.txt Gerardo Giaretta (15 minutes) - Made some structural changes to these drafts - Have to wait for these drafts to finish and get some expert reviewer to make sure these drafts are on target Gerardo: The working group last call was finished. We dont have major issues. But RADEXT wanted one more week for review. One more issue for 4025. There is a consensus to include the requirement for 4025, requires one more month for review. John: We can do the work in parallel Gerardo: Does not talk in general about the split scenario but the communication between the AAA server and the HA. Discussion in the mailing list about the design choice that needs to be made for new applications. Result of discussion is separate auth from authorization and accouting with - Authnetication: RFC 4072 in auth only mode - Authorization and Accounting: Desing a new application Diameter EAP (authenticate only) for the AAA-EAP server and Diamter MIP6 for Authorization and Accounting - New Application * MIP6-Authz-Request * MIP6-Authz-Answer * Accounting: RFC 3588 (+ new AVPs) * Session Mngt: - STR/STA - ASR/ASA - Open Issues * Authorization Token - Authentication is done by one entity and Authz/Acct is done by another. They are de-correlated - AAAA-MIP6 has no proof that MN has been corectly authenticated We need some authorization token to prove that the MN is authenticated - Do we want mechanism for this ? Glen: I agree that Authentication, Authz and Acct are bound together for session mngt and improved security. Maybe some other simplier scheme besides authorization token binding. Simply say that Mipv6 authentication protocol as diameter EAP with a new app id and reference the document and require that acct will be included. Splitting the servers are is not a good idea. Gerardo: Reconsider the scheme of splitting server Glen: You can do the reuse by using diameter EAP with new app id for the authorization but splitting the server is not a good idea Gerardo: We are not trying to split the server but just making sure that if the servers are different then the protocol still works. Agree that it is easier not to split the server. John: Avri suggested that some deployment has split server scenario such as when adding new feature you add a new server Glen: In that case, your going to have to bind these things together anyway so may as well add a whole new server with everything Madjid: If they are different, there should be some binding because you don't know which user is being authenticated for mip6 This is an issue we need to look at. Gerardo: The point is that its not the MN thats communicating to the second AAA server. Its the HA thats doing that and we can consider that as a trusted entity. Madjid: But the second AAA does not know that the MN has been authenticated. Mohan: During EAP, MN talks to AAA directly. In that scenario the issue is valid. Hannes: Is the entity that authenticates the user the same entity that authorizes the service ? Mohanna: How will the that work ? If the user goes through the home AAA there is no option to communicte the identity of the EAP server to the home server. Gerardo: This is how diameter EAP works now. The HA is the EAP authenticator so the HA knows. Do we trust the HA in this situation or not ? Mohanna: So the EAP authenticator which is the HA will push the key to the HA ? Madijid: This scenario is find, the problems is how does the 2nd AAA knows to trust 1st AAA unless they hit the same database. Hannes: Will you volunteer for document review ? Ahmand Mohanna: Yes Glen: Its better not to trust the HA. We are assuming the somebody connected to this HA so an evil HA can sent invalid accounting data Vishnu: I think we are not talking about NAS. The split diagarm is not talking about network access auth but MIP auth. The NAS auth is done right ? Gerardo: Yes Hannes: This document talks about HA to AAA. Vishnu: How would the HA route to the 2 differnt service, i.e. two differnet domains routing ? How would be diameter routing be affected. Hannes: Use diameter EAP for identity and the app id which is a different app id. No one propose to route it to a different domain. Vishnu: How many user id's ? Gerardo: One Madjid: First, there is access authentication and there is mobile authentication. Second is to use the same user id for diameter EAP and diameter MIP. - HA as single physical device - IKEv2 responder may act as: * VPN concentrator * HA - How the IKEv2-R know that IKEv2-I wants MIP6 service Gerardo: How will AAA know this is a mip6 authentication ? Glen: My suggestion takes care of this if you use mip6 app id on what amounts diameter EAP. Reuse the protocol with just a different app id. Gerardo: We are not splitting anymore ? One point is if you split them how will you bind ? It seems that we need some more features than 4072. Is it still worth splitting if we not going to split 4072 ? Lionel: If the EAP server is co-located to the AAA then one app id is used it would not be an issue Hannes: Other folks want to keep this as a different service Lionel: What is the meaning to split if you are not binding the authorization Hannes: Authentication happens sometime before we initiate Authorization. It might seem to be non obvious. Lionel: If you are assuming that server is tied to the authentication manager it is assumed that authentication is done before the authorization Hannes: Seems to be different view on what the security threats could potentially be. Depends on how much you trust the HA Yoshi: What is the consensus for splitting ? Gerardo: There is no consensus yet Dave: To be meaningful. Authorization has to be bound to Authentication but when you start doing multiple servers you add complexity. Flexibility is an enemy of security John: Unless there is a way to easily bind the AA when you have slipt. There will be security problems. Diameter Mobile IPv6: NAS-to-HAAA Interface for MIPv6 Bootstrapping draft-ietf-dime-mip6-integrated-01.txt Jouni Korhonen (15 minutes) - Applies to case where ASA is the same entity as MSA - Convey bootstraping info AVP as part of NAS auth - Status: * Version 01 of this document * Checked against MIP6 AAA goals - Issues: * Change the term from integrated scenario to NAS-to-HAAA interface * Is a new app needed ? * No need for new app, re-use NASREQ and EAP * All avps are optional * Do not specify new values for Nas-Port-Type and Service-Type * Capabilities advertisment * Use bootstrapping avp to adveriize nas bootstrapping cap to HAAA * Local HA allocation - No open issues Hannes: Expert review ? John: Ask reviews for this and previous draft to progress the wor. Some convergence already present Yoshi: New AVP are mandatory-to-support is set to existing applications Jouni: All avps are optional Yoshi: But its optional to use but mandatory to understand. In the case diameter EAP, request contains the new avp so the NAS will not understand. M-bit set right ? Jouni: It should not be mandatory. There might be errors in the AVP tables. Hannes: Review the document 4. Diameter Quality of Service draft-tschofenig-dime-diameter-qos-01.txt Tina Tsou (15 minutes) - Overview - Not a WG item, needs WG consensus to decide for direction. Dong: Whats the relationship between two documents. Which one are we going to standardize. Tina: In between IETF meetings, we selected on document to work on and revise. Not much different Dong: Some confusion on which document to lookup Hannes: It was the intention to have strawman proposal. Combined with the other one to have something to look at. Its up to the WG which one to adopt. Dong: Whats the output of diameter Qos diner ? Is there any conclusion how to integate with other Qos work ? Hannes: Qos dinner is a brainstorming to see how other SDOs did in this space. A lot of work was done so its challenging to combine it in one way. One way is to try to capture some use cases. John: Dinner does not have any implications in WG consensus. Pls identify on the ML what your issues are. Dong: Did not see a lot of activity on this subject on the ML Hannes: Would appreciate very much if we can get more activity. - Solution * Packet classification - Qos parameter description * SDOs plan to use differnet Qos parameters * Unlikely IETF is going to find parameter set that everyone wants Dong: I agree its challenging to support differnt Qos param. Should be beneficial if we can define common data structure. Hannes: We have already seen that different SDOs are using diffent data structures. We would not want to add a new one. We would want to talk to other SDOs to harmonize the work. Steve: How far down the road is everybody in this data format ? If not complete with other SDOs we have opportunity to influnce then otherwise were stuck with this. John: Look at what is reasonable and see if this fits on what other SDO. We can provide an end to end IP Qos, a higher layer Qos params. Dong: Other SDOs already thier own Qos in previous release. In general, it is better to combine these structures in a comon data struct Glen: The hardest task is the abstraction of Qos into a generalized entity. It takes a while to be architecture independent etc. Hannes: It really takes a while thats why this work started in NSIS years ago. John: Dave has been working with us in NSIS on this to make it interoperable. Dan Romanscanu: Problem needs to be decompose. It is not charter of this wg to define a model for Qos parameter. You should outsource some of this work. Just clarify the reference to that work regarding the model it is using. - Usage scenarios - What editors have done, update the binding and push methods in Sec 3.2 Qos Auth models - Next steps * Diameter application supporting Qos in AAA deployments * NSIS WG will be consulted on proper design of Qos attribute * WG item ? Dong: 01 added new model for the push. Its unclear what kind of push method you support ? Some push models are required by some technology. In some other SDOs they use a different model for push. Hannes: Those are valid scenarios. We need to descirbe both in reasonable level of detail. Dong: Commands can be different for different models. We can discuss later. Glen: Qos seems to be useful in many apps. Falls into the categroy in base that should NOT have a separate app. Lots of complaints of having too many app ids in the message. Can't have multiple apps in a message. John: Whose read the latest draft ? We cannot get a consensus calls. Call on review for the document to decide if this is a WG doc Avri: With two documents, bring them together so we dont have two things that are in disagreemnt. John: Use the document that we have as a strawman. Diameter Resource Control App draft-sun-dime-diameter-resource-control-requirements-00.txt Dong Sun - Focus on Qos authorization tirggered by path-coupled signaling - Integrated models imply auth sever and app server are collocated - Existing mechanisms and paras concerns about the qos as resource to be controlled - NGN view of TISPAN, ITU-T is that application functions (e.g. SIP proxy, IMS) should be totally independent of transport networks. Also reiterated by Dan. - Push mode is necessary for certian scenarios, already defined/used by other SDOs. Dan Romanscanu: There is a reason between separate application plane and network control plane. There is no way in networks that I know that the service provider can know what is going on in the end-point. This what leads to the separation of the application layer and control layer. John: Proposal goes beyond what the Qos document is. Get a little bit more background rather than just a solution. This can potentially be a different application or service. Hannes: We need to talk to ADs on what they think about this Glen: Its a completely different model. Theres no user involved your just pushing config data to a device. Major change to the protocol. 5. Planning for Next Diameter Interop Arun Handa / Chairs (15 minutes) - Logistics etc. Hannes: Improve the test cases John: Good to show the service provider Glen: We should not be doing this here Tom: We would like to add more to the test cases ---- ran out of time ---------- 6. Auditing with Diameter draft-bodin-dime-auditing-reqs-01.txt Avri Doria (15 minutes) 7. Diameter Duplicate Detection Cons. draft-asveren-dime-dupcons-00.txt Tolga Asveren (15 minutes) 8. Specification for use of EAP EMSK in deriving Mobile IP root keys draft-nakhjiri-eap-mip-usrk-00 Madjid Nakhjiri (10 minutes) 9. Any Other Business (5 minutes)