Re: [Dime] 99 IETF DIME session notes

Misha Zaytsev <misha.zaytsev.rus@gmail.com> Tue, 18 July 2017 14:58 UTC

Return-Path: <misha.zaytsev.rus@gmail.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 0DFF11204DA for <dime@ietfa.amsl.com>; Tue, 18 Jul 2017 07:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CZkG5oddtG9 for <dime@ietfa.amsl.com>; Tue, 18 Jul 2017 07:58:23 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2D512ECBC for <dime@ietf.org>; Tue, 18 Jul 2017 07:58:23 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id d78so12085441lfg.3 for <dime@ietf.org>; Tue, 18 Jul 2017 07:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZsRzxflDDEmlPzfDnN70IcZSRWn6tygNtTVXD+0Y804=; b=OBYsteXS0+bXw74cTN2o51F2scKFoqMHDVsPAHojGN1VhQcouRiPtkDX7c7+GeOyDH vVfwYPxs/IEVcWtoGuqYcIZ2B+mf4AK4YFD/HECvPvVBpzx8tWEFcnvxAeOkB4Kzb5wc RkNUqg4dBEyHOsFLaJVimxeSRx5cxP4+V62i8p4eohU7FNC8k1dmIfpbnMwS0PyZIdWT Sp+ZZSJPXGKv+hfU5OCCDfxL1wyYpZDPjEa7bXczn2rtg52VInSLBbAZbbfVzdXm+27l c9Msv7kyw2nPATwSL2gBP6+6rZeBhDqrj6MeR09ut4gg64a/0WqL9WZ61kDLEybNtYCg NkgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZsRzxflDDEmlPzfDnN70IcZSRWn6tygNtTVXD+0Y804=; b=Rfdzo6jf3i0pH5RGNPl/sm995YzVedoMU7GwhzLMZt9+T1z749CClIuVH7mY7mFWc6 pJT4/SrppPGteJrnsOoXdQbUZlnQ+1IojHnpcpggBNlAQuZ2uzbtnZK76llostJqsL2Z 8t/DroktGQpM7FU504aGOHooOFkgyF04u0xyJ+zHvpNVGEK7xhYbAKRyXPoNGg/tcynH K/lcJvzYINuCgA7m2Y8mR/fJIs+xnI/oQeX5rDcwflfWDXE1E8KxA5OdyWTpUTQBdAXW M8sqtqnYfYA8yyCvA0fWCT9326UUf4S2KdpXlztOr238bO/mw8QJDlc64EeQRiiow/Bj Fhow==
X-Gm-Message-State: AIVw110dJCGHigiTUlDU8KU91Ae0GGoFcSy7bH1VOkKo33jBh6rMrQUb 2cw7bvH85gxFE02VQyYcrRAk4vuxFg==
X-Received: by 10.25.103.19 with SMTP id b19mr925036lfc.80.1500389901270; Tue, 18 Jul 2017 07:58:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.20.193 with HTTP; Tue, 18 Jul 2017 07:58:20 -0700 (PDT)
In-Reply-To: <7278718efbb946b8adb89c7306cced30@CSRRDU1EXM025.corp.csra.com>
References: <9ec38b25-41d4-a751-aa97-d8af0f9022c5@nostrum.com> <7278718efbb946b8adb89c7306cced30@CSRRDU1EXM025.corp.csra.com>
From: Misha Zaytsev <misha.zaytsev.rus@gmail.com>
Date: Tue, 18 Jul 2017 17:58:20 +0300
Message-ID: <CABPQr25D4f5RrSAy3gEEvjqZ+SP+F5++Uy4tFY5T0sbQNQu91Q@mail.gmail.com>
To: "Gunn, Janet P" <Janet.Gunn@csra.com>
Cc: "A. Jean Mahoney" <mahoney@nostrum.com>, "dime@ietf.org" <dime@ietf.org>
Content-Type: multipart/alternative; boundary="f403045e92541704ac055498bf6d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/rds_FVhyLegmooNwsGfe2B5Xp9E>
Subject: Re: [Dime] 99 IETF DIME session notes
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 18 Jul 2017 14:58:27 -0000

Hi All,

May I wonder about e2e security draft mentioned in the MoM? Where can I
find it?

Thanks in advance!

/Misha


