Subject: [Lwip] Ben Campbell's Discuss on draft-ietf-lwig-ikev2-minimal-05: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 02 Dec 2015 14:37:36 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-lwig-ikev2-minimal-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Apologies for changing to DISCUSS after my initial NO OBJECTION position,
but I just realized an implication to my comment about copying the IKEv2
text:

The shepherd's write up says "[Informational] is the proper type of RFC
because the document describes implementation recommendations for a
proposed standard and is not a proposed standard in itself.". But this
document does not merely make recommendations; it claims to stand alone
as a full specification of everything needed  for a minimal
implementation that works with IKEv2.  I'd like to discuss why this
should not be standards track, as it's currently written.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I question the choice of copying IKEv2 text forward into this document,
at least without clearly marking (and citing) the copied text. What
happens if 7296 gets updated or obsoleted? It seems like that would
effectively fork the protocol. And since this draft does not seem to
distinguish copied text from new text, I wonder if the other authors of
7296 should be considered authors of this document.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Dec 2015 14:33:56 +0200

The document contains Appendix A which makes it stand alone and that
whole appendix is clearly marked of being copied from the 7296:

----------------------------------------------------------------------
Appendix A.  Header and Payload Formats

   This appendix describes actual packet payload formats.  This is
   required to make the document self contained.  The descriptions are
   mostly copied from the RFC7296 and more information can be found from
   there.
----------------------------------------------------------------------

So I think this document do clearly mark which parts are copied from
the RFC7296.

It also mentions in the abstract that:

----------------------------------------------------------------------
   This document does not update or modify RFC 7296, but provides more
   compact description of the minimal version of the protocol.  If this
   document and RFC 7296 conflicts then RFC 7296 is the authoritative
   description.
----------------------------------------------------------------------

I.e. RFC7296 is and will be authorative answer for IKEv2. If the
RFC7296 is obsoleted in a way which will make it incompatible with old
RFC7296 meaning it will also be incompatile with this draft, then we
need to explain in that new version what it means for this document
and what it means for RFC7296.

If RFC7296 is just updated in a way which does not make old version
incompatible, then this document should stay compatible with those
changes too. I.e. adding new optinal extensions to IKEv2 (for example
the clone-ike-sa) will not affect this document at all, as minimal
implementations will be able to ignore the notification payloads used
to negotiate it, thus minimal implementations will indicate the other
ends that they do not support that extension. 

> at least without clearly marking (and citing) the copied text.

The copied part is the whole Appendix A, and I think it is quite
clearly marked in the beginning of that appendix. Do you think we need
better wording in the beginning of that appendix?

The reason it says "mostly copied" indicates that not all of the
packet formats are copied there, and some of the copied parts are made
shorter by removing parts which are not relevant for minimal
implementations.

> What happens if 7296 gets updated or obsoleted?

If 7296 gets updated, then nothing should happen with this document
provided that updated IKEv2 is something that will still be compatible
with current 7296. I.e if we still keep same major version number then
minimal document should still be compatible with updated IKEv2
versions.

If the 7296 will be obsoleted by IKEv3 using new major version
number, then I assume this document will be obsoleted too and
completely new document might need to be written for minimal IKEv3...

Note, that IKEv2 has already been updated twice (RFC5996 and 7296 when
the original was 4306), and the last version is still compatible with
the original one, meaning original 4306 implementations will work with
latest 7296 versions.

> It seems like that would effectively fork the protocol.

RFC7296 is already a fork of IKEv2. Similarly are RFC5996 and RFC4306
versions. All of those versions are interoperable, but newer versions
do have some changes which older versions do not know about, but they
are made in such way that they are still interoperable with each
other.

> And since this draft does not seem to distinguish copied text from
> new text, I wonder if the other authors of 7296 should be considered
> authors of this document.

The appendix A is copied from the 7296 and that is clearly stated
there. The Acknowledgements section also states that most of the
contet of this document is copied from the RFC7296.
-- 
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Thu, 3 Dec 2015 15:46:40 +0200

For what it is worth, I at least saw the marking of the appendix
material as clear.

I have a comment on the status of the document. I have no objection
to using other status classifications (Proposed Standard and/or
Applicability Statement), but from my perspective of someone who
might use this technology, Informational is a good fit. We already
have the standard. We are not changing the standard. Someone has
provided information about how to implement the standard in a
given setting and under constraints. This useful information
and a useful reference for people who building things.

There is no presumption that the same answer is applicable for
other environments. The document is quite clear on what the
requirements of the standard are.

