Subject: [IPsec] Vendor Identifiers

From: Russ Housley <[email-masked]>
Date: Wed, 11 Mar 2015 14:54:00 -0400

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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Mar 2015 15:44:35 -0400 (EDT)

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

Although it is more used in the reverse. Vendor X supports a feature
and adds a VID that will use it when seen. Now other vendors will have
to send that VID to interoperate. What some call feature others call bug
of course:

Example 1:

                 /* If state has VID_NORTEL, import it to activate workaround */
                 if (md->nortel) {
                         DBG(DBG_CONTROLMORE, DBG_log("peer requires Nortel Contivity workaround"));
                         st->st_seen_nortel_vid = TRUE;
                 }

[..]

                 /*
                  * If we are the responder and the client is in
                  * "Contivity mode",
                  * we need to initiate Quick mode
                  */
                 if (!(smc->flags & SMF_INITIATOR) &&
                     IS_MODE_CFG_ESTABLISHED(st->st_state) &&
                     (st->st_seen_nortel_vid)) {
                         libreswan_log("Nortel 'Contivity Mode' detected, starting Quick Mode");
                         change_state(st, STATE_MAIN_R3); /* ISAKMP is up... */
                         set_cur_state(st);
                         quick_outI1(st->st_whack_sock, st, st->st_connection,
                                     st->st_connection->policy, 1, SOS_NOBODY
                                     );
                         break;
                 }

                 /* wait for modecfg_set */

Another example illustrated by the man page of ipsec.conf on libreswan:

        cisco-unity
 	whether to send a CISCO_UNITY payload to the peer. Acceptable
 	values are: no (the default) and yes. It is recommended
 	to leave this option unset, unless the remote peer (Cisco
 	client or server) requires it. This option does not modify
 	local behaviour. It can be needed to connect as a client to a
 	Cisco server. It can also be needed to act as a server
 	for a Cisco client, which otherwise might send back an error
 	DEL_REASON_NON_UNITY_PEER.

I know we had something with SOFTREMOTE as well, but I don't think we
detectd it via VID - it had to be a compile time option.

Paul

---

From: <[email-masked]>
Date: Wed, 11 Mar 2015 19:50:10 +0000

In our work we have not encountered any situations where the Vendor Identification was relevant.

	paul

> On Mar 11, 2015, at 2:54 PM, Russ Housley <[email-masked]> wrote:
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Mar 2015 23:23:58 +0200

> On Mar 11, 2015, at 8:54 PM, Russ Housley <[email-masked]> wrote:
> 

I haven’t encountered this kind of use of a VendorID. Years ago there was a push by auditors for vendors to stop revealing their versions in protocols. As a result, our VendorID has not changed in ten years. I suspect the same is true for other vendors. So if a bug is fixed, the VendorID is not changed. I don’t believe the VendorID is a good way to identify buggy implementations.

Yoav

---

From: <[email-masked]>
Date: Wed, 11 Mar 2015 23:38:32 +0000

> On Mar 11, 2015, at 5:23 PM, Yoav Nir <[email-masked]> wrote:
> 
> 

As for buggy implementations, I think that it isn’t needed for that.  If someone has a bug that breaks interoperability, we would in general take the view of “if they fix it, it will work” — in other words, vendors normally don’t take on the job of working around someone else’s mistakes.

Interesting story about auditors.  I haven’t run into any such thing.  I would hope that most auditors have more sense than that.

	paul

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Mar 2015 02:02:57 +0200

> On Mar 12, 2015, at 1:38 AM, [email-masked] wrote:
> 
>> 

Unfortunately, it’s far easier to stop sending the version than to argue against this.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2679

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Mar 2015 20:26:50 -0400 (EDT)

On Wed, 11 Mar 2015, [email-masked] wrote:

> As for buggy implementations, I think that it isn’t needed for that.

I agree with that.

>  If someone has a bug that breaks interoperability, we would in general take the view of “if they fix it, it will work” — in other words, vendors normally don’t take on the job of working around someone else’s mistakes.

That I don't agree with. For openswan/libreswan I have done plenty of
workarounds or additional checks. It is just that usually the bugs are
clear enough that you do not need a vendorid to figure it out.

For instance:

