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

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 3 May 2016 08:52:23 -0700

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: 	[email-masked]
To: 	Charles E. Perkins <[email-masked]>

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 May 2016 16:07:01 +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: [email-masked]<mailto:[email-masked]>

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:[email-masked]] 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.

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:

[email-masked]<mailto:[email-masked]>

To:

Charles E. Perkins <[email-masked]><mailto:[email-masked]>

IETF repository.

Revision:      01

Pages:         5

Abstract:

   respectively.

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

---

From: [email-masked]
Date: Tue, 3 May 2016 18:14:15 +0200

> On 03 May 2016, at 18:07, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 

Yes — that has been the point I have made repeatedly: that this e2esec draft (whether done as a 7182-TLV type extension, or as something else) simply precludes extensions. 

Especially for an experimental protocol, where I would anticipate…you know….experiments ;), that would be unacceptable.

> 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…

+1

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

+1

Thomas

> T:  +44 (0)1245 242194  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: manet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Charles E. Perkins
> Sent: 03 May 2016 16:52
> 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 ***
> [email-masked] <mailto:[email-masked]>
> To: 
> Charles E. Perkins <[email-masked]> <mailto:[email-masked]>
>  
> 
> URL:            https://www.ietf.org/internet-drafts/draft-perkins-manet-aodv-e2esec-01.txt <https://www.ietf.org/internet-drafts/draft-perkins-manet-aodv-e2esec-01.txt>
> Status:         https://datatracker.ietf.org/doc/draft-perkins-manet-aodv-e2esec/ <https://datatracker.ietf.org/doc/draft-perkins-manet-aodv-e2esec/>
> Htmlized:       https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-01 <https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-01>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-perkins-manet-aodv-e2esec-01 <https://www.ietf.org/rfcdiff?url2=draft-perkins-manet-aodv-e2esec-01>
>  
> Abstract:
> _______________________________________________
> manet mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>