Hi, Please find below an updated version that addresses the feed backs received during the IET116 [1].
[1] https://datatracker.ietf.org/meeting/116/materials/minutes-116-ipsecme-202303290630-00 We added the following text to clarify how DSCP eases the traffic management: """ This causes both a resource issue - especially with hardware implementations that are designed with a limited number of SAs - as well operational and management issues. Typically, if the DSCP values are negotiated the initiator and the responder can agree to send a set of DSCP value over one SA and another set of DSCP value over a second channel. If DSCP values are not agreed and between (for example) 2 SAs, it is unlikely the initiator and the responder miraculously select the same subset of DSCP values over the same SAs. Instead each peer is likely that inbound and outbound traffic take different SA and as such does not solve the issue of discarding lower priority packets associated to different class of traffic sharing a given SA. This makes traffic management at least much harder as if not impossible. Increasing the number of SAs as to lower the traffic rate over each of these SA might reduce the probability of packet being dropped, but is not deterministic and as such cannot be considered as a solution especially when considering hardware with a hard limitation on the number of SAs. """ We also changed slightly the negotiation and provide additional text in the security consideration to prevent traffic that can potentially ends up in not being protected. """ A packet that matches an SPD entry for all components except the DSCP values would be treated as "not matching". If no other SPD entries match, the traffic might end up being transmitted in the clear. It is not different from ensuring that IP traffic is not sent in clear text and it is presumed that the IPsec subsystem itself would install a REJECT/DISCARD rule in the SPD to prevent that traffic from being transmitted without IPsec protection. To avoid such situation, it is RECOMMENDED to introduce a SP to does not consider the DSCP values after those SP specifying the DSCP. This is very similar to placing a default SP that protects all traffic by default. Upon receiving a TS_UNACCEPTABLE Error Notify or an incorrect response, the initiator MAY retry the IKEv2 negotiation without specifying the DSCP values. The initiator MAY handle the DSCP value on its own for outbound traffic, but MUST be prepared to receive any DSCP values from the responder """ Yours, Daniel ________________________________________ From: internet-dra...@ietf.org <internet-dra...@ietf.org> Sent: Monday, April 17, 2023 9:10 AM To: Ulf Parkholm X; Daniel Migault; Joel Halpern Subject: New Version Notification for draft-mglt-ipsecme-ts-dscp-01.txt A new version of I-D, draft-mglt-ipsecme-ts-dscp-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-ts-dscp Revision: 01 Title: Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP) Document date: 2023-04-17 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-mglt-ipsecme-ts-dscp-01.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ts-dscp/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ts-dscp Diff: https://author-tools.ietf.org/iddiff?url2=draft-mglt-ipsecme-ts-dscp-01 Abstract: This document defines a new Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP) as a traffic selector of the Security Policy Database (SPD). The new Traffic Selector type TS_DSCP consists of DSCP values associated to the negotiated SA. The IETF Secretariat _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