commit f853f44177155f75ff2910a8fe2b96d95f8050e5
Author: Paul Wouters <[email-masked]>
Date:   Wed May 14 10:22:45 2014 -0400

     DPD: openbsd isakmpd bug workaround for duplicate DPD seqno

     openbsd mistakenly re-uses the same DPD sequence number when its DPD
     probe did not receive an answer. If the probe hit the other endpoint,
     but got lost on the return, it means openbsd sends a duplicate DPD seqno,
     which according to RFC 3706 Section 7 "Security Considerations" we detect
     as a replayed packet that we drop.

     This patch introduced the same kludge openbsd uses to interop with
     itself. That is, we allow and answer 3 dupliates before we remain quiet
     and assume it is a DDOS attack.

     If you read this and have openbsd commit access, please do:

     isakmpd/dpd.c around line 350:

     - ISAKMP_NOTIFY_STATUS_DPD_R_U_THERE, isakmp_sa->dpd_seq);
     + ISAKMP_NOTIFY_STATUS_DPD_R_U_THERE, isakmp_sa->dpd_seq++);

We could have done this based on VID, but why not do it directly on the
bad DPD seq_no.

Our IKEv1 code is full of these gems. Writing one from scratch according
to spec will cause you to have to relearn years of interoperability
bugs.

Even today, I found a bug in whatever IKE daemon Amazon AWS is using,
although in this case, there is just no practical workaround because
it is just too broken:

https://libreswan.org/wiki/Interoperability#Multiple_tunnels_fail_with_Amazon.27s_VPN

So, while some vendors might be able to say "fix your stuff", the
opensource people don't often have that luxury. Or, perhaps it is
because we _do_ have the luxury of writing new code :)

Paul

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Thu, 12 Mar 2015 02:09:31 +0000

On 3/11/15, 11:38 PM, "[email-masked]" <[email-masked]> wrote:

>As for buggy implementations, I think that it isn’t needed for that.  If 
>someone has a bug that breaks interoperability, we would in general take 
>the view of “if they fix it, it will work” — in other words, vendors 
>normally don’t take on the job of working around someone else’s mistakes.

It probably not just for work around of someone else mistake, but also for 
your own implementation that has bugs. Even though issue is fixed in newer 
release, for a large customer, it may take to time to upgrade to latest 
version, based on the size of the deployment. As a work around, to 
facilitate software upgrade, vendor-id trick could be ideal. It is a 
temporary work around and not permanent. Thus including a software version 
in vendor-id would be ideal for such issue.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Mar 2015 10:02:50 -0400

<[email-masked]> wrote:
    > If someone has a bug that breaks interoperability, we would in general
    > take the view of “if they fix it, it will work” — in other words,
    > vendors normally don’t take on the job of working around someone else’s
    > mistakes.

Hahaha, that's really funny.
I guess you don't need to interop with anything you didn't buy.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Mar 2015 10:08:57 -0400

Russ Housley <[email-masked]> wrote:
    > 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.

I'm surprised it was only two years ago.
This is the argument that I made for VendorID with I wrote it up back in 1997.
I invented this while working at SSH on the IKEv1 system there, and we did
use it for short periods of time to work around things we couldn't fix
without a flag day.

I agree that this hasn't gotten much use by the "major" VPN vendors, and I
note that we still have code to work around their bugs, and those bugs often
are still seen in the field on a regular basis.  The vendor ID string is
supposed to be opaque and seemingly random.

The VendorID was then also used to qualify use of private use types.

I'm sad that the audit people think that knowing the version enables attacks,
as opposed to: knowing the version enables one to proactively repair things.
It seems like an argument for classifying encryption algorithms to me.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 13 Mar 2015 09:51:29 +0300

Hi Russ,

it is not exactly as you described, but very close. When RFC is unclear
fifferent vendors treat it differently. IKEv1 had quite a lot of moot 
places,
much fewer are in IKEv2. Anyway, when you try to interoperate you
sometimes encounter a situation when your peer behaves very-very strange
in some cases (from you point of view, of course). Let's not call
it a bug, but more mildly - a feature. Anyway, if interoperability
is broken, major vendors might not care, but smaller vendors have
to deal with it. And in this situation Vendor Identifiers (and any other
information that could help indentify the peer) are really used to adjust
your behaviour to get interoperability.

Regards,
Valery Smyslov.

> 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
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec