FBI_Tactical_Mesh_MANET_-_Questions_and_answeres_Amend_0002.pdf

FBI Tactical Mesh MANET - RFP-DJF-16-1800-PR-0013521 Amend 0002

Additional Questions and answers

# Question* Sect. Title Section # Page #

Q1

The Q&A document is posted with a marking in the footer that indicates there are 8 pages but only 7 pages are shown. Please confirm whether there is any additional content or if the Q&A from Amendment 0001 ends with Page 7 and Q&A #72.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Q&A 7

A1 There are only 7 pages ending with Q&Q #72.

Q2

For Requirement 3, the Government requires that “… the solution shall support Layer-2/Internet Protocol (IP) based data exchange and integration with other devices and networks.” It should be noted that Internet Protocol (IP) is a Layer-3 protocol. Commercial Mesh solutions exist that implement seamless Layer-2 bridging/switching for multi-hop routing. In addition, Commercial Mesh Solutions exist that do not provide seamless Layer-2 connectivity but rather provide a Layer-3 IP Routing based Mesh Solution. Is the Government specifying a requirement for a preference of one over the other? To further clarify, a seamless Layer-2 solution supports any Layer-3 protocol transparently (such as the Internet Protocol (IP) for example). However, a Layer-3 IP Routed implementation does not provide seamless Layer-2 Ethernet support

Revision 1 Dated 1/13/2017

SOW Annex I

General

Requirement 3 1

# Question* Sect. Title Section # Page #

A2

The intention is to be able support seamless Layer-2 connectivity within/between systems and IP for connectivity of edge devices and the routing of transmitted video from the mesh solution to other systems, services or connected networks.

Reference SOW Section 2, Paragraph 1 The Tactical Mesh/MANET solution should integrate with other IP-based systems for data backhaul.

Reference SOW Section 2, Paragraph 2 The solution should support multiple interfaces such as wireless, wired and internet protocol (IP)

Q3

For Requirement 3, does the Government mean to request a Layer-2 implementation to support layer-3 IP data needs (which is called out in Requirement 3 – that IP Devices must be supported)?

Revision 1 Dated 1/13/2017

3 1

A3 YES

Q4

For Requirement 5, it is not clear what this requirement provides given what is already stated in Requirement 4. If the Government’s “IP Devices” are sending data such as voice, video, images, PLI, then such data should be delivered by the mesh solution under Requirement 4.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

5 1

# Question* Sect. Title Section # Page #

A4 Requirement 5 was provided to state types of anticipated data to be transmitted.

Q5

For Requirement 5, is the Government’s intent that without 3rd party devices (such as cameras, sensors, etc.), the Mesh Router itself must provide “voice, video, images, text, PLI”? Meaning, the mesh device must support voice, video encoding, chat software, and the creation and transmission of PLI information?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

5 1

A5 See A4

Q6

For Requirement 21, the language very clearly specifies that the solution shall be compatible with the NTIA Federal Government Channel Plan. If the solution can operate on all channels in that channel plan both between 2200 – 2300 and 4400-4990 MHz, then it is not clear why the solution must additionally tune the channels in 1 MHz steps. If all channels are required, please clarify the intent of the additional granularity in channel tuning. This added granularity would result in an ability to tune channels that is not allowed under the NTIA Federal Government Channel Plan, which appears to contradict the intent of this requirement. In addition, a 1 MHz step would result in creation of approximately (700) 20 MHz channels, (700) 10 MHz channels, and (700) 5 MHz channels, which appears to add greatly to the configuration complexity of the solution.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

21 1

A6 As stated

# Question* Sect. Title Section # Page #

Q7

For Requirement 23, the intent is unclear. For example, if the solution provides Layer-2 seamless connectivity, the Government could run any desired Layer-3 VPN technology on top of the network. Please specify the required destination for the Mesh Solution required to open a VPN connection, and the type of VPN technology being utilized/required to be utilized for this connection.

Revision 1 Dated 1/13/2017

Network and routing

23 2

A7 Solution must support VPN on top of network.

Q8

For Requirement 23, the solution provides Layer-2 seamless connectivity, so the Government could run any desired Layer-3 VPN technology on top of the network. Since a VPN is normally an end-to-end connection initiated by an end-user device to connect back securely to a network over an insecure channel, why would the Mesh Router be doing this? It is not clear if the intent was that the Mesh Router must allow (or must not inhibit) the Government from establishing its own VPN connections over the Mesh infrastructure”, and the connectivity provided by the mesh must allow Government’s current VPN technology to operate properly.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

