[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Vendor ID issues
I had a similar exchange with Bob over this. I don't know why ICSA
is testing this stuff. They're having enough trouble just figuring out
how to test main mode with pre-shard keys! As far as interoperability
is concerned, if you barf upon receipt of a vendor ID payload you don't
recognize then you're broken.
draft-ietf-ipsec-isakmp-mode-cfg-04.txt (yea, it's expired but it
helps me make a point) defines the use of an exchange and payload from
the reserved areas. This is wrong. I-Ds can't just start grabbing numbers
from the reserved numberspace. The vendor ID payload is used to fix this
problem. The draft should've defined numbers from the private use range
and defined a vendor ID payload to use for implementations that wish
to implement and test this new mode. If the peer does not produce the
required vendor ID payload then you can't initiate the mode to it. When
the I-D advances it can be assigned valid exchange and payload numbers
by IANA and the verbage discussing the vendor ID payload to use for
testing can be dropped. But that didn't happen. :-( Now we have several
implementations of this draft that use reserved magic numbers.
The BCP is definitely needed before this is repeated. Can you post it
to the list?
Dan.
On Tue, 09 Mar 1999 18:06:53 EST you wrote
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> 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.
Follow-Ups:
References: