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

Greg White <g.white@CableLabs.com> Wed, 15 April 2020 22:50 UTC

Return-Path: <g.white@CableLabs.com>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F2F3A0BB4 for <icnrg@ietfa.amsl.com>; Wed, 15 Apr 2020 15:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cablelabs.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7jwdhOk-sqp for <icnrg@ietfa.amsl.com>; Wed, 15 Apr 2020 15:50:55 -0700 (PDT)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2091.outbound.protection.outlook.com [40.107.237.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292CF3A0BB0 for <icnrg@irtf.org>; Wed, 15 Apr 2020 15:50:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZjCkpQolbkyRcfYFtj4d1xuProegBj9wkx1RIHB3Frirv24z/j2eatawbUChYQrADTiG6T9TfFTkbJ+oFDl0H9oxUUEZxsYjwmAk+yZkq4or3NJtS0kfNKnPvgiftgnlDD1p4l/EXnR5amjw53UGqv9jVt/GkLyvtwxzE0gjvLdeZqA8eWTf8DKjq+AlY+P+PsnF4KFVIUbRyjLaU/i1tUawSznYfSr4SSbCrqkAMlHqI+pJznytdNDHe+dD/Eb958wVnOQgMriqpPKqmAeGQnhZ8Xc7i715i3F/c79/9ceodIAa1hX3jlCrq5RkCB0PF6QrPy5Sfw8Z9XhIgZoxmA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sxJOJZDqJ+8jzlrIRHGbkv3Ib1e5Zyr8npabOQTvcKM=; b=XStS4bmZP3xwo+/hszY7mdzrMzPOzlePueewgdE0YloIkx66toAfV+ClpzkaigfoemIwtAJY47FCSpRAYcMHQj2rgUbdJVowFXG/MwgQja7uZt3tetm3itaLivLjrFagi86Iru6XvUUDlQwK9IKG60ni24AMdX8LtyFGF/SNnSb2gBVjj82FP1+IvQ/p5Tnh4dGGd3Y/xexbGO+64Gv3cN9RYAkrunSr8mV58M8bYlL/sNZoTxrr4r+3q/rjtMRPXkTcijOUyTpcJE24qo+q6DDZlpsY3aAPu1V3HlozUZLjFiR4PKghFjYuSkQXX1IJq3nAYJUXcU5P9TIUlOcwzg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sxJOJZDqJ+8jzlrIRHGbkv3Ib1e5Zyr8npabOQTvcKM=; b=Wbt/FBRcjjWvcqNSim65pc5LzWnABnREXLLPkLblfSqmkhUgRfp9ZnWKH9g9J7EQ8ehVamOerpChO0Ad2mVL7q+99AvKI5yZb3496Yyg59ktLdZLnpADGUPw5UkrHhE1fkIi9+oV8O9mm1Ao8yuIqtIgyefQFguF0nKnwMM0fKDwhDzqoErtTMpxIZydWZ+nTd03K6xEXKRh/hn/bAf+rEdxhP9sG/a/N1s7e5Ggm7oJXy94E5sW3QtbM1VCCeWqPPrHauf1p6Lmv5RJRs5jlKteo70yvktC15g/gE+qVaZd/Y8C+KqJRv0aXnuqwKEO5C6HxKssbfDUhX1f2phvqg==
Received: from CY4PR06MB3239.namprd06.prod.outlook.com (2603:10b6:910:53::14) by CY4PR06MB2407.namprd06.prod.outlook.com (2603:10b6:903:13::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.24; Wed, 15 Apr 2020 22:50:51 +0000
Received: from CY4PR06MB3239.namprd06.prod.outlook.com ([fe80::a539:d44b:3215:a79e]) by CY4PR06MB3239.namprd06.prod.outlook.com ([fe80::a539:d44b:3215:a79e%7]) with mapi id 15.20.2900.028; Wed, 15 Apr 2020 22:50:51 +0000
From: Greg White <g.white@CableLabs.com>
To: Luca Muscariello <muscariello@ieee.org>, "David R. Oran" <daveoran@orandom.net>
CC: ICNRG <icnrg@irtf.org>
Thread-Topic: [icnrg] Last Call: draft-irtf-icnrg-ipoc
Thread-Index: AQHV/r6thAUt+nphTkOkk3l15p6BbKhV1M4AgCS5vQA=
Date: Wed, 15 Apr 2020 22:50:50 +0000
Message-ID: <C8616085-6FE7-4C4F-8048-4CD40C423261@cablelabs.com>
References: <93E56749-73D1-4E34-81BB-B7F66DA30F7A@orandom.net> <CAH8sseRzHtrKpw5S+DKOUuysiZ7LaFM=ew5sgrwQjvSqnKL00A@mail.gmail.com>
In-Reply-To: <CAH8sseRzHtrKpw5S+DKOUuysiZ7LaFM=ew5sgrwQjvSqnKL00A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com;
x-originating-ip: [2601:285:8200:323:101d:fb80:a0d0:b52]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ce1dec03-4714-4954-6b8a-08d7e18f725d
x-ms-traffictypediagnostic: CY4PR06MB2407:
x-microsoft-antispam-prvs: <CY4PR06MB240745EBE1B465CDC348B707EEDB0@CY4PR06MB2407.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR06MB3239.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(366004)(346002)(376002)(396003)(136003)(39850400004)(64756008)(33656002)(53546011)(316002)(66946007)(966005)(110136005)(9326002)(478600001)(8676002)(76116006)(81156014)(6486002)(6512007)(5660300002)(66574012)(4326008)(36756003)(186003)(2616005)(66446008)(8936002)(86362001)(66556008)(71200400001)(66476007)(6506007)(2906002)(85282002); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pYnGK2YT64hhq3fu3CldMCI6WbkqleybTD6+32UDoRRlplhqyCd5qFW2GRRZll6hQZKxw3R1VLAf76jmBMknnbaMxyRt4xDLn9ZtY8tENdrGW7zFNkbipDrpPi9dc8vMjy4i/2B32kLvsQ7FNmJo+30x4nmJkcsoJOoDZd2teDlk/bEgRHijQlINixIAaxivla7M974IyTun90LWWlhwLl8v7uV88cLOflBJ5nSir9wmLEbIPMDWi9d0gOpdWPFzPGsiVw0u3pias/5Jf5591SScZYv5qBAM45InMHqFCFSUg4U7hTtNd6S9QM83eCRcOTOvMlRdblQws9l48K4HTLu84vXu15ZgJyUui9a4sco95eGMxzyo0o4ViYZBDBQ7PkYr5scoefYYh1ixIcbTV+UU92S+L3/WxppF1UmrA0eYfrI6j0zZ2uru/IwQySJWs3sz15XKeXXVwrj3YIY+VlbamMvPh0UPaDATuqZVuFfHGOXktLsPgNlEu5vb/2Fy30+QKeFQHi9o40AdJrust4i/KOCFnLJ3+sTgwVC4XAtvMhbV9gzyPuilXacZp7yg
x-ms-exchange-antispam-messagedata: e7N790yknTWqRur6HBCOOHOlaSZs2jwmP/2TRT2Zh70ovklgXQKlYxXtT7O6UwQpwsSbBiF1CIsOOQIuXpN1Ui8FnoIxtTBWQ+DXSlpB99zP4u2RiWiC1TJWtS4pGevq6mdJAIibI7vxQTkSv/IQX8v0t8IEbveiaF90fPotG7TmhKdynggtxyvHW5RbvEdY6cP31L90MFsJadYAgzxZSg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_C86160856FE74C4F80484CD40C423261cablelabscom_"
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ce1dec03-4714-4954-6b8a-08d7e18f725d
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 22:50:51.0123 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oNhlhF9vVD+zV1PdgUcvda7SkZ2NRu1chE4uxHxW3V1YC8Q97q/UEYgCJMFXzzGz/j0oGw2zRjProlPxdhBhTQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2407
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/Q7nYPUQagH97YKE6B8eXatArBAQ>
Subject: Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2020 22:50:57 -0000

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.

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.

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.


Best Regards,
Greg



From: icnrg <icnrg-bounces@irtf.org> on behalf of Luca Muscariello <muscariello@ieee.org>
Date: Monday, March 23, 2020 at 2:01 AM
To: "Dave Oran (oran)" <daveoran@orandom.net>
Cc: ICNRG <icnrg@irtf.org>
Subject: Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc

Hi

I went through the draft and I have a few comments and some questions.

1 how does this system work when IP addresses at local interfaces change?
  My question is about both the underlying mechanics and also the performance
  of the system in such cases.
2 What are the implications of using signed Interests in this way? I mean
  100% of the Interests are signed in the tunneling scheme. My question is both
  in terms of security and performance. And with performance I mean both
  mobility and local flow balance.
3 Is there any reality check and running code of this scheme?
  Every Internet draft comes with a security section but not a cost section
  however it is unclear in this specific case, what are the benefits of this
  scheme and if one would need it compared to existing tunneling technologies.
  The alleged benefits of CCNx in terms of mobility are never spelled out in the
  draft but it is unclear if any mobility benefit still holds using this technique.
4 The cost of signing every packet is significant and would probably kill
  the performance of the tunnel. In the last section the authors seem to
  consider interest/data signatures as optional. Can this be clarified and spelled
  out clearly? Is the intent to use the tunnel w/o signatures?

Thank
Best
Luca



On Fri, Mar 20, 2020 at 2:51 PM David R. Oran <daveoran@orandom.net<mailto:daveoran@orandom.net>> wrote:
Hello ICNRG,

This is a last call for comments on draft-irtf-icnrg-IPOC (Internet
Protocol Tunneling over Content Centric Mobile Networks).

We want to publish this as an Experimental RFC. Please read it and let
us know if you think there are issues. The last call ends on April 15,
i.e., 3 weeks from today.

https://datatracker.ietf.org/doc/draft-irtf-icnrg-ipoc/

Abstract

    This document describes a protocol that enables tunneling of
Internet
    Protocol traffic over a Content Centric Network (CCNx) or a Named
    Data Network (NDN).  The target use case for such a protocol is to
    provide an IP mobility plane for mobile networks that might
otherwise
    use IP-over-IP tunneling, such as the GPRS Tunneling Protocol (GTP)
    used by the Evolved Packet Core in LTE networks (LTE-EPC).  By
    leveraging the elegant, built-in support for mobility provided by
    CCNx or NDN, this protocol achieves performance on par with LTE-EPC,
    equivalent efficiency, and substantially lower implementation and
    protocol complexity [Shannigrahi].  Furthermore, the use of CCNx/NDN
    for this purpose paves the way for the deployment of ICN native
    applications on the mobile network.

Best regards,
ICNRG chairs


DaveO

_______________________________________________
icnrg mailing list
icnrg@irtf.org<mailto:icnrg@irtf.org>
https://www.irtf.org/mailman/listinfo/icnrg