Return-Path: 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 A3E2C3A0B66 for ; Thu, 14 May 2020 10:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 SDEghUtKsqTM for ; Thu, 14 May 2020 10:12:05 -0700 (PDT) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) (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 A27F53A0BA3 for ; Thu, 14 May 2020 10:12:05 -0700 (PDT) Received: by mail-pf1-f171.google.com with SMTP id x2so1579232pfx.7 for ; Thu, 14 May 2020 10:12:05 -0700 (PDT) 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=rt3yONxsp1NqvZWR/oGbPXddV7OVq9xHMWNgvWIJa+I=; b=XiO0y/qipDYD0nNWhBPYcOMxoaKN/PrdyzVXQA1Xfng6tLLYoNn3Q90Aew1kn80flF 7Tbl1xWbsMoUcqHxCtxE4954TOnikt5A1Al0XyARoFacN++H3sgnLrA/fxh7pGhP1I6X v/Ydvi/77MFzTaPsXpJ6BwsnoGhMXkF3rKuEgkhv1OgEAUSGS6q/FJmaY3n5z1aY0ATu LiPkLVtmyLIr8gslzxkDj8O++PJQPAVGHSbbt9d4SkIpFjYXU5LQ6oE7rHAS54vKPRNZ cJ9qHPusGqELSN0Eb8hratLNXzyTQXdQz4rem+nD+vBIzQhg7onIFkK+Z1pQQmjDNTzA xbtQ== X-Gm-Message-State: AOAM533b7gzs5iUfW+bIjO/jpc8YqaaRUlHqhrqDaqWCzSU/wcfv0OU4 p8yiXVx5lY6p7/zIzvwfvHRDR64Rey2D0PfTmNk= X-Google-Smtp-Source: ABdhPJzpaCWF3nYrhLA4Yan/xcOIBtjCZvwwE/qwK28XuFeKCtC93yUj3F65kyQ/u5H4QnoHOnfpamfGkvkMLDcLCDk= X-Received: by 2002:a62:1cc9:: with SMTP id c192mr5050017pfc.197.1589476324691; Thu, 14 May 2020 10:12:04 -0700 (PDT) MIME-Version: 1.0 References: <93E56749-73D1-4E34-81BB-B7F66DA30F7A@orandom.net> <0A3AFADD-B47E-45BA-A08A-94971C861C34@cablelabs.com> <65AE7F1B-D307-478B-9B86-E36E863C0918@dkutscher.net> <28EA075D-75B4-4046-88C4-1CA28458EDE3@dkutscher.net> <395162EA-39AE-41B3-8B2B-A28008266BD5@orandom.net> <72624FB2-D813-42F4-B559-58E0F3AE085B@cablelabs.com> In-Reply-To: From: Susmit Date: Thu, 14 May 2020 12:11:51 -0500 Message-ID: To: Luca Muscariello Cc: Greg White , icnrg , "Oran, Dave" , Dirk Kutscher Content-Type: multipart/alternative; boundary="000000000000b653a905a59ecb00" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 17:24:09 -0000 --000000000000b653a905a59ecb00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Luca, Would you mind expanding on why you think it will not work with NDN? BTW, here is the actual NDN code that implemented IPoC - https://github.com/named-data/IPoC. Susmit On Tue, May 12, 2020 at 5:21 PM Luca Muscariello wrote: > +list > > + one more comment > I would let you check that IPoC can also work with NDN. > The draft mentions NDN too but I'm not sure it would work. > At first glance, it cannot work with NDN. But maybe things have changed. > > Luca > > > On Wed, May 13, 2020 at 12:01 AM Luca Muscariello > wrote: > >> Hi Greg, >> >> Thanks for the clarifications. >> More comments in line. >> >> >> On Sat, May 9, 2020 at 7:36 PM Greg White wrote: >> >>> Hi Luca, >>> >>> >>> >>> Sorry for the delay in responding. >>> >>> >>> >>> The IPoC draft has been presented at four ICNRG meetings (the first >>> being November 2016) and the draft has been available since December 20= 17. >>> Several ICNRG participants have provided comments at the mic or on the >>> mailing list in the intervening 3.5 years, and in November the chairs a= sked >>> the authors and the RG if the draft was ready for last call. The view = of >>> the authors and the RG participants was that a couple of changes were >>> needed, but it was otherwise ready. Anyway, as Dave indicated, the pur= pose >>> of Last Call is to force final reviews, and I agree with him that it >>> succeeded. >>> >>> >>> >>> On to your comments. >>> >>> >>> >>> Thanks for pointing out the language in the abstract.. I agree it does >>> sound like marketing, and will revise it. >>> >>> >>> >>> Some of your questions echo questions that others in the RG have asked >>> in the past, and have previously been answered verbally. You are not th= e >>> first to read the draft with the mindset that it must be trying to prov= ide >>> ICN features to IP applications, and thus failing to accomplish the goa= l. >>> While I hope that Dirk and I have made it clear what the point of IPoC = is, >>> let me be doubly sure here (and we can look for ways to make the text >>> clearer on this point as well). >>> >>> >>> >>> The primary benefit of IPoC is for the network operator, not for the >>> application. Mobile networks support thousands of 3rd party >>> applications that are built for the IP world. Updating these applicati= ons >>> to use NDN/CCNx (or replacing them) will not happen quickly. >>> >> >> The introduction of the document is misleading because it puts too much >> emphasis >> on mobility. The document is not about mobility but on a >> tunneling protocol. >> Assuming total absence of the IP network creates some issues to me in >> case EPC is considered. >> >> For instance the following I-D in this RG >> https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g >> >> makes use of ICN for the user plane only along with IP. >> >> If you remove IP entirely then EPC operations vanish. >> Several interfaces do not use GTP. Some components may be physically >> located >> out of the backhaul. EPC w/o IP cannot be obtained by just replacing GTP= . >> >> This document is in a logical loop to me: >> >> 0) There is no IP in the hypothetical EPC. But: >> 1) IP in the UE >> 2) IP in the eNB >> 3) No IP in S1-U (also in S1-C?), S1-MME? S5/S8? SGi? etc. >> 4) IP in the IPoC GW >> 5) IP in the Cloud (or anywhere the other application head end is >> running). >> 6) CCNx replaces ONLY GTP, >> 7) Mobility management is absent in CCNx so we must assume >> the rest of the EPC components are still there (MME, HSS, SGW, PGW, >> PCF...) >> 8) Hence, there must be IP in this hypothetical EPC. >> >> If the document did not mention anything about LTE/EPC or GTP >> and just focused on a bare-bones description of the IP tunnel over CCNx >> it would make more sense to me. >> >> I also realize that by rewriting the abstract and the intro only >> you would achieve that easily, as the rest of the document, from >> section 2 until the end of the document, IS a bare-bones description >> of the tunneling protocol. >> >> >> >> >>> >>> >>> If an MNO wishes to support native CCNx applications, they have multipl= e >>> options. One option is to deploy native CCNx forwarding in the mobile = core >>> (without IP as an underlay). This would allow them to take advantage of= the >>> CCNx mobility features instead of using a legacy mobility plane (e.g. >>> GTP/IP). But what about all of the existing 3rd party IP applications? >>> Does the MNO need to continue to maintain the GTP/IP mobility plane >>> indefinitely to support them? IPoC provides a mechanism that an MNO ca= n >>> use to transition off of GTP/IP as a backhaul with **zero** changes to >>> legacy IP applications (and hence zero work for the application develop= er). >>> Since there are zero changes to the legacy applications, their >>> communication semantics are of course not changed. The benefit to the >>> application is that it can continue to work as it always has. >>> >>> >>> >>> You are correct that IPoC is fairly isomorphic with GTP. In the paper, >>> we argue that it has some (relatively minor) benefits compared to GTP >>> tunnel management, but otherwise it is comparable. >>> >>> >>> >>> To be absolutely clear, IPoC presumes that an MNO has an a priori desir= e >>> to deploy CCNx, and it offers them a transition strategy that decreases= the >>> complexity in doing so. IPoC is not intended to be the end goal or the >>> motivating factor in itself. But, many times, removing hurdles is just= as >>> important as providing motivations. >>> >>> >>> >>> Your points about performance and computation cost are fair ones. >>> Neither implementation has been optimized for computational performance= , so >>> that remains an area for experimentation and assessment. This is an >>> experimental protocol after all. >>> >> >> The cost in terms of performance makes IPoC (as a tunnelling protocol) >> way more complex >> and expensive than any other secure tunnel used today. >> Considering that IPoC is just a tunneling protocol, that IMO cannot use >> unauthenticated endpoints, >> you should consider efficient alternatives to full signatures, e.g. by >> using HMAC. >> Provenance in IPoC is not even a requirement as the namespace need not >> authentication of provenance, >> as the end-points are identified by an IP address which is a locator. >> In fact if the IP addresses change the tunnel is reset. >> >> >> >> >>> >>> >>> Let me know if you see an opportunity to make some of these aspects mor= e >>> clear in the draft. As mentioned I will revise the abstract per your >>> suggestion, and will do another review with an eye toward eliminating s= ome >>> of the confusing aspects. >>> >> >> Hope comments above can help achieving that. >> Best >> Luca >> >> >> >> >>> >>> >>> Best Regards, >>> >>> Greg >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *From: *"Dave Oran (oran)" >>> *Date: *Wednesday, April 22, 2020 at 8:55 AM >>> *To: *Luca Muscariello >>> *Cc: *Dirk Kutscher , Greg White >>> , ICNRG >>> *Subject: *Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc >>> >>> >>> >>> Not to derail the discussion, but one clarification on process. Last >>> Call is both for technical review and to assess consensus or the lack >>> thereof. As chair I have no problem with Last-calling documents in orde= r to >>> achieve both goals. Sometimes last call works as a forcing function to >>> produce good technical review and foster discussion that did not happen >>> while a document languished as an RG work item with little or no feedba= ck. >>> >>> So, I=E2=80=99d make the observation that I think the process is workin= g in this >>> case. We have a solid, comprehensive technical review and a discussion = with >>> the authors on that. It would be helpful if more ICNRG participants wou= ld >>> also review IPOC and weigh in on these and possibly other issues that g= et >>> raised. >>> >>> Lastly, the IRTF doesn=E2=80=99t work by consensus formally, so let=E2= =80=99s focus on >>> the technical questions. The document won=E2=80=99t have passed last ca= ll until we >>> get better understanding of whether the technical questions are of a na= ture >>> that would argue against publication. >>> >>> DaveO. >>> >>> >>> >>> On 21 Apr 2020, at 10:41, Luca Muscariello wrote: >>> >>> >>> >>> >>> >>> On Tue, Apr 21, 2020 at 4:28 PM Dirk Kutscher >>> wrote: >>> >>> Hi Luca, >>> >>> > I fail to understand the definition of review in this list. >>> > I made technical comments and got not a single technical answer. >>> > >>> > What's the point of having open reviews? >>> > We can shutdown the discussion right away if this is what it is. >>> > >>> > I'm not interested in fake reviews to let documents go through w/o >>> > an open technical debate. >>> >>> Not sure, I follow. >>> >>> Nobody has discouraged the technical review. I am hoping that the >>> discussion continues. I was trying to explain the nature of this >>> document in my view: documenting an experimental approach (which may no= t >>> be the most desirable approach for all scenarios). I did not object to >>> your other technical comments. >>> >>> >>> >>> So let us focus on technical details. >>> >>> So far I got none. >>> >>> >>> >>> Let's avoid getting text published that may generate mockery from >>> >>> people working on the 3GPP EPC. >>> >>> >>> >>> >>> >>> >>> It's great to get the technical review. Unfortunately, in many groups, >>> not just ICNRG, we don't have enough of it before we last-call things. >>> >>> >>> >>> do not last call something that has no consensus yet. >>> >>> >>> >>> >>> >>> >>> > this is the 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. >>> > >>> > For me the above text is wrong with a marketing tone. >>> >>> >>> Yes, I get it. This should be discussed. >>> >>> >>> >>> The document should be cleaned up from this kind of text. >>> >>> Who's going to buy into this? >>> >>> >>> >>> >>> >>> >>> Cheers, >>> Dirk >>> >>> >>> >>> > >>> > >>> > On Tue, Apr 21, 2020 at 3:26 PM Dirk Kutscher >>> > wrote: >>> > >>> >> Hi Luca, >>> >> >>> >>> The IPoC paper compares to GTP and concludes that it is no worse. >>> >>> It makes a lot of sense to compare to GTP and I am not surprised >>> >>> the authors made that comparison in the first place. >>> >> >>> >> Sure, it's helpful to explain how it compares to the GTP approach. >>> >> >>> >>> If a transition mechanism should be used it has to bring advantages >>> >>> to >>> >>> create incentives to switch to another solution. >>> >>> >>> >>> if, like you say Dirk, it is just about enabling applications to us= e >>> >>> ICN, the mechanism has to let the application use ICN. Otherwise, >>> >>> what's >>> >>> for? >>> >>> >>> >>> For instance: >>> >>> >>> >>> >>> >>> NDNizing Existing Applications: Research Issues and Experiences >>> >> >>> >> There are different ways to support applications, from adapting them >>> >> to >>> >> ICN (perhaps ideal) or just running them unmodified (this is what >>> >> IPOC >>> >> could enable). >>> >> >>> >>> The above work shows that to get benefits you have to work a lot >>> >>> more on the namespace, otherwise if you just tie locators to names, >>> >>> like in IPoC, you get something that is isomorphic to GTP. >>> >> >>> >> Clearly, more invasive changes would leverage ICN better. IPOC is >>> >> just >>> >> for those that you cannot change, i.e., it's transparent to the >>> >> applications. >>> >> >>> >>> In IPoC there are no rewards and no incentives. But it takes >>> >>> implicitly the risk of having CCNx in the stack of the client >>> >>> and in the access/backhaul network. Who's gonna take that >>> >>> risk and why? >>> >> >>> >> I think we all agree that there are better ways. Optimistically >>> >> speaking, this would only be used for a short period of time -- unti= l >>> >> all relevant apps have been ICNified. :-) >>> >> >>> >> As a general comment: in a Research Group, we don't have to converge >>> >> on >>> >> one (possibly optimal) protocol. Instead, we can publish competing >>> >> experimental specifications -- enabling more experiments which could >>> >> inform later standards work (for example). >>> >> >>> >> Cheers, >>> >> Dirk >>> >> >>> >> >>> >>> >>> >>> >>> >>>> >>> >>>> In that sense, it would not have to show improvements over existin= g >>> >>>> tunneling tech at all -- it just has to be good enough (and work >>> >>>> correctly, of course). >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>>> >>> >>>> It is clearly experimental and needs more testing (which may >>> >>>> exhibit >>> >>>> problems) -- that's why it's not proposed as a standard. >>> >>>> >>> >>> >>> >>> It cannot be proposed as standard from the IRTF. >>> >>> >>> >>> >>> >>> >>> >>>> >>> >>>> Cheers, >>> >>>> Dirk >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> On Tue, Apr 21, 2020 at 6:05 AM Greg White >>> >>>>> wrote: >>> >>>>> >>> >>>>>> Luca, >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> Clearly you have a vested interest in hICN. But, just as there >>> >>>>>> are >>> >>>>>> multiple technologies to enable the transition from IPv4 to IPv6= , >>> >>>>>> there is >>> >>>>>> value in having multiple transition technologies for ICN. IPoC >>> >>>>>> fills >>> >>>>>> a >>> >>>>>> different niche from hICN, and it seems you=E2=80=99ve failed to >>> >>>>>> understand >>> >>>>>> that. >>> >>>>>> Whereas hICN is a way to run limited ICN applications over a >>> >>>>>> modified >>> >>>>>> IPv6 >>> >>>>>> network, IPoC is a way to run **unmodified** IPv4/IPv6 >>> >>>>>> applications >>> >>>>>> over >>> >>>>>> a pure CCNx network. Both approaches have their own >>> >>>>>> applicability, >>> >>>>>> and >>> >>>>>> their own tradeoffs. In the context of a mobile network, hICN >>> >>>>>> does >>> >>>>>> not >>> >>>>>> provide a mobility solution for IP traffic, and thus requires th= e >>> >>>>>> operator >>> >>>>>> to deploy and maintain two parallel forwarding planes. On the >>> >>>>>> other >>> >>>>>> hand, >>> >>>>>> IPoC allows the operator to eliminate IP routing and legacy >>> >>>>>> mobility >>> >>>>>> mechanisms from the mobile core and support all services over >>> >>>>>> CCNx. >>> >>>>>> Yes, >>> >>>>>> IPoC assumes a bigger first step (deployment of CCNx), but it >>> >>>>>> makes >>> >>>>>> taking >>> >>>>>> that step easier, and once taken, native CCNx applications can b= e >>> >>>>>> deployed >>> >>>>>> getting the advantages of the full CCNx architecture. >>> >>>>>> Additionally, >>> >>>>>> other >>> >>>>>> transition technologies (like HTTP->CCN proxies) can be deployed >>> >>>>>> to >>> >>>>>> enable >>> >>>>>> certain applications to get more of the CCNx-native benefits. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> -Greg >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> *From: *Luca Muscariello >>> >>>>>> *Date: *Thursday, April 16, 2020 at 1:29 AM >>> >>>>>> *To: *Greg White >>> >>>>>> *Cc: *"Dave Oran (oran)" , ICNRG >>> >>>>>> >>> >>>>>> *Subject: *Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> Hi Greg, >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> comments in line. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> On Thu, Apr 16, 2020 at 12:50 AM Greg White >>> >>>>>> >>> >>>>>> 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=E2=80=99s >>> >>>>>> 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 find= s >>> >>>>>> 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 incentive= s >>> >>>>>> 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 an= d >>> >>>>>> 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=E2=80=99ll >>> >>>>>> 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 the= y >>> >>>>>> carry >>> >>>>>> payload. So local flow balance is gone and this has performance >>> >>>>>> implications in terms of congestion management, loss recovery AN= D >>> >>>>>> 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'r= e >>> >>>>>> 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 us= e >>> >>>>>> 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 thi= s >>> >>>>>> 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=E2=80=99m not sure why you are questioning w= hether >>> >>>>>> 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 loo= k >>> >>>>>> 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 on behalf of Luca >>> >>>>>> Muscariello >>> >>>>>> < >>> >>>>>> muscariello@ieee.org> >>> >>>>>> *Date: *Monday, March 23, 2020 at 2:01 AM >>> >>>>>> *To: *"Dave Oran (oran)" >>> >>>>>> *Cc: *ICNRG >>> >>>>>> *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 interface= s >>> >>>>>> change? >>> >>>>>> >>> >>>>>> My question is about both the underlying mechanics and also th= e >>> >>>>>> 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 >>> >>>>>> >>> >>>>>> 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 Protoco= l >>> >>>>>> (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 implementatio= n >>> >>>>>> 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 mailing list >>> >>>>> icnrg@irtf.org >>> >>>>> https://www.irtf.org/mailman/listinfo/icnrg >>> >>> >>>> >>> >> >>> >> >>> >>> _______________________________________________ >>> >>> icnrg mailing list >>> >>> icnrg@irtf..org >>> >>> https://www.irtf.org/mailman/listinfo/icnrg >>> >>> >> >>> >>> >>> >>> DaveO >>> >> _______________________________________________ > icnrg mailing list > icnrg@irtf.org > > https://nam01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= rtf.org%2Fmailman%2Flistinfo%2Ficnrg&data=3D02%7C01%7Csusmit%40cs.colos= tate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecf= c8b%7C0%7C0%7C637249188662491883&sdata=3DWFBKE1r7FCuA0MJEygETfm0iavfjkz= SVS90pqyP1Wqc%3D&reserved=3D0 > --000000000000b653a905a59ecb00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Luca,

Would you mind= expanding on why you think it will not work with NDN?
BTW, here is the= actual NDN code that implemented IPoC - https://github.com/named-data/IPoC.

Susmit

On Tue, May 12, 2020 at 5:21 PM Luca Muscariello &l= t;muscariello@ieee.org> wrot= e:
+list=C2=A0

+ one mo= re comment=C2=A0
I would let you = check that IPoC can also work with NDN.
The draft mentions NDN too but I'm not sure it would work.
=
At first=C2=A0glance, it cannot work w= ith NDN. But maybe things have=C2=A0changed.

Luca

On Wed, May 13, 2020 at 12:01 AM Luca Muscariello <muscariello@ieee.org> wrote:<= br>
Hi Greg,

=
Thanks for the clarifications.
More comments in line.
=C2=A0

On Sat, May 9, 2020 at 7:36 PM Greg = White <g.whit= e@cablelabs.com> wrote:

Hi Luca,

=C2=A0

Sorry for the delay in responding.

=C2=A0

The IPoC draft has been presented at four ICNRG meet= ings (the first being November 2016) and the draft has been available since= December 2017.=C2=A0 Several ICNRG participants have provided comments at = the mic or on the mailing list in the intervening 3.5 years, and in November the chairs asked the authors and the RG if the = draft was ready for last call.=C2=A0 The view of the authors and the RG par= ticipants was that a couple of changes were needed, but it was otherwise re= ady.=C2=A0 Anyway, as Dave indicated, the purpose of Last Call is to force final reviews, and I agree with him that = it succeeded.

=C2=A0

On to your comments.

=C2=A0

Thanks for pointing out the language in the abstract= ..=C2=A0 I agree it does sound like marketing, and will revise it.

=C2=A0

Some of your questions echo questions that others in= the RG have asked in the past, and have previously been answered verbally.= You are not the first to read the draft with the mindset that it must be t= rying to provide ICN features to IP applications, and thus failing to accomplish the goal.=C2=A0 While I hope = that Dirk and I have made it clear what the point of IPoC is, let me be dou= bly sure here (and we can look for ways to make the text clearer on this po= int as well).

=C2=A0

The primary benefit of IPoC is for the network opera= tor, not for the application. Mobile networks support thousands of 3rd= party applications that are built for the IP world.=C2=A0 Updating t= hese applications to use NDN/CCNx (or replacing them) will not happen quickly. =C2=A0

The introduction of the do= cument is misleading because it puts too much emphasis
on mobility. The document is not about mobility but o= n=C2=A0a tunneling=C2=A0protocol.=C2=A0
Assuming total absence of the IP network creates some issues to me i= n case EPC is considered.

For instance the following I-D in this RG
= makes use of ICN for the user plane only along with IP.

If you remove IP entirely then EPC operations vanish.
Sever= al interfaces do not use=C2=A0GTP. Some components may be physically locate= d=C2=A0
out of the backhaul. EPC w/o IP cannot be obtained by jus= t replacing GTP.

=
This document is in a logical loop to = me:

0) There is no IP in the hypothetical=C2=A0EPC. But:
1) IP in the UE
2) IP in the eNB
3) No IP in S1-U (also in S1-C?), S1-MME? S5/S8? SGi? etc.
4) IP in the IPoC GW
5) IP in the Cloud (or anywhere the other application he= ad end is running).
6) CCNx repla= ces ONLY GTP,
7) Mobility managem= ent is absent in CCNx so we must assume
=C2=A0 =C2=A0the rest of the EPC components are still there (MME, HS= S, SGW, PGW, PCF...)
8) Hence, th= ere must be IP in this hypothetical=C2=A0EPC.=C2=A0

