Subject: Re: [5gangip] blockchain mapping system

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Fri, 1 Jun 2018 12:09:19 +0200

Exactly, with this approach you know where to find mappings, but NOT the 
mappings themselves.

You could even store access control policies in the blockchain to 
regulate who can read/update these mappings.

Jordi

El 31/05/18 a les 17:29, Dino Farinacci ha escrit:
> There are different uses of it. Transactions on the blockchain can point to data else where that is encrypted and require additional authentication to get access to.
>
> Dino
>
>> On May 31, 2018, at 8:18 AM, Behcet Sarikaya <[email-masked]> wrote:
>>
>> Did we already establish that blockchain does not help in privacy?
>> Who said that, Jordi or Rodriguez?
>>
>> Behcet
>>
>> On Thu, May 31, 2018 at 9:46 AM, Dino Farinacci <[email-masked]> wrote:
>> Terry, let me expand what Jordi is trying to get across. The LISP-DDT structure is relatively static and the delegation of EID-prefixes is the hierarchical structure of the DDT-roots, the DDT-nodes that are children of the roots, and the map-servers that are DDT leaf nodes.
>>
>> What authenticates which Map-Servers are allowed to accept Map-Registers for their delegated prefixes can be stored in the blockchain. This is a write to the blockchain which is unmuutablely verified at the time the DDT branch is provisioned.
>>
>> When a Map-Resolver is processing a Map-Request from an ITR, and receives a Map-Referral from a Map-Server, it could look up the Map-Server in the blockchain to verify that the EID-prefix in the referral matches the EID-prefix in the transaction stored on the blockchain.
>>
>> Also, the Map-Referral is signed by the Map-Server, so the Map-Resolver could verify the signature by obtaining the public-key from the blockchain or use the one the DDT parent of the Map-Server returned in the Map-Referral (as well as make some conclusions if they differ).
>>
>> There is no push mechanism here and the Map-Resolver gets EID->Map-Server referral entries by using DDT on demand. Blockchain is used to validate the address allocations and delegations and not any map-cache entries, which would change much more frequently then these delegations.
>>
>> Dino
>>
>>> On May 31, 2018, at 3:36 AM, Jordi Paillissé Vilanova <[email-masked]> wrote:
>>>
>>> Hi Terry,
>>>
>>> I agree, but you can use it to store pointers to the servers storing the mappings (like a DNS for mappings). Then these servers can support fast and dynamic updates.
>>>
>>> Regards,
>>>
>>> Jordi
>>>
>>>
>>> El 30/05/18 a les 22:21, FIGURELLE, TERRY F ha escrit:
>>>> Plus how can it be fast enough and propagating mapping information to all servers that store mappings is a huge challenge on physically large networks.
>>>>
>>>>> -----Original Message-----
>>>>> From: 5gangip <[email-masked]> On Behalf Of Mikael
>>>>> Abrahamsson
>>>>> Sent: Monday, March 26, 2018 11:50 PM
>>>>> To: Jordi Paillissé Vilanova <[email-masked]>
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [5gangip] blockchain mapping system
>>>>>
>>>>> On Mon, 26 Mar 2018, Jordi Paillissé Vilanova wrote:
>>>>>
>>>>>> That said, depending on the dynamics of the mappings the blockchain is
>>>>>> suitable or not for a mapping system. If mappings change frequently,
>>>>>> it's not useful, so  it does not make sense for the 5G use-case.
>>>>>>
>>>>>> However, a blockchain can be useful to authenticate the servers that
>>>>>> store such mappings, because this information changes way more slowly
>>>>>> than mappings. A similar scenario is described in this draft:
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
>>>>>> org_doc_draft-2Dpaillisse-2Dsidrops-2Dblockchain_&d=DwIDaQ&c=LFYZ-
>>>>> o9_H
>>>>> UMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=gFRQ2s_dLZtBZOQpFDDiG
>>>>> YKH8WUKw
>>>>> _ZhBg4_uUdEFzo&s=UNs9FqOBStXgWINVb_jrtsjbdjKFsgkJiZmkt1O2YmY&e=
>>>>>
>>>>> "The main outcomes of the
>>>>>      analysis are that blockchain is suitable in environments with
>>>>>      multiple distrusting parties and that Proof of Stake is a potential
>>>>>      candidate for a consensus algorithm."
>>>>>
>>>>> In what scenario for 5G is this applicable?
>>>>>
>>>>> --
>>>>> Mikael Abrahamsson    email: [email-masked]
>>>> _______________________________________________
>>>> 5gangip mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>> _______________________________________________
>>> 5gangip mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/5gangip
>> _______________________________________________
>> 5gangip mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/5gangip
>>
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Mon, 4 Jun 2018 18:45:29 +0000

