Subject: [manet] Checklist of basic AODVv2 issues to close

From: Charlie Perkins <[email-masked]>
Date: Tue, 24 Mar 2015 08:03:11 -0700

Hello folks,

Here is the second of two lists of issues for AODVv2.  The issues
in this list required a bit more discussion and textual changes
to the document over the last several revisions.  Please take
a look to make sure that the issue resolutions are satisfactory.
If the resolutions are satisfactory, then the issues should all
be closed.  Otherwise, comments for further resolution will
be appreciated.

Bigger changes (i.e., the "is it good enough now?" list)
21    Document hard to read
         ... many parts rewritten
23    Format of processing algorithms
         ... Made much more regular, added sections
24    Ordering of processing instructions
         ... Collected together
26    Specification of optional features / on bidirectionality
         ... Collected together, RREP_Ack mandated
28    Routers with multiple interfaces [multi-homing text]
         ... multi-homing is not supported - Appendix H
32    Multicast transmission
         ... Clarified role of RFC6621
33    RFC 5444 processing constraint
         ... Written to show Data Elements --> RFC 5444 blocks, etc.
35    A constant is constant
         ... Text on result of variations added as requested
36    Security Considerations: Reactive protocol concept
         ... Text added to applicability statement
37    Security Considerations: what needs to be implemented?
         ... Similar approach as DLEP
38    difficulty to do security, in case messages are mutable
         ... Similar approach as DLEP
43    Reliance on bidirectional paths (submitted for Chris Dearlove)
         ... Clarified
44    Hop count (submitted for Chris Dearlove)
         ... Other metrics out of scope for base specification
45    RFC 5498 non-compliance (submitted for Chris Dearlove)
         ... Is now compliant
46    What is needed from IP and ICMP (submitted for Chris Dearlove)
         ... Text added, related to issue #31
47    Security approach unacceptable (submitted for Chris Dearlove)
         ... Similar approach as DLEP
48    Single address per interface per router (... Chris Dearlove)
         ... Clarified that restriction does not apply
50    Weak gateway support (submitted for Chris Dearlove)
         ... full support is out of scope for this document

Regards,
Vicky and Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 24 Mar 2015 15:34:59 +0000

The response "Similar approach as DLEP" is not adequate to address the security considerations issue. Maybe you have a problem (you do if the same rules apply as were imposed on OLSRV2), maybe you don't (if policy has changed). Personally I think you have significant issues with some handwaving "you can do this" which is not adequate for interoperability. What I think is not of course the critical point (though I would make the point at WGLC if not addressed before then). But arguing that it's the same as DLEP completely misses the point, because DLEP also has not been through the process, so isn't a helpful role model to know what is and is not acceptable. (I also note that I haven't checked if same as DLEP is an accurate description. Reading the latest draft there is also in my plans.)

I haven't checked the other points, nor have I finished reading and commenting (at least that's my plan, time permitting).

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Charlie Perkins
Sent: 24 March 2015 15:03
To: Mobile Ad Hoc Networks mailing list
Subject: [manet] Checklist of basic AODVv2 issues to close

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hello folks,

Here is the second of two lists of issues for AODVv2.  The issues in this list required a bit more discussion and textual changes to the document over the last several revisions.  Please take a look to make sure that the issue resolutions are satisfactory.
If the resolutions are satisfactory, then the issues should all be closed.  Otherwise, comments for further resolution will be appreciated.

Regards,
Vicky and Charlie P.

_______________________________________________
manet mailing list
[email-masked]
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.
********************************************************************

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 24 Mar 2015 12:22:55 -0500

Chris,

First up, I'm typing this on my iPhone, so apologies for the brevity and for typos.

My intent with the security considerations section was to point out that The security problems are typically (best?) handled at the transport layer. In a 5444 environment, it implies (at least to me) that the security is a function of the parser process. Maybe I'm missing something, though. For example, when AODV and OLSR are running on the same box, and sharing the same 5444 entity for comms to the next hop, how does security work in that case? 

I'm sum, the intent was to direct implemented to use the common toolset. Can you give me some guidance? Am I way off base here, or is there s better way we can express the point? 

Regards,
Stan

Sent from my iPhone

> On Mar 24, 2015, at 10:34 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 24 Mar 2015 18:00:33 +0000

If AODV and OLSRv2 are sharing the same 5444 layer, there are two basic options for security at that level, based on that RFC 7182 offers both packet and message signatures.

