On Tue, 31 Jan 2023, Valery Smyslov wrote:

This document should simply say that TS_SECLABEL MUST NOT be used
alone. This document must not try to do incompatible change to the
base RFC7296 which would make conforming implemntations
non-conforming.

Unfortunately, this won't work. It is not enough to add new TS type,
with security labels the semantics of TS types should be changed
so, that there are "primary" TS types and "additional" ones.

This is because in RFC 7296 individual Traffic Selectors in TS payload
are combined with OR. In other words, traffic matching
combination of any Traffic Selector in TSi and
any Traffic Selector in TSr is protected.

TS_SECLABEL cannot be treated with this semantics,
it must be treated with AND (as additional condition for
the traffic to match), which requires RFC 7296 update.

Right.

I agree with you that current document text doesn't take into considerations
the existence of other "primary" TS types, like TS_FC_ADDR_RANGE.

Yes, we assumed that one, which was not "regular IKEv2", was out of
scope but we can say something about it. As Tero pointed out, perhaps
people do want to use it there.

So I do not think this document should update RFC7296 at all, so most
of the section 3 is wrong.

The "proper" way would be to introduce new TS types
TS_IPV4_ADDR_RANGE_WITH_SECLABEL and TS_IPV6_ADDR_RANGE_WITH_SECLABEL.
I recall that it was already tried before, but I don't remember
why this way was abandoned.

The fear of combinatory explosion if something else got added. Eg lets
say we have a similar new TS TYPE that modifies like sec_label. Let's
call it FOO. We would end up with:

TS_IPV4_ADDR_RANGE
TS_IPV4_ADDR_RANGE_WITH_SECLABEL
TS_IPV4_ADDR_RANGE_WITH_FOO
TS_IPV4_ADDR_RANGE_WITH_SECLABEL_AND_FOO
TS_IPV6_ADDR_RANGE
TS_IPV4_ADDR_RANGE_WITH_FOO
TS_IPV6_ADDR_RANGE_WITH_SECLABEL
TS_IPV6_ADDR_RANGE_WITH_SECLABEL_AND_FOO

The WG thought this would be a worse solution.

Paul

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to