Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

[Jiazi YI <[e-mail]>]

On Mon, Apr 25, 2016 at 5:34 PM, Justin Dean <[e-mail]> wrote:

> On Mon, Apr 25, 2016 at 11:29 AM, Jiazi YI <[e-mail]> wrote:
>
>> Hi,
>>
>> Maybe I missed a bit here:
>>
>> If only the desired receiver of the multicast RREP (carrying a
>> destination address) can reply to the multicast RREP, why not using unicast
>> directly?
>>
>> Because the link isn't yet known to be bi-directional and a unicast route
> can't be installed yet.
>

Does it matter? I can send a unicast to the next hop anyways: if I didn't
get a RREP-ACK, then it's unidirectional, so that I can blacklist the next
hop.

If I get a RREP-ACK, then it's bidirectional and I can continue to set up
the (bi-directdional) route.

best

Jiazi



>
> Justin
>
>
>> best
>>
>> Jiazi
>>
>> On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca <[e-mail]>
>> wrote:
>>
>>> Hi Chris,
>>>
>>>
>>> On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <
>>> [e-mail]> wrote:
>>>
>>>> I has to go back to Victoria’s summary here. It says:
>>>>
>>>>
>>>>
>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>> bidirectional, it includes the AckReq (an address to indicate that it
>>>> expects to receive a RREP_Ack from B).
>>>>
>>>>
>>>>
>>>> That doesn’t actually indicate if that’s C’s address or B’s address
>>>> being included. I’d assumed it was C’s address. Your comment makes sense if
>>>> it’s B’s address. Reading again, I think you’re probably right. But only
>>>> probably. Can we confirm that.
>>>>
>>>>
>>>>
>>>
>>> C creates the RREP. The included AckReq address is B's address. The RREP
>>> then gets multicast.
>>> B receives it, sees that it own address is marked as the AckReq address,
>>> and sends an ack unicast back to C.
>>> Anyone else who receives the multicast RREP from C does not send the
>>> Ack, since the AckReq address does not match any of their interface
>>> addresses.
>>>
>>>
>>>> I assume you meant that the RREP (not RREP_Ack) is multicast. There’s a
>>>> bit of a chicken and egg problem here. We do know how we want to unicast.
>>>>
>>>
>>> The RREP is multicast (when we dont know if the link is bidirectional),
>>> the RREP_Ack is always unicast.
>>>
>>> Kind regards,
>>> Vicky.
>>>
>>>
>>>>
>>>> *-- *
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *__________________________________________________________________________
>>>> *
>>>> *T*:  [phone]  |  *E: *[e-mail]
>>>>
>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>> 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:* Justin Dean [mailto:[e-mail]]
>>>> *Sent:* 25 April 2016 15:26
>>>> *To:* Thomas Heide Clausen
>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>>> Networks mailing list; Victoria Mercieca
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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>.*
>>>>
>>>> The address in the RREP_Ack may be required due to the RREP_Ack being
>>>> multicast as there is not yet a verified unicast route installed yet.
>>>> Going to double check if I'm remembering correctly.
>>>>
>>>> Justin
>>>>
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 10:18 AM, <[e-mail]> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I must admit that while I have reviewed the protocol several times,
>>>> I’ve not been digging that deep into the protocol functioning to catch this
>>>> issue of how invasive the protocol operations are when forwarding a
>>>> message: there were other “major” issues to address (and which obscured the
>>>> details), so as a first order: thank you Victoria, for having called
>>>> attention to this.
>>>>
>>>>
>>>>
>>>> To the substance of these emails.
>>>>
>>>>
>>>>
>>>> I am afraid that I do not understand the use of inserting validity TLVs
>>>> while in-flight, into a message. Actually, I am dubious for both the
>>>> originator inserting this (how can the originator of a message know how
>>>> “latter parts of the path” will be have”) except if we are talking
>>>> duty-cycling of devices and inserting “the remaining time that I am going
>>>> to be up before I suspend”. Intuitively, that would also assume fairly long
>>>> duty cycles “I am up for tens of seconds”, which I am not sure are actually
>>>> realistic. And, as Chris says in another email, this is trading off “the
>>>> ability to do security” for an unknown/untested feature — which I think is
>>>> the wrong trade-off.
>>>>
>>>>
>>>>
>>>> On he topic of “needing to put an address in” for RREP-ACK, I must
>>>> admit that this seems roundabout. I can see three issues here:
>>>>
>>>>
>>>>
>>>> o I am not sure that adding an address vs. a flag may not have to do
>>>> with the “multiple interfaces/
>>>>
>>>> multiple addresses” discrimination mechanics of the protocol? I haven’t
>>>> worked it through, though,
>>>>
>>>> but that would be a guess.
>>>>
>>>>
>>>>
>>>> o The end-to-end topology diffusion mechanism should not need to be
>>>> concerned with the
>>>>
>>>> “bidirectionally check” of a local link (in part, as it encumbers
>>>> security, but not only).  In short, a
>>>>
>>>> flag or an address, both are (equally) bad.
>>>>
>>>>
>>>>
>>>> o A cleaner mechanism would be a “hello mechanism”, not necessarily as
>>>> NHDP, but a “when
>>>>
>>>> forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link is
>>>> estimated to be of a
>>>>
>>>> type which potentially can be unidirectional”. There is another benefit
>>>> to doing that, see the end
>>>>
>>>> of this email.
>>>>
>>>>
>>>>
>>>> Either way, I do not like the notion of fusing
>>>> metrics-and-link-bidirectionality-detection any more than I like fusing
>>>> global-topology-diffusion-and-link-bidirectionality-detection.
>>>>
>>>>
>>>>
>>>> The solution all this is, to me, threefold
>>>>
>>>>
>>>>
>>>> 1) Factor out the bidirectionally check in a (triggered) neighbour
>>>> detection mechanism
>>>>
>>>> (triggered HELLO message)
>>>>
>>>>
>>>>
>>>> 2) Remove the “validity time TLVs”, since they add complexity for no
>>>> perceivable benefits
>>>>
>>>>
>>>>
>>>> 3) Use the security model that we’ve discussed previously, where (only)
>>>> the metrics change per hop.
>>>>
>>>>
>>>>
>>>> Since we’re discussing bi-directionality of links here, and the
>>>> necessity of a mechanism for handling these, I want to call attention to a
>>>> related issue, as I hinted previously.
>>>>
>>>>
>>>>
>>>> The abstract states that the protocol:
>>>>
>>>>
>>>>
>>>>    ...is intended for use by mobile routers in wireless, multihop
>>>>
>>>>    networks.
>>>>
>>>>
>>>>
>>>> Section 5 paragraph 4  of the document, however, reads:
>>>>
>>>>
>>>>
>>>>    Assuming link metrics are symmetric, the cost of the routes installed
>>>>
>>>>    in the Local Route Set at each router will be correct.  While this
>>>>
>>>>    assumption is not always correct, calculating incoming/outgoing
>>>>
>>>>    metric data is outside of scope of this document.
>>>>
>>>>
>>>>
>>>> I do not know of *any* wireless systems, where the assumption that
>>>> “link metrics are symmetric” actually holds. Consequently, the conclusion
>>>> in the quoted paragraph:
>>>>
>>>>
>>>>
>>>>    calculating incoming/outgoing
>>>>
>>>>    metric data is outside of scope of this document.
>>>>
>>>>
>>>>
>>>> Is not an acceptable design choice.
>>>>
>>>>
>>>>
>>>> While this protocol may not want to “calculate if for this link the
>>>> metrics is 4 or 5”, the protocol must be able to convey and distinguish
>>>> that “the metric from A to B is 4, and the metric from B to A is 19”.
>>>>
>>>>
>>>>
>>>> This is a “related issue” since the solution may (as with the
>>>> bi-directionality check) be in the triggered neighbour detection mechanism:
>>>> that exchange could, if designed carefully, be used to probe for and convey
>>>> metrics information, also.
>>>>
>>>>
>>>>
>>>> Hope this helps,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <
>>>> [e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> Assuming for the moment that everyone will need an RREP-Ack or won’t
>>>> (let’s come back to that) why do C and B need to put an address in as an
>>>> RREQ-Ack request? Why not a flag, because the address will be included as
>>>> the IP sending address - and we know 5444 is required to pass that on.
>>>> (It’s used by NHDP as well.) Then we don’t need to change the RREP, it will
>>>> have a flag set or not, and won’t change (in this regard).
>>>>
>>>>
>>>>
>>>> Now let’s consider do we know whether we can set a fixed flag. First
>>>> I’d say there are two cases - you’ve got a firm control on what’s going on
>>>> in your network, or it’s one of unknown parties and behaviour (consistent
>>>> with specification). In the former case you only want one setting, for
>>>> example no-Ack if running NHDP or your MAC layer tells you about
>>>> bidirectionality, Ack otherwise. In the latter case, I think you just
>>>> always want an Ack. So both cases get you to the same place.
>>>>
>>>>
>>>>
>>>> Should that not be an acceptable argument (though I think it’s good for
>>>> where we are - in fact always Ack is close) then at flag is a step better,
>>>> it’s a fixed location to change. However it would be better in that case if
>>>> the two things to change (metric and ack flag) were together. But that has
>>>> its own issues, so I won’t go there.
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *__________________________________________________________________________
>>>> *
>>>> *T*:  [phone]  |  *E: *[e-mail]
>>>>
>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>> 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:* Victoria Mercieca [mailto:[e-mail]
>>>> <[e-mail]>]
>>>> *Sent:* 25 April 2016 14:15
>>>> *To:* Jiazi YI
>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>>> Networks mailing list
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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>.*
>>>>
>>>> Hi Jiazi,
>>>>
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <[e-mail]> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
>>>> [e-mail]> wrote:
>>>>
>>>> With regard to your validity time point, we here have a tradeoff. If
>>>> you allow that feature, it significantly impacts on the approach that was
>>>> coming together on as best you can end to end encryption.
>>>>
>>>>
>>>>
>>>> So the question is, is this a feature that’s really wanted?
>>>> Unfortunately I think we know that the answer to that is, we don’t know
>>>> because we don’t have any experience. My view would be that in the tradeoff
>>>> of an untested feature (unless I’m wrong about that) and the security
>>>> complication, security wins and drop the feature. If there is some real
>>>> requirement, then there’s a discussion. (Questions like how often the
>>>> intermediate routers actually have any knowledge - typically links break
>>>> for unexpected rather than expected reasons. Andan intermediate router
>>>> could possibly use a validity time to influence its behaviour.) Note that
>>>> dropping the ability of intermediate routers to modify/set still allows
>>>> validity times per route to be set at endpoints.
>>>>
>>>>
>>>>
>>>> I agree with Chris' concern.
>>>>
>>>> The ValidityTime is optional, which makes the integrity protection
>>>> hard. Furthermore, it gives a potential attack vector: as all the routers
>>>> in a path will take the shortest validityTime, a compromised router can set
>>>> the the validityTime to a very short value, which will make the route
>>>> installed along the path became invalid (very soon).
>>>>
>>>>
>>>>
>>>> On the other hand, I'm not sure this option will give us much help.
>>>> Chris mentioned much knowledge intermediate router would have to decide
>>>> this value (and how much sense the value would make).
>>>>
>>>> Another issue is, a route to a destination might be updated by
>>>> different sources. For example, in the network below:
>>>>
>>>>
>>>>
>>>> A----B-----C
>>>>
>>>>
>>>>
>>>> A first establish a route to B with long validity time. Then A
>>>> initiates a route discovery to C. C tends to set a short validity time,
>>>> which will make the route between B and A expire earlier than expected.
>>>>
>>>> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered
>>>> or not.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Not sure I follow here.
>>>>
>>>> Currently, the validity time of the route between A and B would not
>>>> affected by a short validity time of a route between A and C. Validity
>>>> times are per-route, and the route A-B and the route A-C are separate.
>>>>
>>>> If we switched to a validity time per neighbor (so that we can keep
>>>> validity time separate from route advertisements) as I mentioned in the
>>>> email below, then the validity of a route between A and C would be affected
>>>> if there was a short validity time between A and B. But, if B will only
>>>> route for a certain amount of time, then the route between A and C will of
>>>> course be affected. Is it best to know in advance that there's a time
>>>> limit, or just deal with RERRs when they happen?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> With regard to the acknowledgements, the problem (with regard to
>>>> security) comes from trying to do two jobs with the same message - end to
>>>> end route advertisement and hop by hop acknowledgement. I understand the
>>>> reasons - saving bytes and message types. (I would have to study the
>>>> protocol really hard to identify if any message types can be folded
>>>> together and recognised by content rather than type efficiently. This I do
>>>> not expect to do.) Again a tradeoff. This one is in discussion space,
>>>> though that needs people who understand both sides of the issue, including
>>>> the details of the bidirectionality mechanism. Of course, as has been said,
>>>> we need one of those.
>>>>
>>>>
>>>>
>>>> I haven't finished my review of the latest draft, and I don't get the
>>>> necessity of AckReq and the corresponding multicast RREP yet.
>>>>
>>>> If possible, this "optional" field should be avoided.
>>>>
>>>>
>>>>
>>>>
>>>> To give an overview of AckReq and RREP:
>>>>
>>>> Since AODVv2 requires bidirectional links, this is the way to determine
>>>> if a link is bidirectional.
>>>>
>>>> A----B----C
>>>>
>>>>
>>>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both
>>>> install a route to OrigAddr but they dont yet know if it's valid because
>>>> they dont know if the link to their next hop is available in the reverse
>>>> direction.
>>>>
>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>> bidirectional, it includes the AckReq (an address to indicate that it
>>>> expects to receive a RREP_Ack from B).
>>>>
>>>> 3) B receives the RREP, installs a route to TargAddr and marks it as
>>>> valid, since it knows the link to C is bidirectional, because the RREQ went
>>>> in one direction and the RREP came in the other. B also sends the RREP_Ack
>>>> to C and forwards the RREP to A (and might change the message to indicate
>>>> its own AckReq - ie that it requires an ack from A).
>>>>
>>>> 4) C receives the RREP_Ack from B, and therefore knows that B received
>>>> the RREP, therefore the link is bidirectional. C can then mark its route to
>>>> OrigAddr as valid.
>>>>
>>>> 5) Similarly, A receives the RREP, installs the route to TargAddr and
>>>> sends an RREP_Ack to B.
>>>>
>>>> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>>>>
>>>>
>>>>
>>>> Alternatively, in step 2, if C knows the link to B is bidirectional
>>>> (perhaps from some earlier route discovery), it doesnt need to put the
>>>> AckReq in the RREP. Then in step 3, since B doesnt know if the link to A is
>>>> bidirectional, it changes the message to add the AckReq address, in order
>>>> to get an RREP_Ack from A.
>>>>
>>>> If we want to avoid changing the message, we'll need to look at
>>>> forwarding the RREP as-is, and creating a second message to solicit an
>>>> RREP_Ack, in order to verify that the link is bidirectional before marking
>>>> the route to OrigAddr as valid.
>>>>
>>>> Kind regards,
>>>>
>>>> Victoria.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> regards
>>>>
>>>>
>>>>
>>>> Jiazi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *__________________________________________________________________________
>>>> *
>>>> *T*:  [phone] <%2B44%20%280%291245%20242194>  |  *E: *
>>>> [e-mail]
>>>>
>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>> 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:* Victoria Mercieca [mailto:[e-mail]]
>>>> *Sent:* 23 April 2016 10:55
>>>> *To:* Christopher Dearlove
>>>> *Cc:* [e-mail]; Dearlove, Christopher (UK); Mobile Ad
>>>> Hoc Networks mailing list
>>>>
>>>>
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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>.*
>>>>
>>>> Hi Chris,
>>>>
>>>>
>>>>
>>>> These have both been in the draft in some form since before I got
>>>> involved... but I'll do my best to explain.
>>>>
>>>>
>>>>
>>>> - For Validity Time, its a way to advertise that you would only support
>>>> the route contained in the message for a certain period of time. The
>>>> originator might use this, but the draft was written to allow any
>>>> intermediate node to be able to add it or update it too. The route created
>>>> in the Local Route Set has an expiration time associated with it, based on
>>>> the received validity time.
>>>>
>>>> - For the AckReq address, its so that you can add into a RREP a request
>>>> for an acknowledgement, so that you don't have to have a different message
>>>> type altogether for working out whether links to neighbors are
>>>> bidirectional, and also, since you only care about bidirectionality on
>>>> routes that are being set up, you dont need to constantly monitor all
>>>> neighbors.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In order to avoid the potential AckReq-related changes to each message,
>>>> maybe we do need to introduce a different message specifically for this. We
>>>> could maybe use RREP_Ack to both request and acknowledge? It means an extra
>>>> message of control traffic that needs to be sent, maybe one extra message
>>>> per hop on the path of a RREP, but it could still be limited to neighbors
>>>> which have participated in the route discovery rather than monitoring all
>>>> neighbors at all times.
>>>>
>>>>
>>>>
>>>> This message could maybe also include "I'm happy to route anywhere for
>>>> a certain amount of time", sort of like willingness in OLSR/OLSRv2. So
>>>> instead of having a validity time per route, its a validity time per
>>>> neighbor. Then, for RREQ and RREP, only the metric value would change in
>>>> transit, as discussed. However, that leads to some issues with deciding
>>>> what a route's expiration time is. You might know how long the next hop
>>>> router is valid for, but what if a router beyond that, which was also part
>>>> of the route, had a lower validity time? You couldn't determine the real
>>>> validity time. Do we remove the route expiration time altogether to avoid
>>>> this issue? In which case, we would have to rely on RERR messages being
>>>> sent for routes which become invalid when the neighbor's validity time has
>>>> expired? So neighbor validity time expiration is treated the same as a link
>>>> break.
>>>>
>>>>
>>>>
>>>> What do you think?
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Victoria.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
>>>> [e-mail]> wrote:
>>>>
>>>> Pretty much all of the discussion has been assuming only a metric value
>>>> change. With multiple things changing many of the ideas go out of the
>>>> window. That reinforces the point about not making specifications now that
>>>> might turn out to be wrong for ICVs.
>>>>
>>>>
>>>>
>>>> Ignoring how this misunderstanding happened, I'll start by asking why.
>>>> Metric changing I understand. Why the other two? (there's a partial
>>>> explanation of one). What alternatives have people implemented in
>>>> comparable protocols?
>>>>
>>>> --
>>>>
>>>> Christopher Dearlove
>>>>
>>>> [e-mail] (iPhone)
>>>>
>>>> [e-mail] (home)
>>>>
>>>>
>>>> On 23 Apr 2016, at 00:26, Victoria Mercieca <[e-mail]>
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> Continued in this thread because the other one seems to be more about
>>>> TLV types and metric type numbers, whereas this is about
>>>> regeneration/forwarding.
>>>>
>>>>
>>>>
>>>> To recap, in the current draft, there are 3 things that might change at
>>>> each hop:
>>>> - the metric value (happens in RREQ and RREP),
>>>> - adding/changing Validity Time using the Validity Time TLV (can happen
>>>> in RREQ and RREP),
>>>> - adding an address (and corresponding value in the AddressType TLV to
>>>> indicate how to interpret the address) to indicate the address from which
>>>> an RREP_Ack is expected, to accomplish the bidirectionality check (can
>>>> happen in RREP).
>>>>
>>>> If we define a certain portion of the message as immutable and include
>>>> the ICV to verify that part, end to end:
>>>> - The metric value would be excluded from the ICV since it needs
>>>> changing at each hop.
>>>> - Would adding a Validity Time TLV at an intermediate hop be
>>>> acceptable? The whole TLV could be removed in order to calculate the ICV?
>>>>
>>>> - Would adding an address cause issues for the ICV, because it's in the
>>>> address block? Could the rule be "if it contains an AckReq address, remove
>>>> it (and the corresponding value in the AddressType TLV), before checking
>>>> the ICV", is that OK? Or would we need to avoid touching the ICV'ed part of
>>>> the message altogether, maybe put the AckReq address in a separate Address
>>>> Block, with an extra AddressType TLV following that address block? Is there
>>>> a way to accomplish this?
>>>>
>>>>
>>>>
>>>> Also, to be thorough, do we need to consider RERR messages while we
>>>> discuss regeneration vs forwarding?
>>>>
>>>> - RERR (sent when a link breaks) is a way of saying "I've lost my route
>>>> so I'm telling others" and "you were my next hop, so now I've also lost my
>>>> route, I'll tell others", etc. It's going to be tailored at each step to
>>>> include the relevant routes that got deleted, it's not one message being
>>>> sent end-to-end like RREQ and RREP are.
>>>>
>>>> - However, RERR (sent when a source of traffic is sending data on a
>>>> route which comes through you, and you want to tell the Packet Source's
>>>> router to delete the route) could be seen as an end-to-end message which
>>>> all intermediate routers learn from, similar to RREQ and RREP. It reports
>>>> one route, and doesn't need changing at intermediate hops, so could be
>>>> protected with ICV.
>>>>
>>>> - Would it be OK to only require a message ICV if a PktSource address
>>>> was included, i.e. when the message needs to go via a number of
>>>> intermediate hops to PktSource's router? All other RERRs are intended to be
>>>> one-hop messages, which may in turn prompt other one-hop messages, etc...,
>>>> and a packet ICV might be more appropriate?
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Victoria.
>>>>
>>>>
>>>>
>>>> On Thu, Mar 17, 2016 at 5:26 PM, <[e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>>>> [e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> Yes, I meant AODVv2, thanks for the catch.
>>>>
>>>>
>>>>
>>>> So is your (Thomas) proposed base specification a hop count only metric?
>>>>
>>>>
>>>>
>>>> No, the would be silly as base specification, given that hop count
>>>> mostly is useless.
>>>>
>>>>
>>>>
>>>> As base specification I would simply say “Include a Metric Type Message
>>>> TLV with a value field, and a 7182 Message TLV & Timestamp” as we do in
>>>> OLSRv2 (with the appropriate verbiage as to generation and processing).
>>>>
>>>>
>>>>
>>>> With the message generated by the originator of the RREQ/RREP and *not*
>>>> deconstructed/reconstructed/reordered (as is the risk with “regeneration)
>>>> allows knowing that it would be *only* that metric field being modified
>>>> (other than hop count/limit) for when eventually writing up the extension.
>>>>
>>>>
>>>>
>>>> (Actually doesn’t the current specification only define hop count, or
>>>> has that changed in latest draft?)
>>>>
>>>>
>>>>
>>>> No. That is one of the issues I raise in my original. For some reason,
>>>> it cites RFC6551, which is a ROLL document and which has in its abstract
>>>> that:
>>>>
>>>>
>>>>
>>>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>>>
>>>>    compared with traditional wired and ad hoc networks that require the
>>>>
>>>>    specification of new routing metrics and constraints.
>>>>
>>>>
>>>>
>>>> I.e. this document cites a metric document which clearly claims to be
>>>> inapplicable in ad hoc networks. I note that this is another thing I’ve
>>>> raised for years without seeing it attempted resolved.
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *__________________________________________________________________________
>>>> *
>>>> *T*:  [phone] <%2B44%20%280%291245%20242194>  |  *E: *
>>>> [e-mail]
>>>>
>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>> 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:* [e-mail] [mailto:[e-mail]
>>>> <[e-mail]>]
>>>> *Sent:* 17 March 2016 17:10
>>>> *To:* Dearlove, Christopher (UK)
>>>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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>.*
>>>>
>>>>
>>>>
>>>> On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>>>> [e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> OK, so we have a message that mutates by:
>>>>
>>>> - Modifying hop count/limit.
>>>>
>>>> - Modifying a metric value.
>>>>
>>>> Anything else?
>>>>
>>>>
>>>>
>>>> As mutating (other than hop count/limit) messages aren’t covered by
>>>> 5444 or any derivative document (but only recommended against, not banned)
>>>> that you may need to make the message otherwise immutable (no
>>>> deconstruction and rebuilding, other than guaranteed unchanging) that would
>>>> have to be specified by AODVv2. (Easy to say, but needs saying.)
>>>>
>>>>
>>>>
>>>> With you so far.
>>>>
>>>>
>>>>
>>>> Then that information is not in a guaranteed fixed location given by a
>>>> simple offset. So any signature algorithm that finds it and ignores it or
>>>> aggregates on it is specific to OLSRv2.
>>>>
>>>>
>>>>
>>>> Surely you mean AODVv2
>>>>
>>>>
>>>>
>>>> So standard 7182 ICVs don’t do the job, you would need an AODVv2
>>>> specialised variant. Which is the sort of thing that the message specific
>>>> TLV space is there for, I’d be strongly against a “but ignore the value of
>>>> this specific TLV should it occur” being in the general space. However it
>>>> can easily be defined by reference to 7182 (“this TLV is like that TLV,
>>>> except if an X TLV is present, set its value field to zero”).
>>>>
>>>>
>>>>
>>>> Messy, but could work.
>>>>
>>>>
>>>>
>>>> Not that messy, actually, although clearly not as nice as “fixed
>>>> offset”.
>>>>
>>>>
>>>>
>>>> That said, I am arguing for the base spec being:
>>>>
>>>>
>>>>
>>>>             “make the message otherwise immutable (no deconstruction
>>>> and rebuilding, other
>>>>
>>>>              than guaranteed unchanging)” which is afforded by
>>>> forwarding
>>>>
>>>>
>>>>
>>>>                                     +
>>>>
>>>>
>>>>
>>>>             RFC7182 Timestamps and ICVs.
>>>>
>>>>
>>>>
>>>>                                     +
>>>>
>>>>
>>>>
>>>>             RFC7183 style text bringing it all together.
>>>>
>>>>
>>>>
>>>> The “aggregated signatures around mutable field” would very be an
>>>> experimental extension.
>>>>
>>>>
>>>>
>>>> What I object to is, if the base spec specifically renders such
>>>> extensions impossible
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *__________________________________________________________________________
>>>> *
>>>> *T*:  [phone] <%2B44%20%280%291245%20242194>  |  *E: *
>>>> [e-mail]
>>>>
>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>> 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:* Lotte Steenbrink [mailto:[e-mail]
>>>> <[e-mail]>]
>>>> *Sent:* 17 March 2016 16:48
>>>> *To:* Dearlove, Christopher (UK)
>>>> *Cc:* [e-mail]; Mobile Ad Hoc Networks mailing list
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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>.*
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>>>> [e-mail]>:
>>>>
>>>>
>>>>
>>>> Good point about whether you just pass on one cost or a set of costs.
>>>> As I said, not looked at details - I will, when time permits. One cost is
>>>> much easier, and yes, it reduces the fixed size aggregated signatures
>>>> problem to “just” one of computational load.
>>>>
>>>>
>>>>
>>>> For the record, Thomas’ understanding is correct; the cost is one
>>>> aggregated value.
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Lotte Steenrbink
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *__________________________________________________________________________
>>>> *
>>>> *T*:  [phone] <%2B44%20%280%291245%20242194>  |  *E: *
>>>> [e-mail]
>>>>
>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>> 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:* [e-mail] [mailto:[e-mail]
>>>> <[e-mail]>]
>>>> *Sent:* 17 March 2016 16:38
>>>> *To:* Dearlove, Christopher (UK)
>>>> *Cc:* Mobile Ad Hoc Networks mailing list
>>>> *Subject:* Re: Message integrity and message mutability (was RE:
>>>> [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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>.*
>>>>
>>>>
>>>>
>>>> On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>>>> [e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> I appreciate Thomas’s comments about the limitations of message
>>>> regeneration, but I would be a bit less absolute.
>>>>
>>>>
>>>>
>>>> The issues over end to end authentication and more advanced signatures
>>>> are valid. I need to read the given reference on aggregate signatures to
>>>> increase my knowledge (thanks for it), but my understanding of the
>>>> possibilities in this field may offer a solution to the problem, but with
>>>> some other issues (possibly including a new type of TLV).
>>>>
>>>>
>>>>
>>>> But the hop count/limit point I don’t fully agree with, you can
>>>> regenerate with an incremented/decremented count/limit, which leaves the
>>>> ability to prevent messages propagating indefinitely, including expanding
>>>> ring searches, and retains the ability to use RFC 5497 interval and
>>>> validity times that might be useful with an expanding ring search (or might
>>>> not).
>>>>
>>>>
>>>>
>>>> But the key issue is that AODVv2 wants to accumulate metrics. I still
>>>> haven’t got to the bottom of many details here, but let’s for the moment
>>>> just consider that conceptually.
>>>>
>>>>
>>>>
>>>> It’s hard to handle end to end. Charlie’s draft attempts to do an end
>>>> to end of some information, not this information. I’m not sure if that’s
>>>> useful (and the specialised format is better avoided if possible). Other
>>>> approaches are hop by hop (might as well use packet signatures) and shared
>>>> key (might as well go hop by hop). Pairwise signatures for each pair of
>>>> routers I’m discounting as scaling terribly. In the interests of
>>>> completeness let’s mention not accumulating metrics, which puts us back to
>>>> hop count and that’s not ideal either.
>>>>
>>>>
>>>>
>>>> I don’t think there is an ideal solution. (I like ideas I’ve seen about
>>>> aggregating, but that has some issues of its own, even apart from
>>>> computational load.) I’d love to be proved wrong - someone with the perfect
>>>> solution to come along.
>>>>
>>>>
>>>>
>>>> Which means that either we make an arbitrary choice - which will be
>>>> disagreed with, but needs discussing first - or create something flexible.
>>>> Unfortunately flexible in that regard constrains in others, e.g. some
>>>> (many? most?) aggregating signatures need fixed data sizes (which we can do
>>>> by defining a TLV that “fills up” with hop count, but that has a cost too).
>>>>
>>>>
>>>>
>>>> I have been told by people much more well versed in this than I in
>>>> cryptology, that the correct answer is “some”.
>>>>
>>>>
>>>>
>>>> That said, "AODVv2 wants to accumulate metrics” — does that mean that
>>>> the message grows as it is being forwarded, and that the recipient of a
>>>> RREQ/RREP will know the individual costs of each path segment? My
>>>> understanding is, that the recipient will get “the sum the costs of each
>>>> path segment” which should be fitting within a fixed size?
>>>>
>>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Sorry, no answers, just comments. And I’m not addressing Thomas’s later
>>>> points here.
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *__________________________________________________________________________
>>>> *
>>>> *T*:  [phone] <%2B44%20%280%291245%20242194>  |  *E: *
>>>> [e-mail]
>>>>
>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>>>> Baddow, Chelmsford, Essex CM2 8HN.
>>>> 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:[e-mail] <[e-mail]>] *On
>>>> Behalf Of *[e-mail]
>>>> *Sent:* 17 March 2016 16:00
>>>> *To:* Mobile Ad Hoc Networks mailing list
>>>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
>>>> ticket Items
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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
>>>> .
>>>>
>>>>
>>>>
>>>> Dear all,
>>>>
>>>>
>>>>
>>>> Apologies for not having gotten this done sooner - day-job leaving few
>>>> spare cycles.
>>>>
>>>>
>>>>
>>>> I’ve previously offered reviews and comments, and some of those have
>>>> been addressed in the latest I-D — others have not, but should be. I recall
>>>> that there was some mail attempting to rebut parts of the review, and I
>>>> will dig it out and reply to that.
>>>>
>>>>
>>>>
>>>> With that being said, I have reviewed the latest version of the
>>>> document, and full details will be forthcoming. There’re a couple of
>>>> big-ticket/architectural items that I want to address up front, as I
>>>> believe that before we have those hammered out, it will be useless to go
>>>> into details. Note, I do not claim that this is an exhaustive list of “big
>>>> ticket items”, but that’s as far as I have gotten in thinking this through.
>>>>
>>>>
>>>>
>>>> I also bring these up as they are items that have been brought up
>>>> repeatedly over the past years, but not resolved nor discussed.
>>>>
>>>>
>>>>
>>>> *Loops*
>>>>
>>>> Just to bring this out: I share Chris’ worry about conflicting and
>>>> concurrent statements from the authors on “There are no loops possible” and
>>>> “We need to fix two situations where loops can occur” and “we are still
>>>> investigating some loop conditions”
>>>>
>>>>
>>>>
>>>> I particularly worry that this is not a discussion had in public, but
>>>> apparently in some other forum…
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Intermediate Route Replies, and all of section 10*
>>>>
>>>> Section 10 contains a set of “vaguely specified extensions”, which is
>>>> incoherent with the intended status indicated for this document.
>>>>
>>>>
>>>>
>>>> Specifically, and this is not unrelated to the point about loops above,
>>>> intermediate RREPs (section 10.3) are a potential source for loops.
>>>>
>>>>
>>>>
>>>> Expanding Ring Multicast (section 10.1) is not documented in a way that
>>>> can be implemented (and also, see “Forwarding-vs-regeneration” below, it is
>>>> in the present form of this protocol impossible), etc.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Forwarding-vs-regeneration*
>>>>
>>>> Recent exchanges on the list made me understand that protocol control
>>>> messages are *not* forwarded, but are consumed at each hop, then a new
>>>> message with (almost-but-not-quite) the same content is generated and
>>>> transmitted.
>>>>
>>>>
>>>>
>>>> I have thought some more on this (& read some of the exchanges on the
>>>> list on this topic by Chris, Ulrich, and others), and I am convinced that
>>>> this is not the right way to go, *at least* for the following reasons:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             o          *It renders the hop-limit/hop-count fields in
>>>> the RFC5444 message header useless.*
>>>>
>>>>                         This would not be bad if the functionality
>>>> offered by those fields was not useful
>>>>
>>>>                         — sadly, it is. For example, for scope limited
>>>> flooding (expanding ring search, and
>>>>
>>>>                         such) which may be of interest, and which
>>>> require hop-limit.
>>>>
>>>>                         A hop-count field may also provide a “cheap”
>>>> (in terms of overhead) additional piece
>>>>
>>>>                         of information to use conjunctively with a
>>>> “real” metric.
>>>>
>>>>
>>>>
>>>>                         The only practical solution would be to
>>>> re-introduce these functions by way of inserting a
>>>>
>>>>                         MessageTLV — which (i) is not specified in this
>>>> document, and (ii) which would just
>>>>
>>>>                         serve to render messages bigger than strictly
>>>> needed.
>>>>
>>>>
>>>>
>>>>                         Scope limited flooding  does seem to be a
>>>> necessary requirement, if for no
>>>>
>>>>                         other reason than to prevent information from
>>>> “circulating forever in the network”.
>>>>
>>>>
>>>>
>>>>             o          *It makes end-to-end authentication
>>>> unnecessarily hard.*
>>>>
>>>>                         I think Chris called this out already, but it
>>>> bears repeating: S generates a message
>>>>
>>>>                         (say, a RREQ), and includes an ICV calculated
>>>> over the content of the message.
>>>>
>>>>                         For any recipient to be able to validate the
>>>> ICV, the message has to be exactly
>>>>
>>>>                         the same — not just in content, but in
>>>> structure — as what was generated.
>>>>
>>>>
>>>>
>>>>                         “Regenerating” rather than “forwarding”
>>>> messages means, that the intermediate
>>>>
>>>>                         router “regenerating” the RREQ may chose a
>>>> different structure (e.g., include TLVs
>>>>
>>>>                         in a different order).
>>>>
>>>>
>>>>
>>>>                         The proposal from
>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>>>
>>>>                         is to add constraints on (i) the set of
>>>> elements to include in a signature and (ii) the
>>>>
>>>>                         order of these elements.
>>>>
>>>>
>>>>
>>>>                         One problem with that approach is (i): if an
>>>> extension adds a message TLV, or an
>>>>
>>>>                         Address TLV, to a message, then that will not
>>>> be “covered” by the proposed e2esec TLV.
>>>>
>>>>                         Rather for *each* extension developed, an
>>>> “updates e2esec” clause needs to be done.
>>>>
>>>>
>>>>
>>>>                         I’d say that this approach would be prone to
>>>> errors — and add entropy to the process
>>>>
>>>>                         of designing protocol extensions. The
>>>> alternative, a message being generated by the
>>>>
>>>>                         source and *forwarded* (as we do in OLSRv2, for
>>>> example) would allow ICV TLVs
>>>>
>>>>                         (even, allow reuse of those specified for
>>>> OLSRv2) for covering a message and
>>>>
>>>>                         extensions.
>>>>
>>>>
>>>>
>>>>                         “But what about the metrics value which will
>>>> change on each hop”, you may say?
>>>>
>>>>                         Fortunately, that is relatively easy to handle:
>>>> simply zero out the value of that TLV when
>>>>
>>>>                         generating or verifying the ICV MessageTLV. And
>>>> use Packet-TLVs for hop-by-hop
>>>>
>>>>                         authentication, if needed (but, see below).
>>>>
>>>>
>>>>
>>>>             o          *It prevents the use of more clever/advanced
>>>> signature schemes/ICVs*
>>>>
>>>>                         Aggregate signature algorithms (
>>>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>>>
>>>>                         exist, and an interesting use-case can be found
>>>> in also reactive protocols, allowing verifying
>>>>
>>>>                         not “just” the end points, but also the
>>>> intermediaries (again, with the appropriate “zero out”
>>>>
>>>>                         discussed above, or something smarter).
>>>>
>>>>                         Regeneration of messages, rather than
>>>> forwarding, renders that impossible (or, if used,
>>>>
>>>>                         updating to
>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>>>
>>>>
>>>>
>>>> There are other reasons, but the above are those that jump at me as
>>>> immediate show-stoppers.
>>>>
>>>>
>>>>
>>>> I do honestly not see what possible benefit there is from
>>>> “regeneration” — but I see very clear inconveniences, and security is not
>>>> the least of these. Insisting on “regeneration” requires development of
>>>> “non-general workarounds” as pointed out above.
>>>>
>>>>
>>>>
>>>> *Security Considerations*
>>>>
>>>> This is an always thorny subject. When OLSRv2 was going through the
>>>> process we got a thorough education in how little we knew about security
>>>> from the SEC-ADs, and had to spend about a year or so developing RFC7183.
>>>> The bottom line is, that this protocol needs its “RFC7183  equivalent”,
>>>> either as part of the main document, or as an independent document.
>>>> currently, that is not the case.
>>>>
>>>>
>>>>
>>>> A minima, looking at BCP72 and BCP107 — taking inspiration from RFC7183
>>>> might be aw good idea, as that was the most recent that went through the
>>>> SEC AD. Regardless of how, however, a “mandatory to implement” security
>>>> mechanism most be specified (I think the right term was “MUST implement,
>>>> SHOULD use”), in sufficient detail to ensure interoperable implementations.
>>>>
>>>>
>>>>
>>>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>>>
>>>>
>>>>
>>>>       On receiving a ... message, a router MUST first check if the
>>>>
>>>>       message is invalid for processing by this router
>>>>
>>>>
>>>>
>>>> and then proceed to give a number of conditions that, each, will lead
>>>> to a rejection of the message as "badly formed and therefore invalid for
>>>> processing” — a list which RFC7183 then amended. That gave a “hook” for
>>>> RFC7183 for inserting “rejection”. Idem for message generation.
>>>>
>>>>
>>>>
>>>> If I was to do RFC7181/RFC6130 today, I would include that directly
>>>> into the protocol specifications. It turned out to be more overhead (and
>>>> slow down publication anyways) to do it as separate documents.
>>>>
>>>>
>>>>
>>>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>>>> Timestamps, etc. are added/removed, and what that brings.
>>>>
>>>>
>>>>
>>>> For example (with the assumption that messages are *forwarded* and
>>>> *not* regenerated), this could be one option:
>>>>
>>>>
>>>>
>>>>                         o          When a RREQ, RREP message is
>>>> generated, add an ICV Message TLV, which is calculated <this way>
>>>>
>>>>                                      …(take inspiration from RFC7183
>>>> here)
>>>>
>>>>
>>>>
>>>> ...
>>>>
>>>> [Message clipped]
>>>> _______________________________________________
>>>> manet mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> [e-mail]
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>