Hello. Thank you for the review and comments. Responses inline.
On Mon, Aug 12, 2019 at 4:28 PM Nancy Cam-Winget via Datatracker <noreply@xxxxxxxx> wrote:
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.
IP addresses that are contained in DLEP LID are assumed to be on the public side of any NAT (that is, post-NAT for egress traffic, pre-NAT for ingress traffic). We can work on including this assumption in the draft.
* 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.
Link identifiers MUST NOT span MAC addresses, nor can they be reused. This is what the text refers to when it discusses "recycling" LIDs.Having said that, we will work on strengthening the language.
* Section 2.2: what happens if "link identifiers" is negotiated but no link
identifiers are provided?
If identifiers are negotiated, and then not used, there is no impact to operation. The LID was introduced as a way for radio modems to introduce destinations that it knows about, but that it does not specifically manage from a Layer1/Layer2 perspective.
* 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?
The notion of IP address vectors is in RFC 8175. The IP address(es) represent the unicast IP addresses of the destination specified, or potentially a Multicast address to be carried over the RF. IMO, the introduction of LIDs and their IP addresses does not increase the potential security exposure over and above the RFC 8175 flows that can contiain IP addressing information.
I hope this addresses your concerns. Please let me know if additional discussion is needed.
Regards,
Stan
_______________________________________________
manet mailing list
manet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/manet
