Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02

Tom Herbert <tom@herbertland.com> Wed, 18 October 2017 17:34 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBEC132F7C for <ideas@ietfa.amsl.com>; Wed, 18 Oct 2017 10:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 VKIgQvRLVs-c for <ideas@ietfa.amsl.com>; Wed, 18 Oct 2017 10:34:47 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 632691270AB for <ideas@ietf.org>; Wed, 18 Oct 2017 10:34:47 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id o187so7214997qke.7 for <ideas@ietf.org>; Wed, 18 Oct 2017 10:34:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4QIa64Xl/JCxoh2UyUnCoycWTrnAkNFG71sbtovAwDE=; b=zjLmu2t0sX3zTSkg9W/XowgGzl8mB0OsILclwmKNwdYXqXNQAJoR+/+Q9huCsRj7ql yX9vUlzjqGqMLIZCCEx7hYb5QJt5p4dq6HR2Xn8PIqTHZ4Z1TEIXKiEKXJpnvdiY4ng9 Ihkb8qWtkELAenTPWU1uAXIcsvBCSQRE8pkzxXsilWZLTeVjTVkc6kLm5AwkWdk90FkB ugZCtpCBIdMSfZ2tAfdzbVOvL6dfZorqGG0EvTAW5tr/f/b8I11OwSXuwhpDtVCU4HqN QstcuFZR4FzCWqsRyJLiJODHKLKWUG2805OZfKQwCybu8TPWX26pzxiupB0CrRnlOjD5 hZ6w==
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=4QIa64Xl/JCxoh2UyUnCoycWTrnAkNFG71sbtovAwDE=; b=LJBRgtuadt9lbyKV+Hv65f/pz1lyxt+UJNok0tbJpJuL7IVTwbnjfTK0PhFMQgQLmV z0U1yP6aRd18Dl5EhNffqi8TThQPr2ST+RIhe1HhYXtxTtcg5/+plH6kwywaLLR8i9Kd 2CkcZmNHlXaOOX4M2etTnDC/OBw+QDbeXw9ShwOd3ioYZ7ryFJY5tvEnjrHr4mJEGJiM 0FaU+0W6LJbRIbK6x1Wh2k7UbfteCuTn0IfCWy91Teh9TXS4gwlXT8I3odcsUn/rVR6E M5qLqHf5/KjN8OhZQnVBjmyy0LQAzDbKQ+4cX67Rh8Po6yxgFENnk5c2Zlj2huwaVg3k pHaQ==
X-Gm-Message-State: AMCzsaX7UkQwRgaXo3HltQ1zb5YWdICUxbcMOKvZkZwspP/9cRGdaJUD Hpy5H8HXJivPzhg4QbEc8lPwIjP3pYBscpIntcptLA==
X-Google-Smtp-Source: ABhQp+ThY3RGXGN6wDTz5CTMq2GBvGbfNp2td7Rmlfr2AMyOSsylspfu3eDTzf+hYSWOsq8Om/neXPxbWBa14ySuhvM=
X-Received: by 10.55.148.70 with SMTP id w67mr3623470qkd.102.1508348086410; Wed, 18 Oct 2017 10:34:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Wed, 18 Oct 2017 10:34:45 -0700 (PDT)
In-Reply-To: <25B4902B1192E84696414485F57268541351464E@sjceml521-mbs.china.huawei.com>
References: <CALx6S34veBEvreg7SFVu=YJ9rRmNuk=0GHEtjVKGkTsByD7Y7w@mail.gmail.com> <25B4902B1192E84696414485F57268541351464E@sjceml521-mbs.china.huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 18 Oct 2017 10:34:45 -0700
Message-ID: <CALx6S37B8U3pL-CiTSpoESkM5k9TO3ahvGOu5LZQ6Y6AKpiAeQ@mail.gmail.com>
To: Uma Chunduri <uma.chunduri@huawei.com>
Cc: "ideas@ietf.org" <ideas@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/EUCNDAunQN_BKyfPSAgNmCfNBDo>
Subject: Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Oct 2017 17:34:49 -0000

On Wed, Oct 18, 2017 at 9:44 AM, Uma Chunduri <uma.chunduri@huawei.com>; wrote:
> Tom,
>
>
>         >Google Cloud for instance operates a huge multi-tenant network and I suspect they use LOAS to authenticate access to
>
> Context here is not where to deploy this but how to make a mapping system where it's applicable for multiple environments (enterprise, DC,  etc..)   with flexibility to work with existing ID/LOC protocols.
>
>         >In my design for ILA, I'm fond of using TLS for communications which provides both security (encryption) and verifiable identity in certificates. The X.509 identity can be used to against ACLs to control read and write access.
>
> Couple of things:
> 1. ILA is one of the data planes and lot of issues you raised in this thread applicable there too, IMO. What we thoroughly looked into were the existing IETF approved ID/LOC technologies (HIP & LISP), where there are multiple  immediate use cases

The deployment of HIP and LISP pale in comparison to the deployed uses
of VXLAN, nvgre, ILA, and a few hacked up internal protocols that do
identifier-locator. If I wanted to build something practical and that
scales I'd be more inclined to look at what is being used and what
lessons can be learned.

> 2. I would note -  DC/VM with multi-tenant mobility is only one of the use cases for IDEAS - and AFAIK you contributed a lot from ILA pov.

To be clear, ILA is suitable for both the DC _and_ public wireless
network use cases. We are designing and implementing both for both use
cases.

> 3. On using TLS/X.509  - we are jumping way ahead of ourselves - we can come back on this if we have *a wg*

Sure, but my point is that people may have already have a solution for
this part of the problem. To say that mapping systems today have no
solution to security doesn't seem not correct. As we learned well in
nvo3, the industry doesn't wait for IETF!

> 4. The above also depends on the type of the device in question too (for low power devices #3 may not be applicable).

IMO its unlikely that low powered or end devices would directly access
the mapping system. In both the design for DC and  (likely design) for
wireless mobile networks the infrastructure uses identifier-locator to
implement an overlay network. In the DC case this is consistent with
the nvo3 architecture (i.e. identifier-locator is transparent to VMs).
In the same manner, the mobility in the mobile networks can be
implemented in the infrastructure. This is where some reference
network architecture on what actual and practical deployment would
look like helps.