2017-07-18 17:53 GMT+03:00 Gunn, Janet P <Janet.Gunn@csra.com>om>:

> Nit
> In Martin's statement, I think  "FCC sys rec" should be "FCC CSRIC"
> https://www.fcc.gov/about-fcc/advisory-committees/communications-security-
> reliability-and-interoperability-1
>
> Janet
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of A. Jean Mahoney
> Sent: Tuesday, July 18, 2017 9:42 AM
> To: dime@ietf.org
> Subject: [Dime] 99 IETF DIME session notes
>
> Hi all,
>
> Below are my notes from the session yesterday.
>
> Thanks!
>
> Jean
>
>
> ------------------------------------------------------------
> -------------------------------
>
> IETF-99 DIME
>
> 1740-1840  July 17, 2017, Monday Afternoon session III meeting room:
> Karlin III Jabber room: dime at jabber.ietf.org (Please join)
>
> Chairs:Jouni Korhonen, Lionel Morand
> AD: Ben Campbell
>
> 17:40 - 17:45, Preliminaries, Chairs (5 minutes)
> ------------------------------------------
> Presentation:
> https://www.ietf.org/proceedings/99/slides/slides-
> 99-dime-agenda-wg-status-00.pdf
>
> slide 1: Title
>
> Lionel Morand: Jouni is not able to make it to the meeting.
>
> slide 2: Note Well
>
> slide 3: Agenda
>
> Note taker/Jabber scribe: Jean Mahoney
>
> Martin Dolly: when will Diameter security discussion happen?
>
> Lionel: end of the session.
>
>
> 17:45 - 17:50, WG Document Status, Chairs (5 minutes)
> ------------------------------------------
>
> *draft-ietf-dime-agent-overload-11    --> RFC Ed Queue
> *draft-ietf-dime-doic-rate-control-06 --> Waiting for Write-Up
> *draft-ietf-dime-group-signaling-08   --> In WG Last Call
> *draft-ietf-dime-load-09              --> RFC Ed Queue
> *draft-ietf-dime-rfc4006bis-03        --> In WG Last Call
>
> slide 4: WG Status Update
>
> Lionel: Both overload and load are in the RFC editor queue due to a
> MISREF. I'll take care of it after this meeting.
>
> Steve Donovan: Just a nit on the slide - I'm the editor on load
> information, I'm not the editor for 4006bis.
>
> Lionel: Group signaling - the author's think it's ready. We need more
> reviews. Marco?
>
> Marco Liebsch: we've updated it before Chicago. We've covered all
> comments. Is ready for expert review.
>
> Lionel: we've received a good technical review from Steve. Needs another
> before WGLC. Rate control is missing its writeup.
>
> Steve: Has it finished WGLC?
>
> Lionel: Yes, needs writeup. Rate-control didn't receive a deep technical
> review. Need further review. From SA5 guys in 3GPP, since they are the main
> users.
>
> slide 5: WG Status update (2/2)
>
> Lionel: AVP level security (e2e) draft has expired - Jouni is not able to
> support the workload alone. I will go to the SAAG meeting and will ask for
> support from security experts. Solution doesn't have to be Diameter
> specific.
>
> Ben Campbell: I would personally like to see this completed. Who will
> deploy it?
>
> Martin Dolly: next round of FCC sys req, they just finished looking at
> SS7 security vulnerabilities, next 2 years they'll look at Diameter. SA3
> coming up in 3 weeks. I'll give them discussion paper, a status update of
> work here. It gets friendly talk there. It's been discussed with regard to
> 5G and security system. It's now or never, forever-hold-your-peace time.
>
> Lionel: GSMA would like a recommendation. If it's easy to implement, we
> have ongoing deployment.
>
> Ben: They are welcome to come here and help.
>
> Eric Guttman: for mission-critical deployments, there are 2 security
> domains - operator domain and mission-critical operator domain. We've
> looked at securing at a message or component to a SIP message level. The
> message has to be e2e secure between client and host at the
> mission-critical ISP. Are there AAA requirements where you can't expose
> certain AVPs to the operator? Need to check.
>
> Lionel: From the requirements POV, both should be available with the
> solution. Normally you would only be able to secure signaling between
> gateways for instance. You may have e2e secure exchange between any
> Diameter client and any Diameter server.
>
> Martin: I don't think that's a case. 401 specifies that equipment
> manufacturers must support IPsec for communication within the EPC, but says
> it optional to deploy. No one has deployed. For 5G, the European operators
> are fighting pulling the security into the EPC not at the ENodeB. Some of
> those statements aren't true.
>
> Lionel: Ben, you see there is some interest. We would like to see this
> work done in IETF.
>
> Ben: I observe an interest in using the work. I need to observe interest
> in doing the work. Maybe SAAG will help.
>
> Lionel: It's more a security discussion than a Diameter discussion. Need
> help from security area.
>
> Eric: There was a mechanism for using an SMIME encapsulation. That became
> historic?
>
> Lionel: deprecated. A new mechanism will be defined outside the base
> protocol. All new drafts are based on this.
>
>
>
> 17:50 - 18:35 Individual draft discussions (45 minutes)
> -------------------------------------------
>
> 17:50 - 18:10 Diameter Policy Groups and Sets, Lyle (20min)
>    Draft: https://tools.ietf.org/html/draft-bertz-dime-predictunits-02
>    Draft: https://tools.ietf.org/html/draft-bertz-dime-policygroups-04
>    Presentation:
> https://www.ietf.org/proceedings/99/slides/slides-99-dime-predicted-units-
> policy-groups-00.pdf
>
>
> slide 1: Title
>
> slide 2: Predicted Units v02 - Motivation
>
> Lyle: It takes 3-4 minutes to spin up a VM.
>
> slide 3: Predicted Units v02 - Update
>
> Lyle: Have not received any new updates. I would like to ask for adoption.
>
> Lionel: Who has read? I wasn't in the last meeting what was the feeling
> in the room?
>
> Ben: Besides the chair and the AD?
>
> Jean: About 7 people total.
>
> Lionel: I've read it and understood the mechanism, which is good. Check
> on the ML if there is support for adoption. There's not much to do on
> this doc.
>
> slide 4: Intermission
>
> slide 5: Purpose
>
> slide 6: Policy Groups - Update
>
> slide 7: Relationship Model
>
> slide 8: Policy Groups Example 1, Overlap Deduplication at Enforcement
> Point - Adding Membership Assignment to Filters
>
> Lyle: SDN switches have limitations of tables (13 tables in OpenFlow).
> Can concatenate tables. The rules no longer overlap. How to use your
> metadata field and tie it back to a customer?
>
> slide 9: Policy Groups Example 2, Application at the Decision Point Process
>
> Lyle: We don't change the user's relationship to their services
> mid-session. Usually reauthorize them before doing that.
>
> slide 10: Applications
>
> slide 11: Next Steps
>
> Lyle: Would like to hear more from the group before asking for adoption.
>
> Lionel: who has read?
>
> Lionel: Go back to the Purpose slide.
>
> Lyle: didn't want to confuse people but wanted a similar aggregation
> concept with backwards compatibility. It's similar to ... It's a
> membership domain.
>
> Lionel: I need to review it again. It would be useful to have more review.
>
> Lyle: I'm not happy with the examples, I'd like them to be consistent
> through the doc.
>
> Lionel: the draft needs to clearly identify why you can't do this with
> existing mechanisms.
>
> Lyle: all of our filters are based on time and what's in the packets.
> When the time is the same and the rule is a default rule, that's the
> most overlap in the system.
>
> Lionel: It's not that clear from the creation of AVP, be good to
> describe it.
>
>
> 18:10 - 18:35 Diameter Specification Recommendations, Lyle (25min)
>    Draft: https://tools.ietf.org/html/draft-bertz-dime-diamimpr-00
>    Pres:
> https://www.ietf.org/proceedings/99/slides/slides-99-dime-diameter-
> specification-recommendations-00.pdf
>
> slide 1: Title
>
> slide 2: Motivation
>
> Lyle: 85% of the time, errors due to ambiguity.
>
> slide 3: Findings
>
> Eric Guttman: send this to SA5 charging if you have a delegate.
>
> Lyle: we don't, but wanted to get it out.
>
> slide 4: Methodology
>
> slide 5: Unexpected Use Cases
>
> slide 6: We are not immune
>
> slide 7: Enumerations
>
> slide 8: Recommendations
>
> slide 9: Defined AVP Recommendations
>
> slide 10: Defined AVPs Recommended Formats
>
> slide 11: Imported AVP Recommendations
>
> slide 12: Grouped AVP / Command Refinement
>
> slide 13: Example Refinement
>
> slide 14: Command Recommendations
>
> slide 15: Enumeration Recommendations
>
> slide 16: GAPs for Automated Validation
>
> slide 17: Example to Close Gaps
>
> slide 18: Enumeration Example Format
>
> slide 19: Open Questions
>
> slide 20: Summary
>
> slide 21:  Next steps
>
> Lionel: who has read? (Three people raised hands)
>
> Lyle: Dave Dolson and Jouni read it.
>
> Lionel: in 3GPP it's not really refinement, because in 3GPP just
> highlight the AVPs they use. We you take a specification and not reading
> anything -
>
> Lyle: they want to just write the code and be done.
>
> Lionel: For new drafts, it should be taken into consideration. For
> existing RFCs, these are documentation errors. When it's clarification,
> it needs to go through the errata process. For the 3GPP specs, CRs need
> to be opened.
>
> Lyle: This has a lot of errors documented. Would this be informational?
> How would it progress?
>
> Lionel: It can be informational, and can be referenced by other docs. No
> guideline here. Just highlight what could go wrong.
>
> Lyle: I would change the style. Make it more of a report.
>
> Lionel: It's not unusual for the IETF to explain issues with
> implementations.
>
>
> 18:35 - 18:40 Wrap-up and Next, Chairs/AD (5 minutes)
> -----------------------------
>
> WG Goals/Milestones status - skipped
>
> Next steps/Action Points - Future of the WG
>
> Lionel: We have 3 remaining documents.
>
> Ben: And two that you are thinking of adopting.
>
> Lionel: few people in room, not much activity on the list. I won't be
> able to continue with the chair position - too much work in the 3GPP.
> Same with Jouni - he changed companies, won't be able to continue. What
> is the next step except closing the group?
>
> Ben: The existing documents are post or near WGLC. Those can be in the
> hands of the ADs before long. What's you're time frame for needing to
> step down?
>
> Lionel: I need to know when to stop adopting new documents. Even for Jouni.
>
> Ben: Of the 2 drafts for the adoption - the predictive units can be AD
> sponsored. The group one is on the border, a little more complex. I
> don't have to be the AD that sponsors it.
>
> Lionel: For the group one, I need to see more interest.
>
> Ben: even if I AD sponsor, I want someone to review them.
>
> Lionel: E2E security needs to be done. If we get volunteers from SAAG.
>
> Ben: lets see what happens in SAAG. If there's interest - maybe we can
> spin up some mini-group. Or just speculating here - recharter dime with
> new chairs to just do that.
>
> Lionel: If it is only to go with existing drafts, I think it can be done
> in short timeframe. Need to confirm with Jouni. Defining new charter
> with new chairs may not be useful.
>
> Ben: E2E security may go into the security area.
>
> Lionel: Are there any other comments? (none from the room). To summarize
> - existing WG documents will be pushed forward. For predictive units,
> confirm on ML that it's a WG doc, for the group one, we'll check. After
> those documents, we'll close the WG.
>
> Ben: Those 2 new drafts - predictive definitely and maybe group - can be
> AD sponsored. They can still change to AD sponsorship if we need to
> close the working group sooner. I'm skeptical of bringing new work into
> the group, unless we see interest.
>
> Lionel: Thank you.
>
> ACTION: Chairs to push existing WG documents forward.
>
> ACTION: Lionel to bring the e2e security draft to the SAAG session this
> week to ask for support in finishing it.
>
> ACTION: Confirm interest on mailing list for adopting
> draft-bertz-dime-predictunits.
>
> ACTION: Confirm interest on mailing list for adopting
> draft-bertz-dime-policygroups.
>
> ACTION: Ben to look more closely at draft-bertz-dime-policygroups as a
> candidate for AD sponsorship.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
> This electronic message transmission contains information from CSRA that
> may be attorney-client privileged, proprietary or confidential. The
> information in this message is intended only for use by the individual(s)
> to whom it is addressed. If you believe you have received this message in
> error, please contact me immediately and be aware that any use, disclosure,
> copying or distribution of the contents of this message is strictly
> prohibited. NOTE: Regardless of content, this email shall not operate to
> bind CSRA to any order or other contract unless pursuant to explicit
> written agreement or government initiative expressly permitting the use of
> email for such purpose.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>