Skip to main content

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

Yes

(Alexey Melnikov)
(Kathleen Moriarty)

No Objection

(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 10-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

Alexey Melnikov Former IESG member
Yes
Yes (for -10-01) Unknown

                            
Kathleen Moriarty Former IESG member
Yes
Yes (for -10-00) Unknown

                            
Stephen Farrell Former IESG member
Yes
Yes (2016-08-30 for -10-00) Unknown
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.
Alissa Cooper Former IESG member
No Objection
No Objection (2016-08-31 for -10-00) Unknown
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.
Alvaro Retana Former IESG member
No Objection
No Objection (2016-08-31 for -10-00) Unknown
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.
Ben Campbell Former IESG member
No Objection
No Objection (2016-08-31 for -10-01) Unknown
I share Alissa's concern about the number of documents for the time window.
Benoît Claise Former IESG member
No Objection
No Objection (2016-09-01 for -10-01) Unknown
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -10-00) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -10-01) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -10-01) Unknown

                            
Mirja Kühlewind Former IESG member
(was Block) No Objection
No Objection (2016-09-01 for -10-01) Unknown
Thanks for changing the text on TCP!
Spencer Dawkins Former IESG member
No Objection
No Objection (2016-08-29 for -10-00) Unknown
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?
Suresh Krishnan Former IESG member
No Objection
No Objection (for -10-01) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -10-00) Unknown