Re: [IPsec] [saag] IETF 114 IPsecME report
On Tue, 31 Jan 2023, Valery Smyslov wrote: The WG thought this would be a worse solution. This could be solved by adding only two new TS types TS_IPV4_ADDR_RANGE_WITH_CONSTRAINTS and TS_IPV6_ADDR_RANGE_WITH_CONSTRAINTS with a format that allows to add new constraints to the Traffic Selector. Cute, but we have received an early code point in Jan 2021. This has been implemented and deployed in libreswan v4.2 released February 2021. So I don't think we can or want to change this anymore. We went through 3 redesigns before we ended up on this one. I'm fine with clarifying text, but we can't redesign it again this late in the publication process. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] IETF 114 IPsecME report
Valery Smyslov writes: > Hi Tero, > > few comments inline. > > [a lot of text snipped] > > > 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. Yes, but that change should not affect any other TS type than TS_SECLABEL. > 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. No it does not. Nothing in this RFC will change any behavior of any of the existing implementations, and there is no need for existing implementations to be updated to this AND behavior. Only implementations who implement TS_SECLABEL need to know the special processing of it. If the initiator does not support TS_SECLABEL, it will never send them, and there is no issues. If the responder requires TS_SECLABEL it will return TS_UNACCEPTABLE, and the negotiation fails. If the initiator does support TS_SECLABEL, but responder does not, then it will send TS_IPV*_ADDR_RANGE and TS_SECLABEL, and the responder will only return with TS_IPV*_ADDR_RANGE. The initiator should notice there is no TS_SECLABEL, and if that TS_SECLABEL was mandatory then it should delete the SA, and fail the negotiation. As the responder does not support TS_SECLABELs, there is no security issue for it sending data to IPsec SA, as it does not support security labels that would forbid such operation. As the initiator never installs the SA which does not have proper TS_SECLABEL there is no security issues there as it will never receive or send any traffic to that SA that got deleted immediately as it was never installed. So the text in draft saying: If the Security Label traffic selector is optional from a configuration point of view, the initiator will have to choose which TS payload to attempt first. If it includes the Security Label and receives a TS_UNACCEPTABLE, it can attempt a new Child SA negotiation without that Security Label. does not match with that it needs to be updated to: If the Security Label traffic selector is optional from a configuration point of view, the initiator will try with TS_SECLABEL. If the responder includes TS_SECLABEL, then IPsec SA with that Security Label got created. If the responder did not include TS_SECLABEL in its response, then it does not support (or its policy does not allow) them, thus if the TS_SECLABEL was optional in the initiator then it can accept that SA. If the TS_SECLABEL was mandatory in the initiator policy, then it MUST not install the SA, and MUST send delete the Child SA using Delete notification. I.e., there is no need for it to try with two different CREATE_CHILD_SA exchanges, it can simply try with one, that has both TS_IPV*_ADDR_RANGE and TS_SECLABEL, and responder will return either TS_IPV*_ADDR_RANGE only or both. If the responder does not support TS_SECLABEL, it will never pick that one, and if it does support TS_SECLABEL, it knows it MUST NOT return only that, it also needs to include TS_IPV*_ADDR_RANGE selectors. I rather have the complications of processing TS_SECLABEL in the implementations that support it, and not cause all old implementations to suddenly be non-conforming as they do not follow this MUST added here: A responder MUST create each TS response by creating one of more (narrowed or not) TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE entries, plus one of each further TS_TYPE present in the offered TS by the initiator. If this is not possible, it MUST return a TS_UNACCEPTABLE Error Notify payload. I.e., that it MUST return all other TS_TYPEs or if it does not understand them it MUST return TS_UNACCEPTABLE... This makes adding TS_TYPES really hard in the future, as if we add TS_MY_TEST_TYPE, then every single implemenation will always return TS_UNACCEPTABLE to me if it does not support it, and I must do two exchanges one with it, and another without it if the first one fails. > 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. I think all TS types are "primary" except this TS_SECLABEL one as this is how RFC7296 defines them. y > > 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
Re: [IPsec] [saag] IETF 114 IPsecME report
Hi Paul, > > 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. This could be solved by adding only two new TS types TS_IPV4_ADDR_RANGE_WITH_CONSTRAINTS and TS_IPV6_ADDR_RANGE_WITH_CONSTRAINTS with a format that allows to add new constraints to the Traffic Selector. Something like: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS Type |IP Protocol ID*| Selector Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Port* | End Port* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Starting Address* ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Ending Address* ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Constraints* ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each constraint can be represented as an Attribute (it is also possible to introduce a dedicated structure) and all of them are treated with AND. This way we may add any number of additional restrictions to the base Traffic Selector. Regards, Valery. > > Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] IETF 114 IPsecME report
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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] IETF 114 IPsecME report
Hi Tero, few comments inline. [a lot of text snipped] > 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. 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. > 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. Regards, Valery. > -- > kivi...@iki.fi > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] IETF 114 IPsecME report
Paul Wouters writes: > On Fri, Sep 23, 2022 at 1:15 PM Paul Wouters wrote: > > On Mon, Jul 25, 2022 at 10:24 PM Tero Kivinen wrote: > > Labeled IPsec is ready for publication and > will be submitted to the IESG immediately after this IETF. > > This has still not happened. The Shepherd's write up looks done, so it > would be nice if you can push this to Roman. > > I said that 4 months ago :( > > Tero, please grab a coke zero and spend an hour to push this forward. Let's > not wait yet another IETF please. Sorry no coke zeros here, I only drink Pepsi-max at home :-) Anyways checking the document now, and first of question I have why it is standard track not experimental. The shepherd writeup says: As it is adding a Traffic Selector type, and updates the core IKEv2 specification in RFC 7296, the document is Standards Track. but even if it adds new traffic selector type, I do not really see any reason for it to be standard track it could be experimental. Also I am not sure it even updates RFC7296. It adds new traffic selector type, and adds new rules how that must be narrowed, but it does not affect any old implementations. Old implementations do not need to be changed because of this draft if they do not want to support this. Actually now when I am reading it I can see it provides all kind of incorrect updates to the RFC7296, that will BREAK old implementations. For example the section 1.2 A Traffic Selector payload (TS) is a set of one or more Traffic Selectors of the same or different TS_TYPEs, but MUST include at least one TS_TYPE of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. and section 1.3 The negotiation of Traffic Selectors is specified in Section 2.9 of [RFC7296] and states that the TSi/TSr payloads MUST contain at least one Traffic Selector type. This document updates the text to mean that the TSi/TSr payloads MUST contain at least one Traffic Selector of type TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE, as other Traffic Selector types can be defined that are complimentary to these Traffic Selector Types and cannot be selected on their own without TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. are wrong. The RFC 7296 says: Each TS payload contains one or more Traffic Selectors. Each Traffic Selector consists of an address range (IPv4 or IPv6), a port range, and an IP protocol ID. There is no mandatory text there, this is all just explaining what traffic selectors are. Implicitly there will be one traffic selector as the selectors are taken from the policy, and if we matched some policy then there must be something that we will fill in the Traffic Selectors, but even that is not required by RFC7296. The requirement that each "TSi/TSr payloads MUST contain at least one Traffic Selector of type TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE" is incorrect, and cannot be added to RFC7296 directly or in here. There is for example TS_FC_ADDR_RANGE, and it is completely valid to only include TS_FC_ADDR_RANGE types and no TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE selectors. The RFC4595 defines this TS_FC_ADDR_RANGE and it contains 24-bit addresses for Fibre Channel communications, and other fields which I assume can be narrowed using regular rules specified in the RFC7296 (as RFC4594 does not specify its own narrowing rules). Only the TS_SECLABEL selector defined in this document is "complimentary to these Traffic Selector Types and cannot be selected on their own without TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE." There can be other traffic selectors defined in the future which do not require TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE types at all, thus that kind of limitation cannot be done here. For example the IEEE Std 802.15.9 negotiating keys for the IEEE Std 802.15.4 does not use TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE at all, as there is no IP-addresses there. Currently it does not define its own TS_TYPEs, it simply says we use Childless Initiation of IKEv2, thus there will not be TS payloads, and it will derive pairwise key between the two devices using SK_d and nonces. In the future there might be need to actually specify addresses also, and then they would need to come in IETF and specify new TS_TYPE to be used there. 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. So I do not think this document should update RFC7296 at all, so most of the section 3 is wrong. The first bullet in section 3 is wrong, and second is already allowed by RFC7296, there nothing that says there cannot be one more more other TS_TYPES, thus it is not needed. Section 3 should most likely say something like this: The TS_SECLABEL cannot be used alone as it does not specify traffic selectors completly, it is just complimentary to other traffic selectors.
