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
