IP Security Maintenance and Extensions
charter-ietf-ipsecme-13

Changed charter milestone "Postquantum cryptography document for IKEv2 to IESG", set due date to May 2020 from May 2019, reverted to not being resolved, added draft-tjhai-ipsecme-hybrid-qske-ikev2 to milestone

[Ballot comment]
While I have no objection to the charter, I would suggest to coordinate to compressed ESP/IKEv2 of this charter with the compression work done in LPWAN (mainly or only for the non-encrypted parts).

[Ballot comment]
Some wordsmithing on the two new paragraphs, mostly correcting grammar errors and awkward wording:

NEW
RFC8229, published in 2017, specifies how to encapsulate         
IKEv2 and ESP traffic in TCP.  Implementation experience has                   
revealed that not all situations are covered in RFC8229, and that may             
lead to interoperability problems or to suboptimal performance. The WG             
will provide a document to give implementors more guidance about how to use             
reliable stream transport in IKEv2 and clarify some issues that have been           
discovered. A possible starting point is draft-smyslov-ipsecme-tcp-guidelines.     
                                                                                   
The demand for Traffic Flow Confidentiality has been increasing in the user       
community, but the current method defined in RFC4303 (adding null         
padding to each ESP payload) is very inefficient in its use of network           
resources. The working group will develop an alternative TFC solution that         
uses network resources more efficiently.
END

[Ballot comment]
Very clear charter with well defined goals. nice work!

one nit: s/public keys then/public keys than/

I would have appreciated to read the expansion of ESP and IV but I can understand this is not needed for subject matter experts.

[Ballot comment]
Minor punctuation comment for the paragraph starting with "RFC7427":

OLD:
"A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS, however
it is envisioned..."
NEW:
"A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however,
it is envisioned..."

[Ballot comment]
If TSV can help with the work on Postquantum key exchange methods and the impact of increased size of initial IKEv2 messages, please let us know.

I note that https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-04#section-6 is part of a current TSVWG work item, and this might be relevant to that discussion, but that's only my poorly informed opinion. But we may be able to help in other ways.

[Ballot comment]
For the "The internal address failure indication in IKEv2" item it might be good to talk to 3GPP since they seem to be the only potential consumer of this work.

[Ballot comment]
Just to hammer on:  the use of an expiration date on the charter for this WG has already proven not useful -- as we are already 6 months past the last expiration date and the WG was not closed.

[Ballot comment]
I agree that I don’t see value in having the expiration date. Why does the working group feel this is needed?

s/IPsec SA. non-standard/IPsec SA. Non-standard/

[Ballot comment]
Substantive comments:

(1) I don't see the value in having an expiration date in a WG charter because it's not enforced in practice. The previous version of this charter said the WG would close if the charter wasn't updated by Dec 2017, but the WG continued to exist without the charter being updated. This charter seems tightly scoped enough to just get the work done according to the milestone dates or close sooner if people lose interest.

(2) I think it might be worth a few words to state the reason why the goal was for the new IKEv2 mode to have the same quantum resistant properties as existed in IKEv1, rather than better/fuller quantum resistance.


Nits:

Based on the number of grammar and wording errors I found in this charter, I would strongly suggest doing a clean-up pass to make sure all of the text reads properly. Here is what I found:

(1)
s/to have similar quantum resistant properties than IKEv1 had/to have similar quantum resistant properties that IKEv1 had/

(2)
s/in form of counter/in the form of a counter/

(3)
I can't parse this sentence:

"A growing number of use cases for constrained network - but not
limited to - have shown interest in reducing ESP (resp. IKEv2)
overhead by compressing ESP (resp IKEv2) fields."

(4)
OLD
Currently IKE peers have no explicit way
to indicate each other which signature format(s) the support, that
leads to ineroperability problems.

NEW
Currently IKE peers have no explicit way
to indicate to each other which signature format(s) they support. That
leads to ineroperability problems.

(5) The milestones need to be updated. Some of the dates and draft names are wrong.

[Ballot comment]
I don't object to this proposed charter going for internal review, but do have one question.

When looking at some of the work items, I see

"A possible starting point is draft-yeung-g-ikev2" (nit, missing closing period)

"draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good starting points for ESP compression."

"draft-smyslov-ipsecme-ikev2-compression and raft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2 compression." (nit, should be "starting points")

"draft-boucadair-ipsecme-ipv6-ipv4-codes could be used as a starting point for this item."

If you're using different language to convey a nuance, that would be fine (I'm missing it, but I miss things).

If you're saying the same thing in all four cases, I'd suggest using the same phrasing in each case. so working group chairs and participants aren't trying to figure out whether "possible starting point" and "could be used as a starting point" are the same as "expected to be good starting points" and "are good starting points".

I think I see "A possible starting point is" in most charters that point to individual drafts, which lets the working group decide whether to adopt that proposal or work on a different approach, but do the right thing, of course.

