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.