Subject: [Ideas] IDEAS @IETF98 Minutes

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 13 Apr 2017 00:01:23 -0700

Please find below the minutes of the meeting.

Many thanks to our two scribes: Toerless Eckert and Uma Chunduri.

If you have any comments/corrections please let us know.

Thanks

Padma

IDEAS Side Meeting Minutes

1. Slides

Please find below a pointer to the slides

https://drive.google.com/drive/folders/0BwYx7u1T_20RODdLaWpIdk9feHc?usp=sharing

2. Agenda

2.1. Introduction and Problem Statement for IDEAS  - Padma Pillay-Esnault

https://www.ietf.org/internet-drafts/draft-padma-ideas-problem-statement-01.txt
<https://www.ietf.org/internet-drafts/draft-padma-ideas-problem-statement-01.txt>

IDEAS Introduction

IDEAS aims to be the forum where common issues across all ID Enabled
Networks can be discussed.

 Goals:

-       to create awareness

-       to present the work proposed in IDEAS

-       A generic architecture that is scalable, extensible, robust,
secure, and flexible for future ID enabled networks

-        to sollicit comments and feedback from the community on the drafts

-       to call for new contributions

Problem Statement

Motivation: Why Now?

ID solutions can address diverse areas

            IOT, M2M communication, Discovery, privacy, Latency,
Virtualization

Beneficial to have standardized common infra across ID protocols

Key Issues Identified

Lack of common Infrastructure cause harder to deploy a common solution E2E

  -       No Common Management due to disjoint nature

  -       No Common/consistent policy framework

  -       Risk of fragmented communication

 Identifier Lifecycle

  -       No guidance or allocation scheme for public IDs

  -       Agreed upon ID format and scope in cross-domain communication

  -       Recycling IDs

  -       Better address merging of networks

 Security of Mapping Systems

  -       Secured access to the MS

  -       data integrity, Confidentiality, Anonymity, Access control

  -       DDOS attack prone

Proposal

-       To investigate the opportunity of a new specification effort to
address some specific problems from an ID Enabled Networks perspective.

-       To find a common solution and infrastructure that can be shared by
current protocols and facilitate the introduction of new ID-based services
while avoiding rehashing the same problems again each time a new service
pops up

-       Generic Resilient ID Services (GRIDS) infrastructure with
standardized access and multiple services.  The services include

      -       secured registration

      -       discovery

      -       updates with data integrity,

      -       mapping and resolution capabilities,

      -       define relationships between IDs or group of IDs

      -       access control policy and security

- Other Related Work/ Groups

       - LISP (ALT, DDT)

       - HIP uses DNS

       - NVO3 WG

Questions:

Eric Nordmark: What’s unclear is what is out of scope re. Identifier. Are
you considering "what is an identifier", clearly this is not about URI, how
about IP in IP with IPsec ? Is one of them an identifier the other one a
locator. Even LISP was not clear cut between locator/identifier as one
could be routed locally.

Padma Pillay-Esnault: Regarding scope, the way we thinking about this,
there can be multiple scopes with multiple allocation systems. The range of
solutions is so vast that it may not be appropriate to only have one
solution. Plenty options of where to put it and how to put. GRIDS can be
used as local, proximity, global instance just as possible to have Private
ID.

Bob Moskovitz: Concept of Identity and Identifier is important and  I have
been involved and saw some form of this for the last 20 years may be more.
It really does to be discussed in the list. Definitely it needs to be
fleshed out a lot more about

what identifiers are, should be part of the work, tough problem with lots
of opinions.

2.2. Requirements for Generic Resilient Identity Services (GRIDS)
in IDEAS  - Alex Clemm

https://www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt

- This is the core infrastructure document which captures all requirements

     - Talked on Core components of GRIDS

     - GRIDS-MS, GRIDS-IS are covered

     - Grouping and Meta data are not described yet

     - Identity and Identifier definitions elaborated

     - Talked in details about mapping services

     - Identity related services are detailed

          - Structured and unstructured identifiers

          - Grouping related services

     - Requirement (Distribution, Redundancy, Performance and Scale..)

     - Key performance requirements

     - Security requirements

     - GRIDS should be able to be deployed in private space as well as in
