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

[Luca Muscariello <[e-mail]>]

Hi Susmit,

thanks for the clarifications. More below.


On Fri 15 May 2020 at 00:33, Susmit <[e-mail]> wrote:

> Hi Luca,
>
> It is correct that the current NDN specification does not provide an
> explicit Payload field for an Interest.
>
> That being said, there are two ways to accomplish this in NDN:
> a) Using the ApplicationParameters field in the current Interest
> specification
>

ApplicationParameters is NOT designed to carry payload as this
field carries information related to matching data on the reverse
path.  Please also review ParametersSha256DigestComponent and
how signed Interests in NDN are conceptually different from
Interest payload in CCNx.

In CCNx the Interest payload is NOT related to matching data on the reverse
path
which requires an additional field to carry the Payload ID.

The designers of CCNx and NDN have made choices that must be used
as intended because there are implications in NOT doing that
as specified.



> b) Overriding the Interest packet to carry a payload.
>

I've no idea what Overriding means in this context.
This is how I interpret Overriding the Interest packet:

*NDN does not support Interest payload as in CCNx therefore I add Interest
payload to NDN.*

Which brings us back to my original remark:  IPoC does not work with NDN.
However, it is on the proponent's shoulders to check that and spell it out
rigorously
and formally in the proposed internet draft.

A software developer starting from NDN to implement IPoC will face this
problem
and will not be allowed to do a) nor b). Unless... this and that... or use
CCNx.
But again see my detailed review about the security implications
about doing that.

For CCNx we have RFCs to honor and for NDN we have public specs.

/Luca


>
> In this work, we used (b).
>
> Susmit
>
>
> ***I soon won't have access to this email address. Please use my new
> work email <[e-mail]> for further communications.***
>
>
> On Thu, May 14, 2020 at 4:49 PM Luca Muscariello <[e-mail]>
> wrote:
> >
> > 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
> >>>> 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/
> >>>>> >>>>>>
> >>>>> >>>>>> 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
> >>>>> >>>>>>
> >>>>> >>>>>>
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>>> _______________________________________________
> >>>>> >>>>> icnrg mailing list
> >>>>> >>>>> [e-mail]
> >>>>> >>>>> https://www.irtf.org/mailman/listinfo/icnrg
> >>>>> >>>>
> >>>>> >>
> >>>>> >>
> >>>>> >>> _______________________________________________
> >>>>> >>> icnrg mailing list
> >>>>> >>> icnrg@irtf..org
> >>>>> >>> https://www.irtf.org/mailman/listinfo/icnrg
> >>>>> >>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 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
>