[Dime] Notes from IETF95 dime meeting

["A. Jean Mahoney" <[e-mail]>]

Below. Pieces I missed are marked with ellipses (...)

Jean

-----------------------------------------------------------------
IETF-95 DIME

1000-1200  FRIDAY, April 8, 2016, Morning Session I (120 min)
meeting room: Quebracho A

Chairs:
Jouni Korhonen <jouni.korhonen at broadcom.com>
Lionel Morand <lionel.morand at orange.com>


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
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