Paul Hoffman writes:
> > No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same
> > IANA values for two different non-interoperable uses of the groups, I
> > cannot say there is enough interoperable use for that RFC.
>
> Nor can you say that there is *not* enough interoperable use. As
> others have pointed out, there are lots implementations, and as far
> as I have heard, all current implementations are using RFC 5930.
I agree there is enough interoperable implementations, I do not know
if they are "widely used". As far as I know people are still using
MODP DH groups when they are actually using IKEv2 in the field.
> > I have recommended everybody not to use them, as you never know if
> > they work, as you do not know if the other end is upgraded to Errata
> > version of 4753 (i.e. RFC5903).
>
> That's fine if you want to recommend it; many implementors are
> ignoring you and interoperating just fine.
Again I did not recommend implementors not to implement it or fix
their code to use RFC5930 way of doing thigs, I was recommending users
not to use them unless they are sure all their environment is updated
to latest versions (which usually is not the case).
You are confusing the "use" vs "implementation" here. There needs to
be "widespread deployment and successful operational experience.", and
that at least for me would mean that actually would need to use that
feature, not just that it might be complied in to the implementation.
> That may all be true, but it is also irrelevant to whether the RFC
> itself should advance. The IANA values are not in question: only the
> bits on the wire are covered in the RFCs. The bits on the wire in
> RFC 5930 are highly interoperable, as shown by many different
> implementations (possibly even yours).
And how does that point there is "successful operational experience"
for those groups?
When I went through the list of IPsec related standards I used
following criteria for it:
1) It is widely implemented
2) It is widely used
3) If document does not have errata, it is easy to upgrade.
The RFC6410 lists following ones:
(1) There are at least two independent interoperating implementations
with widespread deployment and successful operational experience.
(2) There are no errata against the specification that would cause a
new implementation to fail to interoperate with deployed ones.
(3) There are no unused features in the specification that greatly
increase implementation complexity.
(4) If the technology required to implement the specification
requires patented or otherwise controlled technology, then the
set of implementations must demonstrate at least two independent,
separate and successful uses of the licensing process.
The first one covers my case 1 and 2. My case for 3 is more strict, as
(2) only requires there is no errata that would cause implementation
to fail. The errata in RFC4753 was definately such, the errata to
RFC5903 is not. (3) and (4) should not be problem for it.
This for example one reason I do not think we can put some of the
other ones forward either. I.e. following ones are standard track, but
even if some of them do have enough implementations, I do not think
they are used widely enough yet:
MOBIKE (4555), ECDSA (4754=>5903), OCSP extensions (4806), AEAD for
IKEv2 (5282), redirect (5685), session resumption (5723), EAP only
athentication (5998), Quick Crash Detection (6290), High Availibility
(6311).
> <hat on="yes">
>
> Do others in the WG feel that the issues Tero brought up are
> significant enough to prevent RFC 5930 from advancing on the
> standards track?
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