public domain

- The naming evolved from mapping system, which was too functionally
constrained.

Questions:

Ravi Ravindran: Trying to understand scope: trying to expand LISP ?

What is the scope ?

Alex Clemm: No, not planning to just "expand lisp", that should be done in
LISP WG. Some of those questions are better answered in the use cases,
clear which ones are not resolved by LISP.

Benjamin Damm: How is this different from Multicast DNS ?

Bob Moskovitz: I can totally implement everything in GRIDS in DNS but that
would not be a great idea but there would be a lot of

problems, DDoS, etc.. Think that metadata is not optional but must be
called mandatory. Determined by use case.

Alex Clemm: Note taken

Dino Farinacci:  rfc8060 defines multiple RLOC types, eg: LISP can support
those. Does this look like multicast DNS ? No, this is network layer
mapping information mapping addresses to addresses.

Eric Nordmark: Multicast DNS is a local service, this is meant to be global.

2.3. A Blockchain-based Mapping System - Jordi Paillisse

- Blockchain is decentralized and secured

     - Add blocks of data one after other

     - Blockchain work flow

     - Transaction with a data, Senders Signature and Senders Public Key to
a P2P network

     - Properties

        - Decentralized, No prior trust is required

           Data can be added but not modifiable

     - Basic Idea

        - Store mappings in blockchain

        - EID prefixes are distributed to all participants

     - Pros and Cons

        - Infrastructure less, Decentralized, fast lookup, secure, no prior
trust, simple rekeying

        - Cons

            - Slow updates, costly boot strapping

     - Comparison with LISP DDT

        - No Infra, easy management

     - Issues with RPKI

         - Anonymity (prefix linked to owner name)

         - Revocation issues (block chain doesn’t use certificates)

     - Scalability

         - Growth similar to BGP Churn

         - Prefix delegation + Mappings

     - Design considerations

           - Bitcoin is too restrictive

           - New technologies - More scalable and more contracts

     - Dedicated chains..

Questions:

Toerless Eckert: what is the incentive model for participants to deploy the
necessary infrastructure for this system ? In bitcoin, the security is
achieved  through tremendous amount of calculation, the cost for that
hardware is financed by handing out bitcoins for successful calculations.
Do we need to hand out IPv4 addresses to pay for IDEAS bitchain
calculations ?

Jordi Paillisee: Good question, there are some new blockchain methods with
other incentive structures. See references on last slide of the slide deck.

Regarding incentive it is about security.

Dino Farinacci:

