Skip to main content

Telechat Review of draft-ietf-ace-wg-coap-eap-11
review-ietf-ace-wg-coap-eap-11-iotdir-telechat-lear-2024-10-19-00

Request Review of draft-ietf-ace-wg-coap-eap
Requested revision No specific revision (document currently at 15)
Type Telechat Review
Team Internet of Things Directorate (iotdir)
Deadline 2024-11-15
Requested 2024-10-19
Requested by Éric Vyncke
Authors Rafael Marin-Lopez , Dan Garcia-Carrillo
I-D last updated 2025-09-12 (Latest revision 2025-02-19)
Completed reviews Secdir IETF Last Call review of -09 by Deb Cooley (diff)
Genart IETF Last Call review of -09 by Roni Even (diff)
Secdir Early review of -08 by Deb Cooley (diff)
Iotdir Early review of -08 by Eliot Lear (diff)
Iotdir Telechat review of -11 by Eliot Lear (diff)
Assignment Reviewer Eliot Lear
State Completed
Request Telechat review on draft-ietf-ace-wg-coap-eap by Internet of Things Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/FyH_AJNH-L8_vfUfTB2O7_tIauk
Reviewed revision 11 (document currently at 15)
Result Ready w/issues
Completed 2024-10-19
review-ietf-ace-wg-coap-eap-11-iotdir-telechat-lear-2024-10-19-00
This is a follow-up to my earlier IoT directorate review.  In that review I
raised four issues:

1. Proper illustration of EMSK key derivation (this is somewhat optional)
2. Terminology alignment
3. MTU issues
4. A difference between how EAP is used (e.g., without IP connectivity) and
this work.

All four points have (mostly) been addressed, although I have comments on the
last one.  There is a key deployment aspect missing that I would suggest the WG
consider:

When dealing with EAP at the 802.1X layer, since the device doesn't have an IP
address, in effect from the application point of view, and even at certain
kernel layers, the interface is down.  That means that no address has been
assigned, and from the network edge standpoint, no IEEE 802.1q VLANs assigned
either.

One complication that remains is this: if the network enables access based on
VLAN assignments, then the L3 address may need to change.  Upper layers in the
client need to be prepared for that, and address plans may need to take it into
account.  I suggest that some operational cautions be added to address these
points.

In addition, and without going into a whole lot of detail, if this method is
being made use of by a mesh network for permitting access, it must be clear how
both admission and removal are handled; or an applicability statement should be
added that until someone does that work, this document should not be
recommended for such networks.