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

Sure. thanks for making it more precise :)

Jiazi

On Thu, Dec 3, 2015 at 10:53 PM, Christopher Dearlove <
christopher.dearlove@gmail.com> wrote:

> 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 <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 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-12#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 <https://tools.ietf.org/html/rfc6621>] in deployments is recommended. Employing [RFC6621 <https://tools.ietf.org/html/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
>
>