Re: [secdir] [manet] Secdir last call review of draft-ietf-manet-dlep-lid-extension-05

Stan Ratliff <> Mon, 19 August 2019 00:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F84F12012D; Sun, 18 Aug 2019 17:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6kmHS2R8wOHO; Sun, 18 Aug 2019 17:32:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA724120052; Sun, 18 Aug 2019 17:32:41 -0700 (PDT)
Received: by with SMTP id n9so109677pgc.1; Sun, 18 Aug 2019 17:32:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pAv0nHfvRc4YWW4/vSj2VoUfB1CYtGduyFqjjl+OQJY=; b=rwzuk8zyjLuosWDnD3621Lit7bg3/133cK60TFSjA2Qe0uvf/NopC9n9BaUQnvBQ26 o00VRUePwLoQzj5WSB+oE89uUnUxDPnu6Wd8lOoRUwFtQ3khBiq4LKdcRe1BFyxhVAcr vCTJgh6dqF3Gj8wj3z1isqWXUeKBqNYaGTEHZond8aNfRFgWGu5Pd+yl0+LQe5V4sSAg /RY9aP3S582qoNvFizP62FOZByfhQmbuZ6Qsto21v6BWKjAuSyfUNqNHqJoAcOhhvPK9 R0j9fiGxP9GCvR5CJTgalgpti8mfRH8SvgZKuTca4hEBuBAwaTLxVrOt/uFCIySDBYGS +PEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pAv0nHfvRc4YWW4/vSj2VoUfB1CYtGduyFqjjl+OQJY=; b=Cc+N1ecBPyG1z/QuXEb6TnrbhStSPUagem6jH107FibBE4vdMezscJwZxq8v//i21p zudbI7nSQ39apPLcD3zqkMWY875KykAhlxSQUDwBPjbfqE9oS4O06wT0Yo7nGlnOgKlk PaB5Sm1NVtb4bifIxeeAWdvV3OFlIkmIuZvsrEwTbSxb7LEQn3kLQBQ5CjqcGf2lokAZ +L75OvMD1317PaBTtuUjkgx820a5Tfv/GjxQUqwdoCN7MzIjHcJmL4qIHm5f0h4R08Jp MEG2BbgN61o43PK21RXM5VI21JmkeCIMC/sM96IsnRg3LZq7ZVowOmxEYE8XyYIXrB/g GpFg==
X-Gm-Message-State: APjAAAVUxyp6h/bzNyj0BRPwMqOqfM4HMTgY4NIcUUqjfd04jEXZTFi+ wjC1MKfyJTWXxWU19G7CLBAqBh02jN7EwyIfU2A=
X-Google-Smtp-Source: APXvYqzseGBuXGWJkPmsdmlSiPyrcYiIpe3BG6bQ1QLHRrFZqDjs8OWAcL2JjQzfPup9tTb9Tu+8xRvJBqZ34AZT+A4=
X-Received: by 2002:a17:90a:35e3:: with SMTP id r90mr18460354pjb.34.1566174760178; Sun, 18 Aug 2019 17:32:40 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Stan Ratliff <>
Date: Sun, 18 Aug 2019 20:32:29 -0400
Message-ID: <>
To: Nancy Cam-Winget <>
Cc:,, MANET IETF <>,
Content-Type: multipart/alternative; boundary="0000000000003c981a05906d7a6b"
Archived-At: <>
Subject: Re: [secdir] [manet] Secdir last call review of draft-ietf-manet-dlep-lid-extension-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Aug 2019 00:32:44 -0000

Hello. Thank you for the review and comments. Responses inline.

On Mon, Aug 12, 2019 at 4:28 PM Nancy Cam-Winget via Datatracker <> 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.


> _______________________________________________
> manet mailing list