[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Vendor ID issues


  Bob and I have had a number of discussions about the Vendor ID payload.
  ICSA testing has revealed that quite a number of people are
uncertain about what the VID is for.

  I have produced a BCP that provides a longer example of how to
use it. I do not pretend it is complete. The BCP missed last Friday's
deadline due to lack of proper boilerplate. I have proposed to Ted to
take 15 minutes of IPsec meeting time to try and lead a discussion
about what VID is for. 

  Bob and my most recent exchange is below.

>>>>> "Robert" == Robert Moskowitz <rgm@icsa.net> writes:
    Robert> This highlights the whole problem with Vendor ID.
    Robert> Consider:

    Robert> Vendor X develops the foo extenstion to IKE and ships it
    Robert> with release 5.6 of XOS.

    Robert> Vendor Y enters into an agreement with X and supports foo
    Robert> in release 3.4 of YOS; meanwhile XOS is upgraded to 5.7 to
    Robert> recognize Vendor ID Y.

    Robert> However, Y was smart, realizing that many X customers
    Robert> would not be so fast to upgrade.

  I'm missing a sentence here. What did Y do to be smart?

    Robert> If X was the intiator, Y would go right into foo mode and
    Robert> not bother to send its ID.

  That isn't according to spec. Y should still send its VID. 

    Robert> If Y was the initiator, and X rejected Y's ID, when Y
    Robert> receives X's ID, Y would still do foo.

  If X sends a VID, then it should assume that whomever it is talking
to can send extensions *TO* it using the private use space. The fact
that X does not recognize Y's VID means that X may be unable to
respond. Possibly that calls for a specific notify message. But, some
payloads may not require responses anyway.
  The private use spaces are unique to the *receiver* of the payload.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface