Last Call Review of draft-harkins-owe-05
review-harkins-owe-05-opsdir-lc-jethanandani-2017-01-10-00

Request Review of draft-harkins-owe
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-01-13
Requested 2016-12-05
Other Reviews Genart Last Call review of -05 by Lucy Yong (diff)
Secdir Last Call review of -05 by Matthew Miller (diff)
Opsdir Telechat review of -06 by Will LIU (diff)
Review State Completed
Reviewer Mahesh Jethanandani
Review review-harkins-owe-05-opsdir-lc-jethanandani-2017-01-10
Posted at https://www.ietf.org/mail-archive/web/ops-dir/current/msg02353.html
Reviewed rev. 05 (document currently at 07)
Review result Has Nits
Draft last updated 2017-01-10
Review completed: 2017-01-10

Review
review-harkins-owe-05-opsdir-lc-jethanandani-2017-01-10

I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document reviewed:  draft-harkins-owe-04

Status:

Ready with nits.

Summary:

This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media.

The document is informational but does present an extension to a IEEE 802.1 standard, which makes one wonder why is this document informational in nature. 

Operational Considerations:

The memo specifies a new encryption mechanism, without specifying an authentication mechanism. With Opportunistic Wireless Encryption (OWE), the client and AP perform a Diffie-Hellman key exchange during the access procedure and use the resulting parities secrets with a 4-way Handshake.  Because it is an addition to the existing mechanism, it fits into any existing environment, allowing for a gradual replacement to distribution of a shared and public PSK used today in the 4-way handshake. As such if anything, the procedure simplifies the usage from an operational perspective.

It is not clear how the clients can participate in the new encryption mechanism. Will the client software need to downloaded before it can use the new encryption mechanism. If so, can the client download the software using open authentication/open encryption or a shared and public PSK and then switch to OWE?

Finally, it would be helpful to suggest how a migration path could be provided for operators as they move from either an open encryption or a shared and public PSK mechanism, i.e. can two mechanisms coexist for a period of time.

Management considerations:

Can the new mechanism operate “out of the box”, in that the operators do not need to specify and values or it would work with any configurable values. If there are values that are configurable, it would be helpful to state what their default values are.

There would also be a need to support a troubleshooting and a programmatic interface for monitoring and debugging any problems that might come up in deployment. These should be similar to existing techniques used to monitor and debug issues. These interfaces are not mentioned in the document, something that would be helpful to have.

Is there a management model being considered for this mechanism both from a configuration and from a monitoring perspective? If so, it would be helpful to document it here.

Fault management:

The draft should document how any failures or faults are tracked. What are some of the basic faults that need to be traced. Same for health indicators. For example, if the client is not able to negotiate the 4-way handshake, how is that reported? 

If notifications are used to alert operators of certain conditions, they need to be documented, with a mechanism to throttle those notifications if they happen frequently.

Fault determination:

If a client is not able to connect to the AP, how is an operator supposed to determine whether the issue is on the client or the server side?

Verifying correct operation:

The draft needs to talk about how the new encryption method can be tested for correct behavior. For example, if in a migration strategy, how would one know if the key being used is from the Diffie-Hellman exchange?

Account management:

The draft also needs to consider how to collect usage information related to the technique, and what information needs to collected. A lot of times usage information is used to determine capacity, do trend analysis, calculate cost allocation, auditing and billing.

Monitoring the new mechanism:

It would be helpful to know how many clients are able to both successfully generate the Diffie-Hellman exchange and which ones are not. A count of how may client requests were received, and how many keys were generated would helpful to the operators. Counter definitions that define what is included in the count and what is not, should be documented.

A run of idnits did not reveal anything in particular.

Thanks.

Mahesh Jethanandani
mjethanandani at gmail.com