[Dime] DIME IETF81 draft notes
"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Thu, 28 July 2011 21:00 UTC
Return-Path: <fbrockne@cisco.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0C75E8023 for <dime@ietfa.amsl.com>; Thu, 28 Jul 2011 14:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.561
X-Spam-Level:
X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il10m6oLwvSN for <dime@ietfa.amsl.com>; Thu, 28 Jul 2011 14:00:27 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76C5E8014 for <dime@ietf.org>; Thu, 28 Jul 2011 14:00:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=12401; q=dns/txt; s=iport; t=1311886826; x=1313096426; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=QKSG5CkwGPRTbK76tTLgxlbmkSREsSU+HqMfwoh41Ek=; b=VdgsoYU99noMwI4XOEiQg5MSCpaDX69BG8A5e0oboDAUD1tudNvKepMK 7OCcev0LFX+jFhSSKnkzc065AWFKEvGEHEaJBQEfCBuSmnqUSR2oScXnf wd4KRCjcou0VQX5EpLPnqyxBUn0kt8N4kNpK9vGB7U0m+r5Uz+3xHqf/h k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuQAALvNMU6Q/khR/2dsb2JhbAApDQEBAxQBIQozBAcaASsGBgEJFAcTUgEFEhEUB5drj093rEuBI549gyMBGguCGV8EmAmLVjo
X-IronPort-AV: E=Sophos;i="4.67,284,1309737600"; d="scan'208";a="105273994"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 28 Jul 2011 21:00:13 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SL0D4B030647 for <dime@ietf.org>; Thu, 28 Jul 2011 21:00:13 GMT
Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 23:00:13 +0200
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Jul 2011 22:58:19 +0200
Message-ID: <0D212BD466921646B58854FB79092CEC064689CE@XMB-AMS-106.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: DIME IETF81 draft notes
Thread-Index: AcxNaRSF1z14u6BJSpOi/CvQ9SqUOw==
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: dime@ietf.org
X-OriginalArrivalTime: 28 Jul 2011 21:00:13.0859 (UTC) FILETIME=[587FFF30:01CC4D69]
Subject: [Dime] DIME IETF81 draft notes
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 21:00:28 -0000
FYI. Below are the raw notes from today's DIME WG session at IETF 81 (sorry for any typos/misspelled names etc). Please review and unicast me any updates/changes. I'll consolidate those into the final version. Thanks, Frank ------------------------------------------------------------------------ ------ DIME IETF 81 notes 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 disapeared. * Dan R: Still waiting for base protocol mib. * Glen Z: Issues with co-author. Glen hopes to finish i-d. * Glen Z: Question: When 2 or more docs 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. == Working group draft presentations ========================================= ** Diameter IKEv2 PSK (Simon M) draft-ietf-dime-ikev2-psk-diameter (-v09 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 encrypt it in the application. * Simon: This draft is not the right place to specify a solution * Lionel: Doc 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 specify 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) ------------------------------- * Qui: 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 * Linoel: 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 auths the session. In the response AAA asigns 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. * Linoel: 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. * Linoel: You can use this identifier. * Glen: Then NAS assigns a new accounting session ID. Some carriers see this as a big problem. * Linoel: 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.
- [Dime] DIME IETF81 draft notes Frank Brockners (fbrockne)