IETF68 DIME Meeting Minutes (3/22/2007) --------------------------------------- DIME Activity Overview (Hannes) ------------------------------- * Summary of Interop event Hannes : A couple of SCTP implementations available. TLS we are doing fine, there were more people doing transport layer security. Still some gaps in the base protocol spec with regards to the security check which one would want to do. Still some difficulty in the differences between certificate formats used among participants. Problem was present during the last interop but we already had some idea on how to resolve them. On TLS over SCTP, only one implementation and it is on a single stream only which defeats the purpose of SCTP a bit. More work needed. Base protocol election test are difficult to setup. Mostly because of timing issues in arranging the proper race condition. Dynamic peer discovery is rarely implemented because people don’t see a need for it. If it’s implemented it’s the DNS based approach. Something we can look at in the bis work. We had a few NASREQ and EAP implementations that we were able to test. Better than the last interop. For Diameter MIPv4 we saw two(2) implementations and none for Diameter SIP. Dan : Was the interop announced in different SIP list ? For SIP vendors to be aware of the event. Hannes : Good question. Speaking only about this particular interop, people were mostly interested in testing the base spec and credit control. Feedback from these tests is what we take into account when we look at the documents. Only two(2) companies had diameter eap. Feedback on that may be enough. On the diameter base we are doing fine. People implemented client, relay and server and played different roles. Lionel : People are not relying on diameter sip but rather with IMS interfaces which are not totally aligned with diameter sip. Hannes : Our focus was mostly on the base protocol so we did not solicit too much on specific applications. Dan : It would be better to announce this interoperability testing on the list which are relevant. The least we can do. Hannes : Something we should consider for the next event. No plans yet for the next event. * Status of documents Hannes : The QoS work is progressing slower than desired and slower than the mobility work. I have contacted a number of experienced QoS people to give feedback. To move forward, we would like to schedule phone conference where every one could participate including authors of the documents to give feedback on related SDO work and keep things aligned. Presentations ------------- * Bis document - Victor presenting Victor : All issues for bis has been captured on the tracker. Issues raised in the last interop + on the list has proposed solutions. bis-02 contains all of them. History, bis-00 is formatting only, bis-01 has changes for the 1st interop, bis-02 has solutions for 2nd interop. Issue #21, AAA/AAAS URI schemes has been registered Issue #28, Multiple Failed-AVPs in an ABNF, how would the result code map to the errors. First failure it detected would be sufficient and hence only one Failed-AVP would be present in practice. Lionel : Same comment in the last IETF. First failure would cause the error and we use the same model. Glen : It might be efficient in the long run to go through the entire message and detect all the errors but on the other hand this is a serious error which requires human intervention. So might as well signal the first error. Dave : Also a possibility that it could be trash data and you could be generating a lot of Failed-AVP if that’s the case. One Failed-AVP is the best way to go. Victor : Issue #33, Why is there a need for vendor-specific-application-id if application id space is flat. vendor-id has no discriminating properties. But since it’s already there and people have implemented it we should add text where we state that it should be treated as any other application id. ignore vendor-id. Lionel : Could you please rephrase ? Victor : There's an embedded application id in this group. Treat it as a regular application id. Simply ingore the vendor-id. Lionel : I'm not sure but at least the vendor-id is used in 3gpp in CER/CEA to indicate the vendor information, i.e. alcatel implementation of some interface. Victor : For capabilities exchange you may need that as an informational element but for routing purpose or other purpose other than informational we can skip over that. Issue #34, Question raised on the precedence of route discovered via redirect. Multiple cached redirect routes introduced several routing criterias. A new request can be matched with more than one of them. Which takes precedence ? Hannes : We had a conference call with Glen and Jari during the last interop. Give implementers a chance to talk to the original authors. Victor : Glen mentioned that you cache only a single redirect route at any given time. Glen : Can't remember. Hannes : Folks should look into the strawman proposal so we can close that issue soon. Jouni, Madjid ? Victor : Issue #35, Is the FQDN in the diameter identity an ascii representation or DNS resolvable. From talking to Jari and Glen, seems like this is just an ascii representation by default. Only redirect indication make it necessary to resolve hosts. Hannes : We need to ask some DNS experts on the internationalization stuff. At the time diameter was written there was no internationalization support. Chairs will try to find someone to do a review. Victor : Issue #37 Clarification on election text. Semi-solved. Why election winner closes connection ? Leave it the way it is since its already implemented. For FQDN comparison, see proposed text. Proposed text present in bis-02. Issue #38 Clarify what the "clientHello" envelop should be during TLS handshake. Is it SSLv2 or TSLv1 ? Some implementations break when expecting SSLv2. Probably just an implementation issue. Hannes : This is an implementation issue. Spec already indicates which TLS security should be implemented. Victor : We can close this issue. Issue #39 Additional checking needs to be done on received certificates after TLS completes. Make sure that the received certificate belongs to the peer you connected to. One proposal is to use subject alternate name. Hannes : Had a chat with the TLS WG chairs. Applicable to other transport security which has cipher suites that uses certificates. But there are other ciphers suites that does not do that so just listing this one is not sufficient. Have to list the others as well. This is an issue that comes up in various places as well. Best to write once and be applicable to the rest. Victor : Application specific issues. Will not go into detail. For others interested pls see issue tracker. Last issuses #50, 51 & 52 are comments for Jari Arkko. Issue #50, Remove SLPv2 and NAPTR discovery. Few people are interested in it. Hannes : Even though it might not be needed some discovery scheme is still useful. With todays roaming agreements which has preset association there is no discovery. Possible to simplify spec by removing discovery such as SLPv2. We only have one company implementing it out of 20+. An indication that it is not useful. Consider as potential candidate for removal. Unknown : There maybe future usage for this scheme. Hannes : But we have the DNS base discovery already. Victor : Is DNS sufficient for discovery ? Lionel : Which information will you use to do DNS queries ? Victor : Example is in redirect indication where you try to dynamically connect to your peer. Lionel : Is it related to diameter identities ? Victor : Yes Lionel : In TISPAN, SLP was seen as a way to differentiate the application supported and the services supported by the diameter entity. If using just DNS, you would only be able to know that the entity is a Diameter node. And capabilities exchange is not possible if there is a proxy in between them. Not sure if it was important but it was an issue. Hannes : Could you do a write-up on this issue ? Lionel : Ok Hannes : Are they mandating the use of this protocol or just discussing ? Lionel : It was being discussed. SLP was a way to discover supported applications by the client especially when there is a proxy in between. Victor : Issue #51, Removal of Sec 2.9 end-to-end security framework. Never really materialized. Hannes : To me it makes sense to remove it if the functionality just doesn’t exists. Victor : Issue #52, Consider removing references to IPsec. IPsec is transparent from the base protocol viewpoint. Unlike TLS, there is no interaction. Glen : I would assume that it is better to remove IPsec as a recommended transport security. I think its not a good idea to have IPsec. Victor : I agree. Inband-security AVP in CER/CEA does not have IPsec support. * MIP6 split scenario document - Julien presenting Julien : Issue #1 First option, Authorization and authentication separated. For authentication we are using diameter eap and for authorization we define a new application specific to mipv6. Second option, Authorization and authentication combined in a new application for mipv6. We have a running consensus call on this option. ++ Call flow for combined authorization and authentication shown in slides. At the end of eap auth exchange the home agent will send success and some specific mipv6 avp, i.e. home address, mipv6 capability etc. After exchange, the mobile node can send binding update to HA. ++ Call flow for comparing different type of authentication option. mip6 auth and rfc4285 support (???). If we use mip6 auth option, the MN would have shared key with the home AAA. The MAC will be computed by the MN and sent with the binding update to the HA. The HA will have to do AAA. If we use ikev2 option, we will have ikev2 at the same time as our application and then we use ipsec security association and then we can send binding update. The application is not used at the same time. In mip6 auth option we use the application after binding update is sent. We have three(3) alternatives: * One application id per authentication method. One application id for eap and one application id for 4285. * One application id but two different commands. One eap based command to deal with ikev2 auth and one command for 4285 to deal with mipv6 authentication type. * One application id with one command but a generic auth avp which would indicate the type of auth used. Victor : Speaking on behalf of Yoshi. He has concern on using one application id for authentication and authorization. It would be nice to get some feedback from his comments on the list. Hannes : From responses on the list, there is a consensus on using one application id for authentication and authorization. We have to move forward. I would believe that this issue is done. Julien : We already had a lot of discussion on the list about this issue. We also need to decide on the mipv6 authentication option. Hannes : We have asked the mipv6 WG and they came up with the requirements. They want support for this. Julien : We can make a decision now. Which one of the three alternatives are we going to use ? Unknown : Option 3 seems to be better than option 2 because we can reuse commands. What is advantages of option 3 over 1 ? Julien : For me, the problem with option 3 is that the diameter application is not used at the same time. In the mipv6 option we use the application after binding update, in the ikev2 we use it during ikev2 exchange. Lionel : At least we have one given example where different authentication mechanism are used over the same interface. It is the sip application in 3gpp interface where the same command is used for any kind of authentication. Also when to send the authentication request is not strict so we can reuse the same command at different times in the process. There is no relation on what happens on the mobile side and on the core network side. Julien : I dont think there is eap in diameter sip. Hannes : sip does'nt use eap. Lionel : But maybe the same case where you use one command with several round-trips and you use the avps as containers only. I prefer option 3. Hannes : We dropped the first option and we only have option 2 and 3. ++ Voting on the alternatives Who understands what the issue and alternatives are ? +++ only 3 answered Insufficient. Julien will do a write-up on this and we can make a decision on the list. Lionel : My only issue on option 2 is that will you be introducing a new authentication method. Julien : We are not going to introduce a new authentication method for mipv6. Hannes : We currently have two(2) and it took a very long time. Timeframe of years so its not that it comes up out of the blue. We can bring up the issue on the list. * MIP6 integrated scenario document - Jouni presenting Jouni : Status on integrated mip6 scenario. There are no big technical changes since 01. Mostly editorial. We are now in 02. Received a few reviews. So far there is no pending issue except for two(2). Not very well discussed in the DIME list. Issue #1, See presentation. Hannes : Who in the room is in favor of having explicit indication where the visited networks supports bootstrapping functionality ? ** no response ** Hannes : Re-phrase. Who understands what this issue is about ? ** little response ** Jouni : Put a summary in the list and provide some background for more discussion. This is for local ISPs to have a relationship with multiple MSP. It should be able to indicate to the MSA that these MSPs are available. Also be able to return back/authorize these MSPs. Hannes : My reading on this is that the previous doc provides implicit indication. But in some corner cases it’s not possible to let the home network know whether the access network know whether the access network supports such functionality. Being explicit is much more robust. Julien : I think this is for the second issue. Hannes : Sorry. My comment was for the second issue. Madjid : I think this is a good idea. It boils down to having nothing or having both networks allocate HAs. In order to avoid having nothing, its better to atleast have an indication. Also allow mobile to pick. Jouni : Issue #2, Authorization of local HA assignment while returning HA Hannes : Who understand the issues ? ** few people responded ** Hannes : Who is in favor of adding this capability ? ** few people responded ** Who objects ? ** few people responded ** Put the issue on the list again. Jouni : I would like people who had worked on split case to also review this document. Hannes : Doing fine with the document, we still need work. We'll update the document after getting some feedback from the list. This will get done pretty soon compared to the other document. * Qos document - Glen presenting Glen : The draft is now a bit better organized since last IETF. Terms used in the draft: * Application server - i.e. SIP server * Application end-point - i.e. SIP UA * Authorizing entity - Diameter server * AAA cloud * Network element - Qos aware device that has a diameter qos client Qos application runs on the network element which receives qos request. It sends authorization request to authorizing entity. We expect the network element to perform certain functions: * Admission control * Authorization * Resource reservation Authorization requirements - a lot of this you get with basic diameter * inter domain * identity based * flexible authentication * flexible authorization There a few Qos AVPs and there are questions on some of them. The questions with the AVPs are related to questions on how Qos should be integrated with diameter in general. Good thing to have a diameter Qos application but various SDOs might be interested only in Qos AVPs including the NASREQ messages. The extended Qos filter rule has some controversy. Prefer the use of grouped AVP instead of just an octet string to have greater flexibility. Hannes : For QSPEC (Quality of service specification) it refers to the parameters that the NSIS WG came up with. We don't do parameters in the DIME WG for obvious reasons. There’s one document which describes how the NSIS messages works with these parameters and these parameters are copied into a separate document. In addition, you also need to describe what kind of traffic are these parameters applicable for. We can refer to the IP filter rule in the base document and an extended version (NAS filter rule) in the NASREQ document. These types of things need to be extended in order to tie the Qos description to the traffic description. It also makes sense to align this with the IP filter rule that was defined in RADEXT WG. Dan : Is this a new development in RADEXT ? Hannes : No, a year ago there was this filtering and re-direct document. The decision was to go for a dual strategy. First RADEXT should point to the IP filter rule in diameter (document is in publication). There is another document which is the filter req rules. We have to make sure that the content of this document is compatible with what we are doing here and that there are some room for extensibility. It’s a string with the FreeBSD packet filter format. Some people want to have a different format but whatever we do we should be in sync with that format. AD : It is better if WG chairs talk about this prior. Glen : It was not clear on whether there was really a plan. Have been working with 3GPP folks to make this redirect rules to work and make RADEXT pay attention to them for a long time. I dont think it matters how much you talk if people make decisions in an unknown fashion. It was a big mistake to make this filter rules into strings. There was some proposals in RADEXT to enable something like grouped AVPs in RADIUS. Hannes : Given that there is a diameter compatibility statement in RADEXT, if you put something in there it automatically becomes available in diameter. In this particular case the RADEXT work provided more functionality than the IP filter rule found in diameter. The decision was made that RADIUS should not provide more functionality than the corresponding part in diameter and that’s why they went for the IP filter rule in RADEXT first. So they have to take equivalent of the IP filter rule in one of their document which is becoming RFC. Now we are trying to extend the IP filter rule. Madjid : Is the Qos a new applications or AVPs only ? Hannes : The use of application ids and mandatory avps is covered in the application guidelines doc but there are also use cases for both new application and use of AVPs only. Madjid : So your saying the use of AVPs cannot be the Qos application. Hannes : One scenario would be that after authentication/authorization with NASREQ, the AAA would return additional Qos AVPs in the NASREQ messages. This is one usage scenario. In other Qos scenarios, there is no natural fitting application so you need to define a new application, i.e allocate a new application id. Jouni : An example is in 3GPP where Qos application is needed because it is not present anywhere. Madjid : The AVPs would be considered mandatory for those people and therefore consider a new application ? Hannes : Almost a philosopical discussion on what mandatory means. Glen : At that point we are starting to run into the limitations of the M-bit. In order to use the AVPs without defining a new application then the M-bit must not be set. I think we can make it all work. Madjid : What the network element mean in the slides ? Hannes : We just have to name the network entity enforcing QoS policy. Unknown : We should discuss the push-pull methods in the mailing list. I'm in support of integrating this draft ... Hannes : There are decisions we need to make. First is, we have Qos documents describing the attributes - work is more editorial, just copy only the relevant parts. The other is how would we align the different documents out there. Example is the merging of the document describing the push approach and another document describing attribute only approach. We also have to consider the timelines of other SDOs. This also factors into whether we put this into a separate document or not. We schedule a phone conference for these issues. * Application design guideline document - Victor presenting Hannes : One of the milestones in the DIME charters is the app guidelines doc. Did have much attention even though it’s a fairly important one. Victor : Short overview of the app guidelines doc. Purpose of the document is to aid app designers in making better decisions during the design process. Provide some tradeoff analysis when presented with one model against another on commonly encountered problems. Current version is not comprehensive. Try to get more as time goes along. Document also tries to do some clarification on what the current extensibility rules mean. Not intended to add/change delete anything from the current spec. Current rules: * Creation of mandatory AVPs * Creation of new commands - automatically means new application id The tricky part is trying to decide when an AVP is mandatory. As a general rule, reuse commands and AVPs as much as possible. Mandatory AVPs are introduced only when there is a significant change in the semantics of the application. Avoid using optional AVPs for changing the sematics of an application. Adding optional AVPs tends to have a lot of interoperability problems. Avoid using optional AVPs which has duality in meaning. Document also provides other considerations: * Tradeoffs with single app-id or separate app-ids * Accounting models with current base protocol definition of ACR/ACA * Generic extensions to the base protocol Hannes : Document is something to read for people who plan to extend diameter. How many people have had a chance to look at it ? ++ good response How many think that this should be a WG document ? ++ roughly the same Lionel : Clarification, how about modifying existing application. Example, using User-name as mandatory in one application and re-using it as optional in another. It is not always about adding something new, it is also modifying existing applications. What about the modification of an ABNF ? Victor : You are allowed to add as many optional AVPs as you want. Lionel : But removing AVPs. Victor : Yes Lionel : The document will not define how to extend existing applications. So will the bis document changes do that ? Hannes : That’s true. The base protocol will also have to undergo some simplification. One might think that the rules in the base are quite easy but its not easy to decide when the criteria is met. Do we have volunteers for reviewers ? ++ few folks Victor : Clean of document. Pls read next week. * Auditing document - Avri presenting Avri : Quick update on the auditing documents * Requirements documents: There are no substantive requirement updates since last IETF. Contacted Pat Calhoun and added resource management 08 from the 2001 draft verbatim. The idea is that while moving forward we can discuss if it is still an appropriate solution. * Ulf and Tolga's discussion about state recovery and requirements. The authors wrote a draft on this. At some point this maybe worth folding into the whole auditing document. Hannes : We have support for the work but as I mentioned to the authors we are a little bit late on some of the existing milestones so obviously we are not going to add anything new. The only thing we can do is encourage the people to continue the work. The work is also supported by a liason request from ETSI-TISPAN. We encourage people to take a look at the work. Avri : Haven’t yet changed the name from requirements. More improvements will be introduced. Not sure if the state recovery belongs in this document or not but it seems to me that they do. * Liason request from ITU-T - Tina presenting Tina : ITU-T intends to use diameter in the Rw interface for signaling policy decisions between DPPE and PEPE. The DPPE acts as a diameter server and PEPE acts as a diameter client. There are two(2) modes: push and pull. The liaison is request to change the diameter base protocol to allow a diameter server session to send request. Dan : I'm trying to make the process more simple and reduce some overhead. We received some liaison letter from ITU-T and we need to reply. We need to suggest to ITU-T that they follow the document and the evolution of things. Liaison request should probably be limited to more important things rather than things like discussing state machine issues. Participants in both IETF and ITU-T can track the activities of the WG. Victor : As a summary, they want to do a server initiated request and the current statemachine defined in bis does not allow that. The suggestion is to simply switch over the type of session used by each entity, i.e. use client sessions on the server entity and use server sessions on the client server entity. Tina : The client and server can be more complicated. It matters in the implementation. The point is that an entity should act only as a server or a client. Hannes : We can reply to the ITU-T that this is still a work in progress. I don't think we have made up our mind already. Dan : Even if we have made up our mind during this meeting we should still reply that we are still working and pls follow our activities. * Source routing document - Tina presenting Tina : The issue is related to issue #4 on the issue tracker. This allows a request of the same session to pass through the same node/proxy. Changes in this version is to clarify some of the scenarios where this extension is used. The solution is not a true source routing. Hannes : What would you like the group to do ? Tina : Proceed with a WG document for this topic. Hannes : At the moment we cannot take on this document since we have outstanding work items. Who thinks that the idea/concept is a useful thing to work on ? ++ much better than last time Lionel : A general question, since it is not possible to add new work since we have outstanding work but is it possible to add this new AVP in the bis document ? Dan : In other words you are asking if we can play tricks. You can do it as long as it does not delay the current work. If you believe this is a small incremental change in the document. Victor : This work is too big for the bis Hannes : We want to simplify the bis. We want to placate some of the things people say that diameter is to complicated. This is partly because the spec is too long. We can do this as part of another document if people think that this is really important. Glen : Is this still optional. Victor : Yes