Subject: [IPsec] How to negotiate a new capability with parameters

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Wed, 20 May 2015 12:13:33 +0000

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 20 May 2015 15:38:06 +0300

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 considering using configuration attributes instead of Notify 
> Payload but we are not sure this is an adequate message type.
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 May 2015 15:49:01 +0300

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-masked]> wrote:
> 
> Hello,
>

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Wed, 20 May 2015 13:57:54 +0000

Thanks!

Sent from my iPad

> On 20 May 2015, at 14:49, Yoav Nir <[email-masked]> wrote:
> 
> Hi, Frederic
>

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Wed, 20 May 2015 14:04:25 +0000

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 <[email-masked]> wrote:
> 
> Hi Frederic,
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 27 May 2015 00:52:11 +0300

Yoav Nir writes:
> 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.

Actually in both IKEv1 and IKEv2 you use VendorIDs if you use private
use number space. I.e. if you decide to use private use notify number,
or private use payload numbers then you need to sue VendorIDs in the
IKE_SA_INIT before you send those private use values. I.e. the Vendor
IDs are used to identify whose private use numbers you are using.

The reason in IKEv2 we mostly use real IANA allocated status
notifications is that the status notifications in the IKEv2 have IANA
allocation policy of Expert review, i.e. they are easier to get. For
IKEv1 the allocation policy was Specification required, which means
you need to have some kind of public specification (RFC or similar)
before you can get those.

So because getting new status notifications is easier in IKEv2, we
have added lots of features negotiated using them. As they have been
used so much for extensions, they also have the benefit of backward
compatibility, i.e if other end does not support them, implementations
will simply ignore them (i.e. I would say all implementations knows
how to ignore unknown status notifications).

> Whether the parameters are passed in new payloads,

Using new payloads might break some implementations, even when the
specification says they should not break, but as they are not used
that much in IKEv2 now, this is not something that vendors test
against. 

> 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.

Lots of implementations support very fixed format for configuration
payloads, and even though the IKEv2 format allows them to be used in
different ways, most of the implementations only support very limited
set of operations for them. 
-- 
[email-masked]