A8 Mesh must support VPN traffic from between ends. i.e., camera to collection server.

# Question* Sect. Title Section # Page #

Q9

Requirement 24 indicates that the Government’s surveillance data uses VPN technology to connect to networks/servers on the Government’s network. Assuming the intent of Requirement 23 is that the mesh must not prevent such VPN establishment from occurring, is it the intent of Requirement 24 that multiple / different VPN connections to different destinations could be occurring over the Mesh, and the mesh must not prevent multiple VPN’s from being established?

Revision 1 Dated 1/13/2017

24 2

A9 Mesh must support the ability for multiple VPN simultaneously to transverse the network. Mesh could have multiple end devices requiring VPN connections to different terminating points.

Q10

If the intent of Requirement 24 is that multiple / different VPN connections to different destinations could be occurring over the Mesh, and the mesh must not prevent multiple VPN’s from being established, then we respectfully request the Government to revise Requirement 23 as follows: “The solution shall support the ability for one or more 3rd party VPN tunnels to be established over the Mesh. These tunnels could terminate to Government devices which are connected to the mesh or to destinations reachable via egress points.”

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

A10 See A9

# Question* Sect. Title Section # Page #

Q11

For Requirement 23, if the Government is requiring the vendor to support the initiation of VPN tunnels, then the technology utilized (SSL, TLS, DMVPN, etc.) and the basis of trust (certificate based, pre-shared key, pass phase, hardware token) must be indicated in the requirement to ensure compatibility. For example, if a hardware token was required, then the mesh device would need to have a hardware interface (USB, RS-232, or other) that is compatible with the hardware token that the Government intends to utilize.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

A11 Government’s requirement is for the solution to support VPN tunnels.

If VPN connectivity were required for management of a solution’s nodes, the expectation is that the vendor will specify in their proposal.

Q12

For Requirement 28, please define “unidentified / unauthorized traffic”.

For example, if the mesh is a seamless layer-2 device, then the “identification / authorization” would be a function of how one connects to the device. In addition, if a device was connected via Ethernet to the mesh radio, then it is assumed to be authorized and its traffic would be permitted.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

28 2

A12 “unidentified / unauthorized traffic” is any device which attempts to connect to/access/transmit data using the mesh network which was not deployed by authorized personnel.

# Question* Sect. Title Section # Page #

Q13

For Requirement 33, the mesh solution is the infrastructure and not necessarily the beginning or end of the connection and the overall requirements specify connectivity to networks to be accessible via egress points, and call out client devices such as cameras. In this example, an end-to-end security mechanism would be between the Camera and the Video server. Since the mesh solution controls neither end of that connection, what is meant by end-to-end security in this requirement?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

Security/Integrity

33 2

A13 From edge/device point of connection to mesh to point of demarcation from mesh

Q14

Requirement 35 indicates that the device shall not Broadcast its Service Set Identifiers (SSID), but Requirement49 specifies Wi-Fi support. Does this mean that the Wi-Fi access point (either in, or connected to) the mesh node should not broadcast its SSID and that all Wi-Fi client devices (e.g., phones, cameras, etc.) will be hardcoded with the SSID to associate with?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

35 3

A14 If SSID is not broadcast, government will enable connectivity by that device.

# Question* Sect. Title Section # Page #

Q15 For Requirement 35, if the vendor utilizes a technology that is Wi-Fi based to meet the mesh node requirements, does this mean it should not broadcast its/a Wi-Fi SSID?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

35 3

A15 The SSID should be configurable for government to hide/spoof.

Q16

Does Requirement 37 mean that if the Mesh Node has a Bluetooth interface (even though that is not required), then that interface must be deactivated or not detectable via a Bluetooth scanner, or, does it mean that its Manufacturer ID (OUI) needs to be configurable/modifiable by the government to hide/spoof it ID as indicated in Requirement 36?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

37 3

A16 Bluetooth should be able to be deactivated, not detectable with scanner. If active, OUI should be configurable for government to hide/spoof.

# Question* Sect. Title Section # Page #

Q17

For Requirement 38, Mesh Radios typically periodically transmit routing / discovery messages to discover each other and form the mesh. What specifically is being required by the LPI / LPD requirement?

Revision 1 Dated 1/13/2017

38 3

A17 As stated in requirement, minimization of intercept and detection.

Q18