If the do= cument did not mention anything about LTE/EPC or GTP
and just focused on a bare-bones description of the IP = tunnel over CCNx
it would make mo= re sense to me.=C2=A0

<= div style=3D"font-family:monospace">I also realize that by rewriting the ab= stract and the intro only
you wou= ld achieve that easily, as the rest of the document, from
section 2 until the end of the document, IS a ba= re-bones description
of the tunne= ling protocol.


=C2=A0

=C2=A0

If an MNO wishes to support native CCNx applications= , they have multiple options.=C2=A0 One option is to deploy native CCNx for= warding in the mobile core (without IP as an underlay). This would allow th= em to take advantage of the CCNx mobility features instead of using a legacy mobility plane (e.g. GTP/IP). But what = about all of the existing 3rd party IP applications?=C2=A0 Does = the MNO need to continue to maintain the GTP/IP mobility plane indefinitely= to support them?=C2=A0 IPoC provides a mechanism that an MNO can use to transition off of GTP/IP as a backhaul with *zer= o* changes to legacy IP applications (and hence zero work for the appli= cation developer). Since there are zero changes to the legacy applications,= their communication semantics are of course not changed. The benefit to the application is that it can conti= nue to work as it always has.

=C2=A0

You are correct that IPoC is fairly isomorphic with = GTP.=C2=A0 In the paper, we argue that it has some (relatively minor) benef= its compared to GTP tunnel management, but otherwise it is comparable.=C2= =A0

