Hi Yaron,
First, I raised a third concern, which is that allowing the client to
decide on the difficulty of the puzzle it is willing to solve adds
unneeded complexity. Basically the client doesn't have enough information
to make a good decision.
The problem is that the server doesn't have
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
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
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
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
Thanks!
Sent from my iPad
On 20 May 2015, at 14:49, Yoav Nir ynir.i...@gmail.com 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
