Hi, Frederic That sounds mostly correct.
In IKEv1 capabilities were usually declared in VendorIDs. In IKEv2 they are mostly declared in notifications within IKE_SA_INIT. Why the difference? No idea. It’s just the way other extensions were done, but with a private extension you can do either. Whether the parameters are passed in new payloads, notify payloads or Config attributes is a matter of taste. Generally, Config attributes are mostly for remote access and have request-response semantics, so they’re somewhat negotiable. Notifications are for something one side declares which is not negotiable, and new payloads are hardly ever used. Note though, that in the IKE_AUTH exchange, the peer is not yet authenticated. So depending on how sensitive the content of the parameters is, you might not want to send it at that point. The IKE SA at that point protects against passive eavesdropping and message modification only. Yoav > On May 20, 2015, at 3:13 PM, Frederic Detienne (fdetienn) > <[email protected]> wrote: > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