I was responding to the estimate for the example given and comparing that to virtualized UPF/SPGW. Note that you can't partition prefix's without causing other issues. This was one of the challenges with learn with SDN.

> From: Dino Farinacci <[email-masked]>
> Sent: Thursday, May 31, 2018 7:47 AM
> Cc: FIGURELLE, TERRY F <[email-masked]>; Mikael Abrahamsson
> <[email-masked]>; [email-masked]
> Terry, let me expand what Jordi is trying to get across. The LISP-DDT structure
> is relatively static and the delegation of EID-prefixes is the hierarchical
> structure of the DDT-roots, the DDT-nodes that are children of the roots, and
> the map-servers that are DDT leaf nodes.
> 
> What authenticates which Map-Servers are allowed to accept Map-Registers
> for their delegated prefixes can be stored in the blockchain. This is a write to
> the blockchain which is unmuutablely verified at the time the DDT branch is
> provisioned.
> 
> When a Map-Resolver is processing a Map-Request from an ITR, and receives
> a Map-Referral from a Map-Server, it could look up the Map-Server in the
> blockchain to verify that the EID-prefix in the referral matches the EID-prefix
> in the transaction stored on the blockchain.
> 
> Also, the Map-Referral is signed by the Map-Server, so the Map-Resolver
> could verify the signature by obtaining the public-key from the blockchain or
> use the one the DDT parent of the Map-Server returned in the Map-Referral
> (as well as make some conclusions if they differ).
> 
> There is no push mechanism here and the Map-Resolver gets EID->Map-
> Server referral entries by using DDT on demand. Blockchain is used to
> validate the address allocations and delegations and not any map-cache
> entries, which would change much more frequently then these delegations.
> 
> Dino
> 
> > I agree, but you can use it to store pointers to the servers storing the
> mappings (like a DNS for mappings). Then these servers can support fast and
> dynamic updates.
> >
> > Regards,
> >
> > Jordi
> >
> >
> >> Plus how can it be fast enough and propagating mapping information to all
> servers that store mappings is a huge challenge on physically large networks.
> >>
> >>>> That said, depending on the dynamics of the mappings the blockchain
> >>>> is suitable or not for a mapping system. If mappings change
> >>>> frequently, it's not useful, so  it does not make sense for the 5G use-
> case.
> >>>>
> >>>> However, a blockchain can be useful to authenticate the servers
> >>>> that store such mappings, because this information changes way more
> >>>> slowly than mappings. A similar scenario is described in this draft:
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mai
> >> lman_listinfo_5gangip&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTx
> >>
> wl2paJIf4zw&m=7kFHRLEmRPFqBrQZoS0uskFEHRrJ6lOuxu4HoknmfEQ&s=Uo
> s3OVgr-
> >> -LjBXlv97ceLrZggf2lKyU_-TzwMCBZMY8&e=
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_5gangip&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl
> >
> 2paJIf4zw&m=7kFHRLEmRPFqBrQZoS0uskFEHRrJ6lOuxu4HoknmfEQ&s=Uos3
> OVgr--Lj
> > BXlv97ceLrZggf2lKyU_-TzwMCBZMY8&e=