Avatar of cfan73

asked on 

Encryption requirements over carrier/WAN circuits

I'm looking for input regarding compliance requirements for data encryption over carrier WAN circuits (MPLS, L2 VPN, etc.).

One particular customer is demanding encryption for their MPLS connectivity (due to HIPAA compliance reqs), but they also have dedicated P2P optical circuits between a couple locations, as well some data center interconnect (DCI) between a hosting provider for data replication. While MPLS is multi-tenant by nature, their P2P optical circuit is not (at least their wave/lambda isn't) - same for the DCI. HIPAA states a requirement for “encryption for all data in transit.” I’ve seen a lot of fluidity in satisfying compliance reqs in the past (especially with PCI), where some partial effort in a particular req will be sufficient to check the box. That said, there’s no wiggle room on what’s in quotes here, so I’m looking for any input regarding whether these reqs might also apply to links that are not “multi-tenant” by nature, such as the dedicated optical circuit.

This largely boils down to equipment (router/firewall sizing), but if there were some relaxed requirements for non-MPLS WAN circuits to still satisfy the HIPAA checkbox, that's what we're looking for.

Thank you

Avatar of undefined
Last Comment
Avatar of David Favor
David Favor
Flag of United States of America image

The only way you can really enforce this is if you have control over both ends of a circuit.

If you do, then you might choose a hardware of software implementation.

Normally TLS encryption is sufficient + there may be requirements for a certain level of cipher to use.

Refer to any HIPAA or MIL specs or any other specs required by both producers + consumers using the line.

The main point about HIPAA is it's easy to secure a line + becomes very difficult to control outside the line.

For example, let's say someone sends an email over a HIPAA encrypted line, from one end to the other. If the email must leave the HIPAA encrypted connection to reach it's final destination, then you'll configuring your outgoing MTA to only connect to other MX records which enforce Opportunistic TLS connections... In other words, you must ensure your email only moves between MTAs as encrypted.

If there's ever a chance of additional delivery past the MX endpoint, then you'll use S/MIME to actually encrypt the message.

Figuring out every detail of any encryption compliance is complex.

There is no... one size fits all solution... Each enterprise + related workflow is best analyzed, then infrastructure built to support all compliance guidelines.

Tip: None of this requires point to point networks. For example, if you use HTTPS + IMAP4S + S/MIME with strong ciphers, you'll accomplish compliance easily... in a few hours, rather than weeks or months of tooling.
Avatar of cfan73


@David Favor

Thank you for the great/quick response. I do have some follow-up questions, of course.

I understand that you can attack it at an application level, and also that encrypting a path requires every hop of that path. What they're currently looking at is encryption at the infrastructure level (at least currently for the MPLS network) by having firewalls at each end with IPsec tunnels between the locations. Thus, everything would be encrypted while traversing the L3 VPN WAN.  (Again, I understand that once the traffic extends beyond the tunnel, you'd have to deal with it separately.)

That said, two questions:

- Is the above a bad approach for some reason (vs. dealing with it at the application level)?  One challenge is sizing around the traffic requirements, of course.
- If the above is a "normal" solution for satisfying this requirement, have you found that it seems to be less of a concern regarding "dedicated" links (such as the P2P DWDM) vs. inherently multi-tenant (MPLS)?

I'm just curious what's been seen in the field more often, as I'm fairly new in dealing with these types of requirements.

Thanks again
Coming from a shop where this was a normal conversation (and it was always repeated with each new project/customer), I can say that the two methodologies that we attempted to stay within (regarding securing the path) were either IPSEC tunneling or (more recently) SD-WAN.  On private circuits we normally used IPSEC and on public infrastructure we pushed for SD-WAN.

Tunneling presents the advantage of being vendor agnostic (though cross vendor inter-operation can be challenging).

SD-WAN presents the opportunity to control both anchors of the path (source agnostic) and pass traffic directly to the customers security domain, over IP.  The down side is customers can be more resistant to the idea and may need more coaching to get over the hump.
Avatar of cfan73



Thanks for your input as well. I understand the tunneling vs. SD-WAN stuff, but let's focus on the following:

  • It's assumed the customer is requiring encryption for their MPLS circuits.
  • They also have dedicated optical DWDM circuits between their sites.
  • They also have DCI (through us, their DC/carrier) between data centers via optical.

I'm looking for input regarding potential compliance requirements (and maybe more specifically how other customers are dealing with this) for the 2nd/3rd bullets.

Thanks again for your patience and input.
Avatar of atlas_shuddered
Flag of United States of America image

Blurred text
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial

A virtual private network (VPN) is a network that uses a public telecommunication infrastructure, such as the Internet, to provide remote offices or travelling users access to a central organizational network securely. VPNs encapsulate data transfers using secure cryptographic methods and other security mechanisms to ensure that only authorized users can access the network and that the data cannot be intercepted.

Top Experts
Get a personalized solution from industry experts
Ask the experts
Read over 600 more reviews


IBM logoIntel logoMicrosoft logoUbisoft logoSAP logo
Qualcomm logoCitrix Systems logoWorkday logoErnst & Young logo
High performer badgeUsers love us badge
LinkedIn logoFacebook logoX logoInstagram logoTikTok logoYouTube logo