Re: [manet] DLEP-18 Security Considerations

Henning Rogge <> Sun, 07 February 2016 17:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AEE571A016C for <>; Sun, 7 Feb 2016 09:46:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MOU180z_HIaf for <>; Sun, 7 Feb 2016 09:46:35 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1E351A016B for <>; Sun, 7 Feb 2016 09:46:34 -0800 (PST)
Received: by with SMTP id bc4so72528645lbc.2 for <>; Sun, 07 Feb 2016 09:46:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dQM5XglccYcRSwZ3x4yZKCM93c8DJKTN8quKzRVYwMo=; b=DGm5qBt2YphHSKpz/pL9MOEcTO5zxV/h207c2qD7cXAFNP2BnHvCowbllMFWZuZA2s uxBSag4WTXonFDyIf6qX2wq31lhkw0EhIzRvNw7Uc/jumeMC+yhKD2GwQ0xz9i8T5uQY 6AoKnOsb1N/RcPfxcWdbRruU9L2QOWdvrhGV1Npz0TloBNEd8hirB7iJerOjvDZBs2JZ lwc6hidk/QVg51DUIyHxaaIYWy746g+sQau4n+rN4czupeNCqVpTvwXJlpUZel63IbOr xluTtJG7/87qNggwCVhchbocjh9PTsb+FIinZYJ3a3pYz9JkL/6rxp3Ud3FMGm/NK6Se VGaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=dQM5XglccYcRSwZ3x4yZKCM93c8DJKTN8quKzRVYwMo=; b=PS+keQrdML064B7wAJ4ONEXFBU0uMhWq9GdIcBZm7FSuzKaX2wtLxrlJxGaQ66JmZ4 SAgy/MVWbwnUaTcukfSKtpnCRabtUNJfwDIjlrfCIBaQW6lFIkRHneFupkK9vol2CEWE 1/pZFYs75ID3T10unF7Osp0LaK4fq94dvpE77kPydNCbNKngqUUKh+Xow/msUuqflTXa hCzzIg0l6oJorXY3qoJi5XxuWSOTTntOMN7uQ/0tXxdKSWj1xCRjm2io5TAHg7nyUCcG xf5SdF+oW+INVklQoQy6M7RRXmq/nNyROa/3oMoLJ4SzPL3qhE33tFSIcLt9oDYGq8Fx +rAQ==
X-Gm-Message-State: AG10YORjB30E1oFWtHPlQB7AHGwfKFypvmtHd8splcRJ1cz6C+vqMgy+gEoiTKBuHyjRTMkth6qhxDB6NN0OGA==
X-Received: by with SMTP id pz7mr9789230lbb.3.1454867192806; Sun, 07 Feb 2016 09:46:32 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 7 Feb 2016 09:46:03 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Henning Rogge <>
Date: Sun, 7 Feb 2016 18:46:03 +0100
Message-ID: <>
To: Stan Ratliff <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [manet] DLEP-18 Security Considerations
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Feb 2016 17:46:36 -0000

On Sun, Feb 7, 2016 at 5:33 PM, Stan Ratliff <>; wrote:
> All,
> I think the critical point here is Alvaro's comment:
>> The main problem I see with the text below is that it is based on
>> assumptions — even though you do say that "DLEP is restricted to…a single
>> (possibly logical) hop at layer 2", it is based on the deployment
>> assumptions.  What happens if it isn't deployed that way?
> It's NOT an "assumption". We've mis-lableld it as an assumption. It's
> actually a requirement.


> Henning's response to the above text is correct:
> "It will not work because the user traffic will not reach the
> destination. DLEP is the model of a "external radio" which acts as a
> bridge (as in "layer-2 bridge") between the connection to the router
> and the radio network."
> Anyone attempting multi-hop deployment will immediately bump into the issue
> of a router issuing packets with a Destination MAC address that's not on the
> local segment. Traffic won't pass. As Henning states, it simply won't work.
> I believe we need to move the following text from "Assumptions" to
> "Requirements":
>    DLEP assumes that the MAC address for delivering data traffic is the
>    MAC address used by DLEP to identify the destination.  No
>    manipulation or substitution is performed; the MAC address supplied
>    in all destination messages is used as the OSI Layer 2 Destination
>    MAC address.  DLEP also assumes that MAC addresses are unique within
>    the context of a router-modem session.
>    The reliance on MAC addresses by DLEP forces the assumption that
>    participating DLEP peers are on a single segment (either physical or
>    logically, via tunneling protocols) at Layer 2.


> We also need to take the TLS flag out of the IPv4 and IPv6 Connection Point
> data items (a clear "miss" on our part). I believe this addresses the
> concern, in that 1-hop deployment is no longer an "assumption".

If we really want to do TLS we can always add a "TLS Connection Point"
TLV in a later extension draft.

We could also keep the flags field if we think its useful for later,
but I think the TLV format is flexible enough to deal with it when we
need a flags field.