Hi Daniel,
That seems to be part of the problem. The IETF isn't in the business
of dictating
administrative behavior through normative language. Protocols comply.
People can use
compliant protocols or not, and if they decide to use protocols which
are non-compliant,
or if they use proprietary protocols, it doesn't make them somehow
"non-compliant".
This effort seems to have gained steam due to developers being told
by their project
management co-workers to do things to their IKEv1 code which they did
not think was
appropriate given the state of IKEv2. I can certainly relate to such
difficult interactions.
That said, the give-and-take of engineering and project/product
management is not really in
the IETF's bailiwick. If people want to take an RFC to the
project/product management
team and say, "look, the IETF has spoken!" then good luck, but that is a
misuse of the
imprimatur of the IETF and don't try and standardize _that_ behavior.
We can move a standard to historic. We can decide not to do any more
development on it.
We can't force people to do anything and we can't declare they are
"non-compliant" if
they decide to use a protocol we don't approve of.
It's interesting how SCEP has survived and actually thrived despite
its restricted
use and it's well-known security problems when EST, an IETF standard,
exists. People
strung the SCEP draft through multiple dozens of versions, dragging it
out, it was made
historic as a sop to this effort yet people still want to use it. I
don't understand but
a very large vendor of tablet and phone hardware/software (who
ironically stole their OS
name from the company that developed SCEP) decided to use it in their
BYOD offering
and so product/project management teams all say we must continue to use
SCEP and update
our SCEP code in order to work with these products that we can't avoid
due to their
massive market share. Sure, continued use of IKEv1 is a problem but it's
a molehill
compared to the mountain of today's use of SCEP. Yet here we are.
Dan.
On 6/29/21 11:17 AM, Daniel Migault wrote:
I thought the purpose of the draft was to be able to say "look at this
document it says you MUST switch to IKEv2 if you want to remain IPsec
interoperable. I am suprised I do not see the MUST in question. I am
fine whatever chair/co-authors are fine with.
Yours,
Daniel
On Tue, Jun 29, 2021 at 2:00 PM Yoav Nir <ynir.i...@gmail.com
<mailto:ynir.i...@gmail.com>> wrote:
[no hats]
I don’t want to start (or resume) a religious holy war about
uppercase MUSTs, but they’re usually about protocol compliance.
What people should (not SHOULD) do with their systems is not
subject to requirements language, because the IETF does not
engineer administrators. What? You are not compliant with RFC xxxx
if you didn’t upgrade your systems already?
I could understand a statement that Product yyyy is not compliant
with RFC xxxx because it still offers IKEv1, but I don’t like
non-compliant administrators. Not that I’m advocating to add that
statement to the draft. I think it’s fine as it is: just offering
advice that systems should be upgraded.
Yoav
On 29 Jun 2021, at 17:21, Daniel Migault <mglt.i...@gmail.com
<mailto:mglt.i...@gmail.com>> wrote:
I believe that the first sentence of section 3 says it all. ship it!
I still have some minor comments, though these may have already
been discussed. There are no normative MUST to upgrade ( and in
general very little normative language).
Shouldn't we have for example:
Systems running IKEv1 should be upgraded and reconfigured to run
IKEv2.
moved to :
Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2.
There are overall very little number of SHOULD/MUST but maybe
that is an editorial choice.
Yours,
Daniel
Yours,
Daniel
On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins <dhark...@lounge.org
<mailto:dhark...@lounge.org>> wrote:
Hi,
On 6/28/21 1:23 AM, Valery Smyslov wrote:
> Hi,
>
> I think document is mostly ready. Few observations:
>
> - FWIW I think that Dan's efforts to make draft's language
less speculative and more concrete
> are valid and should be reflected in the document.
>
> - Is it OK that the intended status is Standards Track?
Shouldn't it be BCP?
>
> - The draft states that it updates RFC 7296, 8221, 8247.
What in particular is being updated?
> I believe the recent IESG directives require a short
explanation of what is being updated
> to be present in Abstract. In any case, it should be
clearly indicated in the body of the document.
> Have I missed it?
>
> - Section3: I think that phrase "IKEv2 is a more secure
protocol than IKEv1 in every aspect." is a bit too vague.
You know, that was bugging me too. "in every aspect" is
laying it on
a bit thick. IKEv1
has a security proof. The much maligned PSK mode
authenticates the key
as well as the
exchange which is better than what IKEv2 does (and why IKEv1
did not
need an update to do
PQC). So saying it's less secure "in every aspect" just isn't
true. But
I couldn't figure
out a better way to say it....
> I believe it's better to list security aspects where we
believe IKEv2 is superior:
>
> * IKEv2 supports modern cryptographic primitives,
including AEAD ciphers
> * IKEv2 provides real defense against DoS (cookies, core
spec) and DDoS (puzzles, RFC 8019) attacks
> * support for post-quantum crypto in IKEv2 is being
developed (draft-ietf-ipsecme-ikev2-multiple-ke)
> * IKEv2 supports various authentication methods via
integration with EAP (core spec)
> * an extension that allows build PAKE methods in IKEv2
exists (RFC 6467)
> * did I forget something?
But this is great! I agree that such a brief summary of
the superior
features
would be better than a factually challenged "in every aspect"
statement.
regards,
Dan.
--
"The object of life is not to be on the side of the majority,
but to
escape finding oneself in the ranks of the insane." -- Marcus
Aurelius
_______________________________________________
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec
<https://www.ietf.org/mailman/listinfo/ipsec>
--
Daniel Migault
Ericsson
_______________________________________________
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec
<https://www.ietf.org/mailman/listinfo/ipsec>
--
Daniel Migault
Ericsson
--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
