----------------------------------------------------------------- IETF-95 DIME 1000-1200 FRIDAY, April 8, 2016, Morning Session I (120 min) meeting room: Quebracho A Chairs: Jouni Korhonen Lionel Morand 10:00 - 10:10, Preliminaries (5 minutes) ------------------------------------------ Audio/Video & Remote Presentation Debugging Presenter: Jouni Slides: https://www.ietf.org/proceedings/95/slides/slides-95-dime-4.pdf Note Takers - Jean Mahoney (Thank you!) Jabber scribe - Jean Mahoney Jabber log - http://www.ietf.org/jabber/logs/dime/2016-04-08.html slide 1: Title slide 2: Note Well slide 3: Agenda 1/2 slide 4: Agenda 2/2 10:10 - 10:20, WG Document Status (10 minutes) ------------------------------------------ Presenter: Jouni Slides: https://www.ietf.org/proceedings/95/slides/slides-95-dime-4.pdf slide 5: WG Status Update (1/2) * draft-ietf-dime-e2e-sec-req-04 --> in IESG * draft-ietf-dime-drmp-04 --> in IESG slide 6: WG Status Update (2/2) * draft-ietf-dime-group-signaling-06 --> In WG --> WGLC? Received comments from Steve Donovan, which will be covered in the meeting. * draft-ietf-dime-load-02 --> In WG --> WGLC? * draft-ietf-dime-doic-rate-control-03 --> In WG --> WGLC? * draft-ietf-dime-agent-overload-04 --> In WG --> WGLC? * draft-ietf-dime-ovli-10 --> RFC7683 slide 7: Milestones Dime working group draft discussions (0 minutes) ------------------------------------------- Presenter: Steve Donovan Slides: https://www.ietf.org/proceedings/95/slides/slides-95-dime-3.pdf slide 8: Next steps Jouni - How far along is the agent-overload draft? Steve - it's ready for WGLC. Jouni - Then leave the draft as-is. All drafts can go to WGLC about the same time. Lionel - What's the issue with SourceID? Steve - The agent-overload draft defines the payload for it. The node that inserts the OL report or the node that advertises support. It's just a DiameterID. In the case of load - it's the node that inserted load report. Lionel - Is it a different type of id depending on the what you're sending? Steve - It's meant to be generic. I'll make sure it's clean. slide 14: Next Steps Lionel - maybe we should not send everything to WGLC at the same time, but send them in rapid succession. Start with the dime-load draft? Steve - That has dependencies on the agent-overload draft. Jouni - start with the document with most dependencies. Steve - agent-overload, then dime-load. Lionel - We don't have a dependence yet in 3GPP. Next step will be to rely on the AVP in the Release 14 timeframe, so we'll need something soon. Need to review agent-overload and dime-load. Steve - What about getting an early assignment for the AVP number? Lionel - I'll ask, but I don't think it's necessary. We have time. ACTIONs: Review/WGLC agent-overload first since more drafts are dependent on it. Then move on to dime-load review/WGLC, then the rest of the overload-related drafts. --------------------------------------- Group signaling feedback Presenter: Marco Liebsch Draft: https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/ Slides: None posted Slide: Title Thanks for Steve's comments Slide: RFC2119 consistency Steve - Capitalization issues - 2119 usage. Marco - we need to determine if the statements are mandatory or not. Slide: Server rejection of group assignment Steve - It's not clear. Are you talking about general Diameter requests or requests for group allocation? Could be read either way. Marco - Even if server rejects group assignment, the server could handle the Diameter session. It's for assignment of the group. Need to make it clear in the text. Lionel - It's in the sentence above. Steve - There's a few other places where it needs to be clearer. Slide: Server partial success of session group assignment Marco - Didn't think about this case. What would cause one to fail but another to succeed? Resource allocation? Steve - that's the fundamental question. Resources, policies. Server can insert a session into a group based on policy. Multiple groups request in one request. Resources is fundamental. Marco - From the signaling point of view. The client asks for assignment to 3 groups, of which, 2 allocations are set and the 3rd is cleared (not successful). How does the client react? Or does it reject all sessions? Steve - the last sentence implies all or nothing. Marco - that should be fine. For all 3 group. Lionel - The Session-Group-Info AVP will be there for all 3 groups. For the failed one, the flag is cleared. Steve - Add words to the effect that each AVP will present the status of each request. The words "as received" implies that it's one-to-one and can't be changed. Lionel - It's up to the client what to do - whether it wants to go on with a partial assignment or close the session. Steve - makes sense. Once a session assignment request fails, the session request must not be in group. This is a corner case - have to clarify that Lionel - client needs to manage each individual request for group assignment. And need to say what do to when not successful? Steve - yes. Slide: Client failure at server's session group assignment Steve - Agree that it should be rare. There's a policy concern. The client would not have requested it in first place. It has resources when it makes the request. What if the state saved in client is different than what's saved in the server? Is it bad to have inconsistent state? and if so, how do you sync state? Lionel - Especially if you have multiple groups. One spec group and... and if it was not maintained in the client, it would fail for at least one session. Clarify this. Marco - should the client terminate the session if it can't handle the group assignment? Lionel - "should" would be enough, but should clarify it. Avoid corner cases. There's not a concept of an optional assignment. The client should be able to comply to a request from the server or renegotiate the session. Slide: "Hard" server rejection of server Lionel - I don't see the problem for this one. For this request the server can't do group assignment. The session will be a single session. Marco - the server includes the Session-Group-Info AVP with the flag cleared. Lionel - if it's a legacy server, it doesn't send back anything at all. Steve - this is a protocol error. It's not constructing protocol error. RFC doesn't have to handle this case. Lionel - This server doesn't support it at all. Once the server has been updated to support the feature, but doesn't want to use it with these clients is another case. Marco - Should be known from other session using capabilities vector. Lionel - if you are a client, proxy, so on. Have e2e negotiation. I'll check that it's consistent in text. Slide: Use of Group-Response-Action AVP Steve - a fundamental question - and it's not clear - You have a group in a server with 1000 sessions. Which session does the server chose to send the update request to? The first one isn't an anchor or something? Marco - No Steve - Add text to clarify Lionel - any sessionID can be used can effect the session. Steve - Why all groups that this sessionID is part of. Why all groups? that's pretty complex. Lionel - we like to complexify everything. Multiple groups with similar ... Creating a request to put session in multiple groups. Charging characteristics with few differences. One characteristic is shared by all groups. Steve - but you can have a group of all groups. It's complex - you have to search... it's doable. It's seems strange when you can create another group. If you are defining a metagroup - Lionel - Can discuss on ML whether to keep the ALL_GROUPS. Marco - it's meant to be all groups in the request. You can indicate one or multiple groups in the request. If the session is in multiple groups - for instance Change QoS in these groups. Steve - need to define impacted groups. Lionel - Move on, move to ML. Slide: Next Marco - do we use tracker? Steve - look at state consistency question closely. Things can get out sync it seems. Individual draft discussions (15 minutes) ------------------------------------------- 10:20 - 10:35 End to end security solution, Jouni (15min) Draft: https://tools.ietf.org/html/draft-korhonen-dime-e2e-security-03 Slides: https://www.ietf.org/proceedings/95/slides/slides-95-dime-0.pdf slide 7: Protecting AVPs Jouni - JSON is kinda ok. Is CBOR/COSE more appropriate? Steve - we have some Diameter AVPs with an encoding. We would translate into JSON or CBOR and then encrypt? Jouni - just two new AVPs. slide 8: Signed-Data AVP Lionel - what about multiple instances of the same AVP? Jouni - you can have that. They have different signatures. Lionel - you sign each AVP? Jouni - yes slide 9: Encrypted-Data AVP Steve - it's not addressed in this draft, that it cannot be used with applications since encrypted AVPs. Jouni - The middlebox has to look at them. Steve - you could allow the encryption of routing headers if hop-by-hop. Jouni - but we're looking for e2e. Lionel - What about encrypting only AVP content? Jouni - Why reveal anything about the AVP? You can always encrypt content of the AVP unless there's structured content defined. Lionel - Username cannot be encrypted. Domain info. Jouni - You'll need a new app. You don't need username for routing in 3GPP. Lionel - if you can encrypt the contents-- Jouni - unless you have strict format of the AVP. NAI. Will fail at some middle box. It needs to be rehashed. slide 11: Anyway.. Jouni - pull up the presentation at IETF 85 for good examples. Jouni - does 3GPP want this? Lionel - likely, yes. No 3GPP requirements yet since the main interfaces have been internal. But they are asking more questions about security and integration. There are security questions around Charging Info. No TR yet. It's a MUST from my point of view. We just need people to work on it. People with more knowledge of security would be helpful. Jouni - There's just one guy who has the experience with both security and Diameter - Hannes. Lionel - maybe we ask for Hannes' support. Jouni - Please review the document. Lionel - we can use this doc as a starting point for WG discussions. Other discussions topics (20 minutes) ------------------------------------------- 10:35 - 10:55 Protocol errors, 'E' bit and answer command CCF grammar, Lionel (20min) Draft: N/A slide 9: Basic assumption Lionel - Must be compliant with 7.2 when it's a protocol error. Jouni - what's the real-life problem? Lionel - Redirection is a good example. EAP request in Answer has redirect indication. Vendors say you're not compliant. They just-- Jouni - that's just bad implementation. slide 10: Proposed way forward Jouni, as individual - it's not broken specification wise. There's bad implementations. We had an earlier situations where we had to clarify the base. I wouldn't update existing RFCs. If there is an issue, then a BCP or informational doc on how to write your spec would work. I wouldn't fix existing specifications. Jean - What about updating the Application Guide? Jouni - there are some corner cases in the App Guide. . Jouni as chair - I need to get the sense that this really is an issue. Anyone seen this in the field? Lionel - This is from 3GPP. Jouni - they can send it to the mailing list. Lionel - Yes slide 11: Your view? Lionel - could see what to put in the revision. Highlight what's missing/unclear. Lionel - It is difficult for new people to get involved in this group. It's not clear for new people. Wrap-up and Next (10 minutes) -------------------- 11:00 - 11:10 Next Steps: WG Chairs & ADs (10 minutes) WG Goals/Milestones status, next steps Slides: https://www.ietf.org/proceedings/95/slides/slides-95-dime-4.pdf slide 8: Next Step/Charter Jouni - not looking for new work just for the sake of extending diameter. Just security and the e-bit clarification. Lionel - what about topology hiding? any willingness to work on this issue? Steve - it's not an IETF problem. Is anyone asking for it? Lionel - not anymore. But it was brought up during overload discussions. Steve - GSMA has topology-hiding requirements. Lionel - I can check. Jouni - Actions before next IETF: ACTIONS: Progress all the overload/load docs. Lionel will assign reviewers for the documents. Lionel - e-bit handling Jouni - to initiate discussion on e2e sec and get secdir people. Jouni - WG to use the issue tracker for WGLC comments. slide 9: AOB? No further business