On Wed, 11 Mar 2015, Russ Housley 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.

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

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to