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

[Luca Muscariello <[e-mail]>]

Hi Susmit,

AFAIK, there's no payload in the interest packet in NDN.
Is there?

Luca

On Thu, May 14, 2020 at 7:12 PM Susmit <[e-mail]> wrote:

> 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 <[e-mail]>
> 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 <[e-mail]>
>> wrote:
>>
>>> Hi Greg,
>>>
>>> Thanks for the clarifications.
>>> More comments in line.
>>>
>>>
>>> On Sat, May 9, 2020 at 7:36 PM Greg White <[e-mail]> 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)" <[e-mail]>
>>>> *Date: *Wednesday, April 22, 2020 at 8:55 AM
>>>> *To: *Luca Muscariello <[e-mail]>
>>>> *Cc: *Dirk Kutscher <[e-mail]>, Greg White
>>>> <[e-mail]>, ICNRG <[e-mail]>
>>>> *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 <[e-mail]>
>>>> 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 <[e-mail]>
>>>> > 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 <[e-mail]
>>>> >
>>>> >>>>> 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 <[e-mail]>
>>>> >>>>>> *Date: *Thursday, April 16, 2020 at 1:29 AM
>>>> >>>>>> *To: *Greg White <[e-mail]>
>>>> >>>>>> *Cc: *"Dave Oran (oran)" <[e-mail]>, ICNRG
>>>> >>>>>> <[e-mail]>
>>>> >>>>>> *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
>>>> >>>>>> <[e-mail]>
>>>> >>>>>> 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 <[e-mail]> on behalf of Luca
>>>> >>>>>> Muscariello
>>>> >>>>>> <
>>>> >>>>>> [e-mail]>
>>>> >>>>>> *Date: *Monday, March 23, 2020 at 2:01 AM
>>>> >>>>>> *To: *"Dave Oran (oran)" <[e-mail]>
>>>> >>>>>> *Cc: *ICNRG <[e-mail]>
>>>> >>>>>> *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
>>>> >>>>>> <[e-mail]>
>>>> >>>>>> 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
>>>> >>>>>> [e-mail]
>>>> >>>>>> 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
>>>> >>>>> [e-mail]
>>>> >>>>> 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 <[e-mail]>
>>>> >>> 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
>> [e-mail]
>>
>> 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
>>
>