[secdir] Secdir last call review of draft-ietf-manet-dlep-lid-extension-05
Nancy Cam-Winget via Datatracker <firstname.lastname@example.org> Mon, 12 August 2019 20:27 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B843C122617; Mon, 12 Aug 2019 13:27:35 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Nancy Cam-Winget via Datatracker <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Reply-To: Nancy Cam-Winget <email@example.com>
Date: Mon, 12 Aug 2019 13:27:35 -0700
Subject: [secdir] Secdir last call review of draft-ietf-manet-dlep-lid-extension-05
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Mon, 12 Aug 2019 20:27:36 -0000
Reviewer: Nancy Cam-Winget Review result: Has Issues SECDIR review of draft-ietf-manet-dlep-lid-extension-05 Reviewer: Nancy Cam-Winget Review result: Ready with questions (issues?) I have reviewed this document as part of the security directorate'sÊ ongoing effort to review all IETF documents being processed by theÊ IESG.ÊÊThese comments were written primarily for the benefit of theÊ security area directors.ÊÊDocument editors and WG chairs should treatÊ these comments just like any other last call comments. This document defines extensions to the Data Link Exchange Protocol (DLEP) to enable modems to advertise the status of wireless links that are not reachable beyond a device on the Layer 2 domain. The extension focuses on the inclusion of IPv4 or IPv6 address(es) to DLEP when the modems provide Layer 3 connectivity. As this is not my area of domain expertise, I have the following questions: * It seems that WANs could include NATs but I see no consideration for how to treat the IP addresses in the presence of NAT. Is this not an issue? I think some mention of this should be included. * Section 2.1: What happens if Link Identifiers span multiple MAC Addresses or if they are reused? What does it mean for a link identifier to be reused (per session? or ever?) There is a reference to the destination MUST NOT be recycled, but I am not sure what recycled means in this context? What happens if they are reused? A note either here, or in the security considerations should describe these conditions. * Section 2.2: what happens if "link identifiers" is negotiated but no link identifiers are provided? * Security (no privacy considerations?): given that this draft is now including IP addresses, it seems that there is potential to determine a network topology and perhaps identification of a network used to mount attacks. I do see that RFC 8175 doesn't have privacy considerations, but given that this is now at the IP layer it may be good to provide one?
- [secdir] Secdir last call review of draft-ietf-... Nancy Cam-Winget via Datatracker
- Re: [secdir] [manet] Secdir last call review of... Stan Ratliff