When a new registration added (Say Jordi first and then 100000 more records
added. Now the entry moved to the end. This solution will have

complete history of movements. Q1: can the really old stuff be chopped off.
Q2: if RLOCs change etc. is it not really slow when you need to look
through a lot of other newer mappings ?

Jordi Paillisee : Q1 Answer: It can be mitigated through implementation

Q2 answer: implementation detail. Database should have latest data for all
entities, not in sequential order of evens.

Manu Sporny: Blockchain developer. Referring to blockchain group
(w3c-blockain group) met in the morning, sees overlap with that work, how
could we create alignment. Whom to talk to coordinate ?

Padma Pillay-Esnault: Let’s discuss this offline.

2.4. Use Cases for IDEAS - Tom Herbert

https://www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt

- Mapping essentially a distributed key/value store

       - Key is fixed size per mapping DB

      - Maps "virtual address" to "physical address"

       - Mapping table is assumed to be distributed and possibly shared for
load

       - Rate of entry is important characteristic

       - Use Cases:

              - Common Control plane

              - Mobility

              - Network Virtualization (for network simplification)

              - Heterogeneous Multi-Access (hetnet)

              - Security

              - Device Discovery

       - Mobility

           - Map entity to its current location for forwarding

           - Variants

               - Encap: IP Mobility, IPIP, GTP etc..

               - ID/LOC: LISP, ILA

           - Properties

       - Mobility sub-cases

           - Within a single mobile network

           - Mobility between mobile networks

           - Multi-homed devices

           - Hetnet environments

           - Whole networks are mobile (WIFI in bus)

       - Network Virtualization

           - Variants

              - Encap: Map virtual IP address to Physical address

              - ID/LOC split

           - Properties

              - Mostly in DC

       - Address resolution static tunnels

           - Could be used as alternative means to resolve L2/L3

       - Host Routes

           - A network could implement virtualization simply by creating a
host route

Questions:

Bob Moskovitz: We have been mobile since 1993. We need to start looking at
mobility as baseline. Would almost challenge in discussion the starting
point. Take rate of mobility (how fast it can move) as distinguishing
attribute.

Tom Herbert: Agree. How quickly is my "device" going from one network to
another. With higher rate, updates become a problem. Also get more and more
use cases where latency becomes an issue. Hope we could avoid relying on a
distributed system. Control path is critical system, keeping everything in
sync with low latency and secure, reliable, available. Can we design this
system with applicability across different use cases.

Mike McBride: There are applications like AR/VR that have strict
requirements hopefully, that is also included in use cases.

Tom Herbert: Yes this has been discussed in the draft.

Padma Pillay-Esnault: Yes there different strict requirements depending on
the different use cases. Earlier there was a question regarding IOT use
cases. The requirements may vary for example depending if the type of IOT
device. If it battery  operated (supposed to last 10 years) then it may
have only one way communication (such as a pet tracker or sensor) and may
even be on non-IP. In some cases proximity and context may be important too.

2.5. Mobility First and Global Name Resolution Service - Parishad Karimi

https://www.ietf.org/id/draft-karimi-ideas-gnrs-00.txt

-Name based communications

      - Name based Architectures IP ==> LISP, HIP at IETF MF and NDN (in
academia)

      - MF - Mobility First Background

         - MF started in 2010 under NSF, FIA

      - MF Protocol Layers

          - GUID (global Unique Identifiers)

          - We seek to use global name resolution system for resolution

      - Name Resolution Requirements

          - Low propagation and response Latency

          - Storage and load scalability

          - Security and reliability

          - Extensibility and flexibility

     - Structure of mapping should not be limited

     - Why can’t DNS can be supported (DNS Deficiencies)

          - TTL based caching

          - High Mobility makes caching ineffective

          - Static Placement of AUTH Servers

          - Reliance on hierarchal (relating root)

     - For MF we have looked into DMAP and GMAP and Auspice

     - Comparison of all three systems

     - Conclusion - We need a global mapping system with MF project

2.6 Conclusion & Next steps - Padma Pillay-Esnault

Where do we want to go from here ?

Next Steps Slide:

- We need more collaboration from the community and looking forward for
more participation on topics such as Blockchain and distributed trust, Late
binding, Fast Caching, Security, DDOS protection ....

- Let’s take discussions to the alias

- Discuss the scope of work

3. Other Info

Mailing list: IDEAS

List address: [email-masked]

Archive: https://mailarchive.ietf.org/arch/search/?email_list=ideas

To subscribe: https://www.ietf.org/mailman/listinfo/ideas

---

From: Michael Menth <[email-masked]>
Date: Thu, 13 Apr 2017 11:35:03 +0200

Thanks a lot for the minutes - very informative.

Regards, Michael

Am 13.04.2017 um 09:01 schrieb Padma Pillay-Esnault:
>  
> 
> __
> 
> Please find below the minutes of the meeting.__
> 
> Many thanks to our two scribes: Toerless Eckert and Uma Chunduri.____
> 
> 
> Padma____
> -       To find a common solution and infrastructure that can be shared
> by current protocols and facilitate the introduction of new ID-based
> services while avoiding rehashing the same problems again each time a
> new service pops up
> 
> Eric Nordmark: What’s unclear is what is out of scope re. Identifier.
> Are you considering "what is an identifier", clearly this is not about
> URI, how about IP in IP with IPsec ? Is one of them an identifier the
> other one a locator. Even LISP was not clear cut between
> locator/identifier as one could be routed locally.
> 
>  
> 
> there can be multiple scopes with multiple allocation systems. The range
> of solutions is so vast that it may not be appropriate to only have one
> used as local, proximity, global instance just as possible to have
> Private ID.
> 
>  
> 
> Bob Moskovitz: Concept of Identity and Identifier is important and  I
> have been involved and saw some form of this for the last 20 years may
> be more. It really does to be discussed in the list. Definitely it needs
> to be fleshed out a lot more about
> 
> what identifiers are, should be part of the work, tough problem with
> lots of opinions.
> 
>  
> 
>  
> 
>      - GRIDS should be able to be deployed in private space as well as
> in public domain
> 
>  
> 
> Alex Clemm: No, not planning to just "expand lisp", that should be done
> in LISP WG. Some of those questions are better answered in the use
> cases, clear which ones are not resolved by LISP.
> 
>  
> 
> Bob Moskovitz: I can totally implement everything in GRIDS in DNS but
> that would not be a great idea but there would be a lot of
> 
> Dino Farinacci:  rfc8060 defines multiple RLOC types, eg: LISP can
> support those. Does this look like multicast DNS ? No, this is network
> layer mapping information mapping addresses to addresses.
> 
>  
> 
>      - Transaction with a data, Senders Signature and Senders Public Key
> to a P2P network
> 
>      - Properties
> 
>         - Infrastructure less, Decentralized, fast lookup, secure, no
> prior trust, simple rekeying
> 
>         - Cons
> 
> Toerless Eckert: what is the incentive model for participants to deploy
> the necessary infrastructure for this system ? In bitcoin, the security
> is achieved  through tremendous amount of calculation, the cost for that
> hardware is financed by handing out bitcoins for successful
> calculations. Do we need to hand out IPv4 addresses to pay
> for IDEAS bitchain calculations ?
> 
>  
> 
> Jordi Paillisee: Good question, there are some new blockchain methods
> with other incentive structures. See references on last slide of the
> slide deck.
> 
> When a new registration added (Say Jordi first and then 100000 more
> records added. Now the entry moved to the end. This solution will have
> 
> complete history of movements. Q1: can the really old stuff be chopped
> off. Q2: if RLOCs change etc. is it not really slow when you need to
> look through a lot of other newer mappings ?
> 
> Q2 answer: implementation detail. Database should have latest data for
> all entities, not in sequential order of evens.
> 
>  
> 
> (w3c-blockain group) met in the morning, sees overlap with that work,
> how could we create alignment. Whom to talk to coordinate ? 
> 
>        - Mapping table is assumed to be distributed and possibly shared
> for load
> 
>            - A network could implement virtualization simply by creating
> a host route
> 
>  
> 
> Questions:
> 
> Bob Moskovitz: We have been mobile since 1993. We need to start looking
> at mobility as baseline. Would almost challenge in discussion the
> starting point. Take rate of mobility (how fast it can move) as
> distinguishing attribute.
> 
>  
> 
> another. With higher rate, updates become a problem. Also get more and
> more use cases where latency becomes an issue. Hope we could avoid
> relying on a distributed system. Control path is critical system,
> keeping everything in sync with low latency and secure, reliable,
> available. Can we design this system with applicability across different
> use cases.
> 
>  
> 
> Padma Pillay-Esnault: Yes there different strict requirements depending
> on the different use cases. Earlier there was a question regarding IOT
> use cases. The requirements may vary for example depending if the type
> of IOT device. If it battery  operated (supposed to last 10 years) then
> it may have only one way communication (such as a pet tracker or sensor)
> and may even be on non-IP. In some cases proximity and context may be
> important too.
> 
>  
> 
> more participation on topics such as Blockchain and distributed trust,
> Late binding, Fast Caching, Security, DDOS protection ....
> 
>  
> 
> List address: [email-masked] <mailto:[email-masked]>
> 
> _______________________________________________
> Ideas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ideas
> 

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de