Thanks Valery, We are negotiating experimental keep-alive methods and a protected address must be exchanged between the peers. This is why we wish to cover the exchange.
We will go with a simple protected Notify in the Status Type range. Thanks again and best regards, Fred > On 20 May 2015, at 14:38, Valery Smyslov <sva...@gmail.com> wrote: > > 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
