Subject: [IPsec] Any objection to the mitigation methods proposed by draft-dunbar-sr-sdwan-over-hybrid-networks for the security risks associated when CPEs are connected to PEs via Internet

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Jul 2018 21:50:28 +0000

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/  describes a scenario to steer an IPsec tunnel between two CPEs (E1<->E2) through a provider SR domain.

In the figure above, C1, being VPN PE node, is connected to CPE E1 via public internet, and it doesn't terminate the IPsec tunnel.  (We call it "remotely attached CPE" in the description below):

This scenario might bring out the following security risks:
1)            Potential DDoS attack to the PEs with ports facing internet. I.e. the PE resource being attacked by unwanted traffic.
2)            Potential risk of provider VPN network bandwidth being stolen by the entities who spoofed the addresses of SD-WAN end nodes.

We would like to hear community feedback on potential other security risks and the following proposed mitigation methods. Copy IPsecme group and Sec ADs to get more scrutiny to the proposed method.

--------------------------------------
To mitigate security risk of 1) above, it is absolutely necessary for PEs which accept remotely attached CPEs or simply have ports facing internet to enable Anti-DDoS feature to prevent major DDoS attack to those PEs.
To mitigate the security risk of 2) above, RFC7510 defines the use of DTLS to authenticate and encrypt the RFC7510 encapsulation.
However, for the scenario of SD-WAN source node being remotely attached to PEs, using the method recommended by RFC7510  means the source node has to perform DTLS on top of the IPSec encryption between SD-WAN end points E1<->E2. This can be too processing heavy for the SD-WAN end nodes. In addition, if there are many SD-WAN flows to traverse through the ingress PE (e.g. C1, C2, C4 in the figure 1 above), heavy processing is required on the ingress PEs.
Since the payload between E2<->E2 is already encrypted, the confidentiality of the payload is already ensured.  The network operators need to balance between how much they can tolerant some percentage of bandwidth being stolen and how much extra cost they are willing to pay for completely prevent any unpaid traffic traversing through its VPN networks. For operators who opt for lower cost ingress PEs and CPEs, but can tolerant some percentage of bandwidth being used by unpaid subscribers, a simple approach can be considered:
-              Embed a key in the packets, which can be changed periodically, like the digital signature used by a certificate authority or certification authority (CA).
-              The key can be encoded in the GRE Key field between SD-WAN end node and Ingress PE. Since GRE has 24 bits, some fixed bits can be used to represent the signature of paid subscribers.

Thank you very much.