Subject: [Drip] End to end arguments in systems design

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 30 Jul 2020 16:40:28 +0200

https://dl.acm.org/doi/10.1145/357401.357402

End to end arguments in systems design

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 30 Jul 2020 12:07:28 -0400

> End to end arguments in systems design

In UAS we have to think hard about what the ends are; even with Network RID.

UAS is made of 2 distinct components:  UA and GCS.  The UA <-> GCS 
channel starts out direct radio.  But for commercial use, it moves 
beyond direct radio contact, using some relay (LTE, SATCOM, etc.) 
method.  But easy E2E.

Is Network RID UA <-> USS/UTM or GCS <-> USS/UTM? Answer YES!  See my draft:

draft-moskowitz-drip-secure-nrid-c2

Now on to Broadcast RID.  Normally UA -> Observer.  Is GCS -> Observer 
allowed?  And where Network RID is a defined set of pairs for E2E, 
Broadcast is this rapidly changing list of viewers.  Really not 
different from V2V in this regard, other than SWAP.

So Privacy in Broadcast RID becomes a challenge of sticking separate 
pieces loosely together.  Look at my drafts:

draft-moskowitz-drip-operator-privacy
draft-moskowitz-drip-crowd-sourced-rid

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 30 Jul 2020 18:10:09 +0200

one of the advices in this paper, IIRC, is to carefully put a 
functionality at a best place, and not elsewhere.  A 'place' is a layer 
in a stack, or a box in the network.  So, the advice is to make sure to 
make the best placement decisions.

Internet: there is a principle of 'smart end and dumb network' which 
results somehow from that advice: put most of the functionalities in the 
smartphone and the webserver and keep the intermediary routers dumb 
packet forwarders.

Bluetooth: put a single functionality throughout all layers of a 
Bluetooth stack.  A profile is in a set of layers that is dedicated 
entirely to that application, for example exchange of business cards 
('VCARD' I think).

These two things are very different.

When marrying them, we get, for example, a Heart-Rate monitoring belt 
connected to a smartphone and then to a webserver.  But they are not 
end-to-end.  That belt will work only with that smartphone and only  to 
that server.  They are end-to-intermediary-to-end.  The belt cant talk 
directly to the server.  Similarly, the Apple watch needs a smartphone 
to talk to Internet, and similarly other things.

To me, that means Bluetooth does not need the paper cited above.

Were Bluetooth end-to-end, then we'd have an IP stack in these Bluetooth 
devices, and use IP-over-Bluetooth.  There is an RFC7668 for 
IP-over-BluetoothLE.  With that RFC, an HR belt could talk directly to 
the server.  But I think that RFC is not widely deployed, even though it 
is used in some places. (I used it myself some times).

DRIP authentication manifest?  All bellow IP, as seen in the 
presentation.  Is it end-to-end?  Is end-to-end needed at all for DRIP.

Alex