DIME IETF 81 notes (draft status on 5-Aug-2011)
THURSDAY, July 28, 2011
1300-1500 Afternoon Session I


== Administrative
============================================================

** WG status update (Jouni)
----------------------------

Discussion on Status of drafts in IESG processing:

Discussion on draft-dime-priority-avps)
* Ken C: IESG asks for of motivating new AVPs.
  Additions to an existing application. Will refer to the existing
  Application incl. the security section. Revised I-D which has the 
  reference to QoS needed.
* Jouni K: Had discussions with IESG members. Conclusion is that
  not every ID has to have an outline of solution applicability.
  It is left to the reader to think of deployment scenarios/
  applicability.
* Simon M:
  Think that there are additions required for 3588-bis.
  (not the encrypted indicator). Indicator required in the message
  header. Will provide details during the presentation.

General:
* Dan R:
  There was an issue with the tools, which is why 3588bis temporarily
  disappeared.
* Dan R: 
  Still waiting for base protocol MIB.
* Glen Z:
  Issues with co-author. Glen hopes to finish I-D.
* Glen Z: Question: When two or more documents relate to each other 
  they put them into a holding pattern - meaning that they are  
  completed but wait for publication. Does this process still exist?
* Jouni K: Don't know. Chairs will check the current procedure.


== Working group draft presentations
=========================================

** Diameter IKEv2 PSK (Simon M)
   draft-ietf-dime-ikev2-psk-diameter 
   (-09 is in progress - being circulated among authors)
---------------------------------------------------------
* Simon (see also presentation):
  - added architectural background to the draft
  - clarified that they do not specify how the IKE peer derives the 
    PSK
  - key issue clarified that mutually authenticated TLS between 
    Diameter nodes is already expected
* Glen: Why "Key-SPI AVP is included in the request instead of Key 
  AVP"?
* Simon: In the request it does not make sense to send the full key,  
  it only needs to send the reference which key to use. This was 
  based on comments received.
* Simon: There would need to be an indication in the diameter header

  that "this AVP is critical", so that it would be encrypted. Does 
  this make sense?
* Glen: Wishful thinking that this would be a solution. Most attacks
  come from inside.
* Simon: What is the solution?
* Glen: Getting rid of hop-by-hop security is not the way to go.
* Simon: 3588 does not mandate hop-by-hop security.
* Simon: They will add a note to the security section.
* Glen: Best solution would be encrypting it in the application.
* Simon: This draft is not the right place to specify a solution
* Lionel: The document says that you need to have a secure transport. 
  But it does not enforce IPsec/TLS.
* Glen: Simple approach: "My network is secure - hence we don't have 
  to do everything" - which isn't appropriate - "my network is secure  
  because I say it is secure" logic should not be applied.
* Lionel: Then it is up to the telco/operator - not to the protocol,
  because the protocol says that you have to secure it. Doc says it 
  has to  be secure - it does not say which mechanism (i.e.,
  TLS/IPsec). 
* Glen: Putting a flag that says: If you go to the evil Internet, 
  then encrypt - is wrong.
* Lionel: Then we have agreement. We're covered we don't need
  anything else.
* Simon: So conclusion is that 358bis is sufficient.
* Ken C: What exactly means "secure" - we probably needs to be 
  specified what we mean.
* Simon: Don't care about integrity protection - I care about 
  encrypting the key.
* Lionel: Please re-check whether the existing text in 3588bis 
  reflects all security needs.
* Simon: Text is sufficient. But from a practical point of view it is
  not.


** AAA support for PMIP mobility - localized routing (Qin Wu)
   (draft-ietf-dime-pmip6-lr)
   (see also presentation)  
------------------------------------------------------------ 
* Simon: What is A21?
* Qin: Reference to problem statement for PMIP (specific use case).
* Simon: Is this for MN goes through two MAGs to the same LMA at the
  same time.
* Qin: No it is not.
* Marco: Use case is different: It is two MNs - which communicate
  directly. A21 is two MNs connected to two different MAGs.



** Diameter ERP 
   draft-ietf-dime-erp (Qin Wu)
   (see also presentation)
-------------------------------
* Qin: discussed multiple times, but very little progress due to some
  issues
* Presentation outlines approach to resolve remaining issues:
  first is session management during peer handover
* Lionel: How would it be possible to have the same session id by
  multiple NAS? 
* Qin: They use different session IDs. Server would correlate session
  IDs.
* Simon: Session is associated with client ID and IP-address. When
  handover happens, one can easily assign the same IP address. He  
  understands that one can have a correlation id - but it is the same 
  as client-ID + IP-address.
* Glen: what is the client-ID?
* Simon: Client-ID is included in accounting start.
* Glen: Still unclear / don't understand.
* Simon: Mobile requests session through the NAS. Identity of the 
  mobile is send to AAA that authenticates the session. In the 
  response AAA assigns IP address to mobile. Mobile receives HAA. 
  This identifies the session to AAA.
* Qin: we talk different sessions - Diameter session vs. mobile 
  session.
* Simon: Unique identifier for accounting etc. is required Ð 
  identifiers stay.
* Lionel: Do we need something else to identify existing sessions.
* Qin: Reuse acct-multi-session-id
* Lionel: Is this too limited? It is all about having a user move 
  from one access to another access.
* Glen: It is an authentication protocol. The user id is the same. 
* Lionel: You can use this identifier.
* Glen: Then NAS assigns a new accounting session ID. Some carriers 
  see this as a big problem.
