Hi Paul, Those changes resolve the issue and nits I saw, Cheers, S. On 05/04/2023 17:21, Paul Wouters wrote:
On Tue, 4 Apr 2023, Stephen Farrell via Datatracker wrote: Hi Stephen, Thanks for the secdir review!This is basically fine, but I think there's one issue that isn't quite a nit: 1.3: "Typically, the other TS_TYPE would be of type TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE." That seems a bit vague, and maybe less future proof than might be the case, e.g. say if someone defines a new TS type for gold, silver etc. service level that's also intended to be combined with address TS's, I'm not sure it'd make sense to combine this and that (putative) new service level TS with no address type TS's and have things make sense. Maybe better to say this TS MUST be combined with an address type selector? (That statement might go in section 3.)I've changed the sentence in Section 1.3 to: OLD: Typically, the other TS_TYPE would be of type TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE. NEW: It MUST be used along with an IP address Traffic Selector type such as TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE. And in section 3: OLD: Because of this there MUST be some other TS_TYPEs in addition to TS_SECLABEL in the Traffic Selector Payload when it is used in negotiation. NEW: There MUST be an IP address Traffic Selector type in addtion to the TS_SECLABEL Traffic Selector type in the Traffic Selector Payload.nits: 2.2: Typo? "(with deemed the Security Label optional)" s/with/which/ ?Fixed.2/3: I wasn't entirely clear what's meant by "optional" - it doesn't seem to map to a protocol flag or simiilar but to whether or not an implementation chooses to emit one of these TS's - is that right? If so, it could maybe be clearer.That is right. But I thought that was made clear just above the sentence you quote:If the Security Label traffic selector is optional from a configuration point of view,an initiator will add the TS_SECLABEL to the TSi/TSr Payloads. [...]3: the SHOULD level fallback to a new child SA without the label seems a bit odd for a MAC system - is that really the right choice? (I'll believe you if you say "yes," so just asking in case this is an oversight:-)It is a little odd, as you would not want to have the extra security label being "optional", which adds no security. However, some people wanted this to give them an upgrade path from "without" to "with" a security label without requiring a flag day or brand new deployment to switch a deployment from "no label" to "labeled". Note that my own (libreswan) implementation does not support this. Connections are configured either with or without the label and the label must be negotiated if configured. That is, it has no concept of "optional". All changes will appear in version 10. Paul
Attachment:
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
