Re: [manet] AD Review of draft-ietf-manet-dlep-lid-extension-04

Alvaro Retana <> Thu, 01 August 2019 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CAEC120182; Thu, 1 Aug 2019 11:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 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, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VB53uiSZ2qWY; Thu, 1 Aug 2019 11:59:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0901120168; Thu, 1 Aug 2019 11:59:20 -0700 (PDT)
Received: by with SMTP id s49so35349889edb.1; Thu, 01 Aug 2019 11:59:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=KzLXPSmAb3A0Heje7g8YitusQ0h3WE1rJcKuU7Qbx0k=; b=Yex5HFK39LVyG53sn1mp4utDnbhzmrE8XcZOMFFMrimq4WrqjpLIPYHumDWo1VVlWG mY4unfYAh9y1ptcvqiZEHe0do7s18UT6c3jfVj6j3k2ioTNJTqBSyAmOz/3uKjLvLdKB B5fGg4YNJRTNL894FwThpAg4WCSfYXV103L/prk0j29NCOwxVAs3oo2ilqlIeyAqa8Sz qjNlDPQNgHU94QHaiBtfwBQea1+ps8G4azuzkC35Ug4y5SvbTfn4iQOKt6covMQD5kjN 9UoydCHr/+rMxMEcWyjfE8boGEBElT1VIH6XWhO7EQXL19mCpyD/C+9tY4Uj4EfiMCti ZMWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=KzLXPSmAb3A0Heje7g8YitusQ0h3WE1rJcKuU7Qbx0k=; b=IPhM/mkzSTao5p+PTRB/khSy1VPnofGhnOhpD7Mq/Vq+W76S+nIXr6MgA+Zmsiw5Yh EaD1KsJoX7ZuzosMeScPFSDa2lNsHx0i1F1ma8OFZLvGXnBzt5/3HVOcA6BTc9GaO1es yxaFdF+TsW3+Oz55NpZLQP090IHNtztb/3sh2lq7Z8dip2TWQnOcdwQWKO4ehLpeGWE4 aFs7Dq+DxibYdYsdKzgDpL3CSFEmd7HiN0DmqxuyL88+ua8k3eTQDxNydA+rgLn+HG5j xVXQFfy2mIHVcDwqIqbqdvpBuPE11sfBEhTEIUbi2cp9pgqnFCV//Wrf9qtib0V8Csl7 xNJw==
X-Gm-Message-State: APjAAAU/yIeTYSi4aVi+M5MlhCrL7N1lAR8MLhdBwlwBEZ9betNc22bG iLkSKIdipk0f964UbWuOzAWM1cc+5sKtMDvenyE=
X-Google-Smtp-Source: APXvYqwhYikXGJXI9kylIKteVC2KpzETk00edKA/NJBQuhb2M4/INMah2EI6bTYVXrTCHg2NM+0j+RTk2c9iFZskU8U=
X-Received: by 2002:a50:a5ec:: with SMTP id b41mr111759644edc.52.1564685959485; Thu, 01 Aug 2019 11:59:19 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 1 Aug 2019 20:59:18 +0200
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Thu, 01 Aug 2019 20:59:18 +0200
Message-ID: <>
To: Rick Taylor <>, "" <>
Cc: "" <>, "" <>, Justin Dean <>
Content-Type: multipart/alternative; boundary="000000000000ccde41058f12d69e"
Archived-At: <>
Subject: Re: [manet] AD Review of draft-ietf-manet-dlep-lid-extension-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Aug 2019 18:59:23 -0000

On July 30, 2019 at 12:13:46 PM, Rick Taylor (



I am starting the IETF LC.

My only remaining comments are about security (see below), but we can deal
with that as we get other reviews.



Comments inline, but a little forward:

We have done a rewrite of most of the descriptive text, focussing on
the use-cases, and attempting to clearly define terminology to aid the

I think that helps. :-)

The new text in the Abstract/Introduction says: "The core specification of
the protocol assumes that every modem in the radio network has an attached
DLEP router, and requires that the MAC address of the DLEP interface on the
attached router be used to identify the destination in the network…  This
document describes a DLEP Extension allowing modems that do not meet the
strict requirement above…”.   It is not clear if the “strict requirement”
you refer to is the assumption that a router is attached, or that its MAC
address is used…or both.   I think this is important to justify that, for
example, other Security Considerations are not created.  Just trying to
cover our bases…I don’t have anything specific to point out.


> ...
> 11 Abstract
> 13 There exists a class of modems that would benefit from
> supporting the
> 14 Dynamic Link Exchange Protocol (DLEP) [RFC8175] but do not
> present a
> 15 single Layer 2 network domain as required by DLEP. Such
> devices may
> 16 be:
> [nit] Don't include references in the Abstract.

I don't know how to avoid this - can you suggest some text please?

s/[RFC8175]/(RFC8175)  ;-)


> 173 2.1. Identifier Restrictions
> 175 A Link Identifier is by default 4 octets in length. If a
> modem
> 176 wishes to use a Link Identifier of a different length, it
> MUST be
> 177 announced using the Link Identifier Length Data Item
> (Section 3.1)
> 178 contained in the DLEP Session Initialization Response
> message sent by
> 179 the modem to the router.
> 181 During the lifetime of a DLEP session, the length of Link
> Identifiers
> 182 MUST remain constant, i.e. the Length field of the Link
> Identifier
> 183 Data Item MUST NOT differ between destinations.
> [major] This is another case where the session could be terminated if
> the wrong length is used... Call out as a risk.

Damn.. I missed this one. I shall have to uprev with specific
Termination rules.



> ...
> 281 4. Security Considerations
> 283 As an extension to the core DLEP protocol, the security
> 284 considerations of that protocol apply to this extension.
> This
> 285 extension adds no additional security mechanisms or
> features.
> 287 None of the features introduced by this extension require
> extra
> 288 consideration by an implementation.
> [major] I think that the functionality in this extension may result
> in Invalid Data (and a terminated session) -- see the comments in
> §2/2.1 above. While this case may only be the result of a rogue
> modem/router, and rfc8175 already says something general about that,
> it is important to point it out here because the
> functionality/operation is new.

Having called out the additional reasons for termination, I don't see
that any of them cause any additional security considerations beyond
normal DLEP. The consideration is: deviate from the protocol and your
session will terminate - that's covered by DLEP.

True…but now with a bigger attack surface.  I would love to see something
pointing at rogue routers/modems taking advantage of termination
opportunities…but we can also wait and see what the SecDir/SEC ADs say…