Re: Vendor Extensions

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Charlie" == Charlie Kaufman <Charlie_Kaufman@notesdev.ibm.com> writes:
    >> Steve Bellovin, Security Area Director, strongly commented that any
    Charlie> drafts
    >> that contained specific vendor extensions would cause the IESG to be
    >> concerned and may even cause it to be rejected.  He states this in his
    >> capacity of Area Director, not as a co-author of the JFK draft.

    Charlie> Could we get clarification of IESG policy on vendor extensions and also
    Charlie> feedback from the working group on their usefulness? IKEv1 contains
    Charlie> an optional field called "Vendor Extensions" that a compliant
    Charlie> implementation is

  No, that's not correct. Payload #13 is Vendor ID.
  The Vendor ID qualifies the private use space.

  Charlie, Tero Kivinen and I suggested the current text back in early '97.

    Charlie> It does not contain any registry of values assigned to any specific
    Charlie> vendors.

  Nor need it, since the suggested values for the Vendor ID payload are
MD5-hashes of version strings. They can in fact be anything, but since there
are at least 96 bits of them, collision is unlikely. What you *CAN NOT* do is
use more than one extension space.
  In general, this was suggested as a mechanism for vendors who had buggy
products in the field to recognize the buggy product and enable "workaround
code". This eliminates the problem where you can't fix the bug to become
interoperable because doing so would screw the people who actually give you
money. 

  There was some feeling at the time that having an official list of
implementations such that we could have such a registry would not be
desirable to some - in particular to people in various research groups who
might want to innovate without annoucing their existence.

    Charlie> I don't know whether anyone uses this field in IKEv1. We copied it in IKEv2
    Charlie> since is seemed at least potentially useful without introducing any threats
    Charlie> to
    Charlie> interoperability of compliant implementations.

    Charlie> My questions are:

    Charlie> 1) Is anyone using the field in IKEv1?

  In practice it has been used extensively for testing of new features. In
part this is due to the lack of a critical bit in the payloads. 

    Charlie> 2) Does anyone (besides me) feel the field is useful enough to leave it
    Charlie> in IKEv2?

  Yes. We must have a way to innovate. This means either PPP-style vendor
extension fields (probably stealing the PPP vendor space), or maintaining
VID. I'm indifferent to which is done, but we need a way to qualify that when
MCR's code says "magic payload 40045" it means something different than 
when Charlie's code says "magic payload 40045"

    Charlie> 4) Is there some IESG policy that we should be aware of that might override
    Charlie> working group consensus on the utility of such a field.

]    Internet Security. Have encryption, will travel           |1 Fish/2 Fish [
]  Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F [
]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [
]    At the far end of some dark fiber - wait that's dirt!     |for everyone  [
  
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPT4DOYqHRg3pndX9AQFKnQQAjijvwsvLswdXRPn/bOgHVSXJldF0R0/q
QJuNHVUJN8DWzToT4sb5eS7wFRUBB/kTctui3d8kqwYY8+O/FWsjhsZA58n/MI4q
yDAooZz8WL1IOURstpEjkX2EvKoLgyyJyP6Z4onWalJyYMvxDjCm0baJ68tWPaC6
KwbjG6KNeLg=
=SXFH
-----END PGP SIGNATURE-----