[IPsec] IKEv2 vendor-specific payload

"Alper Yegin" <alper.yegin@yegin.org> Thu, 11 March 2010 16:58 UTC

Return-Path: <alper.yegin@yegin.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A9B3A6ACD for <ipsec@core3.amsl.com>; Thu, 11 Mar 2010 08:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level:
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWTHwyx6IIwe for <ipsec@core3.amsl.com>; Thu, 11 Mar 2010 08:58:38 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 222393A6951 for <ipsec@ietf.org>; Thu, 11 Mar 2010 08:50:57 -0800 (PST)
Received: from ibm ([193.153.155.170]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MO6v6-1NmRgL3rDo-005Vqy; Thu, 11 Mar 2010 11:51:02 -0500
From: Alper Yegin <alper.yegin@yegin.org>
To: 'ipsec' <ipsec@ietf.org>
Date: Thu, 11 Mar 2010 18:50:42 +0200
Message-ID: <00e601cac13a$feeed790$fccc86b0$@yegin>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01CAC14B.C277A790"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrBOvbDlhuTO80ORuqQSKbz1CMwSg==
Content-Language: en-us
x-cr-hashedpuzzle: AEEt BLNG Bpwj C6hW DFNs D0v/ EewH Fox1 FyYL GGo4 H74X IPzT Id5Y IkUN IoY9 LQOX; 1; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {34496911-DD1C-4CE9-B89B-A8E777AD9D50}; YQBsAHAAZQByAC4AeQBlAGcAaQBuAEAAeQBlAGcAaQBuAC4AbwByAGcA; Thu, 11 Mar 2010 16:50:32 GMT; SQBLAEUAdgAyACAAdgBlAG4AZABvAHIALQBzAHAAZQBjAGkAZgBpAGMAIABwAGEAeQBsAG8AYQBkAA==
x-cr-puzzleid: {34496911-DD1C-4CE9-B89B-A8E777AD9D50}
X-Provags-ID: V01U2FsdGVkX197ynoOX5XDOM7yp66DokjTcVgiQNiDV/4OaSB WDfbjAqffdEhtbAvpscTEJtLcASSPmuz9s2mrvoOT0zGK+fgnk W7Y3ziVqizX6ogRa4c2cRJdjDiWmNZ+
Subject: [IPsec] IKEv2 vendor-specific payload
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2010 16:58:42 -0000

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