Let’s take the IPv6 issue first. Why do we care about IPv6 versus IPv4? Well, we are running out of addresses to assign in version 4. The Internet of Things (IOT) is actually accelerating that problem. Additionally, IPv6 allows agencies to more effectively monitor what is going on within a network and diagnose problems faster. This is important from a security perspective.
In August 2005 Karen Evans testified and released a memo, M-05-22 5. In this memo she called on agencies to begin their transition to IPv6 and complete the final transition by June 30, 2008. Agencies thus promptly ignored her and did nothing.
In September 2010, Vivek Kundra released another memo on the topic, the Transition to IPv6 6. In this memo he specified two sets of goals; one for external capabilities and one for internal capabilities. All of the external capabilities were to be transitioned to IPv6 by October 2012. Internal capabilities were to be completed two years later. Agencies also ignored him.
The National Institute of Standards and Technology (NIST) developed a dashboard 7 to help us monitor the progress toward the first goal, external capabilities. I just grabbed this data and you can see that agencies have blown by that goal. The Social Security Administration and EPA are the only agencies that have completely transitioned their external capabilities to IPv6. Good for them, but bad for everyone else.
My point in bringing this up here, in the middle of my Networst discussion, is to ask what you think the new RFP says on IPv4 versus IPv6? I’ll bet that most of you think that the solicitation released in October 2015, more than 10 years after Karen Evans’ initial policy on IPv6, does not allow IPv4 solutions. You would be dead wrong. GSA is continuing to allow solutions that are contrary to long-standing administration policy; in fact, two administrations. Hooray for GSA, continuing to enable bad behavior.
In fact, in Section, C.220.127.116.11.4 Technical Capabilities it clearly states:
“The contractor shall support IPv4 as both the encapsulating and encapsulated protocol.”
Then it does it again later in Section C.18.104.22.168 Interfaces, again in C.22.214.171.124.4 Technical Capabilities, as well as the following sections:
- 126.96.36.199 Interfaces
- 188.8.131.52 Standards
- 184.108.40.206.4 Technical Capabilities
- 220.127.116.11.4.1 TIC Portal Capabilities
- 18.104.22.168.2 Standards
- 22.214.171.124.1 Video Teleconferencing Service Interfaces
The external capabilities are really just the tip of the iceberg. The internal capabilities are much more difficult to measure, and as a result, I suspect that there is much less progress. Also, there is a lot more of the internal capabilities than the external ones. The same monitoring tools that are used for CDM can help agencies to identify the extent to which they have IPv4 in their environments. It would be great for OMB to require agencies to use these tools to identify a few things. First, they should be looking for parts of the organization that are not currently being monitored. The tools are good, and things that are measured can be improved, but I am certain that there is still a lot that isn’t currently being monitored. So first, identify the extent to which we have deployed the CDM capabilities throughout the enterprise. Second, require agencies to report, heck, just to OMB, or the IPv6 Task Force on the extent to which there is IPv4 in the internal network. Finally, draw a line in the sand. Make it a budget play by telling agencies that they will be precluded from using appropriated funds for non-IPv6 capabilities. That will get them working on it.
Then, kick someone in GSA’s ass for allowing this RFP to go out the door with IPv4 requirements.
Side note, the RFP actually has a good conceptual diagram that identifies MTIPS in Section C.126.96.36.199.1.1. I think that even though the color choices here seem to reflect a design circa 2002, it does a good job of identifying what MTIPS is and how it fits in.
The problem in this solicitation is that there is some stuff that is optional. For example Section C.188.8.131.52.4.1, which is focused on controlling mobile devices:
|a) (Optional) PIV/CAC Support – shall support the management of PIV/CAC cards on mobile devices via the MDM.
b) (Optional) Biometric Support – shall support biometric support such as fingerprint or face recognition with mobile devices. The ability for the MDM to manage this capability may be combined with PIV / CAC support.
c) (Optional) Network Monitoring – shall support monitoring of the mobile device network quality and performance (e.g., the number and location of dropped calls by enterprise/agency devices).
Remember I already said in the Commodity IT chapter that we should be using mobile devices as a mechanism for authentication, something you have. Also remember that last summer saw the “Sprint” in which agencies finally moved out on PIV cards. So I’m disappointed to see GSA essentially backtracking here by labeling it as an “optional” capability. They are dumb for calling it PIV/CAC when they should have made it more generic like HSPD-12 compliance.
But more on mobile devices, GSA has been cooking up their Prices Paid Portal capability. This can be a game-changer because if it works it can help to ground independent government cost estimates (IGCEs) in real cost data and could also be used by Contracting Officers to both support their negotiations on price as well as “fair and reasonable” determinations. Conceptually the Prices Paid Portal should have a curve for everything the government buys, like the one below.
The problem is that while GSA has been running the Federal Strategic Sourcing Initiative (FSSI) Wireless, they aren’t reporting the prices paid to their own GSA Prices Paid Portal. How completely insane is that? On the wireless front, there is a ton of money to be saved. Just as I put my partner and our kids on a family plan and save money; government agencies can get together to be on one big family plan and also save a lot of money.
The thing that costs an individual or a family money is when there is an instance in which a person goes over the data or talk level that you paid for in a given month. You incur an overage charge. But when you make the pool really big, those single people who use a lot of data make less impact as the pool of people increases. If we are smart about that, an agency might be able to actually lower their requirement for data from 3GB per month to 2GB per month per line. That would deliver some savings back to the agency and help to cut the O&M costs.
But in order to perform that type of analysis, we need to have data on how much agencies are paying for 2GB versus 3GB of data per line per month. The Prices Paid Portal is supposed to help deliver that information to us, but GSA doesn’t seem to be playing ball. OMB collected data on this front and spat it back at us during a couple PortfolioStats. Life would be easier if GSA delivered this like they said they would when they were developing the FSSI Wireless contract under the Digital Government Strategy (Section 5.1) 8.