[bess] Re: Suggested wording to merge the content from draft-wang-bess-secservice to draft-bess-secure-evpn

[Linda Dunbar <[e-mail]>]

Ali,

Since the Network Service Provider managed SRv6 domain is often considered a trusted and secure environment, as detailed in RFC 8754, RFC 8402, and RFC 8986, exposing the VPN-ID or Service-ID as part of the Segment Routing Header (SRH) outside the ESP header is generally less of a concern. Additionally, because the VPN-ID or Service-ID is added and managed by the NSP, it is desirable for these identifiers to be visible to intermediate nodes.

The primary requirement is to encrypt user data flows that carry sensitive or confidential information, rather than the headers managed by the network service provider.

Therefore, for both Case 1) & 2) you listed (VPN-ID being either in the SRH or not), the SRH needs to be outside the ESP header.  i.e., both can be covered by the ESP-Transport tunnel type which is already specified by your draft.

Your current Section 9.1 (Standard ESP Encapsulation) emphasizes on encrypting NVO packets only. Therefore, it is necessary to revise the text in  Section 9 to accommodate the standard ESP Transport for SRv6 packets with SIDs outside the ESP header.

Thank you,

Linda

From: Ali Sajassi (sajassi) <[e-mail]>
Sent: Thursday, June 13, 2024 2:26 PM
To: Linda Dunbar <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: Suggested wording to merge the content from draft-wang-bess-secservice to draft-bess-secure-evpn

Linda,

There are two scenarios to consider with SRv6 IPsec encapsulation:


  1.  VPN-ID/Service-ID is not part of the SRH
  2.  VPN-ID/Service-ID is part of the SRH


  1.  is already covered in the document and I don’t believe we need to do much except adding a sentence or two mentioning that IPv6 EH can be SRH.
  2.  Implies that VPN-ID/Service-ID is carried in the open and this compromises security aspects. So far, if you look at MACsec or IPsec, VPN-ID/Service-ID has always been encrypted with ESP; however, now you are talking about deviating from the prior practices. Because secure-evpn draft is a WG document, we cannot add (2) without WG consensus. So, it would be good to bring up this issue up in BESS and IPSECME and solicit input on this point ONLY.
Cheers,
Ali

From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, June 12, 2024 at 10:39 AM
To: Ali Sajassi (sajassi) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Suggested wording to merge the content from draft-wang-bess-secservice to draft-bess-secure-evpn
Ali,

Section 9 needs change to accommodate the standard ESP Transport for SRv6 packets with SIDs outside the ESP header. Your current Section 9.1 (Standard ESP Encapsulation) emphasizes on encrypting NVO packets only.

Suggest adding a new subsection 9.3 (Standard ESP Encapsulation for SRv6). Here is the suggested wording for 9.3.
---------------------
9.3. Standard ESP Transport Encryption for SRv6 Packets
In scenarios where traffic needs to be securely steered through an SRv6 domain, ESP transport encryption can be applied to SRv6 packets with SIDs outside the ESP header. This allows the packet to benefit from the security provided by ESP while leveraging the routing capabilities of SRv6.

Example of ESP Transport Encryption for SRv6 Packets:
Consider an SRv6 packet with three SIDs where the original transport layer packet (e.g., UDP) is encrypted by ESP. The SIDs remain outside the ESP header, allowing intermediate nodes to route the packet based on the SIDs.

Below is the detailed structure of such a packet:

+--------------------+
| IPv6 Base Header   |
| Version = 6        |
| Next Header = 43   | <- Indicates Routing Header (RH)
| Source Address     |
| Destination Address|
+--------------------+
| Routing Header     | <- Segment Routing Header (SRH)
| Next Header = 50   | <- Indicates ESP header after SRH
| +-----------------+
| | Segment Left = 3|
| | Last Entry      |
| | SID 1           |
| +-----------------+
| | Segment Left = 2|
| | SID 2           |
| +-----------------+
| | Segment Left = 1|
| | SID 3           |
| | Next Header = 17| <- Indicates UDP
| +-----------------+
+--------------------+
| ESP Header         |
| SPI                |
| Sequence Number    |
| Initialization Vec |
+--------------------+
| Encrypted Payload  |
| (Original IPv6 Hdr)|
| (UDP Header)       |
| (UDP Data)         |
+--------------------+
| ESP Trailer        |
| (Padding, Pad Len, |
|  Next Header = 17) | <- Original payload was UDP
+--------------------+
| ESP Authentication |
| (ICV, optional)    |
+--------------------+
---------------------

Alternatively, you can modify the wording of Section 9.1. to include SRv6 and NVO payload as below:

9.1. Standard ESP Encapsulation
When standard IP Encapsulating Security Payload (ESP) is used (without outer UDP header) for encryption of IP packets, including NVO packets as well as SRv6 packets with Segment Identifiers (SIDs) outside the ESP header, it is used in transport mode as depicted below.

(Give the SRv6 example above).

Thank you,

Linda

From: Ali Sajassi (sajassi) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 6, 2024 9:53 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Suggested wording to merge the content from draft-wang-bess-secservice to draft-bess-secure-evpn

