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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F34D91201D0; Thu, 1 Aug 2019 11:34:11 -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 rdgyI5lZqm_K; Thu, 1 Aug 2019 11:34:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95711120168; Thu, 1 Aug 2019 11:34:09 -0700 (PDT)
Received: by with SMTP id d4so70140154edr.13; Thu, 01 Aug 2019 11:34:09 -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=LqXt4Y3QWTIoYDbVq6KZ7rTEz4QTBBLsaBESnzvlB3w=; b=nXZpeJcospZ9wJHDd1ccT8rXjhZZRvt5bd3rRpg2ezwTObeLKHCzE+JaprbAUK0ymp mAivsvDL+XQaFY650Zoa6G7p8Mx+/Vouzk2I/mI5XeignkZE+OpETab7uLe3YS+HHOwp vLSxGOw/e8s/0G6dyit7MXg+H78163TsdRuFFn3TzFtVMSFtv+ozQTBQnj63vIxYcDo5 E1Mn7GmB859oBwnAYxevG1/ilaqnGPBs/LudbSCcEbaLyKXxdQlbTBT2WBRho1dNJ7lD vS/147zCR7NoSXhfHeMfDXlQAUMJOb8hdtkILyvVuBV5cQcruFnPAp5bRndLLGUamtYu Tj5Q==
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=LqXt4Y3QWTIoYDbVq6KZ7rTEz4QTBBLsaBESnzvlB3w=; b=B75ZQpzG9IkWfUKSb1S6gWx6/cQDoJsK4FYOWN8g1BX3hJDGilzyQP8dLCmxYBUUzm HNQ6EJdhnsTCviocMN6Dtrcw2FVpoNjOzIDwhJ3gBZbde/442sCcmfK08ff7GLiBYp/x 1cmOAL8kF+vZvTZQUmmp5RumYAuxbsEV/dTFb7UmVPXdiNSsnhdJ1SwHE+0GgvU9sBvn wxWkIcprPs2UlbGUeJ0qbsF0HIEFK/w3YSNZFFXcJD23GUkzjQKJE6eNTf0vwcc6p4mG 3pli5WfURbaFPFsKKavrU3y6sWpsHGBfAaKqkSCtkQ0CZgzuzAD/uZOHXapmov5GfA78 OkWg==
X-Gm-Message-State: APjAAAXu8oMQql1qvgIXtAGVrCX1M6Qw7F/75tDjl9a89nTwJ9b8IQWx 63tp1T1StvmXwFgi+sIef0LujtHeRTjmwF50Ysc=
X-Google-Smtp-Source: APXvYqwviPQzsfmOj2maA9KyzqpBVwau/AixRNmvEEybvyfTrjl5k6/y3yryZ8q5VtVFCjPWvccc1+FqYOCQJAXJEjA=
X-Received: by 2002:a17:906:e241:: with SMTP id gq1mr100271403ejb.265.1564684447962; Thu, 01 Aug 2019 11:34:07 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 1 Aug 2019 20:34:07 +0200
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Thu, 1 Aug 2019 20:34:07 +0200
Message-ID: <>
To: Rick Taylor <>, "" <>
Cc: "" <>, "" <>, Justin Dean <>
Content-Type: multipart/alternative; boundary="000000000000b4db9e058f127c2c"
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:34:12 -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…