The document has some material copied instead of using the
by reference approach. I consider that an editorial choice, and
only an editorial choice. It should not affect the standing
of the document as such. FWIW, the editorial choice has
some trade-offs, but one that is not made in the document
is not an unreasonable one. And the document certainly
is clear in what it says. Other choices might have been
made with a different set of trade-offs, but that’s another
matter.

Jari

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 03 Dec 2015 10:24:02 -0600

> whole appendix is clearly marked of being copied from the 7296:

Does Appendix A contain all of the copied text? If so, then perhaps the 
earlier mention of copied text could point out that the copying is 
restricted to the appendix.

However, the point of the discuss was about whether a "stand-alone" 
draft should be standards track or informational. The questions about 
copied text and updates to 7296 address my (non-blocking) comments.

> It also mentions in the abstract that:

Do I correctly understand this to mean that 7296 would become burdened 
to explain how it differs from a dependent draft that copied text? That 
seems error prone at best.

> ends that they do not support that extension.

There are a number of ways that 7296 could be updated that would be 
relevant to this draft, but might not make it incompatible per se. For 
example, updates to security considerations.

[I think the discussion above already covers the comment points 
below--please point it out if I missed something.]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Dec 2015 02:39:12 +0200

> restricted to the appendix.

Appendix A has text that is copied from the IKEv2 RFC, and which have
then been shorteded a bit, for example some text which were not needed
for minimal implementations were removed from those sections, and
certain subsections were left out completely.

The main body of the document also has some copied text, but that has
been modified much more to make the description shorter, and leaving
out text talking about different options etc when that was not needed
for the minimal implementations. 

> copied text and updates to 7296 address my (non-blocking) comments.

Ok.

> seems error prone at best.

If we make change in the IKEv2 which is interoperable with 7296, then
that change will most likely also be inteoperable with this one.

If we make change in the IKEv2 which will not be interoperable with
7296, then most likely that new IKEv2 will not be interoprable with
this document either. In that case the new IKEv2 will most likely need
to explain how it proposes to handle the old RFC7296 versions of the
IKEv2, and how they are supposed to interoperate. The answer will most
likely be same for this document too.

On the other hand I do not really see it very useful to try to
speculate what kind of changes we might do for IKEv2, that might cause
problems with this or RFC5996 or RFC4306 versions of the IKEv2. When
we make changes to the IKEv2 we always try to keep changes done in
such way that all older version will also work nicely with the new
version. If we keep doing that this will mean that this document will
also keep working nicely, as this document is based 7296 and we will
try to keep new IKEv2 to work with RFC7296 versions of IKEv2...

> example, updates to security considerations.

I do not really see that happening, can you give me some kind of
example what you are meaning there?

-- 
[email-masked]

---

From: Robert Cragie <[email-masked]>
Date: Fri, 4 Dec 2015 13:36:34 +0000

As shepherd, I agree with what Jari says and stand by my comment that
Informational is the right intended status. FWIW, I did raise the issue of
copying text with Tero and was satisfied that it was an editorial choice to
do it that way.

Robert

On 3 December 2015 at 13:46, Jari Arkko <[email-masked]> wrote:

> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>
>

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 04 Dec 2015 16:07:31 -0600

>> On 3 Dec 2015, at 6:33, Tero Kivinen wrote:

[...]

> for the minimal implementations.

I am reading this to say that copied text, with modifications (i.e. 
mixed with new or changed text), occurs both inside and outside Appendix 
A. If that's the case, then I disagree that the copied text is clearly 
marked as such.

>> copied text and updates to 7296 address my (non-blocking) comments.

You didn't respond to that point, so I will try to clarify it.

I understand, perhaps incorrectly, that you expect this draft to be able 
to stand alone; that is, people would be able to implement this draft 
just by reading the text in this draft, without having to read 7296. 
OTOH, the shepherd's writeup argues that this draft is informational 
because it does not define protocol. I think that, as written, this 
draft _does_ define protocol, at least constructively. That protocol may 
happen to be identical to that from 7296--but this draft, not 7296, is 
the authoritative definition.

That being said, I don't really think your intent was to define a new 
protocol, constructively or otherwise. As Barry mentioned in his ballot 
position, this really seems like an applicability statement for using 
7296 in low-power devices, and that implementors really need to 
understand 7296. I think it would be reasonable and proper to do that in 
an informational RFC. But the attempt to make this draft stand alone 
sabotages that.

I think that some text that instructs implementors that they need to 
understand 7296, and some markup to clarify _in_detail_ which parts of 
this draft merely copy or restate bits of 7296, and which parts describe 
changes from 7296 behavior.

> try to keep new IKEv2 to work with RFC7296 versions of IKEv2...