=C2=A0

To be absolutely clear, IPoC presumes that an MNO ha= s an a priori desire to deploy CCNx, and it offers them a transition strate= gy that decreases the complexity in doing so. IPoC is not intended to be th= e end goal or the motivating factor in itself.=C2=A0 But, many times, removing hurdles is just as important as= providing motivations.

=C2=A0

Your points about performance and computation cost a= re fair ones.=C2=A0 Neither implementation has been optimized for computati= onal performance, so that remains an area for experimentation and assessmen= t. =C2=A0=C2=A0This is an experimental protocol after all.


The cost in terms of performance makes IPoC (as a tunnellin= g protocol) way more complex
and = expensive than any other secure tunnel used today.=C2=A0
Considering that IPoC is just a tunneling protocol,= that IMO cannot use unauthenticated endpoints,
you should consider efficient alternatives to full signature= s, e.g. by using HMAC.=C2=A0
Prov= enance in IPoC is not even a requirement as the namespace need not authenti= cation of provenance,
as the end-= points are identified by an IP address which is a locator.
In fact if the IP addresses change the tunnel is= reset.


= =C2=A0

=C2=A0

Let me know if you see an opportunity to make some o= f these aspects more clear in the draft.=C2=A0=C2=A0 As mentioned I will re= vise the abstract per your suggestion, and will do another review with an e= ye toward eliminating some of the confusing aspects.


Hope comments above can help achieving that.
Best
Luca


=C2=A0

=C2=A0

Best Regards,

Greg

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: "Dave Oran (oran= )" <daveo= ran@orandom.net>
Date: Wednesday, April 22, 2020 at 8:55 AM
To: Luca Muscariello <muscariello@ieee.org>
Cc: Dirk Kutscher <ietf@dkutscher.net>, Greg White <g.white@CableLabs.co= m>, ICNRG <icnrg@= irtf.org>
Subject: Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc<= /span>

=C2=A0

Not to derail the discussion, but one clarification on process. Last Call = is both for technical review and to assess consensus or the lack thereof. A= s chair I have no problem with Last-calling documents in order to achieve both goals. Sometimes last call works as a f= orcing function to produce good technical review and foster discussion that= did not happen while a document languished as an RG work item with little = or no feedback.

So, I=E2=80=99d make the observation that I think the process is working i= n this case. We have a solid, comprehensive technical review and a discussi= on with the authors on that. It would be helpful if more ICNRG participants would also review IPOC and weigh in on these an= d possibly other issues that get raised.

Lastly, the IRTF doesn=E2=80=99t work by consensus formally, so let=E2=80= =99s focus on the technical questions. The document won=E2=80=99t have pass= ed last call until we get better understanding of whether the technical questions are of a nature that would argue against publication.<= u>

