Re: [IPsec] IKEv2 vendor-specific payload

[<[e-mail]>]

Hi Alper

I guess the preferred route is *not* defining vendor-specific
configuration attributes, but instead publishing the spec and getting 
an IANA-allocated number :-) (note that this doesn't absolutely
require publishing it as RFC, or going through the whole IETF
process)

But if you use numbers from the "private use" range, you need to 
use  the Vendor ID payload. I guess the approach would be something
like:

- pick a vendor ID; often specs have used e.g. the MD5 hash of some
unique string (like "draft-foo-05" or "http://intranet.example.com/
some/spec/" -- you don't have to tell what the string was) to avoid
collisions with others. Something like a 16-byte random value would 
work well, too.

- peer A needs to send this VID to B before B can send any of
the vendor-specific configuration attributes to A. Concretely, 
  (1) if the vendor-specific attribute can be included in
  CFG_REQUESTs (usually they can), the VPN gateway needs to 
  include this VID in IKE_SA_INIT response.
  (2) the client needs to include this VID either in the  
  IKE_SA_INIT request or 1st IKE_AUTH request (latter is 
  probably preferred)

- pick random number(s) from the "private use" range (16384-32767)
for your configuration attributes.

Best regards,
Pasi
(not wearing any hats)

-----Original Message-----
> From: Alper Yegin
> Sent: 11 March, 2010 18:51
> To: 'ipsec'
> Subject: [IPsec] IKEv2 vendor-specific payload
> 
> Hello,
> 
> What is the recommended approach for defining vendor-specific
> configuration payload with IKEv2?
>
> According to my reading of RFC 4306, there is a bit of a room
> there. Vendor ID payload is not mandatory to use in such a case. And
> even when it is used, the VID can be anything (there is no mandate
> for using Enterprise ID, or anything that is globally managed).
>
> Other protocols I'm familiar with are more strict about defining
> vendor-specific options/payloads.
>
> So, it makes me wonder if there are some current practices that we
> should use when defining new payloads.
> 
> Thank you.
> 
> Alper