For Requirement 38, is the requirement for radios to be silent (no mesh) until the Government “activates” the mesh via some command and to provide an idle LPD capability?

Revision 1 Dated 1/13/2017

A18 YES

# Question* Sect. Title Section # Page #

Q19

For Requirement 38, is the government requesting that vendors utilize technology that appears like Wi-Fi to blend in with the environment and not be noticed as a Government system so that any Wi-Fi based solution automatically meets the requirement?

Revision 1 Dated 1/13/2017

A19 The government is not specifying how to meet the requirement.

Q20 For Requirement 38, does encryption meet the LPI requirement?

Revision 1 Dated 1/13/2017

A20 The government cannot answer whether encryption would meet the LPI requirement without evaluation of proposed solution.

# Question* Sect. Title Section # Page #

Q21 For Requirement 38, is the requirement to defeat advanced Signal Intelligence / Direction Finding equipment?

Revision 1 Dated 1/13/2017

A21 See A17

Q22

Is the intent of Requirement 38 to mitigate a Nation State threat, or, as in Requirement #36 the spoofing of manufacturer ID’s pretending to be Linksys equipment and ensure that a 3rd party does not realize it is in fact a Government device / network?

Clarification is required since LPI / LPD is a broad requirement and typically, Government LPI / LPD radio systems do not utilize OFDM / Wi-Fi because their RF signature is detectable. and instead, utilize Frequency Hopping or Ultra-Wide Band physical layers (which hide below the noise floor) or operate at Extremely High Frequency bands (e.g.

60 GHz) with low power and directional antennas (which is difficult to detect and intercept).

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

A22 See A17

# Question* Sect. Title Section # Page #

Q23

For Requirement 43, please confirm what is required of the endpoints (e.g., Mesh Router/Solution, etc.), data flow(s), and data format(s) to provide secure data transit from an edge device to the central collection server.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

43 3

A23 See A13

Q24 For Requirement 43, please confirm the specific technology and/or standards required to ensure compliance for the secure data transit from an edge device to the central collection server.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

43 3

# Question* Sect. Title Section # Page #

A24 FIPS 198-1

Q25 For added Requirement 49, does the Government require Wi-Fi as the communication solution for Mesh node communication?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

(Additional)

49 3

A25 The government is not requiring Wi-Fi as part of the solution. Wi-Fi may be part of a solution presented. Wi-Fi must still meet security, throughput rate and egress capabilities.

# Question* Sect. Title Section # Page #

Q26 For added Requirement 49, if other solutions exist that meet or exceed the requirements apart from Wi-Fi, would the Government consider leaving it to the vendor to propose the solution to meet the requirements?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A26 See A25

Q27

Added Requirement 49 appears to conflict with requirement 42. Without the vendor controlling the implementations, certification, or providing / delivering the “devices and egress points” how can the vendor be assured that such connectivity meets FIPS 140-2? A FIPS validated solution would need to exist on both ends of the connection (e.g. between two mesh nodes). Arbitrary Wi-Fi devices (cameras, sensors, access points, tablets, etc.) typically do not carry a FIPS 140-2 validation.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A27 All, see A24

# Question* Sect. Title Section # Page #

Q28

For added Requirement 49, please specify the Wi-Fi standard for communication with 3rd party (unspecified) devices as there are multiple such standards, e.g., 802.11a/b/g/n/ac (and others). Those standards operate on different frequency bands such as 2.4 GHz and 5 GHz ISM.

Without knowing the standard and the frequency band, a vendor cannot be assured that such communication is possible.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A28 The government will evaluate solutions provided. Should solution require additional licensing fees to operate in bands selected, fees must be included as part of cost of solution.

Q29

For added Requirement 49, a standard Wi-Fi AP or Client typically operates outside the frequency bands specified by the Government. For example, the Government specified that the solution must operate in the 2200 to 2300 and 4400 to 4990 bands, but Wi-Fi typically operates in the

2.4 and 5 GHz ISM bands. Is the Wi-Fi solution required to operate in the bands specified by the Government in Amendment 0001, or, does the Government expect the Wi-Fi solution to operate in the ISM bands?

Revision 1 Dated 1/13/2017

SOW Annex I

A29 See A28

# Question* Sect. Title Section # Page #

Q30 For the Requirement 49, if the vendor’s solution is based on Wi-Fi, does that imply that the Mesh Node can alternatively operate in the ISM Bands, or, are the Federal bands still required?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A30 See A28

