Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

Jiazi YI <ietf@jiaziyi.com> Wed, 27 April 2016 22:35 UTC

Return-Path: <yi.jiazi@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA0312B071 for <manet@ietfa.amsl.com>; Wed, 27 Apr 2016 15:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.093
X-Spam-Level:
X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdp7F7B2BCho for <manet@ietfa.amsl.com>; Wed, 27 Apr 2016 15:35:00 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF79C12B03F for <manet@ietf.org>; Wed, 27 Apr 2016 15:34:57 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id j11so74118870lfb.1 for <manet@ietf.org>; Wed, 27 Apr 2016 15:34:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=lnx8MWUV8j/P844mjaKw11la9SojPNNl3gqAR4pAinE=; b=z8T3c7NoFo92sbotyy6mSQiyKnIRMk5yCTk0Vug31Sql0zkOMqMwemw9GyOnwcVgEm Ub1I9/prvO/s0K/Ocx4X+un0NiCryQmXE0Vh6bhJX809xS7S62kq4Ch1p6bpODRvixVd b+qTA3UX6KxDSUusABI70KYdA6dkagFmDWk+08rNKkz8PtDpdSY/ZKGR9GzVgxjqhnKI K7BIaTod2MKTZiUik+HPP56mP5zG8aQS63rGj36C97B63/Tf9Q/L53YJEvZooM8CHhQK PZ8co8Pb/3S4oqebV+RjIxpdb/NWiCuP23U/DRNLWV0HEIGrHnftCR8JeMUHIEfjoXkn 6tOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lnx8MWUV8j/P844mjaKw11la9SojPNNl3gqAR4pAinE=; b=YTxKSnqKOCSY1YVuSnyDeSwrIv4vo28hrDZNVQz7WoHrtGaR3iKs33dmJ1p01Sw1IO qvmC1/Aljc4CnC7pGH2iO6FpZxdEj8FXqxgFnu+kRI4OF7JJptoM8wVs6HOydyHLrzPL RWgt9cnnQHMfJfEV/q69H6IcOOzoQ+lIc+FTqdtuwpMJsYTC6UoCr+vWiERp+xUzFOoO VHdcL+UskYgXu5ltmHeKa/EPQvINTqqVn2H7onPMdf/1tdby4ruyCfBIkgtTIjRrtUCj SawBBkQmJXdf+h3rdNr0q6iOPtu1wjaoTMxSWWZ18j1T3bEzyrd1EohI171pOScuJVB7 FH5A==
X-Gm-Message-State: AOPr4FVuK9CcBvSrgPQ9614EkAAG3G/mQSyQWpUyICxhOAZKqGPsQo3ss4zqjoBb8P6xt1QLaOFROYkGkHrfjg==
MIME-Version: 1.0
X-Received: by 10.25.38.69 with SMTP id m66mr4612572lfm.64.1461796495912; Wed, 27 Apr 2016 15:34:55 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.114.77.4 with HTTP; Wed, 27 Apr 2016 15:34:55 -0700 (PDT)
In-Reply-To: <CAAePS4B81Ep3Gg6bROceqTHAj0LhKDFAsAUWPuF=3hLoVMu5cQ@mail.gmail.com>
References: <B31EEDDDB8ED7E4A93FDF12A4EECD30D9237E267@GLKXM0002V.GREENLNK.net> <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org> <B31EEDDDB8ED7E4A93FDF12A4EECD30D9237E2C8@GLKXM0002V.GREENLNK.net> <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de> <B31EEDDDB8ED7E4A93FDF12A4EECD30D9237E324@GLKXM0002V.GREENLNK.net> <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org> <B31EEDDDB8ED7E4A93FDF12A4EECD30D9237E356@GLKXM0002V.GREENLNK.net> <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org> <CAAePS4D3A3g7NbZ4jND04xhJ2Q+gbGP-7sXZ4p4eC55=ejiWLw@mail.gmail.com> <B0317B9B-09AA-48A5-90C2-2A8DA51C8281@mnemosyne.demon.co.uk> <CAAePS4DCHy6R_Ht7KF3MoeZ7ML+BawnobC92VLQZyS5FaA7vdQ@mail.gmail.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D923B12C9@GLKXM0002V.GREENLNK.net> <CAN1bDFwyTFatXOkuY+N2czFPqVmoygRjSCRG2bubS=sBhLqE7A@mail.gmail.com> <CAAePS4Botm8kfQXuJczHC_rYfjtisDrTk5Vdb5m2LafP2qkTTg@mail.gmail.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1556@GLKXM0002V.GREENLNK.net> <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org> <CA+-pDCdy=9Bea4nwQ5k8hqAPTJ04RgvdeDqHaj6MXeRnFj-3dg@mail.gmail.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D923B15E3@GLKXM0002V.GREENLNK.net> <CAAePS4APf3PsKdbzOZv1kd9oAP_3AUDPxoM9oor=NkjBGExFbg@mail.gmail.com> <CAN1bDFzv0R9UzykYwm-9JK7OVYYHeNzxXYNWRsx87T7ODNmVDw@mail.gmail.com> <CA+-pDCf7zvhagsH--OrX7ASHVi994Oq9P-Kj-udg0047joFRSA@mail.gmail.com> <CAAePS4B81Ep3Gg6bROceqTHAj0LhKDFAsAUWPuF=3hLoVMu5cQ@mail.gmail.com>
Date: Thu, 28 Apr 2016 00:34:55 +0200
X-Google-Sender-Auth: tevlwfm8f_FjB2-RbUB2GGwM2cc
Message-ID: <CAN1bDFzAWQiF=fM5+3Xz=D130mq8teY3E_UEGoXUSTcV6QN2eg@mail.gmail.com>
From: Jiazi YI <ietf@jiaziyi.com>
To: Victoria Mercieca <vmercieca0@gmail.com>
Content-Type: multipart/alternative; boundary="001a113db104df789105317f0448"
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/Okuyx_9f6e4_zt8bv1YRK-POjJY>
Cc: Christopher Dearlove <chris@mnemosyne.demon.co.uk>, Mobile Ad Hoc Networks mailing list <manet@ietf.org>, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2016 22:35:06 -0000

On Wed, Apr 27, 2016 at 10:59 PM, Victoria Mercieca <vmercieca0@gmail.com>
wrote:

> Just quickly, on this note, if we remove the AckReq from the RREP itself,
> then because the RREP is multicast, there might be multiple receivers, but
> there's no way for them to determine if they were the intended next hop, so
> they would all have to forward the RREP. The RREP might then go by multiple
> routes to get to RREQ_Gen. This assumes all receivers of the RREP have a
> route to OrigAddr anyway (current rules say if they didnt, they would send
> a RERR back to RREP_Gen).
>
> So, do we have to install a route to the neighbour, then unicast the RREP
> and create a separate message with an AckReq, then if no acknowledgement is
> received, blacklist the neighbor and remove the route to the neighbor?
> along with the route to OrigAddr which is not available because the link is
> not bidirectional...?
>

