Re: [manet] Fwd: New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt

"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> Tue, 03 May 2016 16:07 UTC

Return-Path: <chris.dearlove@baesystems.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 20BA112D9D3 for <manet@ietfa.amsl.com>; Tue, 3 May 2016 09:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.905
X-Spam-Level:
X-Spam-Status: No, score=-7.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 E_Ebpmv0bxoQ for <manet@ietfa.amsl.com>; Tue, 3 May 2016 09:07:11 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C1512D9D8 for <manet@ietf.org>; Tue, 3 May 2016 09:07:06 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,573,1454976000"; d="scan'208,217"; a="66418116"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 03 May 2016 17:07:02 +0100
X-IronPort-AV: E=Sophos;i="5.24,573,1454976000"; d="scan'208,217";a="116513624"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 03 May 2016 17:07:02 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Tue, 3 May 2016 17:07:02 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: "Charles E. Perkins" <charliep@computer.org>, Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Thread-Topic: [manet] Fwd: New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt
Thread-Index: AQHRpVPmqApiikjTM0GmTK2Ozji/wJ+nXloA
Date: Tue, 03 May 2016 16:07:01 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2CC7@GLKXM0002V.GREENLNK.net>
References: <20160503145248.8264.43392.idtracker@ietfa.amsl.com> <bab70f7f-aa1b-0ae7-fd20-a5d464e9615f@computer.org>
In-Reply-To: <bab70f7f-aa1b-0ae7-fd20-a5d464e9615f@computer.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2CC7GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/ydVFYWGG7PWsVO8E7mixdOXniaE>
Subject: Re: [manet] Fwd: New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt
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: Tue, 03 May 2016 16:07:14 -0000

I think this is the wrong approach, to create a specialised structure containing just what you know you currently want in AODVv2 and protect that, as a type extension to a general purpose TLV. And an approach that doesn’t generalise to any possible AODVv2 extensions. Of course as an experimental non-allocation that handles the former point, but not the latter.

I think the discussions that have taken place on what one might call a subtractive approach is more appropriate, covering everything (plus possibly address(es)) except explicitly excluded parts of the message. And trying hard to make those parts absolutely minimal, ideally just one block of data that carries one (or possibly two if asymmetric) metric values. Because as I understand it one block makes some future concepts such as aggregation more practical, but in the meanwhile is just one block to zero out, with minimal information.

That does require separating out RREP-ACKs, which may be a good idea anyway.

I’d strongly suggest if going down this route (a) designing it carefully, (b) specifying by position, (c) only permitting the exclusion (or each exclusion if more than one is needed - though avoiding that is another strong suggestion) to be all or part of a single message TLV value.

This, including (a), is of course a reason for my last posting.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com<mailto:chris.dearlove@baesystems.com>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://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] On Behalf Of Charles E. Perkins
Sent: 03 May 2016 16:52
To: Mobile Ad Hoc Networks mailing list
Subject: [manet] Fwd: New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt


*** 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.




Hello folks,

According to my understanding of RFC 7182, it seems pretty much straightforward to do the proper end-to-end authentication for RREQ/RREP using a new new type extension.  Please have a look to see whether there is any additional specification required in order to request allocation of the new type extension.

I kept the RFC 4868 section as another alternative just in case the RFC 7182 specification turns out to be more difficult than my current understanding.

If it is suitable, the specification for the new type extension in this draft would probably fit very comfortably with the AODVv2 draft, or it could go forward separately.

Comments will be appreciated.

Regards,
Charlie P.




-------- Forwarded Message --------
Subject:

New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt

Date:

Tue, 03 May 2016 07:52:48 -0700

From:

internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>

To:

Charles E. Perkins <charliep@computer.org><mailto:charliep@computer.org>



A new version of I-D, draft-perkins-manet-aodv-e2esec-01.txt

has been successfully submitted by Charles E. Perkins and posted to the

IETF repository.



Name:          draft-perkins-manet-aodv-e2esec

Revision:      01

Title:         Endpoint Message Authentication for AODV Route Messages

Document date: 2016-05-03

Group:         Individual Submission

Pages:         5

URL:            https://www.ietf.org/internet-drafts/draft-perkins-manet-aodv-e2esec-01.txt

Status:         https://datatracker.ietf.org/doc/draft-perkins-manet-aodv-e2esec/

Htmlized:       https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-01

Diff:           https://www.ietf.org/rfcdiff?url2=draft-perkins-manet-aodv-e2esec-01



Abstract:

   This document specifies a new type extension to enable RFC 7182

   authentication mechanism to be used for authenticating AODVv2 route

   messages.  The document also specifies a new message TLV for AODVv2

   and, potentially, other reactive protocols.  Both mechanisms allow

   the endpoints of a newly discovered route to be assured that they

   were the originator of the RREQ and responder producing the RREP

   respectively.









Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat




********************************************************************
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.
********************************************************************