Q31

For added Requirement 49, is the Wi-Fi connectivity a function of the mesh node or separate/in addition to the mesh node

Revision 1 Dated 1/13/2017

SOW Annex I

A31 See A34 & A35

# Question* Sect. Title Section # Page #

Q32 For added Requirement 49, if the Wi-Fi connectivity function is in addition to mesh node, what are the requirements of the newly requested Wi-Fi device?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A32 See A34 & A35

Q33

For added Requirement 49, do all previously listed requirements (e.g., frequency, security, FIPS, etc.) apply to the newly added Wi-Fi device as well? There appear to be no requirements associated with that device other than the term “Wi-Fi”.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A33 See A34 & A35

# Question* Sect. Title Section # Page #

Q34

For added requirement 49, mesh devices are already required to support Layer-2 bridging. This implies that any third-party Wi-Fi device could be connected to the mesh device via Ethernet. Removing the requirement enables the Government to utilize the Wi-Fi device of their choice since a specific Wi-Fi device/chipset/specification/implementation was not recommended in the requirement. Would the Government consider removing Requirement 49?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A34

NO.

Requirement 49 was added to provide the government with additional solutions which may be applicable in some anticipated uses of Tactical Mesh given the diverse nature of the DOJ agencies’ missions and deployment scenarios.

Q35

For added requirement 49, please specify whether the Wi-Fi communication device is an Access Point or a Client. It appears the intent is to connect to Devices, so the Government is implying an Access Point.

However, when the Government states the need to connect to “…egress points”, this indicates such egress points are, in fact, access points themselves and that vendor implementation would be a client mode device. We respectfully request the Government to clarify their intent so that the vendor may respond appropriately in the proposal.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A35 Wi-Fi is intended to provide alternate means of connection of end devices and/or egress options as well as transmission of data through the mesh network.

# Question* Sect. Title Section # Page #

Q36

For added requirement 49, since the Government specified Wi-Fi communication under “Network and Routing”, does this imply that over-the-air mesh communication utilizes OFDM (Wi-Fi modulations) and Wi- Fi packet framing?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A36 Government is not defining how vendor solutions to meet requirements.

Q37

For added requirement 49, is the Government specifying that Wi-Fi meets the previously listed requirements (in which case requirement 49 is no longer necessary and will be removed), or, is the Government indicating that the mesh network / routing devices must run the Point Coordination Function (the definition of Wi-Fi)?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A37 Government is not defining how vendor solutions to meet requirements.

# Question* Sect. Title Section # Page #

Q38 For the added requirement 49, if the vendor’s mesh devices do not need to run the Point Coordination Function to mesh/communicate/route, then why is Wi-Fi required for Routing?

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

A38 Government is not defining how vendor solutions to meet requirements.

Q39

Given the extensive updates from Amendment 0001 and additional resulting questions, we respectfully request the Government to extend the required submission from 31 January 2017 at 9:00 AM Eastern Time to 10 February 2017 at 12:00 PM Eastern Time

N/A RFP

A39 The government will extend receipt of proposals to 9:00AM Eastern Time, 3 February 2017.

Q40

Would the Government please consider excluding the detailed labor descriptions for each labor category requested by Section L.9.9.4.2 from the page count of the Business Volume? This will allow offerors to provide more complete and comprehensive description for the various labor categories needed to support this 5-year IDIQ.

NA NA NA

A40 No. The labor descriptions will not be excluded from the page count.

# Question* Sect. Title Section # Page #

Q41

Reference AMD 0001, Question 16 - Can the Government please clarify how the Total Evaluated Price will be calculated? Will quantity (1) of every piece of equipment and labor category bid be summed together for comparison to other offerors?

NA NA NA

A41 Equipment will be compared to equipment, and labor will be compared to labor. It will not be summed together.

Q42

Can the government please reconsider about changing the requirement from shall (mandatory) to should (desired)?

A 1 MHz Channel is not wide enough to allow any sizable data transmission and whatever data was sent would be squeezed by protocol overhead to the point of making the connection unusable.

RFP-DJF-16-1800-PR-

0013521 Amend 0001

Revision 1 Dated 1/13/2017

SOW Annex I

Network and routing (Additional)

Requirement 21 2

A42 This is a misinterpretation. The government is asking for the frequency to be tunable in 1MHz increments, not to transmit in 1 MHz bandwidth channels.

End of submitted questions. The government will not accept or respond to any additional questions.