Re: [Ideas] IDEAS @IETF98 Minutes

[Michael Menth <[e-mail]>]

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.____
> 
> 
> 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: [e-mail] <mailto:[e-mail]>
> 
> Archive: https://mailarchive.ietf.org/arch/search/?email_list=ideas
> 
> To subscribe: https://www.ietf.org/mailman/listinfo/ideas
> 
>  
> 
> 
> 
> _______________________________________________
> Ideas mailing list
> [e-mail]
> 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: [phone]
fax: [phone]
mailto:[e-mail]
http://kn.inf.uni-tuebingen.de