Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
Luca Muscariello <muscariello@ieee.org> Thu, 16 April 2020 07:29 UTC
Return-Path: <muscariello@ieee.org>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362A03A10D2 for <icnrg@ietfa.amsl.com>; Thu, 16 Apr 2020 00:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ieee.org
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 mRBctVwM7neF for <icnrg@ietfa.amsl.com>; Thu, 16 Apr 2020 00:29:28 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 B81283A10D1 for <icnrg@irtf.org>; Thu, 16 Apr 2020 00:29:27 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id h9so3565177wrc.8 for <icnrg@irtf.org>; Thu, 16 Apr 2020 00:29:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FrHoYVm7jH2ELwn2mNF8Y+FkMdzYqhEuv//l529Gt2I=; b=YOUWX1qierxgQ1gjOc12Mip4gADhdjCcWR7wQ0xo0rdrNhw0yOEBhKOZZVH25bWdrx KCCTq6wGRzLvwP5eRKbZPk+kKPJ8jP/DWM48Lqz8676iQFI/3w6sW54HKJwlAmJCVanm W08PEQDUQKGauXiUQY8gj+I4ttAaCREySYcVs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FrHoYVm7jH2ELwn2mNF8Y+FkMdzYqhEuv//l529Gt2I=; b=NlsxwmzrNTLkbKxFbw1ik+eZ5kwZM7eKEh4A6qWCiB+U4vEYLvAc583YTUcq9a00jC oTRCnzwGyCfaiSsvjvCteISRli0N92yrnJN9kIxmFL5m9IgSvc6mz3yUW5qN8Qnfd/YD igSYSbQJJ8LPEFwvHgxZpA9h2Ax86JKEiehO2OH7h+Rm8Bv0LPQXP5XhMlKaiTkg3Jw9 F74NubdrLElEQX3g1etVtNVRYxr1tp7sCHCELf3xOPb0bp3DkZMgsLipTW08naf4QvSm S2wsxwIcfqIrJmzoYxaxig27Pb1CuNYa1tQj5itDEUemNKK5MWB3z3hBbwryywpd91vH 1D0g==
X-Gm-Message-State: AGi0PuZSX7O+diyOTsGQi1ScbtM9cm2J0Lo0DTDKQBnoQ3TMplpdcpYJ CrjBFvOHT2qrrrNSIdSFYKZZY8TbJXDEsawULiwa3Q==
X-Google-Smtp-Source: APiQypLVxhMgjiYEVYIdezOlB/aoQ3gFvtsKP+2X/zdI5/c4Uyaov3fBgXJTJxnuAlkErOXIo/EkMTwgZQmUy+flqRA=
X-Received: by 2002:adf:e604:: with SMTP id p4mr20343938wrm.257.1587022165595; Thu, 16 Apr 2020 00:29:25 -0700 (PDT)
MIME-Version: 1.0
References: <93E56749-73D1-4E34-81BB-B7F66DA30F7A@orandom.net> <CAH8sseRzHtrKpw5S+DKOUuysiZ7LaFM=ew5sgrwQjvSqnKL00A@mail.gmail.com> <C8616085-6FE7-4C4F-8048-4CD40C423261@cablelabs.com>
In-Reply-To: <C8616085-6FE7-4C4F-8048-4CD40C423261@cablelabs.com>
From: Luca Muscariello <muscariello@ieee.org>
Date: Thu, 16 Apr 2020 09:29:14 +0200
Message-ID: <CAH8sseQ5Zn1T8DH2YzZaRqc-3cVf3M47aveWOPvjg1Rov6Sq2A@mail.gmail.com>
To: Greg White <g.white@cablelabs.com>
Cc: "David R. Oran" <daveoran@orandom.net>, ICNRG <icnrg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000006e7f0405a363648b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/4RNon8qzvfbbrBlZW3svNdaIhzU>
Subject: Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Apr 2020 07:29:33 -0000
Hi Greg, comments in line. On Thu, Apr 16, 2020 at 12:50 AM Greg White <g.white@cablelabs.com> wrote: > Hi Luca, > > > > Thanks for the review and for the questions and comments. > > > > On your first question, the IPoC naming convention and CCNx routing > mechanism ensure that the IPoC client remains in communication with the > IPoC gateway that provides reachability to the client’s assigned IP address > by other devices on the IP network. If the IPoC gateway becomes > unreachable due to a network attachment change (e.g. if the client leaves > the current IPoC network and joins another), it would need to establish > communication with a new IPoC gateway in the new network, using the > mechanism described in Section 8. It would thus be in a different subnet, > with a different IP address. It would also be possible for a client to > periodically run the Section 8 mechanism in order to determine whether it > was connected to the topologically nearest gateway. If it finds a nearer > gateway (and thus gets a new IP address) it could begin transitioning new > IP connections to the new IP address, while allowing existing connections > that used the previous IP address to complete. > > > The IPoC GW is very similar to what we do in enterprise networks with LISP to optimize Wi-Fi mobility management and more. Even if this happens from the AP to the switch it does not change much. Similarly from the eNB to the SGW using GTP tunneling. IPoC does not provide any advantage w.r.t. LISP or GTP which both rely on IP only. I'd say that in this case I only see the disadvantages of IPoC as it makes the assumption that CCNx is the backhaul. The fact that IPoC binds IP addresses to the CCNx namespace destroys all good features of CCNx which is used with hands and legs tied. In summary: No many-to-many communications, weak security properties, inferior mobility wrt the state of the art and also no incentives to move from the current solutions to this one. > Correct me if I am misunderstanding, but questions 2 & 4 seem to be > essentially the same question, i.e.: is it expected that Interests and > Content Objects are all signed, and if so, what are the performance > implications? > > As you noted, section 14 mentions signing of Interests and Content > Objects, and implies that it is optional. It is in fact optional. As > section 14 discusses, the protocol is intended for use within a managed, > CCNx-based, mobile core network where endpoint authentication and > authorization is managed via existing means. Interest and CO signing would > certainly add computational complexity perhaps on the order of the > complexity associated with encrypted tunnels in IP, so the benefits of > doing so would need to be weighed against the scalability impacts. I’ll > add an explicit mention in Section 4 that signing is optional. > Q2 and Q4 are distinct questions related to the usage of signed interest systematically, i.e. 100% of the interests. Q2: This is about the fact that interests are signed because they carry payload. So local flow balance is gone and this has performance implications in terms of congestion management, loss recovery AND mobility. All gone. This is what Q2 is about. Sorry for being so compact, but I'm assuming some terminology is well understood in this list. Also what are the security implications of signing every Interest? It looks very similar to an IPSEC GW with all the certificate business. Q4: This is about the computation cost. In the hICN project we're spending a lot of time to bring performance of a single transfer beyond 10Gbps. All forms of optimizations are required: manifests, hash computation offloading, software/hardware tricks and many more. This is not a negligible point. In practice one would be tempted to disable signatures. This is worse. The security implication of using non authenticated end-points are very well known even in a managed network. Managed networks carry customer' traffic and security is MUST, not an option. Current solid deployments of LISP in enterprise networks make use of authentication, GTP tunnels too in the EPC backhaul. Tunnel confidentiality may be an option but authentication is not. It is an option in EPC for 4G but for 5G UPC confidentiality is mandatory. > > > On question 3, there are two implementations that have been made > available. One was built on the PARC Metis libraries, experimental results > using this implementation were shared at the November 13, 2016 ICNRG > Interim Meeting, and it was mentioned as well at the March 20, 2018 and > July 21, 2018 ICNRG meeting where IPoC was presented. While this > implementation is not currently being maintained, the code is available. > The second implementation was built in ndnSim, and is available on GitHub. > Experimental results and a link to the repo can be found in the paper > listed in the Informative References of the IPoC draft. That paper > discusses the benefits compared to the existing GTP tunneling mechanisms > used in LTE-EPC. I’m not sure why you are questioning whether CCNx > consumer mobility still holds. This protocol makes use of CCNx stateful > forwarding directly, and is designed precisely to make use of that feature. > I read the paper that describes and evaluates IPoC and compares to GTP. That's the whole point. The conclusion of the paper is that IPoC is no worse than GTP. Which is my whole point. What is the reason to disrupt a technology (GTP) and replace it with something that is no worse? As soon as the IPoC namespace is tied to the IP addresses of the end-points of the tunnel, IPoC becomes isomorphic to GTP or any tunneling protocol making use of locators. So it is no worse than any of those protocols. This does not look like a compelling reason to change the transport infrastructure. Worse, it looks like an argument NOT to move towards ICN. I am surprised that this draft has moved to last call with this implicit message. I did not pay attention to all drafts moving forward in this RG because there are so many of them being pushed by the chairs, but I hope we pay more attention to "shoot-yourself-in-the-foot" messages. Best Luca > > > > > Best Regards, > > Greg > > > > > > > > *From: *icnrg <icnrg-bounces@irtf.org> on behalf of Luca Muscariello < > muscariello@ieee.org> > *Date: *Monday, March 23, 2020 at 2:01 AM > *To: *"Dave Oran (oran)" <daveoran@orandom.net> > *Cc: *ICNRG <icnrg@irtf.org> > *Subject: *Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc > > > > Hi > > > > I went through the draft and I have a few comments and some questions. > > > > 1 how does this system work when IP addresses at local interfaces change? > > My question is about both the underlying mechanics and also the > performance > > of the system in such cases. > > 2 What are the implications of using signed Interests in this way? I mean > > 100% of the Interests are signed in the tunneling scheme. My question is > both > > in terms of security and performance. And with performance I mean both > > mobility and local flow balance. > > 3 Is there any reality check and running code of this scheme? > > Every Internet draft comes with a security section but not a cost section > > however it is unclear in this specific case, what are the benefits of > this > > scheme and if one would need it compared to existing tunneling > technologies. > > The alleged benefits of CCNx in terms of mobility are never spelled out > in the > > draft but it is unclear if any mobility benefit still holds using this > technique. > > 4 The cost of signing every packet is significant and would probably kill > > the performance of the tunnel. In the last section the authors seem to > > consider interest/data signatures as optional. Can this be clarified and > spelled > > out clearly? Is the intent to use the tunnel w/o signatures? > > > > Thank > > Best > > Luca > > > > > > > > On Fri, Mar 20, 2020 at 2:51 PM David R. Oran <daveoran@orandom.net> > wrote: > > Hello ICNRG, > > This is a last call for comments on draft-irtf-icnrg-IPOC (Internet > Protocol Tunneling over Content Centric Mobile Networks). > > We want to publish this as an Experimental RFC. Please read it and let > us know if you think there are issues. The last call ends on April 15, > i.e., 3 weeks from today. > > https://datatracker.ietf.org/doc/draft-irtf-icnrg-ipoc/ > > Abstract > > This document describes a protocol that enables tunneling of > Internet > Protocol traffic over a Content Centric Network (CCNx) or a Named > Data Network (NDN). The target use case for such a protocol is to > provide an IP mobility plane for mobile networks that might > otherwise > use IP-over-IP tunneling, such as the GPRS Tunneling Protocol (GTP) > used by the Evolved Packet Core in LTE networks (LTE-EPC). By > leveraging the elegant, built-in support for mobility provided by > CCNx or NDN, this protocol achieves performance on par with LTE-EPC, > equivalent efficiency, and substantially lower implementation and > protocol complexity [Shannigrahi]. Furthermore, the use of CCNx/NDN > for this purpose paves the way for the deployment of ICN native > applications on the mobile network. > > Best regards, > ICNRG chairs > > > DaveO > > _______________________________________________ > icnrg mailing list > icnrg@irtf.org > https://www.irtf.org/mailman/listinfo/icnrg > >
- [icnrg] Last Call: draft-irtf-icnrg-ipoc David R. Oran
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Luca Muscariello
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Greg White
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Luca Muscariello
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Greg White
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Luca Muscariello
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Dirk Kutscher
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Luca Muscariello
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Dirk Kutscher
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Luca Muscariello
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Dirk Kutscher
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Luca Muscariello
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc David R. Oran
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Greg White
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Luca Muscariello
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Susmit
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Luca Muscariello
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Susmit
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Luca Muscariello
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Greg White
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Greg White
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc David R. Oran
- Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc Greg White