Editing P2p mobile carriers (section)

== 12.2. Detecting contract breach by a seller (algorithm) ==

In the event of a network failure the buyer needs to know if the seller is to blame for it. In fact, there should be a mechanism that '''acts as a deterrence against the seller using their own service.'''

What I propose to achieve this is a novel method that allows the state of temporary identity allocations in a VLR to be fuzzed. Before I introduce this protocol it is necessary to understand exactly how temporary identities are allocated by the VLR, including every edge case.

<span id="from-here-on-i-will-use-tid-to-refer-to-these-values"></span>
=== From here on I will use ‘TID’ to refer to these values: ===

* 2G TID = [t-imsi].
* 3G TID = [t-imsi] for voice, and [p-tmsi].
* 4G TID = [guti].
* 5G TID = [5g-guti].

<span id="behaviour-of-tid-allocation"></span>
=== Behaviour of TID allocation: ===

* '''Option A)''' The mobile device authenticates with the MsC and the VLR returns a new TID. To complete this protocol the MS acknowledges the TID. The state changes to '''{ NEW: { T: TID, I: IMSI } }''' in the VLR.
* '''Option B)''' The same as Option A, but the MS doesn’t acknowledge the new TID. The state changes to '''{ OLD: { T: self.NEW.T, I: self.NEW.I }, NEW: { T: TID, I: IMSI } }'''. '''Authentication accepts both TIDs.'''

<span id="key-aspects-of-session-management"></span>
=== Key aspects of session management: ===

* '''Premise 1:''' A subscriber can only exist in one VLR at the same time. If a subscriber roams to a new VLR their old records are deleted [premise-1].
* '''Premise 2:''' If a subscriber has an active session with an MsC and another entity tries to authenticate as the same subscriber, the first session will be terminated and result in errors [sim-cloning].
* '''Premise 3:''' A location update without successful authentication DOES NOT result in a change to TID state. Authentication is required [location-updates][tid-allocation-4g][tid-allocation].
* '''Premise 4:''' TIDs must be allocated after every new location update [tid-allocation], but in practice not all networks properly follow this [tmsi-implementation]. TIDs may also be deleted or change randomly throughout a session.
* '''Premise 5:''' VLR information may become corrupt or expire if too old.
* '''Premise 6:''' Different networks use different names for temporary identities. Refer to the following list for each network.

<span id="putting-it-all-together"></span>
=== Putting it all together: ===

<ol style="list-style-type: decimal;">
<li><p>'''Auditor''' attempts to issue location update with latest buyer TID (BT).</p>
<ul>
<li>If MsC sends back an identity request the '''Seller''' must have logged in from a new location or acknowledged a new TID. '''Penalise Seller.'''</li></ul>

<pre>{
    NEW != BT
}</pre>
<ul>
<li>If it asks for auth, BT is still a valid a TID.</li></ul>
</li>
<li><p>'''Auditor''' authenticates with '''Sellers''' IMSI and retrieves a new TID (T1) which they don’t acknowledge.</p>
<pre>{
    NEW = X
    OLD = Y
}</pre></li>
<li><p>'''Auditor''' attempts to issue a location update with BT as the TID.</p>
<ul>
<li>If MsC sends back an identity request we can conclude Y == BT which means the '''Seller''' attempted to use an incomplete location update to evade detection. '''Penalise Seller.'''</li></ul>

<pre>X == ? (seller overwritten value)
Y == BT</pre>
<ul>
<li>If we’re prompted for authentication it must mean that X == BT, hence no changes have taken place after the '''Auditor''' last checked. '''Buyer''' now changes BT in secret contract to T1. T1 is the most recent value.</li></ul>

<pre>X == BT (buyer latest value)
Y == T1</pre></li></ol>

Before the buyer accepts the secret contract for the first time they authenticate with the MsC using the TID provided by the seller. Should the sellers information be correct, the outcome from this process will be a new TID which the buyer saves to the contract.

The contract, and the buyers trusted processor control when the buyer can issue a location update. The rules state that the buyer has a set amount of time to issue an update, and to proceed with the contract, they must provide proof that the MsC accepted an update by providing a location update accepted message signed by a valid integrity key.

Such a message may include a new TID, from which we can infer what the TID allocation state in the buyers local VLR should be. If the buyer is unable to provide such a proof, they must end the contract by committing their current credit usage. '''We cannot deduce here if a failure was the result of a malicious buyer, seller, or some kind of network failure, due to the presence of race conditions.''' Multiple parties can issue location updates here at the same time so penalty breaches shouldn’t assigned.

In order to ensure that the buyers update has gone through, they simply issue an update, wait for a response, and decide on an outcome after a countdown X, reaches zero. If anything goes wrong before X expires, the buyer may gracefully end the contract, paying only for the credit they’ve used. No damages can be awarded to the buyer or seller in the event of a failed update due to the presence of race conditions.

Thus, a seller is only able to disrupt service by anticipating the start of the X countdown- and if they fail to guess this correctly, the buyer will have proof of a breach and can penalise them via the fuzzing protocol.

<span id="detecting-contract-breach-by-a-seller-fuzzing"></span>