I agree that it's not useful to speculate what changes might happen. The 
best thing is to assume changes _will_ happen, and not assume they will 
just work fine with this draft.
If a reader looks 4306 or 5996, they will find them clearly marked as 
obsoleted by the later drafts. If 7296 is obsoleted or updated in the 
future, a _this_ draft will not be marked show it. I note that 7296 
_already_ has an update, and also has errata. A reader of this draft 
will not learn of either of those.

> example what you are meaning there?

Errata. Deprecation and/or addition of crypto algorithms. Implementation 
and security guidance based on implementation experience. BCPs that 
describe or change preferred ways to deploy IKEv2. (These are examples, 
not an exhaustive list.)

[...]

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 04 Dec 2015 16:31:24 -0600

> made with a different set of trade-offs, but that’s another

Hi Jari,

I actually agree that it would be appropriate to describe how to use 
IKEv2 with constrained devices in an informational RFC. But I think the 
way this draft handles the "copy vs reference" question goes beyond the 
editorial.

My concern is that statements like "This document is intended to be 
stand-alone, meaning everything needed to implement IKEv2 is copied here 
except the description of the cryptographic algorithms." make this draft 
the authoritative specification for IKEv2 on constrained devices. If RFC 
7296 has errata (it does), is updated (it has been), or even obsoleted, 
those changes will not be reflected in this spec. Likewise, errata and 
updates to this draft won't be reflected back to 7296. That seems to me 
to effectively fork the protocol.

I don't think the intent is to really fork IKEv2 into a 
separate-but-compatible protocol for constrained devices. But if that is 
the intent, then that seems like something that we should at least 
discuss putting on the standards track.

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 04 Dec 2015 16:33:15 -0600

> copying text with Tero and was satisfied that it was an editorial 

Noted, and thanks for weighing in. Please see my most recent comments on 
this to Jari and Tero.

Thanks!

Ben.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Dec 2015 23:15:03 +0000

Hiya,

> to effectively fork the protocol.

Ah maybe that's where the disconnect is.

I'm quite sure there is no intent to fork here - implementations
following this are only useful because they interoperate with a full
IKEv2 implementation. They can't even interop with one another and
that is by design. If forking was to be a goal or done, that'd require
much more work and in another WG that'd be specifically chartered for
that (only after a major fuss no doubt).

And we really would notice if someone wanted to make a new version
of IKE or IPsec, honest:-)

There is a potential bookkeeping issue with errata etc yes but that's
IMO not much of a showstopper. I guess that as IKE and IPsec evolve
then this will need updating accordingly, though as Tero has done it,
I'd say the things he needs are less likely to change or will change
more slowly. It's likely fairly stable, as a profile. (Note: yes,
those could well be words that come back to haunt me, but I'm ok with
that:-)

> discuss putting on the standards track.

For completeness, I would strongly object to such an activity being
based on any concern with this document or the LWIG working group.
If we wanted to re-open IKE or IPsec, that'd require much more support
and much deeper consideration. LWIG is a fine WG, but is not the
vehicle for doing that and won't be. But that's all ok, as there is
no intent to fork that I know of.

Cheers,
S.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 04 Dec 2015 17:23:23 -0600

> of IKE or IPsec, honest:-)

Do you see no chance that, sometime down the road, people might update 
IKE but forget about this RFC?

I don't think the concern is limited to non-backwards compatible 
updates; for example an update to IKE might be backwards compatible, but 
add some new feature or optimization that could be beneficial for 
constrained devices, but not reflected in this draft.

> no intent to fork that I know of.

Okay, I'm convinced that my concern about informational vs standards 
track is a red herring. I'm going to clear the DISCUSS. I still think 
the current approach is problematic, but not DISCUSS level problematic.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Dec 2015 23:30:00 +0000

> IKE but forget about this RFC?

Sure, could happen. But I think the versioning and all the alg ids
etc take care of that. There are already (by design) valid ways to
deploy the non-constrained side here that'd not interop with the
constrained side implementing this. (E.g. using certs for starters!)
So the kind of problem you envisage can already happen today and
that's ok.

But, it might be worth a look again to see if there are any fields
used in this profile that could be likely to change with bad effects
on this. I don't recall such, but good if someone could think about
that.

Cheers,
S.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 7 Dec 2015 08:18:00 -0500

All,
    Sorry for my extended delay in responding...

> So the kind of problem you envisage can already happen today and

The above is the view I hold as well.  I talked through the "copy vs
reference" with Tero and the WG chairs during my evaluation and reached
the conclusion that the copy approach was fine in an Informational document.

> on this. I don't recall such, but good if someone could think about

I am pretty sure this has been done.  Tero, can you confirm?

Regards,
Brian

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Dec 2015 16:39:21 +0200

> I am pretty sure this has been done.  Tero, can you confirm?