My opinion is, if we have a neighbor address and the interface through
which the neighbor can be (possibly) reached, then we can send an unicast
to it.
The others are more implementation details: for example, if a route to the
neighbor is required, we can setup a temporary route entry to the neighbor,
and remove it after the unicast is finished. As it's more implementation, I
don't think it's necessary to go to the specification.

Another related question: when I was reading the specification, a router
only sets up routes to the source/destination, but not to its direct
neighbors?

best

Jiazi


>
> Regards,
> Victoria.
>
> On Mon, Apr 25, 2016 at 4:34 PM, Justin Dean <bebemaster@gmail.com> wrote:
>
>> On Mon, Apr 25, 2016 at 11:29 AM, Jiazi YI <ietf@jiaziyi.com> wrote:
>>
>>> Hi,
>>>
>>> Maybe I missed a bit here:
>>>
>>> If only the desired receiver of the multicast RREP (carrying a
>>> destination address) can reply to the multicast RREP, why not using unicast
>>> directly?
>>>
>>> Because the link isn't yet known to be bi-directional and a unicast
>> route can't be installed yet.
>>
>> Justin
>>
>>
>>> best
>>>
>>> Jiazi
>>>
>>> On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca <vmercieca0@gmail.com
>>> > wrote:
>>>
>>>> Hi Chris,
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>>> I has to go back to Victoria’s summary here. It says:
>>>>>
>>>>>
>>>>>
>>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>>> bidirectional, it includes the AckReq (an address to indicate that it
>>>>> expects to receive a RREP_Ack from B).
>>>>>
>>>>>
>>>>>
>>>>> That doesn’t actually indicate if that’s C’s address or B’s address
>>>>> being included. I’d assumed it was C’s address. Your comment makes sense if
>>>>> it’s B’s address. Reading again, I think you’re probably right. But only
>>>>> probably. Can we confirm that.
>>>>>
>>>>>
>>>>>
>>>>
>>>> C creates the RREP. The included AckReq address is B's address. The
>>>> RREP then gets multicast.
>>>> B receives it, sees that it own address is marked as the AckReq
>>>> address, and sends an ack unicast back to C.
>>>> Anyone else who receives the multicast RREP from C does not send the
>>>> Ack, since the AckReq address does not match any of their interface
>>>> addresses.
>>>>
>>>>
>>>>> I assume you meant that the RREP (not RREP_Ack) is multicast. There’s
>>>>> a bit of a chicken and egg problem here. We do know how we want to unicast.
>>>>>
>>>>
>>>> The RREP is multicast (when we dont know if the link is bidirectional),
>>>> the RREP_Ack is always unicast.
>>>>
>>>> Kind regards,
>>>> Vicky.
>>>>
>>>>
>>>>>
>>>>> *-- *
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *__________________________________________________________________________
>>>>> *
>>>>> *T*:  +44 (0)1245 242194  |  *E: *chris.dearlove@baesystems.com
>>>>>
>>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>>> www.baesystems.com/ai
>>>>>
>>>>> BAE Systems Applied Intelligence Limited
>>>>> Registered in England & Wales No: 01337451
>>>>>
>>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>>>>
>>>>>
>>>>>
>>>>> *From:* Justin Dean [mailto:bebemaster@gmail.com]
>>>>> *Sent:* 25 April 2016 15:26
>>>>> *To:* Thomas Heide Clausen
>>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>>>> Networks mailing list; Victoria Mercieca
>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>> *This message originates from outside our organisation, either from an
>>>>> external partner or the internet.*
>>>>>
>>>>> * Consider carefully whether you should click on any links, open any
>>>>> attachments or reply. For information regarding **Red Flags** that
>>>>> you can look out for in emails you receive, click here
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
>>>>> * If you feel the email is suspicious, please follow this process
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>>>>>
>>>>> The address in the RREP_Ack may be required due to the RREP_Ack being
>>>>> multicast as there is not yet a verified unicast route installed yet.
>>>>> Going to double check if I'm remembering correctly.
>>>>>
>>>>> Justin
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 25, 2016 at 10:18 AM, <ietf@thomasclausen.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> I must admit that while I have reviewed the protocol several times,
>>>>> I’ve not been digging that deep into the protocol functioning to catch this
>>>>> issue of how invasive the protocol operations are when forwarding a
>>>>> message: there were other “major” issues to address (and which obscured the
>>>>> details), so as a first order: thank you Victoria, for having called
>>>>> attention to this.
>>>>>
>>>>>
>>>>>
>>>>> To the substance of these emails.
>>>>>
>>>>>
>>>>>
>>>>> I am afraid that I do not understand the use of inserting validity
>>>>> TLVs while in-flight, into a message. Actually, I am dubious for both the
>>>>> originator inserting this (how can the originator of a message know how
>>>>> “latter parts of the path” will be have”) except if we are talking
>>>>> duty-cycling of devices and inserting “the remaining time that I am going
>>>>> to be up before I suspend”. Intuitively, that would also assume fairly long
>>>>> duty cycles “I am up for tens of seconds”, which I am not sure are actually
>>>>> realistic. And, as Chris says in another email, this is trading off “the
>>>>> ability to do security” for an unknown/untested feature — which I think is
>>>>> the wrong trade-off.
>>>>>
>>>>>
>>>>>
>>>>> On he topic of “needing to put an address in” for RREP-ACK, I must
>>>>> admit that this seems roundabout. I can see three issues here:
>>>>>
>>>>>
>>>>>
>>>>> o I am not sure that adding an address vs. a flag may not have to do
>>>>> with the “multiple interfaces/
>>>>>
>>>>> multiple addresses” discrimination mechanics of the protocol? I
>>>>> haven’t worked it through, though,
>>>>>
>>>>> but that would be a guess.
>>>>>
>>>>>
>>>>>
>>>>> o The end-to-end topology diffusion mechanism should not need to be
>>>>> concerned with the
>>>>>
>>>>> “bidirectionally check” of a local link (in part, as it encumbers
>>>>> security, but not only).  In short, a
>>>>>
>>>>> flag or an address, both are (equally) bad.
>>>>>
>>>>>
>>>>>
>>>>> o A cleaner mechanism would be a “hello mechanism”, not necessarily as
>>>>> NHDP, but a “when
>>>>>
>>>>> forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link is
>>>>> estimated to be of a
>>>>>
>>>>> type which potentially can be unidirectional”. There is another
>>>>> benefit to doing that, see the end
>>>>>
>>>>> of this email.
>>>>>
>>>>>
>>>>>
>>>>> Either way, I do not like the notion of fusing
>>>>> metrics-and-link-bidirectionality-detection any more than I like fusing
>>>>> global-topology-diffusion-and-link-bidirectionality-detection.
>>>>>
>>>>>
>>>>>
>>>>> The solution all this is, to me, threefold
>>>>>
>>>>>
>>>>>
>>>>> 1) Factor out the bidirectionally check in a (triggered) neighbour
>>>>> detection mechanism
>>>>>
>>>>> (triggered HELLO message)
>>>>>
>>>>>
>>>>>
>>>>> 2) Remove the “validity time TLVs”, since they add complexity for no
>>>>> perceivable benefits
>>>>>
>>>>>
>>>>>
>>>>> 3) Use the security model that we’ve discussed previously, where
>>>>> (only) the metrics change per hop.
>>>>>
>>>>>
>>>>>
>>>>> Since we’re discussing bi-directionality of links here, and the
>>>>> necessity of a mechanism for handling these, I want to call attention to a
>>>>> related issue, as I hinted previously.
>>>>>
>>>>>
>>>>>
>>>>> The abstract states that the protocol:
>>>>>
>>>>>
>>>>>
>>>>>    ...is intended for use by mobile routers in wireless, multihop
>>>>>
>>>>>    networks.
>>>>>
>>>>>
>>>>>
>>>>> Section 5 paragraph 4  of the document, however, reads:
>>>>>
>>>>>
>>>>>
>>>>>    Assuming link metrics are symmetric, the cost of the routes installed
>>>>>
>>>>>    in the Local Route Set at each router will be correct.  While this
>>>>>
>>>>>    assumption is not always correct, calculating incoming/outgoing
>>>>>
>>>>>    metric data is outside of scope of this document.
>>>>>
>>>>>
>>>>>
>>>>> I do not know of *any* wireless systems, where the assumption that
>>>>> “link metrics are symmetric” actually holds. Consequently, the conclusion
>>>>> in the quoted paragraph:
>>>>>
>>>>>
>>>>>
>>>>>    calculating incoming/outgoing
>>>>>
>>>>>    metric data is outside of scope of this document.
>>>>>
>>>>>
>>>>>
>>>>> Is not an acceptable design choice.
>>>>>
>>>>>
>>>>>
>>>>> While this protocol may not want to “calculate if for this link the
>>>>> metrics is 4 or 5”, the protocol must be able to convey and distinguish
>>>>> that “the metric from A to B is 4, and the metric from B to A is 19”.
>>>>>
>>>>>
>>>>>
>>>>> This is a “related issue” since the solution may (as with the
>>>>> bi-directionality check) be in the triggered neighbour detection mechanism:
>>>>> that exchange could, if designed carefully, be used to probe for and convey
>>>>> metrics information, also.
>>>>>
>>>>>
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Assuming for the moment that everyone will need an RREP-Ack or won’t
>>>>> (let’s come back to that) why do C and B need to put an address in as an
>>>>> RREQ-Ack request? Why not a flag, because the address will be included as
>>>>> the IP sending address - and we know 5444 is required to pass that on.
>>>>> (It’s used by NHDP as well.) Then we don’t need to change the RREP, it will
>>>>> have a flag set or not, and won’t change (in this regard).
>>>>>
>>>>>
>>>>>
>>>>> Now let’s consider do we know whether we can set a fixed flag. First
>>>>> I’d say there are two cases - you’ve got a firm control on what’s going on
>>>>> in your network, or it’s one of unknown parties and behaviour (consistent
>>>>> with specification). In the former case you only want one setting, for
>>>>> example no-Ack if running NHDP or your MAC layer tells you about
>>>>> bidirectionality, Ack otherwise. In the latter case, I think you just
>>>>> always want an Ack. So both cases get you to the same place.
>>>>>
>>>>>
>>>>>
>>>>> Should that not be an acceptable argument (though I think it’s good
>>>>> for where we are - in fact always Ack is close) then at flag is a step
>>>>> better, it’s a fixed location to change. However it would be better in that
>>>>> case if the two things to change (metric and ack flag) were together. But
>>>>> that has its own issues, so I won’t go there.
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *__________________________________________________________________________
>>>>> *
>>>>> *T*:  +44 (0)1245 242194  |  *E: *chris.dearlove@baesystems.com
>>>>>
>>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>>> www.baesystems.com/ai
>>>>>
>>>>> BAE Systems Applied Intelligence Limited
>>>>> Registered in England & Wales No: 01337451
>>>>>
>>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>>>>
>>>>>
>>>>>
>>>>> *From:* Victoria Mercieca [mailto:vmercieca0@gmail.com
>>>>> <vmercieca0@gmail.com>]
>>>>> *Sent:* 25 April 2016 14:15
>>>>> *To:* Jiazi YI
>>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>>>> Networks mailing list
>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>> *This message originates from outside our organisation, either from an
>>>>> external partner or the internet.*
>>>>>
>>>>> * Consider carefully whether you should click on any links, open any
>>>>> attachments or reply. For information regarding **Red Flags** that
>>>>> you can look out for in emails you receive, click here
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
>>>>> * If you feel the email is suspicious, please follow this process
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>>>>>
>>>>> Hi Jiazi,
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>> With regard to your validity time point, we here have a tradeoff. If
>>>>> you allow that feature, it significantly impacts on the approach that was
>>>>> coming together on as best you can end to end encryption.
>>>>>
>>>>>
>>>>>
>>>>> So the question is, is this a feature that’s really wanted?
>>>>> Unfortunately I think we know that the answer to that is, we don’t know
>>>>> because we don’t have any experience. My view would be that in the tradeoff
>>>>> of an untested feature (unless I’m wrong about that) and the security
>>>>> complication, security wins and drop the feature. If there is some real
>>>>> requirement, then there’s a discussion. (Questions like how often the
>>>>> intermediate routers actually have any knowledge - typically links break
>>>>> for unexpected rather than expected reasons. Andan intermediate router
>>>>> could possibly use a validity time to influence its behaviour.) Note that
>>>>> dropping the ability of intermediate routers to modify/set still allows
>>>>> validity times per route to be set at endpoints.
>>>>>
>>>>>
>>>>>
>>>>> I agree with Chris' concern.
>>>>>
>>>>> The ValidityTime is optional, which makes the integrity protection
>>>>> hard. Furthermore, it gives a potential attack vector: as all the routers
>>>>> in a path will take the shortest validityTime, a compromised router can set
>>>>> the the validityTime to a very short value, which will make the route
>>>>> installed along the path became invalid (very soon).
>>>>>
>>>>>
>>>>>
>>>>> On the other hand, I'm not sure this option will give us much help.
>>>>> Chris mentioned much knowledge intermediate router would have to decide
>>>>> this value (and how much sense the value would make).
>>>>>
>>>>> Another issue is, a route to a destination might be updated by
>>>>> different sources. For example, in the network below:
>>>>>
>>>>>
>>>>>
>>>>> A----B-----C
>>>>>
>>>>>
>>>>>
>>>>> A first establish a route to B with long validity time. Then A
>>>>> initiates a route discovery to C. C tends to set a short validity time,
>>>>> which will make the route between B and A expire earlier than expected.
>>>>>
>>>>> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered
>>>>> or not.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Not sure I follow here.
>>>>>
>>>>> Currently, the validity time of the route between A and B would not
>>>>> affected by a short validity time of a route between A and C. Validity
>>>>> times are per-route, and the route A-B and the route A-C are separate.
>>>>>
>>>>> If we switched to a validity time per neighbor (so that we can keep
>>>>> validity time separate from route advertisements) as I mentioned in the
>>>>> email below, then the validity of a route between A and C would be affected
>>>>> if there was a short validity time between A and B. But, if B will only
>>>>> route for a certain amount of time, then the route between A and C will of
>>>>> course be affected. Is it best to know in advance that there's a time
>>>>> limit, or just deal with RERRs when they happen?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> With regard to the acknowledgements, the problem (with regard to
>>>>> security) comes from trying to do two jobs with the same message - end to
>>>>> end route advertisement and hop by hop acknowledgement. I understand the
>>>>> reasons - saving bytes and message types. (I would have to study the
>>>>> protocol really hard to identify if any message types can be folded
>>>>> together and recognised by content rather than type efficiently. This I do
>>>>> not expect to do.) Again a tradeoff. This one is in discussion space,
>>>>> though that needs people who understand both sides of the issue, including
>>>>> the details of the bidirectionality mechanism. Of course, as has been said,
>>>>> we need one of those.
>>>>>
>>>>>
>>>>>
>>>>> I haven't finished my review of the latest draft, and I don't get the
>>>>> necessity of AckReq and the corresponding multicast RREP yet.
>>>>>
>>>>> If possible, this "optional" field should be avoided.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> To give an overview of AckReq and RREP:
>>>>>
>>>>> Since AODVv2 requires bidirectional links, this is the way to
>>>>> determine if a link is bidirectional.
>>>>>
>>>>> A----B----C
>>>>>
>>>>>
>>>>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both
>>>>> install a route to OrigAddr but they dont yet know if it's valid because
>>>>> they dont know if the link to their next hop is available in the reverse
>>>>> direction.
>>>>>
>>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>>> bidirectional, it includes the AckReq (an address to indicate that it
>>>>> expects to receive a RREP_Ack from B).
>>>>>
>>>>> 3) B receives the RREP, installs a route to TargAddr and marks it as
>>>>> valid, since it knows the link to C is bidirectional, because the RREQ went
>>>>> in one direction and the RREP came in the other. B also sends the RREP_Ack
>>>>> to C and forwards the RREP to A (and might change the message to indicate
>>>>> its own AckReq - ie that it requires an ack from A).
>>>>>
>>>>> 4) C receives the RREP_Ack from B, and therefore knows that B received
>>>>> the RREP, therefore the link is bidirectional. C can then mark its route to
>>>>> OrigAddr as valid.
>>>>>
>>>>> 5) Similarly, A receives the RREP, installs the route to TargAddr and
>>>>> sends an RREP_Ack to B.
>>>>>
>>>>> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>>>>>
>>>>>
>>>>>
>>>>> Alternatively, in step 2, if C knows the link to B is bidirectional
>>>>> (perhaps from some earlier route discovery), it doesnt need to put the
>>>>> AckReq in the RREP. Then in step 3, since B doesnt know if the link to A is
>>>>> bidirectional, it changes the message to add the AckReq address, in order
>>>>> to get an RREP_Ack from A.
>>>>>
>>>>> If we want to avoid changing the message, we'll need to look at
>>>>> forwarding the RREP as-is, and creating a second message to solicit an
>>>>> RREP_Ack, in order to verify that the link is bidirectional before marking
>>>>> the route to OrigAddr as valid.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Victoria.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> regards
>>>>>
>>>>>
>>>>>
>>>>> Jiazi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *__________________________________________________________________________
>>>>> *
>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
>>>>> chris.dearlove@baesystems.com
>>>>>
>>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>>> www.baesystems.com/ai
>>>>>
>>>>> BAE Systems Applied Intelligence Limited
>>>>> Registered in England & Wales No: 01337451
>>>>>
>>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>>>>
>>>>>
>>>>>
>>>>> *From:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
>>>>> *Sent:* 23 April 2016 10:55
>>>>> *To:* Christopher Dearlove
>>>>> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad
>>>>> Hoc Networks mailing list
>>>>>
>>>>>
>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> *This message originates from outside our organisation, either from an
>>>>> external partner or the internet. Consider carefully whether you should
>>>>> click on any links, open any attachments or reply. For information
>>>>> regarding **Red Flags*
>>>>> * that you can look out for in emails you receive, click here
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
>>>>> If you feel the email is suspicious, please follow this process
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>>
>>>>>
>>>>> These have both been in the draft in some form since before I got
>>>>> involved... but I'll do my best to explain.
>>>>>
>>>>>
>>>>>
>>>>> - For Validity Time, its a way to advertise that you would only
>>>>> support the route contained in the message for a certain period of time.
>>>>> The originator might use this, but the draft was written to allow any
>>>>> intermediate node to be able to add it or update it too. The route created
>>>>> in the Local Route Set has an expiration time associated with it, based on
>>>>> the received validity time.
>>>>>
>>>>> - For the AckReq address, its so that you can add into a RREP a
>>>>> request for an acknowledgement, so that you don't have to have a different
>>>>> message type altogether for working out whether links to neighbors are
>>>>> bidirectional, and also, since you only care about bidirectionality on
>>>>> routes that are being set up, you dont need to constantly monitor all
>>>>> neighbors.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> In order to avoid the potential AckReq-related changes to each
>>>>> message, maybe we do need to introduce a different message specifically for
>>>>> this. We could maybe use RREP_Ack to both request and acknowledge? It means
>>>>> an extra message of control traffic that needs to be sent, maybe one extra
>>>>> message per hop on the path of a RREP, but it could still be limited to
>>>>> neighbors which have participated in the route discovery rather than
>>>>> monitoring all neighbors at all times.
>>>>>
>>>>>
>>>>>
>>>>> This message could maybe also include "I'm happy to route anywhere for
>>>>> a certain amount of time", sort of like willingness in OLSR/OLSRv2. So
>>>>> instead of having a validity time per route, its a validity time per
>>>>> neighbor. Then, for RREQ and RREP, only the metric value would change in
>>>>> transit, as discussed. However, that leads to some issues with deciding
>>>>> what a route's expiration time is. You might know how long the next hop
>>>>> router is valid for, but what if a router beyond that, which was also part
>>>>> of the route, had a lower validity time? You couldn't determine the real
>>>>> validity time. Do we remove the route expiration time altogether to avoid
>>>>> this issue? In which case, we would have to rely on RERR messages being
>>>>> sent for routes which become invalid when the neighbor's validity time has
>>>>> expired? So neighbor validity time expiration is treated the same as a link
>>>>> break.
>>>>>
>>>>>
>>>>>
>>>>> What do you think?
>>>>>
>>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Victoria.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
>>>>> chris@mnemosyne.demon.co.uk> wrote:
>>>>>
>>>>> Pretty much all of the discussion has been assuming only a metric
>>>>> value change. With multiple things changing many of the ideas go out of the
>>>>> window. That reinforces the point about not making specifications now that
>>>>> might turn out to be wrong for ICVs.
>>>>>
>>>>>
>>>>>
>>>>> Ignoring how this misunderstanding happened, I'll start by asking why.
>>>>> Metric changing I understand. Why the other two? (there's a partial
>>>>> explanation of one). What alternatives have people implemented in
>>>>> comparable protocols?
>>>>>
>>>>> --
>>>>>
>>>>> Christopher Dearlove
>>>>>
>>>>> christopher.dearlove@gmail.com (iPhone)
>>>>>
>>>>> chris@mnemosyne.demon.co.uk (home)
>>>>>
>>>>>
>>>>> On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> Continued in this thread because the other one seems to be more about
>>>>> TLV types and metric type numbers, whereas this is about
>>>>> regeneration/forwarding.
>>>>>
>>>>>
>>>>>
>>>>> To recap, in the current draft, there are 3 things that might change
>>>>> at each hop:
>>>>> - the metric value (happens in RREQ and RREP),
>>>>> - adding/changing Validity Time using the Validity Time TLV (can
>>>>> happen in RREQ and RREP),
>>>>> - adding an address (and corresponding value in the AddressType TLV to
>>>>> indicate how to interpret the address) to indicate the address from which
>>>>> an RREP_Ack is expected, to accomplish the bidirectionality check (can
>>>>> happen in RREP).
>>>>>
>>>>> If we define a certain portion of the message as immutable and include
>>>>> the ICV to verify that part, end to end:
>>>>> - The metric value would be excluded from the ICV since it needs
>>>>> changing at each hop.
>>>>> - Would adding a Validity Time TLV at an intermediate hop be
>>>>> acceptable? The whole TLV could be removed in order to calculate the ICV?
>>>>>
>>>>> - Would adding an address cause issues for the ICV, because it's in
>>>>> the address block? Could the rule be "if it contains an AckReq address,
>>>>> remove it (and the corresponding value in the AddressType TLV), before
>>>>> checking the ICV", is that OK? Or would we need to avoid touching the
>>>>> ICV'ed part of the message altogether, maybe put the AckReq address in a
>>>>> separate Address Block, with an extra AddressType TLV following that
>>>>> address block? Is there a way to accomplish this?
>>>>>
>>>>>
>>>>>
>>>>> Also, to be thorough, do we need to consider RERR messages while we
>>>>> discuss regeneration vs forwarding?
>>>>>
>>>>> - RERR (sent when a link breaks) is a way of saying "I've lost my
>>>>> route so I'm telling others" and "you were my next hop, so now I've also
>>>>> lost my route, I'll tell others", etc. It's going to be tailored at each
>>>>> step to include the relevant routes that got deleted, it's not one message
>>>>> being sent end-to-end like RREQ and RREP are.
>>>>>
>>>>> - However, RERR (sent when a source of traffic is sending data on a
>>>>> route which comes through you, and you want to tell the Packet Source's
>>>>> router to delete the route) could be seen as an end-to-end message which
>>>>> all intermediate routers learn from, similar to RREQ and RREP. It reports
>>>>> one route, and doesn't need changing at intermediate hops, so could be
>>>>> protected with ICV.
>>>>>
>>>>> - Would it be OK to only require a message ICV if a PktSource address
>>>>> was included, i.e. when the message needs to go via a number of
>>>>> intermediate hops to PktSource's router? All other RERRs are intended to be
>>>>> one-hop messages, which may in turn prompt other one-hop messages, etc...,
>>>>> and a packet ICV might be more appropriate?
>>>>>
>>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Victoria.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 17, 2016 at 5:26 PM, <ietf@thomasclausen.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Yes, I meant AODVv2, thanks for the catch.
>>>>>
>>>>>
>>>>>
>>>>> So is your (Thomas) proposed base specification a hop count only
>>>>> metric?
>>>>>
>>>>>
>>>>>
>>>>> No, the would be silly as base specification, given that hop count
>>>>> mostly is useless.
>>>>>
>>>>>
>>>>>
>>>>> As base specification I would simply say “Include a Metric Type
>>>>> Message TLV with a value field, and a 7182 Message TLV & Timestamp” as we
>>>>> do in OLSRv2 (with the appropriate verbiage as to generation and
>>>>> processing).
>>>>>
>>>>>
>>>>>
>>>>> With the message generated by the originator of the RREQ/RREP and
>>>>> *not* deconstructed/reconstructed/reordered (as is the risk with
>>>>> “regeneration) allows knowing that it would be *only* that metric field
>>>>> being modified (other than hop count/limit) for when eventually writing up
>>>>> the extension.
>>>>>
>>>>>
>>>>>
>>>>> (Actually doesn’t the current specification only define hop count, or
>>>>> has that changed in latest draft?)
>>>>>
>>>>>
>>>>>
>>>>> No. That is one of the issues I raise in my original. For some reason,
>>>>> it cites RFC6551, which is a ROLL document and which has in its abstract
>>>>> that:
>>>>>
>>>>>
>>>>>
>>>>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>>>>
>>>>>    compared with traditional wired and ad hoc networks that require the
>>>>>
>>>>>    specification of new routing metrics and constraints.
>>>>>
>>>>>
>>>>>
>>>>> I.e. this document cites a metric document which clearly claims to be
>>>>> inapplicable in ad hoc networks. I note that this is another thing I’ve
>>>>> raised for years without seeing it attempted resolved.
>>>>>
>>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *__________________________________________________________________________
>>>>> *
>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
>>>>> chris.dearlove@baesystems.com
>>>>>
>>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>>> www.baesystems.com/ai
>>>>>
>>>>> BAE Systems Applied Intelligence Limited
>>>>> Registered in England & Wales No: 01337451
>>>>>
>>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>>>>
>>>>>
>>>>>
>>>>> *From:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>>>> <ietf@thomasclausen.org>]
>>>>> *Sent:* 17 March 2016 17:10
>>>>> *To:* Dearlove, Christopher (UK)
>>>>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> *This message originates from outside our organisation, either from an
>>>>> external partner or the internet. Consider carefully whether you should
>>>>> click on any links, open any attachments or reply. For information
>>>>> regarding **Red Flags*
>>>>> * that you can look out for in emails you receive, click here
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
>>>>> If you feel the email is suspicious, please follow this process
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>>>>>
>>>>>
>>>>>
>>>>> On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> OK, so we have a message that mutates by:
>>>>>
>>>>> - Modifying hop count/limit.
>>>>>
>>>>> - Modifying a metric value.
>>>>>
>>>>> Anything else?
>>>>>
>>>>>
>>>>>
>>>>> As mutating (other than hop count/limit) messages aren’t covered by
>>>>> 5444 or any derivative document (but only recommended against, not banned)
>>>>> that you may need to make the message otherwise immutable (no
>>>>> deconstruction and rebuilding, other than guaranteed unchanging) that would
>>>>> have to be specified by AODVv2. (Easy to say, but needs saying.)
>>>>>
>>>>>
>>>>>
>>>>> With you so far.
>>>>>
>>>>>
>>>>>
>>>>> Then that information is not in a guaranteed fixed location given by a
>>>>> simple offset. So any signature algorithm that finds it and ignores it or
>>>>> aggregates on it is specific to OLSRv2.
>>>>>
>>>>>
>>>>>
>>>>> Surely you mean AODVv2
>>>>>
>>>>>
>>>>>
>>>>> So standard 7182 ICVs don’t do the job, you would need an AODVv2
>>>>> specialised variant. Which is the sort of thing that the message specific
>>>>> TLV space is there for, I’d be strongly against a “but ignore the value of
>>>>> this specific TLV should it occur” being in the general space. However it
>>>>> can easily be defined by reference to 7182 (“this TLV is like that TLV,
>>>>> except if an X TLV is present, set its value field to zero”).
>>>>>
>>>>>
>>>>>
>>>>> Messy, but could work.
>>>>>
>>>>>
>>>>>
>>>>> Not that messy, actually, although clearly not as nice as “fixed
>>>>> offset”.
>>>>>
>>>>>
>>>>>
>>>>> That said, I am arguing for the base spec being:
>>>>>
>>>>>
>>>>>
>>>>>             “make the message otherwise immutable (no deconstruction
>>>>> and rebuilding, other
>>>>>
>>>>>              than guaranteed unchanging)” which is afforded by
>>>>> forwarding
>>>>>
>>>>>
>>>>>
>>>>>                                     +
>>>>>
>>>>>
>>>>>
>>>>>             RFC7182 Timestamps and ICVs.
>>>>>
>>>>>
>>>>>
>>>>>                                     +
>>>>>
>>>>>
>>>>>
>>>>>             RFC7183 style text bringing it all together.
>>>>>
>>>>>
>>>>>
>>>>> The “aggregated signatures around mutable field” would very be an
>>>>> experimental extension.
>>>>>
>>>>>
>>>>>
>>>>> What I object to is, if the base spec specifically renders such
>>>>> extensions impossible
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *__________________________________________________________________________
>>>>> *
>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
>>>>> chris.dearlove@baesystems.com
>>>>>
>>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>>> www.baesystems.com/ai
>>>>>
>>>>> BAE Systems Applied Intelligence Limited
>>>>> Registered in England & Wales No: 01337451
>>>>>
>>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>>>>
>>>>>
>>>>>
>>>>> *From:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
>>>>> <lotte.steenbrink@fu-berlin.de>]
>>>>> *Sent:* 17 March 2016 16:48
>>>>> *To:* Dearlove, Christopher (UK)
>>>>> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> *This message originates from outside our organisation, either from an
>>>>> external partner or the internet. Consider carefully whether you should
>>>>> click on any links, open any attachments or reply. For information
>>>>> regarding **Red Flags*
>>>>> * that you can look out for in emails you receive, click here
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
>>>>> If you feel the email is suspicious, please follow this process
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com>:
>>>>>
>>>>>
>>>>>
>>>>> Good point about whether you just pass on one cost or a set of costs.
>>>>> As I said, not looked at details - I will, when time permits. One cost is
>>>>> much easier, and yes, it reduces the fixed size aggregated signatures
>>>>> problem to “just” one of computational load.
>>>>>
>>>>>
>>>>>
>>>>> For the record, Thomas’ understanding is correct; the cost is one
>>>>> aggregated value.
>>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Lotte Steenrbink
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *__________________________________________________________________________
>>>>> *
>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
>>>>> chris.dearlove@baesystems.com
>>>>>
>>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>>> www.baesystems.com/ai
>>>>>
>>>>> BAE Systems Applied Intelligence Limited
>>>>> Registered in England & Wales No: 01337451
>>>>>
>>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>>>>
>>>>>
>>>>>
>>>>> *From:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>>>> <ietf@thomasclausen.org>]
>>>>> *Sent:* 17 March 2016 16:38
>>>>> *To:* Dearlove, Christopher (UK)
>>>>> *Cc:* Mobile Ad Hoc Networks mailing list
>>>>> *Subject:* Re: Message integrity and message mutability (was RE:
>>>>> [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> *This message originates from outside our organisation, either from an
>>>>> external partner or the internet. Consider carefully whether you should
>>>>> click on any links, open any attachments or reply. For information
>>>>> regarding **Red Flags*
>>>>> * that you can look out for in emails you receive, click here
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
>>>>> If you feel the email is suspicious, please follow this process
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>>>>>
>>>>>
>>>>>
>>>>> On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> I appreciate Thomas’s comments about the limitations of message
>>>>> regeneration, but I would be a bit less absolute.
>>>>>
>>>>>
>>>>>
>>>>> The issues over end to end authentication and more advanced signatures
>>>>> are valid. I need to read the given reference on aggregate signatures to
>>>>> increase my knowledge (thanks for it), but my understanding of the
>>>>> possibilities in this field may offer a solution to the problem, but with
>>>>> some other issues (possibly including a new type of TLV).
>>>>>
>>>>>
>>>>>
>>>>> But the hop count/limit point I don’t fully agree with, you can
>>>>> regenerate with an incremented/decremented count/limit, which leaves the
>>>>> ability to prevent messages propagating indefinitely, including expanding
>>>>> ring searches, and retains the ability to use RFC 5497 interval and
>>>>> validity times that might be useful with an expanding ring search (or might
>>>>> not).
>>>>>
>>>>>
>>>>>
>>>>> But the key issue is that AODVv2 wants to accumulate metrics. I still
>>>>> haven’t got to the bottom of many details here, but let’s for the moment
>>>>> just consider that conceptually.
>>>>>
>>>>>
>>>>>
>>>>> It’s hard to handle end to end. Charlie’s draft attempts to do an end
>>>>> to end of some information, not this information. I’m not sure if that’s
>>>>> useful (and the specialised format is better avoided if possible). Other
>>>>> approaches are hop by hop (might as well use packet signatures) and shared
>>>>> key (might as well go hop by hop). Pairwise signatures for each pair of
>>>>> routers I’m discounting as scaling terribly. In the interests of
>>>>> completeness let’s mention not accumulating metrics, which puts us back to
>>>>> hop count and that’s not ideal either.
>>>>>
>>>>>
>>>>>
>>>>> I don’t think there is an ideal solution. (I like ideas I’ve seen
>>>>> about aggregating, but that has some issues of its own, even apart from
>>>>> computational load.) I’d love to be proved wrong - someone with the perfect
>>>>> solution to come along.
>>>>>
>>>>>
>>>>>
>>>>> Which means that either we make an arbitrary choice - which will be
>>>>> disagreed with, but needs discussing first - or create something flexible.
>>>>> Unfortunately flexible in that regard constrains in others, e.g. some
>>>>> (many? most?) aggregating signatures need fixed data sizes (which we can do
>>>>> by defining a TLV that “fills up” with hop count, but that has a cost too).
>>>>>
>>>>>
>>>>>
>>>>> I have been told by people much more well versed in this than I in
>>>>> cryptology, that the correct answer is “some”.
>>>>>
>>>>>
>>>>>
>>>>> That said, "AODVv2 wants to accumulate metrics” — does that mean that
>>>>> the message grows as it is being forwarded, and that the recipient of a
>>>>> RREQ/RREP will know the individual costs of each path segment? My
>>>>> understanding is, that the recipient will get “the sum the costs of each
>>>>> path segment” which should be fitting within a fixed size?
>>>>>
>>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sorry, no answers, just comments. And I’m not addressing Thomas’s
>>>>> later points here.
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *__________________________________________________________________________
>>>>> *
>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
>>>>> chris.dearlove@baesystems.com
>>>>>
>>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>>> www.baesystems.com/ai
>>>>>
>>>>> BAE Systems Applied Intelligence Limited
>>>>> Registered in England & Wales No: 01337451
>>>>>
>>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>>>>
>>>>>
>>>>>
>>>>> *From:* manet [mailto:manet-bounces@ietf.org <manet-bounces@ietf.org>
>>>>> ] *On Behalf Of *ietf@thomasclausen.org
>>>>> *Sent:* 17 March 2016 16:00
>>>>> *To:* Mobile Ad Hoc Networks mailing list
>>>>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of
>>>>> big ticket Items
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> *This message originates from outside our organisation, either from an
>>>>> external partner or the internet. Consider carefully whether you should
>>>>> click on any links, open any attachments or reply. For information
>>>>> regarding **Red Flags*
>>>>> * that you can look out for in emails you receive, click here
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
>>>>> If you feel the email is suspicious, please follow this process
>>>>> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>>>>>
>>>>> **** **WARNING ******
>>>>> EXTERNAL EMAIL -- This message originates from outside our organization
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>> Dear all,
>>>>>
>>>>>
>>>>>
>>>>> Apologies for not having gotten this done sooner - day-job leaving few
>>>>> spare cycles.
>>>>>
>>>>>
>>>>>
>>>>> I’ve previously offered reviews and comments, and some of those have
>>>>> been addressed in the latest I-D — others have not, but should be. I recall
>>>>> that there was some mail attempting to rebut parts of the review, and I
>>>>> will dig it out and reply to that.
>>>>>
>>>>>
>>>>>
>>>>> With that being said, I have reviewed the latest version of the
>>>>> document, and full details will be forthcoming. There’re a couple of
>>>>> big-ticket/architectural items that I want to address up front, as I
>>>>> believe that before we have those hammered out, it will be useless to go
>>>>> into details. Note, I do not claim that this is an exhaustive list of “big
>>>>> ticket items”, but that’s as far as I have gotten in thinking this through.
>>>>>
>>>>>
>>>>>
>>>>> I also bring these up as they are items that have been brought up
>>>>> repeatedly over the past years, but not resolved nor discussed.
>>>>>
>>>>>
>>>>>
>>>>> *Loops*
>>>>>
>>>>> Just to bring this out: I share Chris’ worry about conflicting and
>>>>> concurrent statements from the authors on “There are no loops possible” and
>>>>> “We need to fix two situations where loops can occur” and “we are still
>>>>> investigating some loop conditions”
>>>>>
>>>>>
>>>>>
>>>>> I particularly worry that this is not a discussion had in public, but
>>>>> apparently in some other forum…
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Intermediate Route Replies, and all of section 10*
>>>>>
>>>>> Section 10 contains a set of “vaguely specified extensions”, which is
>>>>> incoherent with the intended status indicated for this document.
>>>>>
>>>>>
>>>>>
>>>>> Specifically, and this is not unrelated to the point about loops
>>>>> above, intermediate RREPs (section 10.3) are a potential source for loops.
>>>>>
>>>>>
>>>>>
>>>>> Expanding Ring Multicast (section 10.1) is not documented in a way
>>>>> that can be implemented (and also, see “Forwarding-vs-regeneration” below,
>>>>> it is in the present form of this protocol impossible), etc.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Forwarding-vs-regeneration*
>>>>>
>>>>> Recent exchanges on the list made me understand that protocol control
>>>>> messages are *not* forwarded, but are consumed at each hop, then a new
>>>>> message with (almost-but-not-quite) the same content is generated and
>>>>> transmitted.
>>>>>
>>>>>
>>>>>
>>>>> I have thought some more on this (& read some of the exchanges on the
>>>>> list on this topic by Chris, Ulrich, and others), and I am convinced that
>>>>> this is not the right way to go, *at least* for the following reasons:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>             o          *It renders the hop-limit/hop-count fields in
>>>>> the RFC5444 message header useless.*
>>>>>
>>>>>                         This would not be bad if the functionality
>>>>> offered by those fields was not useful
>>>>>
>>>>>                         — sadly, it is. For example, for scope limited
>>>>> flooding (expanding ring search, and
>>>>>
>>>>>                         such) which may be of interest, and which
>>>>> require hop-limit.
>>>>>
>>>>>                         A hop-count field may also provide a “cheap”
>>>>> (in terms of overhead) additional piece
>>>>>
>>>>>                         of information to use conjunctively with a
>>>>> “real” metric.
>>>>>
>>>>>
>>>>>
>>>>>                         The only practical solution would be to
>>>>> re-introduce these functions by way of inserting a
>>>>>
>>>>>                         MessageTLV — which (i) is not specified in
>>>>> this document, and (ii) which would just
>>>>>
>>>>>                         serve to render messages bigger than strictly
>>>>> needed.
>>>>>
>>>>>
>>>>>
>>>>>                         Scope limited flooding  does seem to be a
>>>>> necessary requirement, if for no
>>>>>
>>>>>                         other reason than to prevent information from
>>>>> “circulating forever in the network”.
>>>>>
>>>>>
>>>>>
>>>>>             o          *It makes end-to-end authentication
>>>>> unnecessarily hard.*
>>>>>
>>>>>                         I think Chris called this out already, but it
>>>>> bears repeating: S generates a message
>>>>>
>>>>>                         (say, a RREQ), and includes an ICV calculated
>>>>> over the content of the message.
>>>>>
>>>>>                         For any recipient to be able to validate the
>>>>> ICV, the message has to be exactly
>>>>>
>>>>>                         the same — not just in content, but in
>>>>> structure — as what was generated.
>>>>>
>>>>>
>>>>>
>>>>>                         “Regenerating” rather than “forwarding”
>>>>> messages means, that the intermediate
>>>>>
>>>>>                         router “regenerating” the RREQ may chose a
>>>>> different structure (e.g., include TLVs
>>>>>
>>>>>                         in a different order).
>>>>>
>>>>>
>>>>>
>>>>>                         The proposal from
>>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>>>>
>>>>>                         is to add constraints on (i) the set of
>>>>> elements to include in a signature and (ii) the
>>>>>
>>>>>                         order of these elements.
>>>>>
>>>>>
>>>>>
>>>>>                         One problem with that approach is (i): if an
>>>>> extension adds a message TLV, or an
>>>>>
>>>>>                         Address TLV, to a message, then that will not
>>>>> be “covered” by the proposed e2esec TLV.
>>>>>
>>>>>                         Rather for *each* extension developed, an
>>>>> “updates e2esec” clause needs to be done.
>>>>>
>>>>>
>>>>>
>>>>>                         I’d say that this approach would be prone to
>>>>> errors — and add entropy to the process
>>>>>
>>>>>                         of designing protocol extensions. The
>>>>> alternative, a message being generated by the
>>>>>
>>>>>                         source and *forwarded* (as we do in OLSRv2,
>>>>> for example) would allow ICV TLVs
>>>>>
>>>>>                         (even, allow reuse of those specified for
>>>>> OLSRv2) for covering a message and
>>>>>
>>>>>                         extensions.
>>>>>
>>>>>
>>>>>
>>>>>                         “But what about the metrics value which will
>>>>> change on each hop”, you may say?
>>>>>
>>>>>                         Fortunately, that is relatively easy to
>>>>> handle: simply zero out the value of that TLV when
>>>>>
>>>>>                         generating or verifying the ICV MessageTLV.
>>>>> And use Packet-TLVs for hop-by-hop
>>>>>
>>>>>                         authentication, if needed (but, see below).
>>>>>
>>>>>
>>>>>
>>>>>             o          *It prevents the use of more clever/advanced
>>>>> signature schemes/ICVs*
>>>>>
>>>>>                         Aggregate signature algorithms (
>>>>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>>>>
>>>>>                         exist, and an interesting use-case can be
>>>>> found in also reactive protocols, allowing verifying
>>>>>
>>>>>                         not “just” the end points, but also the
>>>>> intermediaries (again, with the appropriate “zero out”
>>>>>
>>>>>                         discussed above, or something smarter).
>>>>>
>>>>>                         Regeneration of messages, rather than
>>>>> forwarding, renders that impossible (or, if used,
>>>>>
>>>>>                         updating to
>>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>>>>
>>>>>
>>>>>
>>>>> There are other reasons, but the above are those that jump at me as
>>>>> immediate show-stoppers.
>>>>>
>>>>>
>>>>>
>>>>> I do honestly not see what possible benefit there is from
>>>>> “regeneration” — but I see very clear inconveniences, and security is not
>>>>> the least of these. Insisting on “regeneration” requires development of
>>>>> “non-general workarounds” as pointed out above.
>>>>>
>>>>>
>>>>>
>>>>> *Security Considerations*
>>>>>
>>>>> This is an always thorny subject. When OLSRv2 was going through the
>>>>> process we got a thorough education in how little we knew about security
>>>>> from the SEC-ADs, and had to spend about a year or so developing RFC7183.
>>>>> The bottom line is, that this protocol needs its “RFC7183  equivalent”,
>>>>> either as part of the main document, or as an independent document.
>>>>> currently, that is not the case.
>>>>>
>>>>>
>>>>>
>>>>> A minima, looking at BCP72 and BCP107 — taking inspiration from
>>>>> RFC7183 might be aw good idea, as that was the most recent that went
>>>>> through the SEC AD. Regardless of how, however, a “mandatory to implement”
>>>>> security mechanism most be specified (I think the right term was “MUST
>>>>> implement, SHOULD use”), in sufficient detail to ensure interoperable
>>>>> implementations.
>>>>>
>>>>>
>>>>>
>>>>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>>>>
>>>>>
>>>>>
>>>>>       On receiving a ... message, a router MUST first check if the
>>>>>
>>>>>       message is invalid for processing by this router
>>>>>
>>>>>
>>>>>
>>>>> and then proceed to give a number of conditions that, each, will lead
>>>>> to a rejection of the message as "badly formed and therefore invalid for
>>>>> processing” — a list which RFC7183 then amended. That gave a “hook” for
>>>>> RFC7183 for inserting “rejection”. Idem for message generation.
>>>>>
>>>>>
>>>>>
>>>>> If I was to do RFC7181/RFC6130 today, I would include that directly
>>>>> into the protocol specifications. It turned out to be more overhead (and
>>>>> slow down publication anyways) to do it as separate documents.
>>>>>
>>>>>
>>>>>
>>>>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>>>>> Timestamps, etc. are added/removed, and what that brings.
>>>>>
>>>>>
>>>>>
>>>>> For example (with the assumption that messages are *forwarded* and
>>>>> *not* regenerated), this could be one option:
>>>>>
>>>>>
>>>>>
>>>>>                         o          When a RREQ, RREP message is
>>>>> generated, add an ICV Message TLV, which is calculated <this way>
>>>>>
>>>>>                                      …(take inspiration from RFC7183
>>>>> here)
>>>>>
>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>> [Message clipped]
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>>
>>>>>
>>>>> ********************************************************************
>>>>> This email and any attachments are confidential to the intended
>>>>> recipient and may also be privileged. If you are not the intended
>>>>> recipient please delete it from your system and notify the sender.
>>>>> You should not copy it or use it for any purpose nor disclose or
>>>>> distribute its contents to any other person.
>>>>> ********************************************************************
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>
>