Re: [manet] draft-ietf-manet-aodvv2-12 and draft-ietf-manet-dlep-17

In OLSRv2 a compromised router can only speak for itself if ICVs are linked to specific routers. Use a shared secret key (as RFC 7183) then a compromised router can impersonate any router. draft-ietf-manet-ibs is however an example where it can't.

--  
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

> On 3 Dec 2015, at 21:42, Jiazi YI <ietf@jiaziyi.com> wrote:
> 
> I agree with Chris and Thomas on their concerns on the hop-by-hop security issue. 
> 
> This is very different from classical DV protocol, in which the vector information is designed to be exchanged between neighbours. 
> In AODVv2, the RREQ/RREP/RERR are to be forwarded through multiple hops. A router can sign a message that isn't actually initialised by itself -- this is, at least, against intuition. 
> 
> This can be an issue if we have compromised routers in the network. Of course, a compromised router is a problem for every protocol, like OLSRv2. But in OLSRv2, a compromised router can only speak on behalf of itself -- however, in AODVv2, a compromised/mis-configured router can pretend to be any other router (for example, generate RREQ messages using another address as OrigAddr).  The consequence will be much more serious if that happens. 
> 
> best
> 
> Jiazi
> 
> 
>> On Thu, Dec 3, 2015 at 2:53 PM, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:
>> That is exactly the thing -  the trust model assumed (& the protocol mechanics) need to be understood before designing the necessary MTI security, and before deciding which bits (if any) from 7182 to use...
>> 
>> Thomas
>> 
>>> On 3 déc. 2015, at 14:26, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>>> 
>>> If you go down this route of assuming transitive trust, then you might as well use 7182’s packet ICV and timestamp rather than message ICV and timestamp.
>>> 
>>>  
>>> 
>>> There is a complication (mostly one of presentation) that the 5444 multiplexer (rather than AODVv2) needs to do this, at least for packets containing AODVv2 messages (but at which point, probably all 5444 packets). So you either, depending on your point of view, need to request it to do that, or (administratively) decline to operate except over a 5444 multiplexer that is doing this.
>>> 
>>>  
>>> 
>>> The advantage is one of saved space and time when packets contain more than one message. Plus slightly better protection (hop count and limit are covered) but which probably doesn’t matter here.
>>> 
>>>  
>>> 
>>> If messages are changed/replaced on a one-to-one basis as forwarded, then the only solutions I can see are hop by hop transitive trust (packets or messages per hop), or something complicated involving aggregation and knowledge of changes. But the latter would be a research task to develop, so let’s not try that.
>>> 
>>>  
>>> 
>>>  
>>> 
>>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of ietf@thomasclausen.org
>>> Sent: 03 December 2015 12:22
>>> To: Victoria Mercieca
>>> Cc: manet
>>> Subject: Re: [manet] draft-ietf-manet-aodvv2-12 and draft-ietf-manet-dlep-17
>>> 
>>>  
>>> 
>>> Dear Victoria,
>>> 
>>>  
>>> 
>>> Responding twice to this email, intentionally as I want to address two different aspects independently….
>>> 
>>>  
>>> 
>>> On Nov 19, 2015, at 17:09, Victoria Mercieca <vmercieca0@gmail.com> wrote:
>>> 
>>>  
>>> 
>>>  
>>> 
>>> Hi Thomas and Christopher,
>>> 
>>> Thank you for your comments.  If I may address just one point for starters - regeneration vs forwarding. We use the term regeneration since forwarding seems inappropriate when the message content changes at each hop.
>>> 
>>> The changes we make to the message content are:
>>> 
>>> 1) We change the metric so that each router along the path learns a route from the message, with the metric associated with the path up to that point
>>> 2) AckReq only applies between hops, so needs to be removed at each hop, and a new AckReq element may need to be added for the next hop.
>>> 3) ValidityTime could potentially be added by any intermediate router that wishes to limit the time it will forward packets on the route.
>>> 4) Stripping out Unreachable Addresses from RERR which did not affect our route set.
>>> 
>>> Can we really use the term "forwarding" if we are changing the metric value, adding a validity time, adding/removing AckReq or removing addresses and their associated TLVs?
>>> 
>>> OK, so assume that I understand regeneration as per my previous email, as meaning “generate a new message and send to my neighbors, based on what I learned when processing a received message” — just like any distance vector protocol does.
>>> 
>>>  
>>> 
>>> In that model, what you write makes sense: each originator of a control message (i.e., whoever generates or regenerates it) is free to include the information it desires, such as the 4 points you list above. No issues with that.
>>> 
>>>  
>>> 
>>> However, and this joins what I pointed out in a previous email, you write in the applicability statement:
>>> 
>>>  
>>> 
>>>    Providing security for a reactive routing protocol can be difficult.
>>> 
>>>  While we can discuss if the nature of “reactive routing protocol” generates particular difficulties, we certainly can agree that this protocol has the same “difficulties” as a distance vector protocol: routing topology information (by definition) not being exchanged end-to-end, but between neighbors (who do calculations and generate their own announcements — regeneration, as you call it). 
>>> 
>>>  This means that a specific security model of transitive trust must be assumed, no? I trust Victoria, therefore when Victoria says “Stan told me” then I trust that she actually verified that "it was indeed Stan who told her …” — and either way, I have no way of verifying?
>>> 
>>>  I did not see the trust model / trust assumption discussed in the specification (specifically not in applicability and in section 13, both of where it should be called out), but I think that this is actually a crucial point to get right, in order to approach developing the MTI security mechanisms.
>>> 
>>>  Anyways, that observation actually contrasts strongly with what the applicability statement then goes on to say, namely:
>>>  
>>>    AODVv2 provides for message integrity and security against replay
>>>    attacks by using integrity check values, timestamps and sequence
>>>    numbers, as described in Section 13.
>>> 
>>>  This is true only in as much as messages are indeed exchanged between neighbors: when you “regenerate” a message, i.e., generate a new message in response to receipt of a message, you generate brand new payload (but possibly including some of the data from the received message, of course): thus, any ICVs “from farther away than the neighbor” will be useless (or, if you zero out the parts that you change, these parts will not be protected).
>>> 
>>>  The above sentence, quoted from the applicability statement, and that which transpires from section 13, seems - certainly, absent the trust model assumed - to suggest that end-to-end protection/validation is provided. But, this is not the case.
>>> 
>>>  Finally to the applicability statement, a question:
>>> 
>>>     If security associations can be
>>>    established, encryption can be used for AODVv2 messages to ensure
>>>    that only trusted routers participate in routing operations.
>>>  
>>> 
>>> What you want to say here is that “if all trusted routers have a shared secret, then we’re able to use that shared secret to ignore non-trusted routers”, right? 
>>> 
>>> While “security associations” that do not pass through a shared secret probably can be thought up, it’s not trivial and I did not find any discussion of that in the document?
>>> 
>>>  
>>> 
>>> Having, on the topic of security, re-read Section 13, which starts:
>>> 
>>>  
>>> 
>>>    This section describes various security considerations and potential
>>>    avenues to secure AODVv2 routing.  
>>>  
>>> 
>>> While this is an honest description of what follows, I remain convinced that this is not sufficient. So let me ask as precisely as I can:
>>> 
>>>  
>>> 
>>>             o          what is the MTI security mechanism that a conformant implementation must provide? 
>>> 
>>>                         Specifically:
>>> 
>>>                                     -           which are the processing steps (for example in section 7.2.1 
>>> 
>>>                                                 and section 7.2.2 for RREP - and similarly for the other message 
>>> 
>>>                                                 types) that define that security mechanism
>>> 
>>>  
>>> 
>>>             o          what protection is offered by that MTI security mechanism? And what remains
>>> 
>>>                         vulnerable.
>>> 
>>>  
>>> 
>>> If this specification targets std.track, then it should include (reasonably solid, but definitely well specified) MTI security.
>>> 
>>>  
>>> 
>>> Best
>>> 
>>>  
>>> 
>>> Thomas
>>> 
>>>  
>>> 
>>> Further, in reply to the comment about use of the msg-hop-count and msg-hop-limit fields, I think it does not matter that a message only travels one hop in that particular form, with that exact set of information enclosed. Hop limit and hop count are part of the message and used by the routing protocol, and so they refer to the multi-hop path that the AODVv2 message will follow, indicating when not to regenerate any further. So AODVv2 uses these fields as suggested in RFC5444 Appendix B, to limit the number of hops across which it will regenerate a packet so as to "prevent messages from endlessly circulating in a MANET".
>>> 
>>> Kind regards,
>>> Victoria.
>>> 
>>>  
>>> 
>>> On Wed, Nov 18, 2015 at 8:49 AM, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
>>> 
>>> I've not had time to look at either yet, though I hope to review DLEP very soon.
>>> 
>>>  
>>> 
>>> But this has made me think about the RFC 6621 reference in AODVv2. It's always been clear this has been rather a throwaway comment that needed thought, but until now I hadn't really given it any.
>>> 
>>>  
>>> 
>>> And it doesn't work. RFC 6621 is fundamentally unusable here. Let's consider each on turn. 
>>> 
>>>  
>>> 
>>> AODVv2 is in the RFC 5444 structure. As has been noted on many occasions, AOVDVv2 gets to use messages, but packets are not in its competence.
>>> 
>>>  
>>> 
>>> RFC 6621 is about packets. But not even RFC 5444 packets but IP packets. It's about whether or not to forward them. But RFC 5444 packets aren't just not forwarded in unchanged IP packets, they aren't even forwarded at all. They are each a single hop construct, and if a message is forwarded (which is by the routing protocol, as far as RFC 5444 is concerned, it's a new message) it will be in a new packet, with possibly new companions.
>>> 
>>>  
>>> 
>>> If AODVv2 wants to use a more efficient flooding process, it needs one at the message level. Now an example of that exists - the mechanism on RFC 7181. Unfortunately we didn't break that out as a separate draft (we would have liked to, but there were reasons we didn't).
>>> 
>>>  
>>> 
>>> And even if (by reference or other means) it were used - or some related mechanism such as a CDS - that processing/forwarding mechanism assumes you have defined MPRs (or similarly, that you have defined a CDS). And that needs a local exchange of information, such as NHDP's HELLO messages (and the rest of NHDP) augmented with RFC 7181's MPR TLV (though only the flooding bit is needed).
>>> 
>>>  
>>> 
>>> In other words, taking some real work to define. And also raising a question for the WG - why do we want a reactive protocol? The main attraction as I see it is the "if you're not doing anything, you're not transmitting" property. Which adding this voids. Of course maybe the WG doesn't value that. Or it is acceptable as an option. But if so it needs to be an option that all routers use, or none. And if all, compatibly. (MPR flooding allows different MPR selection algorithms - but only as long as they satisfy the fundamental MPR algorithm properties.)
>>> 
>>>  
>>> 
>>> In short, RFC 6621 must go. The alternative is nothing, or significant work.
>>> 
>>> --  
>>> 
>>> Christopher Dearlove
>>> 
>>> christopher.dearlove@gmail.com (iPhone)
>>> 
>>> chris@mnemosyne.demon.co.uk (home)
>>> 
>>> 
>>> On 18 Nov 2015, at 01:35, Thomas Clausen <ietf@thomasclausen.org> wrote:
>>> 
>>> Dear all,
>>> 
>>>  
>>> 
>>> I have started looking through the recently updated draft-ietf-manet-aodvv2-12. A lot has changed, and I regret not to have had a blow-by-bow comeback to the previous review comments  - would have made it a somewhat easier task to check if all have been addressed or not.
>>> 
>>>  
>>> 
>>> But, I will work through it and produce a detailed review - but from my first quick read-through there're a couple of issue that jumped at me as worth bringing forward on a more global level already.
>>> 
>>>  
>>> 
>>> The first relates to  how RREQs are forwarded -- or, more generally, are not.
>>> 
>>>  
>>> 
>>> The protocol currently talks about "message is regenerated" rather than "forwarded". I have understood that this means that a RREQ is actually not an "end to end" entity, but is a "hop by hop" entity. 
>>> 
>>>  
>>> 
>>> First, that is a curious design choice, is there any reason why this is so considered?
>>> 
>>>  
>>> 
>>> Second, if a RREQ message is hop-by-hop only, then I do not think that the use of the RFC5444 hop-limit/hop-count fields is appropriate.
>>> 
>>>  
>>> 
>>> Third, the statement in section 6.5 on the use of RFC6621 is incorrect in two ways: RFC6621 does specify how messages are *forwarded* (but, as discussed above, you are not forwarding messages).
>>> 
>>>  
>>> 
>>> More seriously, this paragraph is incorrect:
>>> 
>>> 
>>> 
>>> "Implementations MAY choose to employ techniques to reduce the number of multicast messages sent. Use of [RFC6621] in deployments is recommended. Employing [RFC6621] in a subset of the operational AODVv2 routers in a network, or configuring different algorithms on different routers, will not cause interoperability issues, but will reduce the effectiveness of the multicast reduction scheme."
>>>  
>>> 
>>> Different routers using different relay selection algorithms in the same network will not *just* cause loss of efficiency, but *will* cause interoperability issues.
>>> 
>>>  
>>> 
>>> For example if "router A" decides to suppress its message relaying because it estimates that "router B" provides sufficient coverage - and conversely "router B" suppresses relaying for the same reason: neither A nor B would relay, and so any routers reachable only via A and B would not be covered.
>>> 
>>>  
>>> 
>>> This is not a far-sought example: it can be as simple as A and B simply using self-selecting relay algorithms with different tie-breakers.
>>> 
>>>  
>>> 
>>> In short: I think that the whole message flooding/regeneration part requires serious work.
>>> 
>>>  
>>> 
>>> The second issue is that I also suspect that there is some issue with buffering, or rather with how it is specified; starting in section 6.6, I am not sure that leaving that as "a matter of policy at each router" is entirely right. 
>>> 
>>> 
>>> 
>>> 
>>> Also on buffering, I am wondering if the "start delivering buffered packets" conditions (penultimate paragraph in 6.6, and of course through the processing sections) is sufficient; I suspect that the condition "When a valid route is installed" is not sufficient - that there are situations where a routing table entry is installed, but the complete route is not available or is not bidirectional?This obviously is related to RREP_Ack being hop-by-hop and not end-to-end....
>>> 
>>> 
>>> 
>>> 
>>> Either way, the parts of the specification that relate to buffering contain a mixture of normative and non-normative verbiage (a lot of "can" but also a lot of MUST/SHOULD) which I think could do with a tightening up. 
>>> 
>>> 
>>> 
>>> 
>>> But....is buffering even something that should be specified by this document? It does not impact interoperability and it interferes substantially with transport and congestion control, and I am not sure that we understand the consequences (I am not convinced that the claims in the document on benefits to TCP are substantiated or even true).
>>> 
>>> 
>>> 
>>> 
>>> As I indicated, a complete review will follow, but I thought that these was a global enough topics to call out and get engineered right.
>>> 
>>>  
>>> 
>>> Thomas
>>> 
>>>  
>>> 
>>> PS: I remain convinced that the security considerations section is insufficient ; I will try to articulate my thoughts on why that is, but for starters looking at the recently raised (by somebody else, the Chris replied) AODV security questions would probably be helpful
>>> 
>>> 
>>> On 10 Nov 2015, at 02:10, Ratliff, Stanley <sratliff@idirect.net> wrote:
>>> 
>>> Hello WG participants –
>>> 
>>>  
>>> 
>>> The above referenced drafts were posted Oct. 13 (for AODVv2), and Oct. 16 (DLEP). The co-authors and the chairs ask that you please take some time to review and comment on the new submissions.
>>> 
>>>  
>>> 
>>> Regards,
>>> 
>>> Stan
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 
>>> _____________________________________________________
>>> This electronic message and any files transmitted with it contains
>>> information from iDirect, which may be privileged, proprietary
>>> and/or confidential. It is intended solely for the use of the individual
>>> or entity to whom they are addressed. If you are not the original
>>> recipient or the person responsible for delivering the email to the
>>> intended recipient, be advised that you have received this email
>>> in error, and that any use, dissemination, forwarding, printing, or
>>> copying of this email is strictly prohibited. If you received this email
>>> in error, please delete it and immediately notify the sender.
>>> _____________________________________________________
>>> 
>>> _______________________________________________
>>> 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
>>> 
>>>  
>>> 
>>> ********************************************************************
>>> 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