I do not remember there being anything that would be easily affected.
Also as currently extensions are done in the way where the initiator
tells that it supports some extension, and then responder confirms
that, this will mean that when minimal client will NOT claim to
support some extension then responder will not use that feature (and
do not even include any of the payloads negotiating it).

Also extensions are usually negotiated using notify payloads using
status notify types (which can be safely be ignored by recipient end
if they are not understood), minimal implementations will simply
ignore the other ends notifications which try to negotiate the
extensions, which will then cause extensions to be disabled.

I think I agree on the statement that if we make so big changes to the
IKEv2 that it would really affect minimal implementations, that would
be IKEv3...

And if we do end up having this issue, we can just make bis version of
this document, and update it. This might happen anyways depending how
the new EC curves and signatures will be taken in to use and what kind
of features we are going to be using. After few years we might see
that minimal implementations in actual use are using more features
than what our current minimal implementations are using, and we might
want to update this document to specify features those implementations
are using.
-- 
[email-masked]

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 7 Dec 2015 08:38:44 -0500

Sent from my iPhone

> On Dec 4, 2015, at 5:07 PM, Ben Campbell <[email-masked]> wrote:
> 
> I am reading this to say that copied text, with modifications (i.e. mixed with new or changed text), occurs both inside and outside Appendix A. If that's the case, then I disagree that the copied text is clearly marked as such.

I agree with the draft being informational as per the comment on my ballot.  However, language changes within the draft to make that point more clear seem to be what Ben is after.

Ben, would you be able to provide a few text additions to add the caveats that would help?  I do see your point on the copied text,  but also that the intent of this draft is to document a PoC only.

Thanks,
Kathleen 
> I understand, perhaps incorrectly, that you expect this draft to be able to stand alone; that is, people would be able to implement this draft just by reading the text in this draft, without having to read 7296. OTOH, the shepherd's writeup argues that this draft is informational because it does not define protocol. I think that, as written, this draft _does_ define protocol, at least constructively. That protocol may happen to be identical to that from 7296--but this draft, not 7296, is the authoritative definition.
> 
> That being said, I don't really think your intent was to define a new protocol, constructively or otherwise. As Barry mentioned in his ballot position, this really seems like an applicability statement for using 7296 in low-power devices, and that implementors really need to understand 7296. I think it would be reasonable and proper to do that in an informational RFC. But the attempt to make this draft stand alone sabotages that.
> 
> I think that some text that instructs implementors that they need to understand 7296, and some markup to clarify _in_detail_ which parts of this draft merely copy or restate bits of 7296, and which parts describe changes from 7296 behavior.
> 
> 
> 
>> 
> I agree that it's not useful to speculate what changes might happen. The best thing is to assume changes _will_ happen, and not assume they will just work fine with this draft.
> If a reader looks 4306 or 5996, they will find them clearly marked as obsoleted by the later drafts. If 7296 is obsoleted or updated in the future, a _this_ draft will not be marked show it. I note that 7296 _already_ has an update, and also has errata. A reader of this draft will not learn of either of those.
> 
>> 
> Errata. Deprecation and/or addition of crypto algorithms. Implementation and security guidance based on implementation experience. BCPs that describe or change preferred ways to deploy IKEv2. (These are examples, not an exhaustive list.)
> 
> [...]
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 7 Dec 2015 09:27:12 -0500

Ignore my message, I didn't realize this was settled and was trying to help... Then my mail decided to finish synchronizing.

Kathleen 

Sent from my iPhone

> On Dec 7, 2015, at 8:38 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPhone
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 07 Dec 2015 14:55:19 -0600

[...]
>
> I agree with the draft being informational as per the comment on my 
> ballot.  However, language changes within the draft to make that point 
> more clear seem to be what Ben is after.
>
> Ben, would you be able to provide a few text additions to add the 
> caveats that would help?  I do see your point on the copied text,  but 
> also that the intent of this draft is to document a PoC only.
>

If this draft is about a proof of concept, that would definitely change 
my opinion. The my concerns about maintenance would be less ... 
concerning.

But I did not get that from the text. Some clarification about that 
would be helpful. I see the implementation section that describes a PoC 
implementation of this draft, but not that this draft is intended to 
document that PoC or be limited to a PoC.

[...]

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 07 Dec 2015 14:58:08 -0600

On 7 Dec 2015, at 7:18, Brian Haberman wrote:

[...]

> the conclusion that the copy approach was fine in an Informational 

I've cleared my discuss on the informational status, and it seems like I 
am in the minority in being worried about the copy vs reference 
approach. So while I have not changed that opinion, I am perfectly happy 
to be declared in-the-weeds.

Thanks!

Ben.