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

[Susmit <[e-mail]>]

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
>