Paul Hoffman writes:
Partially yes, but unfortunately all of the authors of those actual
protocols decided that they wanted to continue publishing those drafts
as individual RFCs, and each of them used different way to negotiate
them, so there was no way to even implement multiple of them.
Is this true? Because each has it's own way to negotiate its use,
one should be able to implement multiple of the competing proposals
as-is, yes?
Before I proposed my common way to negotiate only one of the proposed
protocols included any kind of support for indicating which version is
used. The other two just assumed that initiator selects the method and
responder supports it without any negotiation, meaning there was no
way to make initiator version which supports multiple methods without
trying the first method, if that failed, then starting IKE_SA_INIT
from the beginning and trying second method etc...
This has already been changing as one of the drafts is already changed
to support what I have described in my draft, and another author
has said he will update his. The third one already had negotiation
altough done bit differently to compared what I proposed.
As an implementor I myself I want to keep this problem concentrated in
my code, meaning I do not want to make three completely differently
done implementations for the same thing, when I can instead make
generic changes to common code once, and separate the secure password
method related processing in one module taking care as any methods
needed to be implemented.
At least this drafts gives you that option to implement multiple of
them if you want. This draft only provides instructions for those
other draft authors so they can at least common methods to negotiate
the feature and use common method to trasmit data between peers.
True, but it is still punting the problem of us having just one.
Yes, but there is nothing I can do to that. I cannot fix the problem
that all 3 drafts were sent forward and most likely will be published.
If someone will decided only one of them will go forward (and there
will not be any other ever) then my draft will be mostly unneeded as
all of my draft can be put inside that one protocol draft going
forward just like draft-shin-augmented-pake has already done.
If there is no need to make sure multiple drafts make the negotiation
and common payload things similarly as there is only one draft, then
this draft is not needed.
I am also the IANA expert for the IKEv2 registries, and that was the
main reason I wanted to have common way to do things instead of doing
dozen new allocations to the registries just to support 3 bit
different ways to do same thing (when 3 allocations is enough). I
wanted to point this out to the draft authors as early as possible, so
it will not come as suprise to the authors that I do not support their
way of allocating that many codepoints from the registries.
--
kivinen(_at_)iki(_dot_)fi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf