Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc

Susmit <susmit@cs.colostate.edu> Thu, 14 May 2020 17:12 UTC

Return-Path: <susmit.shannigrahi@gmail.com>
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 <icnrg@ietfa.amsl.com>; 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 <icnrg@ietfa.amsl.com>; 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 <icnrg@irtf.org>; Thu, 14 May 2020 10:12:05 -0700 (PDT)
Received: by mail-pf1-f171.google.com with SMTP id x2so1579232pfx.7 for <icnrg@irtf.org>; 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> <CAH8sseRzHtrKpw5S+DKOUuysiZ7LaFM=ew5sgrwQjvSqnKL00A@mail.gmail.com> <C8616085-6FE7-4C4F-8048-4CD40C423261@cablelabs.com> <CAH8sseQ5Zn1T8DH2YzZaRqc-3cVf3M47aveWOPvjg1Rov6Sq2A@mail.gmail.com> <0A3AFADD-B47E-45BA-A08A-94971C861C34@cablelabs.com> <CAH8sseS4NEi3RE360NUcxhUrbVW_vnDZGbRFv1L3U1WKivx68g@mail.gmail.com> <D2C9AF4E-9E25-48FD-9E0D-9214D397DEA2@dkutscher.net> <CAH8sseSXU1MsoahzCT+9g8Tc9nY-3oH+JTsafYqp4k3BDhrHrg@mail.gmail.com> <65AE7F1B-D307-478B-9B86-E36E863C0918@dkutscher.net> <CAH8sseT0HhzixQ+ofnpF+p+bhOV13z6Uj-tpVuzni_jgJPd9Cg@mail.gmail.com> <28EA075D-75B4-4046-88C4-1CA28458EDE3@dkutscher.net> <CAH8sseQv7evCHgCVQ3aBLnDotnVQ5suGjbip-yBRYmAMjB8Z9w@mail.gmail.com> <395162EA-39AE-41B3-8B2B-A28008266BD5@orandom.net> <72624FB2-D813-42F4-B559-58E0F3AE085B@cablelabs.com> <CAH8sseStpoLoQfQP2q9my4nY0ZMd6o24jcrhnu+JcO4P2ShDsw@mail.gmail.com> <CAH8sseS9z14Rhd3J9j5GgsHuSeW3eXCyLO3-5fWY7042f1ZtSg@mail.gmail.com>
In-Reply-To: <CAH8sseS9z14Rhd3J9j5GgsHuSeW3eXCyLO3-5fWY7042f1ZtSg@mail.gmail.com>
From: Susmit <susmit@cs.colostate.edu>
Date: Thu, 14 May 2020 12:11:51 -0500
Message-ID: <CAM4XVkoj=ayzqa1nvQ6GU=VSpT6XAgo+v7D79-6_GV+eSrHALg@mail.gmail.com>
To: Luca Muscariello <muscariello@ieee.org>
Cc: Greg White <g.white@cablelabs.com>, icnrg <icnrg@irtf.org>, "Oran, Dave" <daveoran@orandom.net>, Dirk Kutscher <ietf@dkutscher.net>
Content-Type: multipart/alternative; boundary="000000000000b653a905a59ecb00"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/98nUofiM7_KAVRad2cFWuDYDmrE>
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, 14 May 2020 17:24:09 -0000

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 <muscariello@ieee.org>
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 <muscariello@ieee.org>
> wrote:
>
>> Hi Greg,
>>
>> Thanks for the clarifications.
>> More comments in line.
>>
>>
>> On Sat, May 9, 2020 at 7:36 PM Greg White <g.white@cablelabs.com> 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 2017.
>>> 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.  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 purpose
>>> 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 the
>>> first to read the draft with the mindset that it must be trying to provide
>>> ICN features to IP applications, and thus failing to accomplish the goal.
>>> 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 applications
>>> 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
>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-icnrg-icn-lte-4g&data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662441903&sdata=F3ROaggCfuq2bJtp9FpZxhMI8Xkad2a7EecmAqtPMMI%3D&reserved=0>
>> 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 multiple
>>> 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 can
>>> use to transition off of GTP/IP as a backhaul with **zero** changes to
>>> legacy IP applications (and hence zero work for the application 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 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 desire
>>> 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 more
>>> clear in the draft.   As mentioned I will revise the abstract per your
>>> suggestion, and will do another review with an eye toward eliminating some
>>> of the confusing aspects.
>>>
>>
>> Hope comments above can help achieving that.
>> Best
>> Luca
>>
>>
>>
>>
>>>
>>>
>>> Best Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *"Dave Oran (oran)" <daveoran@orandom.net>
>>> *Date: *Wednesday, April 22, 2020 at 8:55 AM
>>> *To: *Luca Muscariello <muscariello@ieee.org>
>>> *Cc: *Dirk Kutscher <ietf@dkutscher.net>et>, Greg White
>>> <g.white@CableLabs.com>om>, ICNRG <icnrg@irtf.org>
>>> *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 order 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 feedback.
>>>
>>> So, I’d make the observation that I think the process is working 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 would
>>> also review IPOC and weigh in on these and possibly other issues that get
>>> raised.
>>>
>>> Lastly, the IRTF doesn’t work by consensus formally, so let’s focus on
>>> the technical questions. The document won’t have passed last call until we
>>> get better understanding of whether the technical questions are of a nature
>>> 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 <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.
>>>
>>>
>>>
>>> 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 <ietf@dkutscher.net>
>>> > 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 use
>>> >>> 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 -- until
>>> >> 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 existing
>>> >>>> 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 <g.white@cablelabs.com>
>>> >>>>> 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’ve 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 the
>>> >>>>>> 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 be
>>> >>>>>> 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 <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>et>, 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 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/
>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-icnrg-ipoc%2F&data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662441903&sdata=wnj3dsfrOFqaID%2FVdbhnK8Aic3%2BCFi48V3w3K8yBQWA%3D&reserved=0>
>>> >>>>>>
>>> >>>>>> 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
>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficnrg&data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662451898&sdata=QBeJLfVXip82j8i35KeXV6JPxT5zwRi0ctqBHxZvbHk%3D&reserved=0>
>>> >>>>>>
>>> >>>>>>
>>> >>>>
>>> >>>>
>>> >>>>> _______________________________________________
>>> >>>>> icnrg mailing list
>>> >>>>> icnrg@irtf.org
>>> >>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficnrg&data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662461892&sdata=0svH1%2FOhcmFTLNgzfeWQBwaZvNZr0nCMhebe1dfIO70%3D&reserved=0>
>>> >>>>
>>> >>
>>> >>
>>> >>> _______________________________________________
>>> >>> icnrg mailing list
>>> >>> icnrg@irtf..org <icnrg@irtf.org>
>>> >>> https://www.irtf.org/mailman/listinfo/icnrg
>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficnrg&data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662461892&sdata=0svH1%2FOhcmFTLNgzfeWQBwaZvNZr0nCMhebe1dfIO70%3D&reserved=0>
>>> >>
>>>
>>>
>>>
>>> DaveO
>>>
>> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
>
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficnrg&amp;data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662491883&amp;sdata=WFBKE1r7FCuA0MJEygETfm0iavfjkzSVS90pqyP1Wqc%3D&amp;reserved=0
>