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