[Ballot comment]
The milestones are all in the past. Should 2016 be 2017? Also, I notice the milestone list does not cover the full set of current goals--is that the intent? (I'm okay if it is; just checking.)

[Ballot comment]
The milestones are all in the past. Should 2016 be 2017? Also, I notice the milestone list does not cover the full set of goals--is that the intent? (I'm okay if it is; just checking.)

[Ballot comment]
Not for IPSECME, but for the IESG ...

I don't object to this work:

"There have been middle boxes blocking IKE negotiation over UDP. To
make IKE work in these environments, IKE and ESP packets need to be
transmitted over TCP. Therefore the group will define a mechanism to
use IKE and IPsec over TCP. The group will also provide guidance on
how to detect when IKE cannot be negotiated over UDP, and TCP should
be used as a fallback"

because what's described is going from UDP to TCP, which avoids a lot of challenges that going from TCP to UDP gives you, but it would be good for us to talk about all the ways that people are detecting poor performance, and even complete failures, in one protocol and switching to another protocol in response.  I note that Ian Swett reported in Berlin that Google sees QUIC affected by UDP impairments, including blocking, about five percent of the time, and they also fall back to TCP, so this is a current problem affecting work in multiple areas.

Perhaps this is a a good topic for an upcoming informal telechat.

[Ballot comment]
Please provide some milestones along with dates, as guidance so that all documents are finished by Dec 2017.
Otherwise this text below becomes a blanket statement, not paid attention to.

    This charter will expire in December 2017. If the charter is not
    updated before that time, the WG will be closed and any remaining
    documents revert back to individual Internet-Drafts.

Hint: the current charter says

    This charter will expire in December 2015 (a year from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts.

[Ballot comment]
I find the last paragraph artificial and unnecessary:

  This charter will expire in December 2017. If the charter is not
  updated before that time, the WG will be closed and any remaining
  documents revert back to individual Internet-Drafts.

I understand that this type of text in a charter may help the WG maintain momentum, so I'm not going to stand in the way of making progress.

[Ballot comment]
This seems like a lot of documents for a 16-month window based on this group's past publication rate. Good to be ambitious, but I'm just wondering how realistic this is.

[Ballot block]
Similar to Spencer's commet I have problems understanding what the following really means:

"To make IKE work in these environments, IKE packets need to be
encapsulated in a TCP tunnel. The group will define a mechanism to
tunnel IKE and IPsec over a TCP-based connection. This method is
intended to be used as a fallback when IKE cannot be negotiated over
UDP. The group will create a method where IKEv2 and IPsec packets can
be encapsulated in the TCP connection."

Based on Tero's mail I understand how the stack looks like but that's not clear from the text because there is not really anything like a TCP tunnel. So the big question is, based on the stack indicated by Tero, do you have two full TCP connections running with two congestion control loops and retransmission mechanisms on two different endpoints? That's nothing I would recommend.

I fully understand the need for a fallback mechanism to TCP but depending on what you actually aim for I'm not sure if this is the right wg for it; therefore my block for now. I hope we can resolve that quickly!

[Ballot comment]

There are some typos (s/MIT/MTI) and bits of English that
need to be tidied up.

I have a suggestion about this bit of work:

"IKEv1 using shared secret authentication was partially resistance to
quantum computers. IKEv2 removed this feature to make the protocol
more usable. The working group will add a mode to IKEv2 or otherwise
modify IKEv2 to have similar quantum resistant properties than IKEv1
had."

My suggestion is twofold:

1) - s/will add/will consider adding/

and to add to the end:

2) "In doing this work the WG will consider ongoing work on quantum-resistance
in the CFRG, and whether it is better to re-instate the same level of resistance
that was present in IKEv1 or to wait for more recent work (e.g. in CFRG) to
mature."

The reason I suggest this is that it's possible the WG might conclude that
it's better to wait for some newer QR stuff from CFRG. The current wording
seems to commit the WG to firing ahead anyway, and we might overall be
better if there are fewer QR mechanisms proposed, rather than adding some
now when it might be better to wait a while longer.

[Ballot comment]
This sentence doesn't parse for me - or maybe I just need more security clue?

"IKEv1 using shared secret authentication was partially resistance to
quantum computers."

I don't object to this text

"There have been middle boxes blocking IKE negotiation over UDP. To
make IKE work in these environments, IKE packets need to be
encapsulated in a TCP tunnel. The group will define a mechanism to
tunnel IKE and IPsec over a TCP-based connection. This method is
intended to be used as a fallback when IKE cannot be negotiated over
UDP. The group will create a method where IKEv2 and IPsec packets can
be encapsulated in the TCP connection."

going for external review, but I'd love to understand better what the resulting protocol stack looks like. I get the part about encapsulating IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a general-purpose "IP over TCP" mechanism?

The WG adopted several new drafts that required a charter update as the charter is maintained to current work items and a time limit is set for them to complete those milestones by the WG (their choice to keep the energy up or close if there isn't enough to support getting the work done).

[Ballot comment]
Your mission, should you choose to accept it, is to figure out of IPSEC can work for OE.  Should you be captured, the secretary will disavow all knowledge of your actions.  This working group will self-destruct in five seconds.

[Ballot comment]
This charter will expire in December 2015 (a year from approval). If the charter
is not updated before that time, the WG will be closed and any remaining
documents revert back to individual Internet-Drafts.

I like this "fail fast" type of paragraph.

[Ballot comment]
I do find these "This charter will expire" lines kind of silly, but I'm not going to stand in the way because of it.

[Ballot block]
This is very trivial, but I believe it must be fixed for clarity. The proposed text says:

  The WG will revise the mandatory-to-implement algorithms for
  ESP and AH based on five years of experience with newer algorithms
  and cryptographic modes. This work will be based on
  draft-mcgrew-ipsec-me-esp-ah-reqts.

I believe there is no proposal to revise the algorithms! The intent, I think is to revise the *list* of mandatory-to-implement algorithms.

[Ballot comment]
Is it time to fully close the window on updates to IKEv1?
The charter says:
  Its purpose is to maintain the IPsec standard and to facilitate discussion of
  clarifications, improvements, and extensions to IPsec, mostly to IKEv2.

I guess the bit that bothers me is "mostly to". That leaves the door (or was it a window?) open enough for people to think that improvements and extensions to IVEv1 are in scope.

Would it be possible to re-word this part of the charter to get some more clarity on what can and can't be considered in scope?