[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: new draft-ietf-ipsec-isakmp?
Roy Pereira writes:
> FYI: <draft-ietf-ipsec-isakmp-cfg-01.txt> defines a mechanism for
> exchanging this type of information without defining a new payloda and
> its values can be any length, not just 96 bits.
I assume you mean draft-ietf-ipsec-isakmp-mode-cfg-01.txt? I think
the vendor-id and cfg-mode mechanism are for different things. The
vendor-id payload is to tell the other end that if we use private
extensions later this can be used to detect who's extensions I am
using. The configuration mode can be used to exchange configuration
stuff with two hosts.
The configuration mode has the same problem than normal modes, because
if I want to send some private attribute to other end and that
attribute has no meaning outside our own implementation, I cannot send
it by using configuration mode unless I allocate global identifier for
it. I cannot use private range because we cannot know if the other end
is our own implementation or not, and that other implementation might
use that exactly same number from private range to something else.
The meaning of private range has no sense if I need to allocate those
numbers globally.
Vendor-ID payload is there to provide information who's private number
space / extensions we are using.
> >> If Vendor ID(s) are sent, they MUST be sent during the Phase I
> >> exchange. [comment please! MCR]
I think it is good to restrict them to Phase I, because it makes thing
simplier. And if someone wants to use something like that in Phase II
the can first use Vendor ID payload in Phase I and if they detect
their own implementation at the other end they can use some private
extensions or something to get same results than using vendor id (for
example configuration mode or some other notify payload using private
number space).
> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> ! Next Payload ! RESERVED ! Payload Length !
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> ! !
> >> ! VENDOR ID: 96 bits !
> >> ! !
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >Does this have to be 96bits? Since a payload length is included can't this
> >just be an opaque blob whose length is determined by the payload length
> >field?
I think it might be simplier to just allow it to be any length, and
not to restrict to 96 bits. There is no reason to truncate it and if
someone wants to use hash truncated to 96 bits he can do it.
BTW. I think the notify codes in the configuration mode (101-104)
should be renumbered out from the error types range (1-8192). They are
not really error types so I think something from the status types
range (16384-24575) is better.
--
kivinen@iki.fi Work : +358-9-4354 3207
Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573
Follow-Ups:
References: