Thanks! Sent from my iPad
> On 20 May 2015, at 14:49, Yoav Nir <[email protected]> wrote: > > 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
