Hi Frederic,
in IKEv2 the BCP is that optioal capabilities are negotiated
via exchange of Notify Payloads with the type from Status Types range.
These notifications must be ignored by unsupported implementations,
so there is no harm if they are present in IKE Message.
Vendor ID can also be used for this purpose, but
Notify Payloads usually win in terms of compactness
and fine-grained capability negotiation.
What about your scenario - I don't know the details,
but it seems to me that step 1 is not needed.
The presence of Notify Payload with the parameters
in Message 3 (IKE_AUTH Request) will serve as an
indication for the responder that the initiator supports
these new capabilities. If the responder doesn't support
them, it will include no such Notify Payload in response,
if it does - it will respond with that Payload with the needed
parameters. I could have missed something due to the lack
of details you have given, but as you described it must be worked.
Regards,
Valery Smyslov.
Hello,
we would like to implement new vendor specific capabilities under IKEv2.
This capability requires argument passing. These arguments should be
protected (encrypted and signed).
We were wondering what was the cleanest way to do this.
What seemed the most logical is
1- negotiating capability in message 1/2 via a Vendor-ID payload
2- if both peers support capability, exchange parameters via Notify
Payloads in message 3/4 or later
We were considering using configuration attributes instead of Notify
Payload but we are not sure this is an adequate message type.
Can someone give us an advice ?
thanks,
Frederic Detienne
_______________________________________________
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
