[bess] 为什么 Tunnel-Type suggested by draft-wang-bess-secservice 没有 indication of SRv6 header?

[Linda Dunbar <[e-mail]>]

Shihang, Haibo, and Sheng Cheng,


draft-wang-bess-secservice-02 只要求加一个ESP-Encrypted-Payload。 我觉得Ali 说的有道理， draft-ietf-bess-secure-evpn-00 已经定义了 ESP-encrypted-payload (i.e., ESP-Transport), which expose the IPv6 header (including the SID fields) outside the ESP encryption. Another ESP-encrypted-payload type (ESP-in-UDP-Transport) leaves the UDP outside the ESP encryption.

除非是你们要加一个 新的 tunnel-type, that specifically saying about SRv6 outer header. E.g. ESP-in-SRv6-Transport).

为什么不叫 “ESP-in-SRv6-Transport”?  is it necessary to have two options, option 1  has UDP port outside the ESP, option 2 has UDP port inside the ESP?

Linda




From: Ali Sajassi (sajassi) <[e-mail]>
Sent: Thursday, June 6, 2024 9:53 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

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