Hi Linda,

I don’t think we need to put too much explanation wrt SRv6 because with respect to IPsec, it is just a IPv6 encapsulation. So, let me expand on it with respect to your four points below:

  1.  Scenario description: The rational and the reasons for needing IPsec are basically the same whether it is for regular IPv6 or SRv6. So, such text is already covered in the draft.
  2.  Implementation Strategy: with respect to flow identification, policy configuration, etc. The draft already covers that and indicates different level of granularity (all the way at the flow level) for doing IPsec encap.
  3.  Security considerations and benefits: This is again applies to both IPv6+ VxLAN and SRv6. So, if we need to beef up some existing texts, we can do it.

So, I can add a sentence or two to sections 9.1 and 9.2 mentioning that IPv6 can carry an extension header including SRv6.

Cheers,
Ali

From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 6, 2024 at 12:40 PM
To: Ali Sajassi (sajassi) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Suggested wording to merge the content from draft-wang-bess-secservice to draft-bess-secure-evpn
Ali,

I am writing to follow up on our discussion during the IETF 119 BESS WG session regarding the draft-wang-bess-secservice. As you may recall, you endorsed Option 1 as the preferable approach for using SECURE-EVPN mechanism to encrypt selective SRv6 Flows into the Secure EVPN framework.
Option 1: Merge with Secure EVPN, directly incorporating the section into the main body of the document.
Additionally, consider adding a description of the necessary encapsulation methods in Section 9 and extending the discussion of new tunnel types in Section 10 to accommodate this feature.

Proposed Integration: I suggest adding a new subsection, "Encrypting Selective SRv6 Flows," to Section 3 of the Secure EVPN draft. This addition would detail the use case and requirements for selectively applying IPsec encryption to SRv6 data flows within NSP-managed networks, addressing the need for heightened security measures for sensitive data.

The proposed content for the subsection "Encrypting Selective SRv6 Flows" would include:

Scenario Description: Highlighting environments where SRv6 is deployed and the types of data flows that require enhanced security measures.
Implementation Strategy: Outlining the steps for implementing IPsec encryption, including flow identification, policy configuration, and the encryption mechanism itself.
Security Considerations: Discussing the added complexity and necessary management adjustments to maintain performance and security.
Benefits: Explaining how this approach secures sensitive information and ensures compliance with various regulatory requirements.

Here is the wording proposal. You can modify them to fit the SECURE-EVPN style.

3.6 Encrypting Selective SRv6 Flows
While a Network Service Provider (NSP) managed SRv6 domain is often considered a trusted and secure domain as detailed in RFC 8754, RFC 8402, and RFC 8986, certain scenarios require an enhanced security model. Particularly in cases where data flows carry sensitive or confidential information, there is a compelling need for additional security measures. Encrypting selective SRv6 flows caters to this need by providing robust protection even within a network environment presumed to be secure.

Scenario Description
In environments where SRv6 is deployed, data flows might include transactions requiring confidentiality, integrity, and authenticity assurances that exceed standard network security measures. Examples include financial transactions, personal data transmissions subject to privacy regulations, or corporate communications involving sensitive strategic content. In such cases, selectively encrypting specific SRv6 flows ensures that even if network breaches occur, the encrypted data remains secure.

Implementation Strategy
The implementation of IPsec for encrypting selective SRv6 flows involves the following steps:
Flow Identification: Define criteria for selecting which SRv6 flows require encryption. This could be based on the type of data, the source/destination of the flows, or preconfigured security policies.
Policy Configuration: Configure security policies that dictate the parameters for encryption, such as the algorithms used, the keys to be employed, and the duration of key validity. These policies are applied specifically to the identified SRv6 flows that require encryption.
Encryption Mechanism: Utilize IPsec in transport mode to encrypt the payload of identified SRv6 packets. The SRH (Segment Routing Header) remains unencrypted to allow for the routing of the packet, while the payload is encrypted, ensuring the confidentiality and integrity of the data.

Security Considerations
Encrypting selective SRv6 flows introduces additional complexity into the network management. It requires careful coordination between network security policies and the dynamic requirements of SRv6 routing. Additionally, the overhead introduced by encryption needs to be evaluated to ensure that it does not impact the network performance adversely. Effective monitoring and management are crucial to detect and respond to security incidents in a timely manner.

Benefits
This approach enhances data security by protecting sensitive information from potential eavesdropping and tampering. It also provides compliance with various regulatory requirements for data protection, offering an added layer of security without encrypting all network traffic, which can be resource intensive.
________________________________
This addition will fit seamlessly into your existing document structure under Section 3, providing a detailed examination of how IPsec can be used to enhance the security of selective SRv6 flows in a network environment managed by NSPs.



I look forward to your feedback on this proposal and am eager to assist in any drafting or revisions needed to facilitate this integration. Once we align on the approach, I will provide detailed text for adding a subsection in section 9 to describe encapsulation and adding extension of new tunnel type in section 10.

Thank you for considering this enhancement. I believe it will make a substantial contribution to the deployment and effectiveness of SECURE-EVPN by addressing critical security needs in SRv6 networks.

Linda