DaveO.

=C2=A0

On 21 Apr 2020, at 10:41, Luca Muscariello wrote:

=C2=A0

=C2=A0

On Tue, Apr 21, 2020 at 4:28 PM= Dirk Kutscher <= ietf@dkutscher.net> wrote:

Hi Luca,

> I fail to understand the definition of review in this list.
> I made technical comments and got not a single technical answer.
>
> What's the point of having open reviews?
> We can shutdown the discussion right away if this is what it is.
>
> I'm not interested in fake reviews to let documents go through w/o=
> an open technical debate.

Not sure, I follow.

Nobody has discouraged the technical review. I am hoping that the
discussion continues. I was trying to explain the nature of this
document in my view: documenting an experimental approach (which may not be the most desirable approach for all scenarios). I did not object to
your other technical comments.

=C2=A0

So let us focus on techn= ical details.

So far I got none.

=C2=A0

Let's avoid getting = text published that may generate mockery from

people working on the 3G= PP EPC.

=C2=A0

=C2=A0


It's great to get the technical review. Unfortunately, in many groups, =
not just ICNRG, we don't have enough of it before we last-call things.<= u>

=C2=A0

do not last call somethi= ng that has no consensus yet.

=C2=A0

=C2=A0


> this is the abstract:
>
> This document describes a protocol that enables tunneling of Internet<= br> >=C2=A0 =C2=A0 Protocol traffic over a Content Centric Network (CCNx) or= a Named
>=C2=A0 =C2=A0 Data Network (NDN).=C2=A0 The target use case for such a = protocol is to
>=C2=A0 =C2=A0 provide an IP mobility plane for mobile networks that mig= ht
> otherwise
>=C2=A0 =C2=A0 use IP-over-IP tunneling, such as the GPRS Tunneling Prot= ocol (GTP)
>=C2=A0 =C2=A0 used by the Evolved Packet Core in LTE networks (LTE-EPC)= ..=C2=A0 By
>=C2=A0 =C2=A0 leveraging the elegant, built-in support for mobility pro= vided by
>=C2=A0 =C2=A0 CCNx or NDN, this protocol achieves performance on par wi= th
> LTE-EPC,
>=C2=A0 =C2=A0 equivalent efficiency, and substantially lower implementa= tion and
>=C2=A0 =C2=A0 protocol complexity [Shannigrahi].=C2=A0 Furthermore, the= use of
> CCNx/NDN
>=C2=A0 =C2=A0 for this purpose paves the way for the deployment of ICN = native
>=C2=A0 =C2=A0 applications on the mobile network.
>
> For me the above text is wrong with a marketing tone.


