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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
