Hi Tero, first, I'm not against using new TS accommodating seclabels. It is the most pure way to go from theoretical PoV. The only concern with this approach is that the number of TS types will be growing up.
Another approach - use some new status notification containing seclabel that the initiator would include in any request to create Child SA. This is easy to implement, but there is a possibility, that unsupporting responder will just ignore this notification and create SA w/o proposed seclabel. In this case the initiator would need to immediately delete this SA. My proposal only deals with this situation. If initiator and responder exchange SECLABELS_SUPPORTED notifications at the time of creating IKE SA (in IKE_SA_INIT), then the initiator will know, whether the responder supports seclabels or not. And if the responder supports seclabels, it will not be able to ignore notification (of other type) indicating the desired security label at the time Child SA is created (in IKE_AUTH or in CREATE_CHILD_SA). So you misunderstood, there is no any timeouts, there is clear indication for the initiator of whether the responder supports this feature (and thus it's OK to use it) or not (in which case depending on the initiator's policy the communication may or may not be possible). Again, I'm fine with either using new Traffic Selectors or Notify for this purpose. Both have pros and contras. Regards, Valery. > Valery Smyslov writes: > > In our case the strategy for initiator is: retransmit and wait. > > If even after several retransmission it doesn't receive message > > with SECLABELS_SUPPORTED, then there is no reason to continue > > with IKE_AUTH (if using labels is mandatory for initiator). > > If it receives a message with SECLABELS_SUPPORTED, then go with it. > > Which means configuration errors result in timeout instead of getting > clear error message that there is configuration error. > > I.e., when initiator changes configuration and add > SECLABELS_SUPPORTED, and then tries to connect SGW, instead of getting > error message saying SECLABLES were not supported by other end it will > result in unauthenticated error messages and then finally timeout. > > I always prefer to get proper authenticated error message from the > other end for configuration errors. I.e., if we instead propose > traffic selectors with SECLABELS and we should get TS_ACCEPTABLE error > message from the responder and that clearly indicates that there is > configuration error. > > >From the RFC7296 section 2.9: > > ---------------------------------------------------------------------- > .... > If the type of Traffic Selector proposed is unknown, the responder > ignores that Traffic Selector, so that the unknown type is not > returned in the narrowed set. > .... > The responder performs the narrowing as follows: > > o If the responder's policy does not allow it to accept any part of > the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE > Notify message. > .... > ---------------------------------------------------------------------- > > I.e., if the other end does not support TS type containing labels, it > will ignore them and not include them in the narrowed set. If the > narrowed set becomes empty because of that it will return > TS_UNACCEPTABLE error message to the initiator and that gives clear > feedback that there is configuration error. > > This is much more preferred than waiting for some time and then after > timeout decide that there might have been configuration error... > -- > 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