Yes, I get it. This should be discussed.

=C2=A0

The document should be c= leaned up from this kind of text.

Who's going to buy i= nto this?

=C2=A0

=C2=A0


Cheers,
Dirk



>
>
> On Tue, Apr 21, 2020 at 3:26 PM Dirk Kutscher <ietf@dkutscher.net>
> wrote:
>
>> Hi Luca,
>>
>>> The IPoC paper compares to GTP and concludes that it is no wor= se.
>>> It makes a lot of sense to compare to GTP and I am not surpris= ed
>>> the authors made that comparison in the first place.
>>
>> Sure, it's helpful to explain how it compares to the GTP appro= ach.
>>
>>> If a transition mechanism should be used it has to bring advan= tages
>>> to
>>> create incentives to switch to another solution.
>>>
>>> if, like you say Dirk, it is just about enabling applications = to use
>>> ICN, the mechanism has to let the application use ICN. Otherwi= se,
>>> what's
>>> for?
>>>
>>> For instance:
>>>
>>>
>>> NDNizing Existing Applications: Research Issues and Experience= s
>>
>> There are different ways to support applications, from adapting th= em
>> to
>> ICN (perhaps ideal) or just running them unmodified (this is what =
>> IPOC
>> could enable).
>>
>>> The above work shows that to get benefits you have to work a l= ot
>>> more on the namespace, otherwise if you just tie locators to n= ames,
>>> like in IPoC, you get something that is isomorphic to GTP.
>>
>> Clearly, more invasive changes would leverage ICN better. IPOC is =
>> just
>> for those that you cannot change, i.e., it's transparent to th= e
>> applications.
>>
>>> In IPoC there are no rewards and no incentives. But it takes >>> implicitly the risk of having CCNx in the stack of the client<= br> >>> and in the access/backhaul network. Who's gonna take that<= br> >>> risk and why?
>>
>> I think we all agree that there are better ways. Optimistically >> speaking, this would only be used for a short period of time -- un= til
>> all relevant apps have been ICNified. :-)
>>
>> As a general comment: in a Research Group, we don't have to co= nverge
>> on
>> one (possibly optimal) protocol. Instead, we can publish competing=
>> experimental specifications -- enabling more experiments which cou= ld
>> inform later standards work (for example).
>>
>> Cheers,
>> Dirk
>>
>>
>>>
>>>
>>>>
>>>> In that sense, it would not have to show improvements over= existing
>>>> tunneling tech at all -- it just has to be good enough (an= d work
>>>> correctly, of course).
>>>>
>>>
>>>
>>>
>>>>
>>>> It is clearly experimental and needs more testing (which m= ay
>>>> exhibit
>>>> problems) -- that's why it's not proposed as a sta= ndard.
>>>>
>>>
>>> It cannot be proposed as standard from the IRTF.
>>>
>>>
>>>
>>>>
>>>> Cheers,
>>>> Dirk
>>>>
>>>>
>>>>>
>>>>> On Tue, Apr 21, 2020 at 6:05 AM Greg White <g.white@cablelabs.com>
>>>>> wrote:
>>>>>
>>>>>> Luca,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Clearly you have a vested interest in hICN.=C2=A0 = But, just as there
>>>>>> are
>>>>>> multiple technologies to enable the transition fro= m IPv4 to IPv6,
>>>>>> there is
>>>>>> value in having multiple transition technologies f= or ICN.=C2=A0 IPoC
>>>>>> fills
>>>>>> a
>>>>>> different niche from hICN, and it seems you=E2=80= =99ve failed to
>>>>>> understand
>>>>>> that.
>>>>>> Whereas hICN is a way to run limited ICN applicati= ons over a
>>>>>> modified
>>>>>> IPv6
>>>>>> network, IPoC is a way to run **unmodified** IPv4/= IPv6
>>>>>> applications
>>>>>> over
>>>>>> a pure CCNx network.=C2=A0 Both approaches have th= eir own
>>>>>> applicability,
>>>>>> and
>>>>>> their own tradeoffs.=C2=A0 In the context of a mob= ile network, hICN
>>>>>> does
>>>>>> not
>>>>>> provide a mobility solution for IP traffic, and th= us requires the
>>>>>> operator
>>>>>> to deploy and maintain two parallel forwarding pla= nes. On the
>>>>>> other
>>>>>> hand,
>>>>>> IPoC allows the operator to eliminate IP routing a= nd legacy
>>>>>> mobility
>>>>>> mechanisms from the mobile core and support all se= rvices over
>>>>>> CCNx.
>>>>>> Yes,
>>>>>> IPoC assumes a bigger first step (deployment of CC= Nx), but it
>>>>>> makes
>>>>>> taking
>>>>>> that step easier, and once taken, native CCNx appl= ications can be
>>>>>> deployed
>>>>>> getting the advantages of the full CCNx architectu= re.
>>>>>> Additionally,
>>>>>> other
>>>>>> transition technologies (like HTTP->CCN proxies= ) can be deployed
>>>>>> to
>>>>>> enable
>>>>>> certain applications to get more of the CCNx-nativ= e benefits.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Greg
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Luca Muscariello <muscariello@ieee.org>
>>>>>> *Date: *Thursday, April 16, 2020 at 1:29 AM
>>>>>> *To: *Greg White <g.white@CableLabs.com>
>>>>>> *Cc: *"Dave Oran (oran)" <daveoran@orandom.net>= , ICNRG
>>>>>> <icnrg@irtf.org>
>>>>>> *Subject: *Re: [icnrg] Last Call: draft-irtf-icnrg= -ipoc
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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 co= mments.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On your first question, the IPoC naming convention= and CCNx
>>>>>> routing
>>>>>> mechanism ensure that the IPoC client remains in c= ommunication
>>>>>> with
>>>>>> the
>>>>>> IPoC gateway that provides reachability to the cli= ent=E2=80=99s
>>>>>> assigned
>>>>>> IP
>>>>>> address
>>>>>> by other devices on the IP network.=C2=A0 If the I= PoC gateway becomes
>>>>>> unreachable due to a network attachment change (e.= g. if the
>>>>>> client
>>>>>> leaves
>>>>>> the current IPoC network and joins another), it wo= uld need to
>>>>>> establish
>>>>>> communication with a new IPoC gateway in the new n= etwork, using
>>>>>> the
>>>>>> mechanism described in Section 8.=C2=A0 It would t= hus be in a
>>>>>> different
>>>>>> subnet,
>>>>>> with a different IP address.=C2=A0 =C2=A0It 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= ..=C2=A0 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 allowi= ng existing
>>>>>> connections
>>>>>> that used the previous IP address to complete.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The IPoC GW is very similar to what we do in enter= prise networks
>>>>>> with
>>>>>> LISP
>>>>>> to optimize Wi-Fi mobility management and more. Ev= en if this
>>>>>> happens
>>>>>> from
>>>>>> the AP to the switch it does not change much.
>>>>>>
>>>>>> Similarly from the eNB to the SGW using GTP tunnel= ing. IPoC does
>>>>>> not
>>>>>> provide any advantage w.r.t. LISP or GTP which bot= h 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 s= ecurity
>>>>>> properties,
>>>>>> inferior mobility wrt the state of the art and als= o 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.:=C2=A0 is it e= xpected that
>>>>>> Interests
>>>>>> and
>>>>>> Content Objects are all signed, and if so, what ar= e the
>>>>>> performance
>>>>>> implications?
>>>>>>
>>>>>> As you noted, section 14 mentions signing of Inter= ests and
>>>>>> Content
>>>>>> Objects, and implies that it is optional.=C2=A0 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 aut= hentication and
>>>>>> authorization is managed via existing means. Inter= est 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 scal= ability
>>>>>> impacts.
>>>>>> I=E2=80=99ll
>>>>>> add an explicit mention in Section 4 that signing = is optional.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Q2 and Q4 are distinct questions related to the us= age of signed
>>>>>> interest
>>>>>> systematically, i.e. 100% of the interests.
>>>>>>
>>>>>> Q2: This is about the fact that interests are sign= ed because they
>>>>>> carry
>>>>>> payload. So local flow balance is gone and this ha= s performance
>>>>>> implications in terms of congestion management, lo= ss recovery AND
>>>>>> mobility.
>>>>>> All gone. This is what Q2 is about. Sorry for bein= g so compact,
>>>>>> but
>>>>>> I'm
>>>>>> assuming some terminology is well understood in th= is list.
>>>>>>
>>>>>> Also what are the security implications of signing= every
>>>>>> Interest?
>>>>>> It
>>>>>> looks very similar to an IPSEC GW with all the cer= tificate
>>>>>> business.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Q4: This is about the computation cost. In the hIC= N project we're
>>>>>> spending
>>>>>> a lot of time to bring performance of a single tra= nsfer beyond
>>>>>> 10Gbps. All
>>>>>> forms of optimizations are required: manifests, ha= sh 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 authenticate= d end-points
>>>>>> are
>>>>>> very
>>>>>> well known even in a managed network. Managed netw= orks carry
>>>>>> customer'
>>>>>> traffic and security is MUST, not an option.
>>>>>>
>>>>>> Current solid deployments of LISP in enterprise ne= tworks make use
>>>>>> of
>>>>>> authentication, GTP tunnels too in the EPC backhau= l. Tunnel
>>>>>> confidentiality
>>>>>> may be an option but authentication is not.
>>>>>>
>>>>>> It is an option in EPC for 4G but for 5G UPC confi= dentiality is
>>>>>> mandatory..
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On question 3, there are two implementations that = have been made
>>>>>> available.=C2=A0 One was built on the PARC Metis l= ibraries,
>>>>>> experimental
>>>>>> results
>>>>>> using this implementation were shared at the Novem= ber 13, 2016
>>>>>> ICNRG
>>>>>> Interim Meeting, and it was mentioned as well at t= he March 20,
>>>>>> 2018
>>>>>> and
>>>>>> July 21, 2018 ICNRG meeting where IPoC was present= ed.=C2=A0 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 d= raft.=C2=A0 That
>>>>>> paper
>>>>>> discusses the benefits compared to the existing GT= P tunneling
>>>>>> mechanisms
>>>>>> used in LTE-EPC.=C2=A0 I=E2=80=99m not sure why yo= u are questioning whether
>>>>>> CCNx
>>>>>> consumer mobility still holds.=C2=A0 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) a= nd replace it
>>>>>> with
>>>>>> something that is no worse?
>>>>>>
>>>>>> As soon as the IPoC namespace is tied to the IP ad= dresses 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. Thi= s does not look
>>>>>> like a
>>>>>> compelling reason to change the transport infrastr= ucture. Worse,
>>>>>> it
>>>>>> looks
>>>>>> like an argument NOT to move towards ICN.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am surprised that this draft has moved to last c= all with this
>>>>>> implicit
>>>>>> message.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I did not pay attention to all drafts moving forwa= rd in this RG
>>>>>> because
>>>>>> there are so many of them being pushed by the chai= rs, 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 Luc= a
>>>>>> 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 l= ocal interfaces
>>>>>> change?
>>>>>>
>>>>>>=C2=A0 =C2=A0My question is about both the underlyi= ng mechanics and also the
>>>>>> performance
>>>>>>
>>>>>>=C2=A0 =C2=A0of the system in such cases.
>>>>>>
>>>>>> 2 What are the implications of using signed Intere= sts in this
>>>>>> way?
>>>>>> I
>>>>>> mean
>>>>>>
>>>>>>=C2=A0 =C2=A0100% of the Interests are signed in th= e tunneling scheme. My
>>>>>> question is
>>>>>> both
>>>>>>
>>>>>>=C2=A0 =C2=A0in terms of security and performance. = And with performance I
>>>>>> mean
>>>>>> both
>>>>>>
>>>>>>=C2=A0 =C2=A0mobility and local flow balance.
>>>>>>
>>>>>> 3 Is there any reality check and running code of t= his scheme?
>>>>>>
>>>>>>=C2=A0 =C2=A0Every Internet draft comes with a secu= rity section but not a
>>>>>> cost
>>>>>> section
>>>>>>
>>>>>>=C2=A0 =C2=A0however it is unclear in this specific= case, what are the
>>>>>> benefits
>>>>>> of
>>>>>> this
>>>>>>
>>>>>>=C2=A0 =C2=A0scheme and if one would need it compar= ed to existing tunneling
>>>>>> technologies.
>>>>>>
>>>>>>=C2=A0 =C2=A0The alleged benefits of CCNx in terms = of mobility are never
>>>>>> spelled
>>>>>> out
>>>>>> in the
>>>>>>
>>>>>>=C2=A0 =C2=A0draft but it is unclear if any mobilit= y benefit still holds
>>>>>> using
>>>>>> this
>>>>>> technique.
>>>>>>
>>>>>> 4 The cost of signing every packet is significant = and would
>>>>>> probably
>>>>>> kill
>>>>>>
>>>>>>=C2=A0 =C2=A0the performance of the tunnel. In the = last section the authors
>>>>>> seem
>>>>>> to
>>>>>>
>>>>>>=C2=A0 =C2=A0consider interest/data signatures as o= ptional. Can this be
>>>>>> clarified and
>>>>>> spelled
>>>>>>
>>>>>>=C2=A0 =C2=A0out 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-icn= rg-IPOC
>>>>>> (Internet
>>>>>> Protocol Tunneling over Content Centric Mobile Net= works).
>>>>>>
>>>>>> We want to publish this as an Experimental RFC. Pl= ease read it
>>>>>> and
>>>>>> let
>>>>>> us know if you think there are issues. The last ca= ll ends on
>>>>>> April
>>>>>> 15,
>>>>>> i.e., 3 weeks from today.
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/draft-irtf-icnrg-ipoc/
>>>>>>
>>>>>> Abstract
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0This document describes a proto= col that enables tunneling of
>>>>>> Internet
>>>>>>=C2=A0 =C2=A0 =C2=A0Protocol traffic over a Content= Centric Network (CCNx) or a
>>>>>> Named
>>>>>>=C2=A0 =C2=A0 =C2=A0Data Network (NDN).=C2=A0 The t= arget use case for such a protocol
>>>>>> is
>>>>>> to
>>>>>>=C2=A0 =C2=A0 =C2=A0provide an IP mobility plane fo= r mobile networks that might
>>>>>> otherwise
>>>>>>=C2=A0 =C2=A0 =C2=A0use IP-over-IP tunneling, such = as the GPRS Tunneling Protocol
>>>>>> (GTP)
>>>>>>=C2=A0 =C2=A0 =C2=A0used by the Evolved Packet Core= in LTE networks (LTE-EPC).=C2=A0
>>>>>> By
>>>>>>=C2=A0 =C2=A0 =C2=A0leveraging the elegant, built-i= n support for mobility
>>>>>> provided
>>>>>> by
>>>>>>=C2=A0 =C2=A0 =C2=A0CCNx or NDN, this protocol achi= eves performance on par with
>>>>>> LTE-EPC,
>>>>>>=C2=A0 =C2=A0 =C2=A0equivalent efficiency, and subs= tantially lower implementation
>>>>>> and
>>>>>>=C2=A0 =C2=A0 =C2=A0protocol complexity [Shannigrah= i].=C2=A0 Furthermore, the use of
>>>>>> CCNx/NDN
>>>>>>=C2=A0 =C2=A0 =C2=A0for this purpose paves the way = for the deployment of ICN
>>>>>> native
>>>>>>=C2=A0 =C2=A0 =C2=A0applications on the mobile netw= ork.
>>>>>>
>>>>>> Best regards,
>>>>>> ICNRG chairs
>>>>>>
>>>>>>
>>>>>> DaveO
>>>>>>
>>>>>> _______________________________________________ >>>>>> icnrg mailing list
>>>>>> icnrg@irtf.org
>>>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>>>>>
>>>>>>
>>>>
>>>>
>>>>> _______________________________________________
>>>>> icnrg mailing list
>>>>> ic= nrg@irtf.org
>>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>>>
>>
>>
>>> _______________________________________________
>>> icnrg mailing list
>>> icnrg@irtf= ..org
>>> https://www.irtf.org/mailman/listinfo/icnrg
>>

=C2=A0

DaveO

_______________________________________________
icnrg mailing list
icnrg@irtf.org
https://nam01.safelinks.protection.outlook.com/?url=3Dhtt= ps%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficnrg&amp;data=3D02%7C01= %7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802f= f7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662491883&amp;sdata=3DWFBKE1= r7FCuA0MJEygETfm0iavfjkzSVS90pqyP1Wqc%3D&amp;reserved=3D0
--000000000000b653a905a59ecb00--