Packet signatures allow you to authenticate the whole packet, covering all of the protocols you are carrying using 5444. As the packet is a one-hop construct, so is the authentication. This isn't an OLSRv2 or an AODVv2 thing directly, but you can say that's appropriate to use.

Message signatures can be added to a message when created, and verified when used. (Definitely verify when data used. Good practice to verify before forwarding.) That is protocol specific, as messages are protocol specific. RFC 7183 says that any implementation of OLSRv2 must include an implementation of such an option. That was IESG mandated.

There are pros and cons of each, and as you note, other solutions (including below layer 3 solutions). Sticking to the pros and cons of these, message signatures give you end to end authentication (for OLSRv2, almost, it's end to last forwarder), packet signatures rely on a chain of trust. Message signatures don't cover hop limits, packet signatures do. And other details (I'm leaving in two minutes).

If you want to consider layer 4, note that packets never go further than one hop, anything that goes further than one hop is unknown to layer 4. So you can again do it one hop, but I don't know how end to end.

AS I said, must go now,

Christopher

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: 24 March 2015 17:23
To: Dearlove, Christopher (UK)
Cc: Charlie Perkins; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Checklist of basic AODVv2 issues to close

Chris,

Regards,
Stan

Sent from my iPhone

> The response "Similar approach as DLEP" is not adequate to address the 
> security considerations issue. Maybe you have a problem (you do if the 
> same rules apply as were imposed on OLSRV2), maybe you don't (if 
> policy has changed). Personally I think you have significant issues 
> with some handwaving "you can do this" which is not adequate for 
> interoperability. What I think is not of course the critical point 
> (though I would make the point at WGLC if not addressed before then). 
> But arguing that it's the same as DLEP completely misses the point, 
> because DLEP also has not been through the process, so isn't a helpful 
> role model to know what is and is not acceptable. (I also note that I 
> haven't checked if same as DLEP is an accurate description. Reading 
> the latest draft there is also in my plans.)
> 
> Senior Principal Engineer, Information Assurance Group Communications, 
> Networks and Image Analysis Capability BAE Systems Advanced Technology 
> Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace 
> Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales 
> No: 1996687
>

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 24 Mar 2015 18:39:03 +0000

Chris, 

Thanks for that clarification.  

If we added text in the Security considerations to say that implementations needing security should refer to RFC 7182, and saying that message signatures should be employed as well, would that address your concern? 

Regards,
Stan

> From: manet [mailto:[email-masked]] On Behalf Of Dearlove,
> Christopher (UK)
> Sent: Tuesday, March 24, 2015 2:01 PM
> To: Stan Ratliff
> If AODV and OLSRv2 are sharing the same 5444 layer, there are two basic
> options for security at that level, based on that RFC 7182 offers both packet
> and message signatures.
> 
> Packet signatures allow you to authenticate the whole packet, covering all of
> the protocols you are carrying using 5444. As the packet is a one-hop
> construct, so is the authentication. This isn't an OLSRv2 or an AODVv2 thing
> directly, but you can say that's appropriate to use.
> 
> Message signatures can be added to a message when created, and verified
> when used. (Definitely verify when data used. Good practice to verify before
> forwarding.) That is protocol specific, as messages are protocol specific. RFC
> 7183 says that any implementation of OLSRv2 must include an
> implementation of such an option. That was IESG mandated.
> 
> There are pros and cons of each, and as you note, other solutions (including
> below layer 3 solutions). Sticking to the pros and cons of these, message
> signatures give you end to end authentication (for OLSRv2, almost, it's end to
> last forwarder), packet signatures rely on a chain of trust. Message
> signatures don't cover hop limits, packet signatures do. And other details (I'm
> leaving in two minutes).
> 
> If you want to consider layer 4, note that packets never go further than one
> hop, anything that goes further than one hop is unknown to layer 4. So you
> can again do it one hop, but I don't know how end to end.
> 
> AS I said, must go now,
> 
> Christopher
> 
> --
> Christopher Dearlove
> Tel: +44 1245 242194 |  Fax: +44 1245 242124 [email-masked]
> | http://www.baesystems.com
> 
> ----------------------! WARNING ! ---------------------- This message originates
> from outside our organisation, either from an external partner or from the
> internet.
> My intent with the security considerations section was to point out that The
> security problems are typically (best?) handled at the transport layer. In a
> 5444 environment, it implies (at least to me) that the security is a function of
> the parser process. Maybe I'm missing something, though. For example,
> when AODV and OLSR are running on the same box, and sharing the same
> 5444 entity for comms to the next hop, how does security work in that case?
> 
> I'm sum, the intent was to direct implemented to use the common toolset.
> Can you give me some guidance? Am I way off base here, or is there s better
> way we can express the point?
> 
> Regards,
> Stan
> 
> Sent from my iPhone
> 
> > I haven't checked the other points, nor have I finished reading and
> commenting (at least that's my plan, time permitting).
> >
> > --
> > Christopher Dearlove
> > ----------------------! WARNING ! ---------------------- This message originates
> from outside our organisation, either from an external partner or from the
> internet.
> > Here is the second of two lists of issues for AODVv2.  The issues in this list
> required a bit more discussion and textual changes to the document over the
> last several revisions.  Please take a look to make sure that the issue
> resolutions are satisfactory.
> > If the resolutions are satisfactory, then the issues should all be closed.
> Otherwise, comments for further resolution will be appreciated.
> >

---

From: Justin Dean <[email-masked]>
Date: Tue, 24 Mar 2015 15:10:54 -0500

I'm not Chris but, I think a little bit more work is required.  As Chris
mentioned there are two different types of Integrity checks and which get
used where depends on a few things that a protocol specific.  If "messages"
change hop by hop then the message tlv integrity check will only be valid
for that one hop.  A packet tlv integrity check will address the whole
packet.  If AODVv2 message only ever go "one hop" before being changed then
a packet TLV should be used alternatively if there are messages which are
"forwarded" without change then for end to end a message tlv should be
used.

Which TLV should be used where (packet or message type) and for what
reason. Single hop, end to end and some text regarding the limitations and
tradeoffs.

Justin

On Tue, Mar 24, 2015 at 1:39 PM, Ratliff, Stanley <[email-masked]>
wrote:

> If we added text in the Security considerations to say that
> implementations needing security should refer to RFC 7182, and saying that
> message signatures should be employed as well, would that address your
> concern?
>
> Regards,
> Stan
>
> > Follow the 'Report Suspicious Emails' link on IT matters for
> instructions on
> > reporting suspicious email messages.
> > First up, I'm typing this on my iPhone, so apologies for the brevity and
> for
> > typos.
> >
> > > Follow the 'Report Suspicious Emails' link on IT matters for
> instructions on
> > reporting suspicious email messages.

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 24 Mar 2015 21:54:03 +0000

More than one issue there. First, what will make the ADs happy? My guess is maybe. Second, is that a workable option? Yes, in fact you don't need the message signatures. If messages are created new then message signatures are pointless (applies to RREQ?). Third, I think there currently are vague suggestions that don't have enough definition to be interoperable. Those I think need work (could remove, could improve),

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 24 Mar 2015, at 18:39, Ratliff, Stanley <[email-masked]> wrote:
> 
> Chris, 
>

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 25 Mar 2015 00:08:51 -0400

Chris,

Again, thanks. I'll work with the rest of the author team and see if we can
craft the appropriate text. Would you mind if we run it by you before a
subsequent post?

Regards,
Stan

On Tue, Mar 24, 2015 at 5:54 PM, Christopher Dearlove <
[email-masked]> wrote:

> More than one issue there. First, what will make the ADs happy? My guess
> is maybe. Second, is that a workable option? Yes, in fact you don't need
> the message signatures. If messages are created new then message signatures
> are pointless (applies to RREQ?). Third, I think there currently are vague
> suggestions that don't have enough definition to be interoperable. Those I
> think need work (could remove, could improve),
>
> --
> Christopher Dearlove
> >> First up, I'm typing this on my iPhone, so apologies for the brevity
> and for
> >> typos.
> >>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 25 Mar 2015 09:46:03 +0000

Not sure of the relationship of that to that a new version has just been posted. I will try to look at it or anything else, but no promises.

[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

From: Stan Ratliff [mailto:[email-masked]]
Sent: 25 March 2015 04:09
To: Christopher Dearlove
Cc: Ratliff, Stanley; Dearlove, Christopher (UK); Charlie Perkins; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Checklist of basic AODVv2 issues to close

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

Again, thanks. I'll work with the rest of the author team and see if we can craft the appropriate text. Would you mind if we run it by you before a subsequent post?

Regards,
Stan

On Tue, Mar 24, 2015 at 5:54 PM, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
More than one issue there. First, what will make the ADs happy? My guess is maybe. Second, is that a workable option? Yes, in fact you don't need the message signatures. If messages are created new then message signatures are pointless (applies to RREQ?). Third, I think there currently are vague suggestions that don't have enough definition to be interoperable. Those I think need work (could remove, could improve),

--
Christopher Dearlove
[email-masked]<mailto:[email-masked]> (iPhone)
[email-masked]<mailto:[email-masked]> (home)

> On 24 Mar 2015, at 18:39, Ratliff, Stanley <[email-masked]<mailto:[email-masked]>> wrote:
>
> Chris,
>
>> From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dearlove,
>> Christopher (UK)
>> Tel: +44 1245 242194 |  Fax: +44 1245 242124 [email-masked]<mailto:[email-masked]>
>> From: Stan Ratliff [mailto:[email-masked]<mailto:[email-masked]>]
>>>> On Mar 24, 2015, at 10:34 AM, Dearlove, Christopher (UK)
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Tel: +44 1245 242194<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>
>>> [email-masked]<mailto:[email-masked]> | http://www.baesystems.com
>>>
>>> From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Charlie
>>> Perkins
>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 25 Mar 2015 05:40:18 -0700

Hello Chris,

Revision 7 already contains the resolutions for the issues in those lists.

Revision 8 was produced in order to show resolutions for the comments 
that have more recently been made by you and Justin in order to be ready 
to go to Last Call.

Regards,
Charlie P.

On 3/25/2015 2:46 AM, Dearlove, Christopher (UK) wrote:
>
> Not sure of the relationship of that to that a new version has just 
> been posted. I will try to look at it or anything else, but no promises.
>
> -- 
>
> Christopher Dearlove
>
> [email-masked] <mailto:[email-masked]> | 
> http://www.baesystems.com
>
> Centre, Farnborough, Hants, GU14 6YU, UK
> *From:*Stan Ratliff [mailto:[email-masked]]
> *Sent:* 25 March 2015 04:09
> *To:* Christopher Dearlove
> *Cc:* Ratliff, Stanley; Dearlove, Christopher (UK); Charlie Perkins; 
> Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Checklist of basic AODVv2 issues to close
>
> **** 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>.//
>
> Chris,
>
> Again, thanks. I'll work with the rest of the author team and see if 
> we can craft the appropriate text. Would you mind if we run it by you 
> before a subsequent post?
>
> Regards,
>
> Stan
>
> On Tue, Mar 24, 2015 at 5:54 PM, Christopher Dearlove 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> More than one issue there. First, what will make the ADs happy? My 
> guess is maybe. Second, is that a workable option? Yes, in fact you 
> don't need the message signatures. If messages are created new then 
> message signatures are pointless (applies to RREQ?). Third, I think 
> there currently are vague suggestions that don't have enough 
> definition to be interoperable. Those I think need work (could remove, 
> could improve),
>
> --
> Christopher Dearlove
> [email-masked] <mailto:[email-masked]> 
> (iPhone)
> [email-masked] <mailto:[email-masked]> (home)
>
> implementations needing security should refer to RFC 7182, and saying 
> that message signatures should be employed as well, would that address 
> your concern?
> >
> > Regards,
> > Stan
> >
> >> From: manet [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Dearlove,
> >> Christopher (UK)
> [email-masked] <mailto:[email-masked]>
> >> First up, I'm typing this on my iPhone, so apologies for the 
> brevity and for
> >> typos.
> >>
> >>> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >>>
> >>> Tel: +44 1245 242194 <tel:%2B44%201245%20242194> | Fax: +44 1245 
> 242124 <tel:%2B44%201245%20242124>
> >>> [email-masked] 
> <mailto:[email-masked]> | http://www.baesystems.com
> >>>
> >>> From: manet [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Charlie
> >>> Perkins
> in this list
> >>> [email-masked] <mailto:[email-masked]>
> >>> [email-masked] <mailto:[email-masked]>
> >> [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Wed, 25 Mar 2015 19:29:49 +0000

Chris,

The new version posted doesn’t have any changes in that area – we’re trying to be responsive to WG input, and perhaps we’re winding up a bit *too* responsive… ☺

Regards,
Stan

From: Dearlove, Christopher (UK) [mailto:[email-masked]]
Sent: Wednesday, March 25, 2015 5:46 AM
To: Stan Ratliff; Christopher Dearlove
Cc: Ratliff, Stanley; Charlie Perkins; Mobile Ad Hoc Networks mailing list
Subject: RE: [manet] Checklist of basic AODVv2 issues to close

*** WARNING ***

Regards,
Stan