Added extra design decision info

docs/source/design/float/decisions/e2e-encryption.md

@@ -0,0 +1,56 @@
+![Corda](https://www.corda.net/wp-content/uploads/2016/11/fg005_corda_b.png)
+
+--------------------------------------------
+Design Decision: End-to-end encryption
+============================================
+
+## Background / Context
+
+End-to-end encryption is a desirable potential design feature for the [float](../design.md).
+
+
+
+## Options Analysis
+
+### 1. No end-to-end encryption
+
+#### Advantages
+
+1.    Least effort
+2.    Easier to fault find and manage
+
+#### Disadvantages
+
+1.    With no placeholder, it is very hard to add support later and maintainwire stability.
+2.    May not get past security reviews of Float.
+
+### 2. Placeholder only
+
+#### Advantages
+
+1. Allows wire stability when we have agreed an encrypted approach
+2. Shows that we are serious about security, even if this isn’tavailable yet.
+3. Allows later encrypted version to be an enterprise feature thatcan interoperate with OS versions.
+
+#### Disadvantages
+
+1. Doesn’t actually provide E2E, or define what an encrypted payloadlooks like.
+2. Doesn’t address any crypto features that target protecting the AMQP headers.
+
+### 3. Implement end-to-end encryption
+
+1. Will protect the sensitive data fully.
+
+#### Disadvantages
+
+1. Lots of work.
+2. Difficult to get right.
+3. Re-inventing TLS.
+
+## Recommendation and justification
+
+Proceed with Option 2: Placeholder
+
+## Decision taken
+
+Decision still required.

docs/source/design/float/decisions/pluggable-broker.md

@@ -0,0 +1,67 @@
+![Corda](https://www.corda.net/wp-content/uploads/2016/11/fg005_corda_b.png)
+
+--------------------------------------------
+Design Decision: Pluggable Broker prioritisation
+============================================
+
+## Background / Context
+
+A decision on when to prioritise implementation of a pluggable broker has implications for delivery of key messaging components including the [float](../design.md).
+
+
+
+## Options Analysis
+
+### 1. Deliver pluggable brokers now
+
+#### Advantages
+
+1.    Meshes with business opportunities from HPE and Solace Systems.
+2.    Would allow us to interface to existing Bank middleware.
+3.    Would allow us to switch away from Artemis if we need higherperformance.
+4.    Makes our AMQP story stronger.
+
+#### Disadvantages
+
+1.    More up-front work.
+2.    Might slow us down on other priorities.
+
+### 2. Defer development of pluggable brokers until later
+
+#### Advantages
+
+1. Still gets us where we want to go, just later.
+2. Work can be progressed as resource is available, rather than right now.
+
+#### Disadvantages
+
+1. Have to take care that we have sufficient abstractions that thingslike CORE connections can be replaced later.
+2. Leaves HPE and Solace hanging even longer.
+
+
+### 3. Never enable pluggable brokers
+
+#### Advantages
+
+1. What we already have.
+
+#### Disadvantages
+
+1. Ties us to ArtemisMQ development speed.
+
+2. Not good for our relationship with HPE and Solace.
+
+3. Probably limits our maximum messaging performance longer term.
+
+   ​
+
+
+## Recommendation and justification
+
+Proceed with Option 2 (defer development of pluggable brokers until later)
+
+
+
+## Decision taken
+
+Decision still required.

docs/source/design/float/decisions/ssl-termination.md

@@ -94,7 +94,7 @@ Design of the [float](../design.md) is critically influenced by the decision of
 
 ## Recommendation and justification
 
-Proceed with Variant option 1a: Include SASL connection checking
+Proceed with Variant option 1a: Terminate on firewall; include SASL connection checking
 
 
 

docs/source/design/float/design.md

@@ -78,10 +78,13 @@ Allow connectivity in compliance with DMZ constraints commonly imposed by modern
 11. Any business data passing through the proxy should be separately encrypted, so that no data is in the clear of the program memory if the DMZ box is compromised.
 
 ## Design Decisions
-1. [AMQP vs. custom P2P](./devisions/p2p-protocol.md)
+
-2. [SSL termination (firewall vs. float)](./decisions/ssl-termination.md)
+The following design decisions are assumed by  this design:
-3. End-to-end encryption
+
-4. Prioritisation of pluggable broker support
+1. [AMQP vs. custom P2P](./decisions/p2p-protocol.md): Use AMQP
+2. [SSL termination (firewall vs. float)](./decisions/ssl-termination.md): Terminate on firewall; include SASL connection checking
+3. [End-to-end encryption](./decisions/e2e-encryption.md): Include placeholder only
+4. [Prioritisation of pluggable broker support](./decisions/pluggable-broker): Defer pluggable brokers until later
 
 ## Target Solution
 
@@ -140,19 +143,7 @@ The bridge control is designed to be as stateless as possible. Thus, nodes and b
 6. The Float should protect against excessive inbound messages by AMQP flow control and refusing to accept excessive unacknowledged deliveries.
 7. The Float only exposes its inbound server socket when activated by a valid AMQP link from the Bridge Control Manager to allow for a simple HA pool of DMZ Float processes. (Floats cannot run hot-hot as this would invalidate Corda's message ordering guarantees.)
 
-## Alternative options considered
-### 1. Using Direct P2P Communication
-I do also have a completely different model of what to do instead of the float/AMQP work, but whilst I don’t think this is likely to be accepted, I do think it has a lot of merits and may be surprisingly fast to implement, at least for small semi-private networks.
 
-Essentially, I would discard the Artemis server/AMQP support for peer-to-peer communications. Instead I would write an implementation of our MessagingService which takes direct responsibility for message retries and stores the pending messages into our own DB. The wire level of this service would be built on top of a fully encrypted MIX network which would not require a fully connected graph, but rather send messages on randomly selected paths over the dynamically managed network graph topology.
-
-For packet format I would use the ![SPHINX packet format](http://www0.cs.ucl.ac.uk/staff/G.Danezis/papers/sphinx-eprint.pdf) although with the body encryption updated to a modern AEAD scheme as in https://www.cs.ru.nl/~bmennink/pubs/16cans.pdf . In this scheme, nodes would be identified in the overlay network solely by Curve25519 public key addresses and floats would be dumb nodes that only run the MIX network code and don’t act as message sources, or sinks. Intermediate traffic would not be readable except by the intended waypoint and only the final node can read the payload.
-
-The point to point links would be standard TLS and the network certificates would be whatever is acceptable to the host institutions e.g. standard Verisign certs. It is assumed institutions would select partners to connect to that they trust and permission them individually in their firewalls. Inside the MIX network the nodes would be connected mostly in a static way and use standard HELLO packets to determine the liveness of neighbour routes, then use tunnelled gossip to distribute the signed/versioned Link topology messages. The nodes will be allowed to advertise a Public IP as well, so some dynamic links and publicly visible nodes would exist. The network map addresses would then be mappings from Legal Identity to these overlay network addresses, not to physical network locations.
-
-## Final recommendation
-
-Implement the Target Solution described above according to the implementation plan described below.
 
 # IMPLEMENTATION PLAN