Re: [Blockchain-interop] New Version Notification for draft-chen-dlt-gateway-identification-00.txt

[Rafael Belchior <[e-mail]>]

Hello All,

Shipping, Thomas, thanks a lot for putting this together.

A few comments:

" (a) Application layer: At the application layer a gateway
    identification scheme is needed that permits an organization who
    participate in a given DLN to declare (advertise) one or more
    gateways into that DLN.  This permits organizations to establish
    peering agreements (contracts) based on the asset type, DLN and
    jurisdictions, identifying (specifying) the gateways that will be
"

isn't this still on the network layer, since it is relative to the 
participation on a DLN?

On 4.1:
"  (iii) asset type transferability: verification that a remote gateway
    for a destination DLN is mechanically capable to receive the type of
    asset and that legally permitted to receive the type of asset.
"

It looks like this corresponds to ODAP's first phase, on the gateway 
verification. Are we performing this on discovery + ODAP?

On "Depending on the specific technical
    constraints of a given DLN (e.g. consensus model), not every node
    within the DLN may be designated to be a gateway capable of
    participating in an asset transfer between two DLNs.  As such, the
    service provider must nominate its nodes or systems specifically as
    gateways"

I think we should add that gateways may not be DLN nodes but rather 
software components that connect to DLN nodes (e.g., Hyperledger Cactus 
ODAP plugin using a Fabric Connector).

"   To ensure the safety of the transferred digital assets, blockchain
    gateway service providers (BGSP) must be trustworthy to clients who
    use the services.  As a result, they must meet a high standard to
    ensure security and trust at different levels, ranging from business
    to networking, from hardware device to software protocol.
"

Essentially the verification comes up to trust a centralized party?
The problem of verifying if a software component is indeed a gateway is 
deferred to those BGSPs, correct?


Cheers,




A 2021-06-07 22:26, Thomas Hardjono escreveu:
> Thanks Mike,
> 
> RPKI is an good possibility, such as for cases when not all the
> Gateways (i.e. their IP addresses) are immediately visible from
> outside the network.
> 
> Its certainly an easy way for an asset service provider (i.e. VASP) to
> declare ownership of a set of IP addresses for the gateways it owns.
> 
> 
> Best
> 
> --thomas
> 
> ________________________________________
> From: Michael McBride [[e-mail]]
> Sent: Monday, June 7, 2021 4:16 PM
> To: Thomas Hardjono; [e-mail]
> Subject: RE: New Version Notification for
> draft-chen-dlt-gateway-identification-00.txt
> 
> Looks good Thomas.
> 
> Since an AS/BGP will be required between gateways (correct? Or only
> when a BGSP is involved?) we can also leverage RPKI to help ensure the
> route being announced between gateways is coming from the legitimate
> route (and subsequent data) owner.
> 
> mike
> 
> -----Original Message-----
> From: Blockchain-interop <[e-mail]> On
> Behalf Of Thomas Hardjono
> Sent: Monday, June 07, 2021 7:53 AM
> To: [e-mail]
> Subject: [Blockchain-interop] FW: New Version Notification for
> draft-chen-dlt-gateway-identification-00.txt
> 
> 
> Folks,
> 
> Here is a first-cut rough draft of the Gateway Identification & 
> Discovery work.
> 
> A couple of the diagrams are still missing, but will be added in the
> next revision.
> 
> Best
> 
> 
> Shiping & Thomas
> 
> ________________________________________
> From: [e-mail] [[e-mail]]
> Sent: Monday, June 7, 2021 10:49 AM
> To: Shiping Chen; Thomas Hardjono
> Subject: New Version Notification for
> draft-chen-dlt-gateway-identification-00.txt
> 
> A new version of I-D, draft-chen-dlt-gateway-identification-00.txt
> has been successfully submitted by Thomas Hardjono and posted to the
> IETF repository.
> 
> Name:           draft-chen-dlt-gateway-identification
> Revision:       00
> Title:          Gateway Identification and Discovery for Decentralized
> Ledger Networks
> Document date:  2021-06-08
> Group:          Individual Submission
> Pages:          13
> URL:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-chen-dlt-gateway-identification-00.txt&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=0iyS9OXfeZzlemwyS2zq01YbrCsj1Y3Rtn7T8LapusM%3D&amp;reserved=0
> Status:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-dlt-gateway-identification%2F&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nmHNbDjw1CBAfpLzgNfRVRwOudemR7gjA5mcpDr6q28%3D&amp;reserved=0
> Htmlized:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-chen-dlt-gateway-identification&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1TxVwx0D6gMJJrfwtYydVD1YQJEenGVL%2BFe9%2F2Ytc7M%3D&amp;reserved=0
> 
> 
> Abstract:
>    Today there is a growth in the number of blockchain and 
> decentralized
>    ledger networks (DLN) around the world, and interoperability across
>    different networks represents a challenge for the value proposition
>    of these networks.
> 
>    One approach for blockchain interoperability to be achieved is to
>    employ gateways that permit assets to flow across the relevant
>    networks of blockchains.
> 
>    However, a core requirement for interoperability is the correct
>    identification of computer systems that act as gateways and the
>    correct validation of the ownership of the gateway.  A secondary
>    requirement is for a gateway to inquire as to the existence of an
>    entity address (public key) within a given decentralized ledger
>    network.
> 
>    This memo discusses options with regards gateway identification and
>    verification strategies.  It looks at addressing the problem from 
> the
>    application layer and from the network layer.  It also discusses
>    other options, such as relying on a third-party 
> blockchain-registered
>    identifiers and resolver services
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> --
> Blockchain-interop mailing list
> [e-mail]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fblockchain-interop&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6FtJXXNd0WfgssWVR%2F3Dc2nCXLiSUjgyo3rKeXCLvqc%3D&amp;reserved=0

-- 
-- Rafael Belchior

Ph.D. student in Computer Science and Engineering, Blockchain - Técnico
Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/