On Thu, May 21, 2026 at 7:58 AM Balázs Varga A <[email protected]> wrote:
> Hi, > > I support the publication of draft-ietf-spring-srv6-security-14. It > provides important aspects of SRv6 networking. > > Comment for a possible consideration: > - pointing to MACSec (using it for communication integrity regarding > SRv6-specifics) > Upper layers like ESP or TLS may protect the user data. However, in the > scope of SRV6, only the elements considered > to route the packet needs to be considered, whereas such packet header > fields change during the forwarding. HMAC > has its own limitations (listed properly in the document). Assuming SRV6 > links are protected by MACsec, passively > listening or spoofing or manipulating packet can only be performed by an > attacker that has compromised a node. > If MACsec is not deployed, then any on path attacker can perform such > techniques. So, communication integrity > regarding SRv6-specifics can be provided by MACsec. Maybe worth to state > this clearly in the document > (i.e., lower layer may help here). > I want us to be careful here. I do think that we should probably put in a bit about MACsec, but does that open the door to including things like optical level encryption over wavelengths on WDM paths? Here is what I propose, without going to deep into the technology, under section 7.5: NEW: ## Layer 2 Mitigation In some circumstances it may be possible to mitigate passive listening and packet insertion by leveraging [MACsec] to encrypt traffic at the media access control (MAC) layer by using encryption between two connected devices. This methodology prevents unauthorized access to traffic over a given point to point path by encrypting and authenticating data in motion at Layer 2 of the OSI model. Much like the encryption mechanisms noted for protocol communication and management access, this level of protection can provide integrity and authenticity to all higher layer communications over a given layer 2 path. This will require some changes to the table as well, and since MACsec could potentially cover most of these, we'd need to add something like this: OLD: +===============================+====================================+ | Attacks | Mitigation Methods | +===============================+====================================+ | Modification attack (6.2.1) | Trusted domains and filtering (7.1)| | | Encapsulation of packets (7.2) | | | HMAC (7.3) | +-------------------------------+------------------------------------+ | Passive listening (6.2.2) | Trusted domains and filtering (7.1)| | | Encapsulation of packets (7.2) | +-------------------------------+------------------------------------+ | Packet insertion and | Trusted domains and filtering (7.1)| | replaying (6.2.3) | Encapsulation of packets (7.2) | | | HMAC (7.3) | +-------------------------------+------------------------------------+ | Control plane attacks (6.3) | Control plane mitigations (7.4) | +-------------------------------+------------------------------------+ | Management plane attacks (6.4)| Management plane mitigations (7.5) | +-------------------------------+------------------------------------+ NEW: +===============================+====================================+ | Attacks | Mitigation Methods | +===============================+====================================+ | Modification attack (6.2.1) | Trusted domains and filtering (7.1)| | | Encapsulation of packets (7.2) | | | HMAC (7.3) | | | MACsec (7.6) | +-------------------------------+------------------------------------+ | Passive listening (6.2.2) | Trusted domains and filtering (7.1)| | | Encapsulation of packets (7.2) | | | MACsec (7.6) | +-------------------------------+------------------------------------+ | Packet insertion and | Trusted domains and filtering (7.1)| | replaying (6.2.3) | Encapsulation of packets (7.2) | | | HMAC (7.3) | | | MACsec (7.6) | +-------------------------------+------------------------------------+ | Control plane attacks (6.3) | Control plane mitigations (7.4) | | | MACsec (7.6) | +-------------------------------+------------------------------------+ | Management plane attacks (6.4)| Management plane mitigations (7.5) | | | MACsec (7.6) | +-------------------------------+------------------------------------+ > > Minor (& subjective) comments: > - insertion: maybe injection might be a more appropriate term (e.g., > Section 4. Threat Terminology) > I leave this to the group to decide. I am happy with the current terminology but if others have very strong opinions we can change it. > - resource exhaustion: maybe worth to add a special form of DoS, where a > modified path causes drop of time sensitive packets, as too late packets > are considered invalid (Section 5. Effect) > We currently have: OLD: Resource exhaustion: compromising the availability of the system can be achieved by sending SRv6-enabled packets to/through victim nodes in a way that results in a negative performance impact of the victim systems (e.g., [ RFC9098 <https://buraglio.github.io/draft-bdmgct-spring-srv6-security/draft-ietf-spring-srv6-security.html#RFC9098>]). For example, network programming can be used in some cases to manipulate segment endpoints to perform unnecessary functions that consume processing resources. Resource exhaustion may in severe cases cause Denial of Service (DoS). NEW: Resource exhaustion: compromising the availability of the system can be achieved by sending SRv6-enabled packets to/through victim nodes in a way that results in a negative performance impact of the victim systems (e.g., [ RFC9098 <https://buraglio.github.io/draft-bdmgct-spring-srv6-security/draft-ietf-spring-srv6-security.html#RFC9098>]). For example, network programming can be used in some cases to manipulate segment endpoints to perform unnecessary functions that consume processing resources, or cause drops of time sensitive packets which can cause too late packets which are considered invalid resulting in those packets being considered invalid. Resource exhaustion may in severe cases cause Denial of Service (DoS). - packet deletion: maybe packet drop would be a better term (e.g., Section > 6.1. Attack Abstractions) > I leave this to the group to decide. I am happy with the current terminology but if others have very strong opinions we can change it. > > Thanks & Cheers > Bala'zs > > -----Original Message----- > From: Alvaro Retana via Datatracker <[email protected]> > Sent: Monday, May 18, 2026 9:45 PM > To: [email protected]; [email protected]; > [email protected]; [email protected] > Cc: [email protected]; [email protected] > Subject: [spring] Second WG Last Call: draft-ietf-spring-srv6-security-14 > (Ends 2026-06-02) > > This message starts a Second WG Last Call for: > draft-ietf-spring-srv6-security-14 > > This Working Group Last Call ends on 2026-06-02 > > Abstract: > SRv6 is a traffic engineering, encapsulation and steering mechanism > utilizing IPv6 addresses to identify segments in a pre-defined > policy. This document discusses security considerations in SRv6 > networks, including the potential threats and the possible mitigation > methods. The document does not define any new security protocols or > extensions to existing protocols. > > File can be retrieved from: > > Please review and indicate your support or objection to proceed with the > publication of this document by replying to this email keeping > [email protected] in copy. Objections should be explained and suggestions > to resolve them are highly appreciated. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [1]. > Appropriate IPR disclosures required for full conformance with the > provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of > any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-spring-srv6-security-14.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-srv6-security-14 > > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