* Lionel: OK it is only an accounting problem. Now I understand.
* Simon: Old NAS sends accounting stop. The new NAS sends a start.
  It is not the same session.
* Glen: acc-multi-session-id is included. Hence records can be
  correlated.
* Simon: UDRs will be put into different caches. Are you saying that 
  we now use this parameter to correlate different caches.
* Mark Jones: Diagram does not help us - should say session-ID 1
  and 2 (not 1). You are using acc-multi-session-id the way it was 
  expected to used. Works for me.
* Glen: Everything works natural. Will be uncontroversial.
* Simon: How is acc-multi-session-id passed?
* Glen: Assigned by the server - it always comes back to the NAS 
  (NAS1 or NAS2).
* Qin: Second issue: Multiple EAP servers in the same home realm.
* Lionel: Any feedback from Hokey received? Do we need to combine the
  issue with the application?
* Glen: We need to discuss the issue: ERP needs to talk to the same 
  guy all the time (guaranteed by Diameter - may be? maybe not?). If
  it is somebody else, then this guy has to have the key. Once we 
  resolve it we say e.g.: Once we have multiple EAP servers,
  they MUST by synchronized.
* Lionel: Do we need to solve it within Diameter? 
* Glen: There can be multiple solutions. Radius has the same issue. 
  It is not an EAP problem. It is a transport problem.
* Lionel: We need this for ERP at least - but issue is more generic.
* Simon: Multiple servers in home domain is not an issue - but it is  
  in local domain.
* Glen: It is an issue in the home domain if there is explicit
  bootstrapping.
* Glen: Issue only comes up with servers with disjoint databases.
* Simon: Load balancing is common - but they ensure to have all the 
  same state.


** draft-ietf-dime-nat-control (Frank B)
----------------------------------------
* Frank: Sorry no slides. Verbal summary:
  - Several DISCUSS received. Key ones are
  - How many NAT-controllers and NAT-devices? New rev will clarify 
    the n:m relationship between controller and NAT-device
    It needs to be ensured that for a single endpoint there's only
    a single controller-NAT-device pair responsible.
  - Relationship MIDCOM (and other NAT control protocols)
  - Intended to be resolved by putting DNCA into the MIDCOM 
    context. RFC 4097 studies Diameter as a potential MIDCOM 
    candidate. DNCA almost fits MIDCOM. Small additions required to
    cope with consecutive ports and oddity of RTP/RTCP.
  - Security questions (largely around trust domain. Updated rev 
    will include additional considerations).
* Dan R.: Key issue in IESG: MIDCOM
  - RFC 4097 (framework doc) was prepared to provide context for 
    MIDCOM protocol selection.
  - Protocol happend not to be Diameter. 
  - Positioning: There can be multiple implementations of MIDCOM -
    because management requirements and deployments by operators 
    differ. Examples already exist: e.g. SNMP and NETCONF.
  - We're proposing *another* standards track - intended to 
    complement existing protocol for MIDCOM. Not intended for 
    replacement. There can be more than a single management protocol.
  - following the requirements of different operators/deployments
    (and Diameter is already used in multiple deployments);
    Having multiple protocol options is typical for management
    protocols. 
  - Protocol work on DNCA could potentially (if there is interest) be
    complemented with BCP work in transport area, recommending one 
    over another solution.
  - If desired (see note on n:m), it could even be that a single NAT-
    box is controlled by different protocols (while ensuring that a 
    single endpoint is only under the control of a single Controller
    and NAT-device pair)

** draft-ietf-dime-extended-naptr  (Mark J)
* Mark provides brief update (see slides). No comments from the WG.
-------------------------------------------------------------------

** Diameter Bulk Signaling  (Marco) 
   (draft-liebsch-dime-diameter-bulksig)
   (draft-liebsch-dime-diameter-gps)
   (please also see presentation)
--------------------------------------
* Dan R.: Do you have a feeling how much you can reduce the load?
* Marco: Depends on the scenario.
* Jouni: Could be a huge amount.
* Dan R: Do we need to have TISPAN/3GPP approve the doc?
* Marco: Shouldn't we do the work first?
* Dan R: Proposal should be circulated during individual submission
  phase with other SDOs first.
* Glen: Seems 4th time that it comes up. Does not have anything to do
  with AAA. But while back, Glen said: Let's have a BOF - but it 
  never happened. He does not have the time and energy to spare on a 
  BOF.  Request to the Chairs: Take it or don't take it. We need a   
  decision: Whether it belongs here (i.e. change the charter of dime) 
  or start a BOF.
* Mark J: I would like to see this done. I don't mind where it is 
  done. 3GPP and others have use cases. The way things are done right 
  now - we don't want to see this happening. I want this group to 
  review this (or another group of experts).
* Lionel: Do we really need to do such work? We need to have clear

  requirements for this work. We need to ensure that this work will 
  be useful for other SDOs and be used.
* Mark J.: My concern is that there is a certain time window. If we
  hesitate, we look at the BCP out there and do things on their own.
* Janrong Wang: Followed 3GPP. Comes to IETF to look for solutions.
  Includes overload scenarios (e.g. server tells client that he's 
  overloaded). 
* Marco: Problems are out there. What do you want us to do?
* Dan R.: If there are other SDOs - have them come to IETF, submit to
  the dime list. If we say that we solve the problems of other SDOs, 
  then these other groups need to tell us.