Re: [Sat] Version -02 of the SATP core protocol draft ---- FW: New Version Notification for draft-hargreaves-sat-core-02.txt

> Some question:
> 
> (a) Is the contextID a common value shared only between an App and its gateway:  eg. contextID1 is shared between App1 and G1 (and contextID2 between App2 and G2).
> 
> or
> 
> (b) Is the contextID a common value known to all 4 parties (for one transfer instance there is one contextID known to App1, App2, G1 and G2).

IMO the contextID is unique for a specific transfer and encompasses the sessionID. It should be communicated to the network in order for the lock to be associated with the specific transfer of the specific Gateway (a reference to the contextID should be present inside the lock assertion). 

In a more general topic, we shall allow for implementations of “optimistic” locking for assets. Otherwise, the first gateway that locks an asset will hold the lock until SATP completes (commit or rollback). In other terms, this is a kind of pessimistic locking behaviour and in real-life cases, it would be very inefficient.  

> 
> 
> 
> One analogy that is well known to the IETF community is the Security Association (i.e. context at endpoints) using the IKE and IPsec protocols (for creating encrypted tunnels). 
> 
> In IPsec the endpoints (i.e. "VPN gateway") need to establish a Security Association (SA), which is separately negotiated using the IKE protocol. 
> 
> Part of the SA establishment is each side generating SPI values  (Security Parameter Index) for the tunnel.
> 
> Each VPN gateway then maintains their own SPI Database, which allows each endpoint to lookup in the database which key to apply to decrypt incoming traffic (encrypt outgoing traffic). There is a separate SPI for incoming traffic and for outgoing traffic.
> 
> 
> In a sense, what we are talking about here is a kind of "Transaction Association" (TA) between the endpoints (which is App2 and App2).
> 
> But this "Transaction Association" must be communicated down from the App to the gateway.

The concept of context is also largely used in distributed transaction processing aiming at synchronising different data repositories. 

> 
> 
> 
> --thomas
> 
> 
> 
> ________________________________________
> From: Denis Avrilionis [denis@compell.io]
> Sent: Sunday, March 12, 2023 3:41 AM
> To: Thomas Hardjono
> Cc: sat@ietf.org; Martin Hargreaves; Rafael Belchior; Claire Facer; Wes Hardaker
> Subject: Re: [Sat] Version -02 of the SATP core protocol draft ---- FW: New Version Notification for draft-hargreaves-sat-core-02.txt
> 
> Hi Thomas,
> 
> I proposed to present a message flow to cover the transfer context for our meeting 14 March.
> @claire @wes please tell me if I can have 10’ to present on Tuesday.
> 
> To my view the transaction context includes the session id so perhaps we can refer to a transaction context ID throughout the flow, that would be simpler than the couple <contextID, sessionID>
> 
> --
> Denis
> 
>> On 12 Mar 2023, at 00:46, Thomas Hardjono <hardjono@mit.edu> wrote:
>> 
>> 
>> 
>> Folks,
>> 
>> Attached below is the link to an update the core protocol draft.
>> 
>> 
>> (a) The major updates to the draft :
>> 
>> -- Uses the terms "Lock Assertion" and "Receipt" (instead of "Evidence").
>> 
>> -- Inclusion of an explicit "session_id" value in each message.
>> 
>> -- The addition of a new subsection on the Commit-Ready message (which previously was not in draft-01)
>> 
>> -- The message flows now matches our agreed flows in v16 of the color message-flow diagram PNG file (in our repo).
>> 
>> 
>> 
>> (b) What was not added as yet (but text may be needed):
>> 
>> The architecture draft-03 talks about a Context-ID, which is transfer-context information/parameter that App1 and App2 are assumed to have established in Stage 0 (which is out of scope for SATP). This occurs at the Application level/layer, before SATP gets kickstarted.
>> 
>> The idea is that the Context-ID value could be (should be) bound somehow to the session_id so that the Applications can always see the progress of a transfer occurring between the two gateways.
>> 
>> Because the App1 & App2 could have multiple independent transfers occurring simultaneously and some of those may be handled by the same pair of gateways G1 and G2, the combination of the <Context-ID, session_id> allows each transfer flow to be identifiable.
>> 
>> We need to discuss this more, I think.
>> 
>> 
>> 
>> Best
>> 
>> --thomas
>> 
>> 
>> ________________________________________
>> From: internet-drafts@ietf.org [internet-drafts@ietf.org]
>> Sent: Saturday, March 11, 2023 5:29 PM
>> To: Martin Hargreaves; Rafael Belchior; Thomas Hardjono
>> Subject: New Version Notification for draft-hargreaves-sat-core-02.txt
>> 
>> A new version of I-D, draft-hargreaves-sat-core-02.txt
>> has been successfully submitted by Thomas Hardjono and posted to the
>> IETF repository.
>> 
>> Name:           draft-hargreaves-sat-core
>> Revision:       02
>> Title:          Secure Asset Transfer Protocol (SATP)
>> Document date:  2023-03-11
>> Group:          Individual Submission
>> Pages:          29
>> URL:            https://www.ietf.org/archive/id/draft-hargreaves-sat-core-02.txt
>> Status:         https://datatracker.ietf.org/doc/draft-hargreaves-sat-core/
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hargreaves-sat-core
>> Diff:           https://author-tools.ietf.org/iddiff?url2=draft-hargreaves-sat-core-02
>> 
>> Abstract:
>>  This memo This memo describes the Secure Asset Transfer (SAT)
>>  Protocol for digital assets.  SAT is a protocol operating between two
>>  gateways that conducts the transfer of a digital asset from one
>>  gateway to another.  The protocol establishes a secure channel
>>  between the endpoints and implements a 2-phase commit to ensure the
>>  properties of transfer atomicity, consistency, isolation and
>>  durability.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> 
>> 
>> --
>> sat mailing list
>> sat@ietf.org
>> https://www.ietf.org/mailman/listinfo/sat