[Ideas] IDEAS @IETF98 Minutes

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: ideas@ietf.org

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

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