IETF Logo Mail Archive

[IPsec] Vendor Identifiers

Russ Housley <housley@vigilsec.com> Wed, 11 March 2015 18:54 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD1E1A0056 for <ipsec@ietfa.amsl.com>; Wed, 11 Mar 2015 11:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBKvkoT18sYj for <ipsec@ietfa.amsl.com>; Wed, 11 Mar 2015 11:54:22 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D75831A003B for <ipsec@ietf.org>; Wed, 11 Mar 2015 11:54:21 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9BC469A4021 for <ipsec@ietf.org>; Wed, 11 Mar 2015 14:54:11 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id QCVsgbeT--HU for <ipsec@ietf.org>; Wed, 11 Mar 2015 14:54:11 -0400 (EDT)
Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3DAD59A401E for <ipsec@ietf.org>; Wed, 11 Mar 2015 14:54:11 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Mar 2015 14:54:00 -0400
Message-Id: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com>
To: IETF IPsec <ipsec@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/Yj2ZAbBdXnTs5puuPxNb9xTH4bA>
Subject: [IPsec] Vendor Identifiers
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 11 Mar 2015 18:54:23 -0000

About two years ago, I was at a workshop where someone claimed that the Vendor Identifiers that are exchanged in IKE are very useful for dealing with bugs.  The claim was that following the report of a bug, others could adjust their behaviors to avoid the circumstances that enable the bug.  In the worst case, they could refuse to talk to the badly broken version, but accept connections to later versions where the bug has been repaired.

Does anyone have operation experience doing this kind of thing?  I want to know if is real experience or speculation about what could be done.

Thanks in advance,
  Russ

v2.23.0 | Report a Bug | By Email